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
Rumbaugh distinguishes two kinds of design: System design and Object design. System design, the topic of this and the next lecture is concerned with the overall aspects of the system. What are the goals it tries to achieve. The main goals are: Low cost, good response time, high reliability. Types (Often listed under Global requirements in Problem Statement). Trade-off priorities
System design is also concerned about the overall structure of the system. How is it broken into pieces? How do these pieces fit together? Must they know about each other? The best system design is one where the interaction between the subsystems is minimal.
Concurrency is another important design issue. The more concurrency we can identify in a system, the better it can perform.
Mapping the subsystem to processors is the moment of truth, and the hardest. While decomposition and concurrency identification are still independent of technology, subsystem allocation is not. Shall we map them to hardware or can we get by with software (Example: Floating point package).
The management of data is also a design issue.
Access methods specify the security of the design. Can a random user or a program gone hay-wire create havoc to the rest of the system?
Control is another important design issue. Who is in control? A main program or a set of harmoniously cooperating processes?
Boundary conditions specify the non-steady state behavior of the system. Usually the designer worries about the steady state (average number of transactions/sec). However, initialization and termination behavior, in particular failure conditions are important design issues. How does the system behave when an error occurs? Does it simply type "Illegal address at PC 0. Abort!" (Famous last words on a screen cockpit filmed by a video camera before the plane, an F-15 fighter, crashed).
For the FRIEND system, database design issues are very important. We will discuss several design goals that are very important for the design of distributed databases
Chapter 7

3. System Design Activities
1. Design Goals
Defi
nition T
rade-of fs
8. Boundary
Conditions
Initialization T
ermination
2. System
Failure
1. Design goals
2. System decomposition
Breaking the system into subsystems, Layers and partitions, System information flow (topology)
3. Identification of concurrency
Threads of control
4. Hardware/software allocation
Estimate hardware requirements, Hardware/software trade-offs, Describe processor allocation, Physical connectivity (existing hardware)
5. Data management
Data structures implemented in memory or secondary storage
6. Global resource handling
Choose access control
7. Software control implementation
Procedure-based, event-based, concurrent systems
8. Boundary conditions
Describe behavior at initialization, termination and failure
9. Feasibility
Discuss design alternatives, Technological constraints that drive the design, What if the constraints change?
Decomposition
Layers/Partitions
Cohesion/Coupling
7. Software
Control
Monolithic
Event-Driven
Threads
Conc. Processes
3. Concurrency
Identification of
Threads
4. Hardware/
6. Global
5. Data
Softwar e
Resource Handling
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 Reliability Modifiability Maintainability
Understandability
Adaptability
Reusability
Efficiency
Portability
Traceability of requirements
Fault tolerance
Backward-compatibility
Cost-effectiveness
Robustness
High-performance
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

6. Relationship Between Design Goals
End User
Functionality
User-friendliness
Ease of Use
Ease of learning
Fault tolerant
Robustness
Low cost
Increased Productivity
Backward-Compatibility
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
Developer/
Maintainer

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.
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: Questions:
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
Reducing coupling may introduce unnecessary layers – middle classes (overhead + development time)
Trade off between cohesion and coupling. Can often increase cohesion by further decomposing the subsystem into smaller subsystem. This increase coupling as the number of interfaces increases. Too much fragmentation (too many subsystems) may not be good. Remember 7+-2 principle.
Subsystem Decomposition Heuristics:
No more than 7+/-2 subsystems
More subsystems increase cohesion but also complexity (more services)
No more than 4+/-2 layers, use 3 layers (good)

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
Application
Presentation
Session
Transport
Network
DataLink
Physical
Socket
TCP/IP
Object
Ethernet
Wire

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)
Subsystem
Repository
createData()
setData()
getData()
searchData()

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
Controller
Model
subscriber
notifier
initiator *
repository 1
View

23. MVC Example: File System
Consider changing the file name

24. Sequence of Events (Collaborations)
2.User types new filename
:Controller
3. Request name change in model
: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
Presentation
Application Logic
Data Management

30. Thin and fat clients Thin-client model Fat-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.
Client
Server
Data Management
Application Logic
Presentation
Thin Client
Client
Server
Data Management
Presentation
Application Logic
Fat Client

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.
Client
Server
Application Logic
Presentation
Three-Tier
Data Management

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
Peer
Client
Server

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
Rumbaugh distinguishes two kinds of design: System design and Object design. System design, the topic of this and the next lecture is concerned with the overall aspects of the system. What are the goals it tries to achieve. The main goals are: Low cost, good response time, high reliability. Types (Often listed under Global requirements in Problem Statement). Trade-off priorities
System design is also concerned about the overall structure of the system. How is it broken into pieces? How do these pieces fit together? Must they know about each other? The best system design is one where the interaction between the subsystems is minimal.
Concurrency is another important design issue. The more concurrency we can identify in a system, the better it can perform.
Mapping the subsystem to processors is the moment of truth, and the hardest. While decomposotion and concurrency identification are still independent of technology, subsystem allocation is not. Shall we map them to hardware or can we get by with software (Example: Floating point package).
The management of data is also a design issue. The FRIEN database group is an example: Most of its problems are design specific.
Access methods specify the security of the design. Can a random user or a program gone hay-wire create havoc to the rest of the system?
Control is another important design issue. Who is in control? A main program or a set of harmoniously cooperating processes?
Boundary conditions specify the non-steady state behavior of the system. Usually the designer worries about the steady state (average number of transactions/sec). However, initialization and termination behavior, in particular failure conditions are important design issues. How does the system behave when an error occurs? Does it simply type "Illegal address at PC 0. Abort!" (Famous last words on a screen cockpit filmed by a video camera before the plane, an F-15 fighter, crashed).
For the FRIEND system, database design issues are very important. We will discuss several design goals that are very important for the design of distributed databases
Chapter 7