Ch 6: Sys. Architecture Design: System Decomposition

1
Ch 6 Sys. Architecture Design System
Decomposition

• Qutaibah Malluhi
• Software Engineering
• Qatar University

Based on slides by Bernd Bruegge Allen H.
Dutoit
2
System Architecture Design

• Analysis Focuses on the application domain
• Design Focuses on the solution domain
• Define design goals
• Decompose into subsystems
• Subsystems are realized by individual teams
• Design decisions on building strategies
• Hardware/software mapping
• Concurrency
• Persistent data management
• Global control flow
• Access control
• Boundary conditions

Chapter 6
Chapter 7
3
System Design Activities
System Design
Failure
2. System
Decomposition
Layers/Partitions Cohesion/Coupling
7. Software Control
Monolithic Event-Driven Threads Conc. Processes
3. Concurrency
6. Global

4. Hardware/
Identification of Threads
5. Data
Resource Handling
Softwar
e

Management
Mapping
Access control Security
Persistent Objects
Special purpose
Files
Buy or Build Trade-off
Databases
Allocation
Data structure
Connectivity
4
System Arch. Design Overview
nonfunctional
requirements
Analysis
dynamic model
analysis object
model
From nonfunctional requirements
System design
design goals

• Includes
• Subsystems and their dependencies
• Design strategies
• Boundary use cases

subsystem
decomposition
Object design
object design
model
5
List of Design Goals

• Good documentation
• Well-defined interfaces
• User-friendliness
• Reuse of components
• Rapid development
• Minimum of errors
• Readability
• Ease of learning
• Ease of remembering
• Ease of use
• Increased productivity
• Low-cost
• Flexibility

• Reliability
• Modifiability
• Maintainability
• Understandability
• Adaptability
• Reusability
• Efficiency
• Portability
• Traceability of requirements
• Fault tolerance
• Backward-compatibility
• Cost-effectiveness
• Robustness
• High-performance

6
Relationship Between Design Goals
End User
Functionality User-friendliness Ease of Use Ease
of learning Fault tolerant Robustness
Low cost Increased Productivity Backward-Compatib
ility Traceability of requirements Rapid
development Flexibility
Runtime Efficiency
Reliability
Portability Good Documentation
Client
(Customer,
Sponsor)
Minimum of errors Modifiability,
Readability Reusability, Adaptability Well-defined
interfaces
7
Typical Design Trade-offs

• Cost vs. Fault Tolerance
• Efficiency vs. Portability
• Rapid development vs. Functionality
• Functionality vs. Usability
• Cost vs. Reusability
• Backward Compatibility vs. Readability

8
2. System Decomposition

• Decompose into Subsystems.
• Subsystem
• Simpler part of the system
• Can be handled by a single developer or
  development team
• Modeled as UML packages
• Some languages have subsystem modeling constructs
• Java packages
• In other languages (e.g. C C) subsystems are
  represented as directories with all related files
• Define on services provided by each subsystem
• Specified by the subsystem interface
• Define relationships among subsystems

9
Services and Subsystem Interfaces

• (Subsystem) Service
• Group of operations provided by the subsystem
• A set of related operations that share a common
  purpose
• Service is specified by subsystem interface
• Set of fully typed related operations
• Specifies interaction at subsystem boundaries
  (not inside the subsystem)
• Should be well-defined and small.
• Also called API Application Programming
  Interface
• The term API is often used during implementation,
  not during system design

10
Choosing Subsystems

• Criteria for subsystem selection
• Most of the interaction should be within
  subsystems, rather than across subsystem
  boundaries (high cohesion low coupling)
• Questions
• What kind of service is provided by the
  subsystems (subsystem interface)?
• What kind of model describes the relationships
  among subsystems (layers and partitions)?

11
Coupling and Cohesion

• Goal Reduction of complexity while change occurs
• Cohesion measures the dependence within a
  subsystem
• High cohesion The classes in the subsystem
  perform similar tasks and are related to each
  other (via associations)
• Low cohesion Lots of miscellaneous and auxiliary
  classes, no associations
• Coupling measures dependencies between subsystems
• High/tight coupling Changes to one subsystem
  will have high impact on other subsystems (change
  of model, massive recompilation, etc.)
• Low coupling A change in one subsystem does not
  affect other subsystems
• Subsystems should have maximum cohesion and
  minimum coupling as possible

12
Partitions and Layers

• Partitioning and layering are techniques to
  achieve low coupling.
• A large system is usually decomposed into
  subsystems using both, layers and partitions.
• Partitions vertically divide a system into
  several independent (or weakly-coupled)
  subsystems that provide services on the same
  level of abstraction.
• A layer is a subsystem that provides subsystem
  services to a higher layers (level of
  abstraction)
• A layer can only depend on lower layers
• A layer has no knowledge of higher layers

13
Relationships between Subsystems

• Layer relationship
• Layer A Calls Layer B (runtime)
• Layer A Depends on Layer B (make dependency,
  compile time)
• Partition relationship
• The subsystem have mutual but not deep knowledge
  about each other
• Partition A Calls partition B and partition B
  Calls partition A

14
Software Architectural Styles

• Subsystem decomposition
• Identification of subsystems, their services, and
  their relationship to each other.
• System may conform to a generic architectural
  model or style. Examples
• Abstract machine (or layered)
• Repository (shared data)
• Client/Server
• Thin client, thick client, multi-tier
• Peer-To-Peer
• Model/View/Controller
• Pipes and Filters
• Service-oriented architecture

15
Layered (Abstract Machine) Style

• Layered systems are hierarchical Organised into
  a set of layers (or abstract machines) each of
  which provide a set of services.
• A layer can only depend on lower layers
• Closed layering only depend on layer immediately
  below
• Reduce complexity (by low coupling)
• When a layer interface changes, only the adjacent
  layer is affected
• Less efficient speed and storage overhead of
  each layer in the path
• If a subsystem is a layer, it is often called a
  virtual machine.
• Supports the incremental development of
  sub-systems in different layers. When a layer
  interface changes, only the adjacent layer is
  affected

16
OSI and TCP/IP Layered Models
17
OSI model Layers Responsibilities

• The Physical layer represents the hardware
  interface to the net-work. It allows to send()
  and receive bits over a channel.
• The Datalink layer allows to send and receive
  frames without error using the services from the
  Physical layer.
• The Network layer is responsible for that the
  data are reliably transmitted and routed within a
  network.
• The Transport layer is responsible for reliably
  transmitting from end to end. (This is the
  interface seen by Unix programmers when
  transmitting over TCP/IP sockets)
• The Session layer is responsible for initializing
  a connection, including authentication.
• The Presentation layer performs data
  transformation services, such as byte swapping
  and encryption
• The Application layer is the system you are
  designing (unless you build a protocol stack).
  The application layer is often layered itself.

18
Repository Architecture Style (I)

• Sub-systems must exchange data. This may be done
  in two ways
• Shared data is held in a central data structure
  or repository and may be accessed by all
  sub-systems
• Each sub-system maintains its own data structure
  and passes data explicitly to other sub-systems.
• When large amounts of data are to be shared, the
  repository model of sharing is most commonly used.

19
Repository Architectural Style (II)

• Subsystems access and modify data from a single
  data structure
• Subsystems are loosely coupled (interact only
  through the repository)
• Control flow is dictated by central repository
  (triggers) or by the subsystems (locks,
  synchronization primitives)

20
Repository Style Characteristics

• Advantages
• Efficient way to share large amounts of data
• Easy to deal with concurrent access and data
  integrity among different subsystems
• Centralised data management e.g. backup,
  security, etc.
• Disadvantages
• Central repository can become the performance
  bottleneck
• Tight coupling between subsystems and repository
• Modifiability limitations
• Sub-systems depend on the repository data model
• Data evolution is difficult and expensive
• No scope for subsystem-specific (rather than
  global) management policies

21
Examples of Repository Architectures

• Database Applications
• Modern Compilers and IDEs
• Case Tools

22
Model/View/Controller Arch. Style

• Subsystems are classified into 3 different types
• Model subsystem Maintains application domain
  knowledge
• View subsystem Display application domain
  objects to the user
• Controller subsystem Responsible for sequence
  of interactions with the user and notifying views
  of changes in the model.
• Model is independent of View and Controller
• Propagate model changes through subscribe/notify
  protocol
• MVC is a special case of a repository
  architecture
• Model subsystem implements the central
  datastructure, the Controller subsystem
  explicitly dictate the control flow

23
MVC Example File System
Consider changing the file name
24
Sequence of Events (Collaborations)
2.User types new filename
3. Request name change in model
Controller
Model
1. View subscribes to event
5. Updated views
4. Notify subscribers
InfoView
FolderView
1. View subscribes to event
25
MVC Advantages

• Easy to modify user interfaces
• User interfaces changes more often than model
• User interface is independent from the model
• Good for systems with multiple views of the same
  model
• Similar to advantages and disadvantages of
  repository (model is the repository)

26
Client/Server Architectural Style

• One or many servers provides services to
  instances of subsystems, called clients.
• Client calls on the server, which performs some
  service and returns the result
• Client knows the interface of the server (its
  service)
• Server does not need to know the interface of the
  client
• Response in general immediately
• Users interact only with the client

27
Client/Server Application Examples

• Network applications
• FTP
• WWW
• Chat
• Database applications
• Front-end User application (client)
• User input through customized user interface
• Front-end processing of data
• Initiation of transactions
• Typically access to database server across the
  network
• Back end Database access and manipulation
  (server)
• Centralized data management
• Data integrity and database consistency
• Database security
• Concurrent operations (multiple user access)
• Centralized management (for example archiving)

28
Client/Server Substyles

• Thin client
• Fat client
• Multi-tier
• Distinction is based on distribution of
  application functionality described in the
  Layered Application Architecture (see next slides)

29
Layered Application Architecture

• Presentation layer
• Present results of a computation to system users
  and collect user inputs
• Application logic layer
• Business rules, processes and application-specific
  functions. E.g., in a banking system, banking
  functions such as open account, close account,
  etc.
• Data management layer
• Concerned with managing the system databases

30
Thin and fat clients

• Thin-client model
• Application processing (business logic) and data
  management is carried out on the server. The
  client is simply responsible for running the
  presentation software.
• Fat-client model
• The server is only responsible for data
  management. The software on the client implements
  the business logic and the interactions with the
  system user.

31
Thin client model

• Used when legacy systems are migrated to client
  server architectures.
• The legacy system acts as a server in its own
  right with a graphical interface implemented on a
  client.
• The small-size thin client software can be
  downloaded on-the-fly before running
• E.g. Web-based clients
• A major disadvantage is that it places a heavy
  processing load on both the server and the
  network.

32
Fat client model

• More processing is delegated to the client as the
  application processing is locally executed.
• Most suitable for new C/S systems where the
  capabilities of the client system are known in
  advance.
• More complex than a thin client model especially
  for management. New versions of the application
  have to be installed on all clients.

33
Three-tier architectures

• In a three-tier architecture, each of the
  application architecture layers may execute on a
  separate processor.
• Allows for better performance than a thin-client
  approach and is simpler to manage than a
  fat-client approach.
• A more scalable architecture - as demands
  increase, extra servers can be added.

34
3-Tier Example Internet banking system

35
Use of C/S architectures
36
Peer-to-Peer Architectural Style

• Generalization of Client/Server Architecture
• Clients can be servers and servers can be clients
• More difficult because of possibility of deadlocks

37
Summary

• Analysis Focuses on the application domain
• Design Focuses on the solution domain
• Define design goals
• Decompose into subsystems
• Subsystems are realized by individual teams
• Design decisions on building strategies
• Hardware/software mapping
• Concurrency
• Persistent data management
• Global control flow
• Access control
• Boundary conditions

Chapter 6
Chapter 7