1. System Design

2. Why is Design so Difficult?
Analysis: Focuses on the application domain
Design: Focuses on the solution domain
Design knowledge is a moving target
The reasons for design decisions are changing very rapidly
Halftime knowledge in software engineering: About 3-5 years
What I teach today will be out of date in 3 years
Cost of hardware rapidly sinking
“Design window”:
Time in which design decisions have to be made
Technique
Time-boxed prototyping

3. The Purpose of System Design
Problem
Bridging the gap between desired and existing system in a manageable way
Use Divide and Conquer
We model the new system to be developed as a set of subsystems
New
System
Existing System

4. Overview System Design I (Chapter 6)
0. Overview of System Design
1. Design Goals
2. Subsystem Decomposition
System Design II: Addressing Design Goals (Chapter 7)
3. Concurrency
4. Hardware/Software Mapping
5. Persistent Data Management
6. Global Resource Handling and Access Control
7. Software Control
8. Boundary Conditions
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

5. How to use the results from the Requirements Analysis for System Design
Nonfunctional requirements =>
Activity 1: Design Goals Definition
Functional model =>
Activity 2: System decomposition (Selection of subsystems based on functional requirements, cohesion, and coupling)
Object model =>
Activity 4: Hardware/software mapping
Activity 5: Persistent data management
Dynamic model =>
Activity 3: Concurrency
Activity 6: Global resource handling
Activity 7: Software control
Subsystem Decomposition
Activity 8: Boundary conditions
In Requirements analysis we have beautifully built 3 descriptions of the problem, the models. Where do the models go in system design?
If you read Rumbaugh, the above list of system design issues looks a little bit random. But there is a reason behind it:

6. Identifying Design Goals
Prioritize criteria
Performance
Response time, throughput, memory
Dependability
Robustness, reliability, availability, fault tolerance, security, safety
Cost
Cost of development, deployment, upgrading, maintenance, administration
Maintenance
Extensibility, modifiability, adaptability, portability, readability, traceability of requirements
End user
Utility, usability
Tradeoffs are decided at this point

7. Typical Design Trade-offs
Functionality vs. Usability
Cost vs. Robustness
Efficiency vs. Portability
Rapid development vs. Functionality
Cost vs. Reusability
Backward Compatibility vs. Readability

8. Nonfunctional Requirements may give a clue for the use of Design Patterns
Read the problem statement again
Use textual clues (similar to Abbot’s technique in Analysis) to identify design patterns
Text: “manufacturer independent”, “device independent”, “must support a family of products”
Abstract Factory Pattern
Text: “must interface with an existing object”
Adapter Pattern
Text: “must deal with the interface to several systems, some of them to be developed in the future”, “ an early prototype must be demonstrated”
Bridge Pattern

9. Textual Clues in Nonfunctional Requirements
Text: “complex structure”, “must have variable depth and width”
Composite Pattern
Text: “must interface to an set of existing objects”
Façade Pattern
Text: “must be location transparent”
Proxy Pattern
Text: “must be extensible”, “must be scalable”
Observer Pattern
Text: “must provide a policy independent from the mechanism”
Strategy Pattern

10. System Design Concepts
Subsystems and services
Services and subsystem interfaces
Coupling and cohesion
Layers and partitions
Architectural styles

11. Subsystems and Services
Subsystem (UML: Package)
Collection of classes, associations, operations, events and constraints that are interrelated
Seed for subsystems: UML Objects and Classes.
(Subsystem) Service:
Group of operations provided by the subsystem
Seed for services: Subsystem use cases
Service is specified by Subsystem interface:
Specifies interaction and information flow from/to subsystem boundaries, but not inside the subsystem.
Should be well-defined and small.
Often called API: Application programmer’s interface, but this term should used during implementation, not during System Design
Relation of subsystems to each other is similar to object model
System topology is similar functional model!

12. Services and Subsystem Interfaces
Service: A set of related operations that share a common purpose
Notification subsystem service:
LookupChannel()
SubscribeToChannel()
SendNotice()
UnscubscribeFromChannel()
Services are defined in System Design
Subsystem Interface: Set of fully typed related operations.
Subsystem Interfaces are defined in Object Design
Also called application programmer interface (API)

13. Identifying Subsystems
Heuristics
Assign objects identified in one use case into the same subsystem
Create a dedicated subsystem for objects used for moving data among subsystems
Minimize the number of associations crossing subsystem boundaries
All objects in the same subsystem should be functionally related

14. Coupling and Cohesion
Goal: Reduction of complexity while change occurs
Cohesion measures the dependence among classes
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 coupling: Changes to one subsystem will have high impact on the other subsystem (change of model, massive recompilation, etc.)
Low coupling: A change in one subsystem does not affect any other subsystem
Subsystems should have as maximum cohesion and minimum coupling as possible:
How can we achieve high cohesion?
How can we achieve loose coupling?

15. Example of reducing the coupling of subsystems.
Alternative 1: Direct access to the Database subsystem
ResourceManagement
IncidentManagement
MapManagement
Database

16. Example of reducing the coupling of subsystems (continued)
Alternative 2: Indirect access to the Database through a Storage subsystem
ResourceManagement
IncidentManagement
MapManagement
Storage
Database

17. Choosing Subsystems
Criteria for subsystem selection: Most of the interaction should be within subsystems, rather than across subsystem boundaries (High cohesion).
Does one subsystem always call the other for the service?
Which of the subsystems call each other for service?
Primary Question:
What kind of service is provided by the subsystems (subsystem interface)?
Secondary Question:
Can the subsystems be hierarchically ordered (layers)?
What kind of model is good for describing layers and partitions?

18. 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
In an object-oriented design such as JEWEL, each subsystem makes its layer a subclass of the generic layer class provided by the UI subsystem. Each individual subsystem must provide for its own zoom and refresh methods. Ideally the refresh method will be called for every draw operation. The UI subsystem is responsible for knowing when to call for a refresh (but the UI group will not have to implement it itself: it is a callback method implemented by the visualization and GIS group). All the interfaces with UI (such as how UI will provide the other groups with selection information) should be well documented and agreed on by all groups.

19. 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

20. Closed Architecture (Opaque Layering)
VM4
VM3
VM2
VM1 C1
attr op
Any layer can only invoke operations from the immediate layer below
Design goal: High maintainability, flexibility

21. Open Architecture (Transparent Layering)
Any layer can invoke operations from any layers below
Design goal: Runtime efficiency C1
attr op C1
attr op C1
attr op
VM1 C1
attr op C1
attr op
VM2 C1
attr op C1
attr op
VM3 C1
attr op C1
attr op
VM4

22. Properties of Layered Systems
Layered systems are hierarchical. They are desirable because hierarchy reduces complexity (by low coupling).
Closed architectures are more portable.
Open architectures are more efficient.
If a subsystem is a layer, it is often called a virtual machine.
Layered systems often have a chicken-and egg problem
Example: Debugger opening the symbol table when the file system needs to be debugged

23. Example of a Layered System
ISO’s OSI Reference Model
ISO = International Standard Organization
OSI = Open System Interconnection
Reference model defines 7 layers of network protocols and strict methods of communication between the layers.
Closed software architecture
Application
Presentation
Session
Level of abstraction
Transport
Network
DataLink
Physical

24. OSI model Packages and their Responsibility
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.

25. Another View at the ISO Model
A closed software architecture
Each layer is a UML package containing a set of objects
An example of a closed architecture is the Reference Model of Open Systems Interconnection (in short, the OSI model) is composed of seven layers [Tanenbaum, 1996]. Each layer is responsible for performing a well defined function. In addition, each layer provides its services by using services by the layer below. The Physical layer represents the hardware interface to the network. It is responsible for transmitting bits over a communication channels. The DataLink layer is responsible for transmitting data frames without error using the services of the Physical layer. The Network layer is responsible for transmitting and routing packets within a network. The Transport layer is responsible for ensuring that the data is reliably transmitted from end to end. The Transport layer is the interface Unix programmers see when transmitting information over TCP/IP sockets between two processes. The Session layer is responsible for the initialization of a connection, including authentication. The Presentation layer performs data transformation services, such as byte swapping or encryption. The Application layer is the system you are designing (unless you are building an operating system or protocol stack). The application layer can and should, of course, also consist of layered subsystems.
An example of closed architecture: the OSI model (UML class diagram). The OSI model decomposes network services into seven layers, each responsible for a different level of abstraction.

26. Middleware Allows Focus On The Application Layer
Presentation
Session
Transport
Network
DataLink
Physical
Socket
CORBA
TCP/IP
Object
Ethernet
Wire

27. An example of open architecture: Java Swing
Xlib
AWT
Swing
Application

28. Software Architecture
Subsystem decomposition
Identification of subsystems, services, and their relationship to each other.
Specification of the system decomposition is critical.
Software architecture
Defines the system in terms of subsystems and interactions among those subsystems
Shows correspondence between requirements and elements of the constructed system
Addresses system-level non-functional requirements

29. Software Architectural Styles
How subsystems and their interactions are organized in order to meet certain design goals while delivering the required services
Some styles
Repository
Client/Server
Peer-To-Peer
Model/View/Controller
Pipes and Filters

30. Repository Architectural Style
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()

31. Examples of Repository Architectural Style
Compiler
SemanticAnalyzer
SyntacticAnalyzer
Optimizer
CodeGenerator
LexicalAnalyzer
Repository
Database Management Systems
Modern Compilers
ParseTree
SymbolTable
SourceLevelDebugger
SyntacticEditor

32. 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

33. Client/Server Architectural Style
Often used in database systems:
Front-end: User application (client)
Back end: Database access and manipulation (server)
Functions performed by client:
Customized user interface
Front-end processing of data
Initiation of server remote procedure calls
Access to database server across the network
Functions performed by the database server:
Centralized data management
Data integrity and database consistency
Database security
Concurrent operations (multiple user access)
Centralized processing (for example archiving)

34. Design Goals for Client/Server Systems
Service Portability
Server can be installed on a variety of machines and operating systems and functions in a variety of networking environments
Transparency, Location-Transparency
The server might itself be distributed (why?), but should provide a single "logical" service to the user
Performance
Client should be customized for interactive display-intensive tasks
Server should provide CPU-intensive operations
Scalability
Server should have spare capacity to handle larger number of clients
Flexibility
The system should be usable for a variety of user interfaces and end devices (eg. WAP Handy, wearable computer, desktop)
Reliability
System should survive node or communication link problems

35. Problems with Client/Server Architectural Styles
Client/server systems do not provide peer-to-peer communication
Peer-to-peer communication is often needed
Example: Database receives queries from application but also sends notifications to application when data have changed

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. Model/View/Controller
Subsystems are classified into 3 different types
Model subsystem: Responsible for application domain knowledge
View subsystem: Responsible for displaying application domain objects to the user
Controller subsystem: Responsible for sequence of interactions with the user and notifying views of changes in the model.
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

38. Example of a File System Based on the MVC Architectural Style

39. Sequence of Events (Collaborations)
:Controller
:InfoView
:Model
2.User types new filename
1. Views subscribe to event
3. Request name change in model
4. Notify subscribers
5. Updated views
:FolderView

40. UNIX Shell: Pipe and filter architectural style
Most suited for
Applications with sequential processing of data
Minimal need for user interaction
% ps auxwww | grep dutoit | sort | more
dutoit pts/6 O 15:24:36 0:00 -tcsh
dutoit pts/6 S 15:38:46 0:00 grep dutoit
dutoit pts/6 O 15:38:47 0:00 sort ps
grep
sort
more

41. Summary System Design Design Goals Definition Subsystem Decomposition
Reduces the gap between requirements and the (virtual) machine
Decomposes the overall system into manageable parts
Design Goals Definition
Describes and prioritizes the qualities that are important for the system
Defines the value system against which options are evaluated
Subsystem Decomposition
Results into a set of loosely dependent parts which make up the system

42. Performance Criteria Performance - speed and capacity requirements
Response Time
Throughput
Memory

43. Dependability Criteria
Dependability – how critical is it to keep the system continuously operational
Robustness
Reliability
Availability
Fault Tolerance
Security
Safety

44. Cost Criteria
Cost – design and managerial considerations constraining the project
Development cost
Deployment cost
Upgrade cost
Maintenance cost
Administration cost

45. Maintenance Criteria
Maintainability – ease or difficulty of modification
Extensibility
Modifiability
Adaptability
Portability
Readability
Traceability of requirements

46. End User Criteria End user criteria – desirable from user’s standpoint
Utility
Usability

47. Chapter 6 System Design: Decomposing the System

48. Design
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.”
- C.A.R. Hoare
Compared with Requirements Analysis System design is messy.
One of the reasons is that the analysis depends on the application domain. When entering design, we add the implementation domain. We worry about how to map the application domain expressed in the system model (object model, dynamic model, functional model) into the existing hardware.
Unfortunately this is not a well known science. Again only heuristics are known. Unfortunately even these heuristics have a half-life of 2-5 years. One of the problems is that we are still making incredible progress in computer science which is driven by technology
20 years ago we every analysis was mapped on a main frame. It was too expensive to waste cycles.
With the advence of minis and LAN networks, people started talking about client/server architectures and mapped their analysis onto distributed networks of computers
One of the questions a designer faces is performance vs reliability. If a certain design needs to be optimized because the response time is too slow, what should the designer do? Pick a Cray or a network of Sun workstations?

49. Why is Design so Difficult?
Analysis: Focuses on the application domain
Design: Focuses on the solution domain
Design knowledge is a moving target
The reasons for design decisions are changing very rapidly
Halftime knowledge in software engineering: About 3-5 years
What I teach today will be out of date in 3 years
Cost of hardware rapidly sinking
“Design window”:
Time in which design decisions have to be made
Technique
Time-boxed prototyping

50. The Purpose of System Design
Problem
Bridging the gap between desired and existing system in a manageable way
Use Divide and Conquer
We model the new system to be developed as a set of subsystems
New
System
Existing System

51. System Design System Design 1. Design Goals 8. Boundary Conditions
nition T
rade-of fs
8. Boundary
Conditions
Initialization T
ermination
2. System
Failure
Decomposition
Layers/Partitions
Cohesion/Coupling
7. Software
Control
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?
Monolithic
Event-Driven
Threads
Conc. Processes
3. Concurrency
6. Global
Identification of
Threads
4. Hardware/
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

52. Overview System Design I (Today)
0. Overview of System Design
1. Design Goals
2. Subsystem Decomposition
System Design II: Addressing Design Goals (next lecture)
3. Concurrency
4. Hardware/Software Mapping
5. Persistent Data Management
6. Global Resource Handling and Access Control
7. Software Control
8. Boundary Conditions
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

53. How to use the results from the Requirements Analysis for System Design
Nonfunctional requirements =>
Activity 1: Design Goals Definition
Functional model =>
Activity 2: System decomposition (Selection of subsystems based on functional requirements, cohesion, and coupling)
Object model =>
Activity 4: Hardware/software mapping
Activity 5: Persistent data management
Dynamic model =>
Activity 3: Concurrency
Activity 6: Global resource handling
Activity 7: Software control
Subsystem Decomposition
Activity 8: Boundary conditions
In Requirements analysis we have beautifully built 3 descriptions of the problem, the models. Where do the models go in system design?
If you read Rumbaugh, the above list of system design issues looks a little bit random. But there is a reason behind it:

54. How do we get the Design Goals?
Let’s look at a small example
Current Situation:
Computers must be used in the office
What we want:
A computer that can be used in mobile situations.

55. Example: Current Desktop Development

56. Identify Current Technology Constraints
Direction where the user looks is irrelevant
Single Output Device
Fixed Network
Connection
Location of user does not matter
Precise Input

57. Generalize Constraints using Technology Enablers
Single Output Device
Precise Input
Direction where the user looks is irrelevant
Fixed Network
Connection
Location of user does not matter
Direction where the user looks is relevant
Multiple Output Devices
Dynamic Network
Connection
Location-based
Vague Input

58. Establish New Design Goals
Mobile Network Connection
Multiple Output Devices
Location-Based
Multimodal Input (Users Gaze, Users Location, …)
Vague input

59. Sharpen the Design Goals
Location-based input
Input depends on user location
Input depends on the direction where the user looks (“egocentric systems”)
Multi-modal input
The input comes from more than one input device
Dynamic connection
Contracts are only valid for a limited time
Is there a possibility of further generalizations?
Example: location can be seen as a special case of context
User preference is part of the context
Interpretation of commands depends on context

60. Prototype the Desired System

61. List of Design Goals Reliability Good documentation 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

62. Relationship Between Design Goals
End User
Low cost
Increased Productivity
Backward-Compatibility
Traceability of requirements
Rapid development
Flexibility
Functionality
User-friendliness
Ease of Use
Ease of learning
Fault tolerant
Robustness
Runtime
Efficiency
Reliability
Portability
Good Documentation
Client
(Customer,
Sponsor)
Minimum # of errors
Modifiability, Readability
Reusability, Adaptability
Well-defined interfaces
Nielson
Usability Engineering
MMK, HCI
Rubin
Task Analysis
Developer/
Maintainer

63. Typical Design Trade-offs
Functionality vs. Usability
Cost vs. Robustness
Efficiency vs. Portability
Rapid development vs. Functionality
Cost vs. Reusability
Backward Compatibility vs. Readability

64. Nonfunctional Requirements may give a clue for the use of Design Patterns
Read the problem statement again
Use textual clues (similar to Abbot’s technique in Analysis) to identify design patterns
Text: “manufacturer independent”, “device independent”, “must support a family of products”
Abstract Factory Pattern
Text: “must interface with an existing object”
Adapter Pattern
Text: “must deal with the interface to several systems, some of them to be developed in the future”, “ an early prototype must be demonstrated”
Bridge Pattern

65. Textual Clues in Nonfunctional Requirements
Text: “complex structure”, “must have variable depth and width”
Composite Pattern
Text: “must interface to an set of existing objects”
Façade Pattern
Text: “must be location transparent”
Proxy Pattern
Text: “must be extensible”, “must be scalable”
Observer Pattern
Text: “must provide a policy independent from the mechanism”
Strategy Pattern

66. Section 2. System Decomposition
Subsystem (UML: Package)
Collection of classes, associations, operations, events and constraints that are interrelated
Seed for subsystems: UML Objects and Classes.
(Subsystem) Service:
Group of operations provided by the subsystem
Seed for services: Subsystem use cases
Service is specified by Subsystem interface:
Specifies interaction and information flow from/to subsystem boundaries, but not inside the subsystem.
Should be well-defined and small.
Often called API: Application programmer’s interface, but this term should used during implementation, not during System Design
Relation of subsystems to each other is similar to object model
System topology is similar functional model!

67. Services and Subsystem Interfaces
Service: A set of related operations that share a common purpose
Notification subsystem service:
LookupChannel()
SubscribeToChannel()
SendNotice()
UnscubscribeFromChannel()
Services are defined in System Design
Subsystem Interface: Set of fully typed related operations.
Subsystem Interfaces are defined in Object Design
Also called application programmer interface (API)

68. Choosing Subsystems
Criteria for subsystem selection: Most of the interaction should be within subsystems, rather than across subsystem boundaries (High cohesion).
Does one subsystem always call the other for the service?
Which of the subsystems call each other for service?
Primary Question:
What kind of service is provided by the subsystems (subsystem interface)?
Secondary Question:
Can the subsystems be hierarchically ordered (layers)?
What kind of model is good for describing layers and partitions?

69. Subsystem Decomposition Example
Authoring
Is this the right
decomposition or
is this too much ravioli?
Augmented
Reality
Modeling
Workflow
Inspection
Repair
Workorder

70. Definition: Subsystem Interface Object
A Subsystem Interface Object provides a service
This is the set of public methods provided by the subsystem
The Subsystem interface describes all the methods of the subsystem interface object
Use a Facade pattern for the subsystem interface object

71. System as a set of subsystems communicating via a software bus
Authoring
Modeling
Workflow
Augmented
Reality
Inspection
Repair
Workorder
A Subsystem Interface Object publishes the service (= Set of public methods)
provided by the subsystem

72. A 3-layered Architecture
Repair
Inspection
Authoring
Augmented
Reality
Workflow
Modeling
What is the relationship between Modeling and Authoring?
Are other subsystems needed?

73. Tournament Statistics
Another Example:
ARENA Subsystem decomposition
User Interface
Tournament
Advertisement
User Management
Component Management
User Directory
Tournament Statistics
Session Management

74. Tournament Statistics
Services provided by
ARENA Subsystems
User Interface
Manages advertisement banners and sponsorships.
Administers user accounts
Manages tournaments, applications, promotions.
Tournament
Advertisement
User Management
For adding games, styles, and expert rating formulas
Component Management
User Directory
Tournament Statistics
Session Management
Stores user profiles (contact & subscriptions)
Stores results of archived tournaments
Maintains state during matches.

75. Coupling and Cohesion
Goal: Reduction of complexity while change occurs
Cohesion measures the dependence among classes
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 coupling: Changes to one subsystem will have high impact on the other subsystem (change of model, massive recompilation, etc.)
Low coupling: A change in one subsystem does not affect any other subsystem
Subsystems should have as maximum cohesion and minimum coupling as possible:
How can we achieve high cohesion?
How can we achieve loose coupling?

76. 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
In an object-oriented design such as JEWEL, each subsystem makes its layer a subclass of the generic layer class provided by the UI subsystem. Each individual subsystem must provide for its own zoom and refresh methods. Ideally the refresh method will be called for every draw operation. The UI subsystem is responsible for knowing when to call for a refresh (but the UI group will not have to implement it itself: it is a callback method implemented by the visualization and GIS group). All the interfaces with UI (such as how UI will provide the other groups with selection information) should be well documented and agreed on by all groups.

77. Subsystem Decomposition into Layers
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)

78. 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

79. Virtual Machine Dijkstra: T.H.E. operating system (1965) Problem VM1
A system should be developed by an ordered set of virtual machines, each built in terms of the ones below it.
Problem
VM1 C1 C1 C1
attr
attr
attr
opr
opr
opr C1 C1
VM2
attr
attr
opr
opr C1
VM3 C1
attr
attr
opr
opr C1
VM4
attr
opr
Existing System

80. Virtual Machine A virtual machine is an abstraction
It provides a set of attributes and operations.
A virtual machine is a subsystem
It is connected to higher and lower level virtual machines by "provides services for" associations.
Virtual machines can implement two types of software architecture
Open and closed architectures.
A virtual machine can be seen a collection of classes instead of a single class. This module uses services provided by lower level virtual machines and provides a service to higher level machines
Key concept in structuring and providing abstraction, but slightly out of out of date, cannot deal with distributed architectures. Works still well for single processor architectures (tasks)

81. Closed Architecture (Opaque Layering)
VM4
VM3
VM2
VM1 C1
attr op
Any layer can only invoke operations from the immediate layer below
Design goal: High maintainability, flexibility

82. Open Architecture (Transparent Layering)
Any layer can invoke operations from any layers below
Design goal: Runtime efficiency C1
attr op C1
attr op C1
attr op
VM1 C1
attr op C1
attr op
VM2 C1
attr op C1
attr op
VM3 C1
attr op C1
attr op
VM4

83. Properties of Layered Systems
Layered systems are hierarchical. They are desirable because hierarchy reduces complexity (by low coupling).
Closed architectures are more portable.
Open architectures are more efficient.
If a subsystem is a layer, it is often called a virtual machine.
Layered systems often have a chicken-and egg problem
Example: Debugger opening the symbol table when the file system needs to be debugged

84. Software Architectural Styles
Subsystem decomposition
Identification of subsystems, services, and their relationship to each other.
Specification of the system decomposition is critical.
Patterns for software architecture
Client/Server
Peer-To-Peer
Repository
Model/View/Controller
Pipes and Filters

85. 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

86. Client/Server Architectural Style
Often used in database systems:
Front-end: User application (client)
Back end: Database access and manipulation (server)
Functions performed by client:
Customized user interface
Front-end processing of data
Initiation of server remote procedure calls
Access to database server across the network
Functions performed by the database server:
Centralized data management
Data integrity and database consistency
Database security
Concurrent operations (multiple user access)
Centralized processing (for example archiving)

87. Design Goals for Client/Server Systems
Service Portability
Server can be installed on a variety of machines and operating systems and functions in a variety of networking environments
Transparency, Location-Transparency
The server might itself be distributed (why?), but should provide a single "logical" service to the user
Performance
Client should be customized for interactive display-intensive tasks
Server should provide CPU-intensive operations
Scalability
Server should have spare capacity to handle larger number of clients
Flexibility
The system should be usable for a variety of user interfaces and end devices (eg. WAP Handy, wearable computer, desktop)
Reliability
System should survive node or communication link problems

88. Problems with Client/Server Architectural Styles
Layered systems do not provide peer-to-peer communication
Peer-to-peer communication is often needed
Example: Database receives queries from application but also sends notifications to application when data have changed

89. 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

90. Peer
Client
Server

91. Example of a Peer-to-Peer Architectural Style
Layer
ISO’s OSI Reference Model
ISO = International Standard Organization
OSI = Open System Interconnection
Reference model defines 7 layers of network protocols and strict methods of communication between the layers.
Closed software architecture
Application
Presentation
Session
Level of abstraction
Transport
Network
DataLink
Physical

92. OSI model Packages and their Responsibility
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.

93. Another View at the ISO Model
A closed software architecture
Each layer is a UML package containing a set of objects
An example of a closed architecture is the Reference Model of Open Systems Interconnection (in short, the OSI model) is composed of seven layers [Tanenbaum, 1996]. Each layer is responsible for performing a well defined function. In addition, each layer provides its services by using services by the layer below. The Physical layer represents the hardware interface to the network. It is responsible for transmitting bits over a communication channels. The DataLink layer is responsible for transmitting data frames without error using the services of the Physical layer. The Network layer is responsible for transmitting and routing packets within a network. The Transport layer is responsible for ensuring that the data is reliably transmitted from end to end. The Transport layer is the interface Unix programmers see when transmitting information over TCP/IP sockets between two processes. The Session layer is responsible for the initialization of a connection, including authentication. The Presentation layer performs data transformation services, such as byte swapping or encryption. The Application layer is the system you are designing (unless you are building an operating system or protocol stack). The application layer can and should, of course, also consist of layered subsystems.
An example of closed architecture: the OSI model (UML class diagram). The OSI model decomposes network services into seven layers, each responsible for a different level of abstraction.

94. Middleware Allows Focus On The Application Layer
Presentation
Session
Transport
Network
DataLink
Physical
Socket
CORBA
TCP/IP
Object
Ethernet
Wire

95. Model/View/Controller
Subsystems are classified into 3 different types
Model subsystem: Responsible for application domain knowledge
View subsystem: Responsible for displaying application domain objects to the user
Controller subsystem: Responsible for sequence of interactions with the user and notifying views of changes in the model.
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

96. Example of a File System Based on the MVC Architectural Style

97. Sequence of Events (Collaborations)
:Controller
:InfoView
:Model
2.User types new filename
1. Views subscribe to event
3. Request name change in model
4. Notify subscribers
5. Updated views
:FolderView

98. Repository Architectural Style (Blackboard Architecture, Hearsay II Speech Recognition System)
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()

99. Examples of Repository Architectural Style
Compiler
SemanticAnalyzer
SyntacticAnalyzer
Optimizer
CodeGenerator
LexicalAnalyzer
Repository
Hearsay II speech understanding system (“Blackboard architecture”)
Database Management Systems
Modern Compilers
ParseTree
SymbolTable
SourceLevelDebugger
SyntacticEditor

100. Summary System Design Design Goals Definition Subsystem Decomposition
Reduces the gap between requirements and the (virtual) machine
Decomposes the overall system into manageable parts
Design Goals Definition
Describes and prioritizes the qualities that are important for the system
Defines the value system against which options are evaluated
Subsystem Decomposition
Results into a set of loosely dependent parts which make up the system