1. Chapter 6, System Design Lecture 1

2. 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?

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

4. System Design System Design 1. Design Goals 8. Boundary Conditions
nition T
rade-of fs
8. Boundary
Conditions
Initialization T
ermination
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?
2. System
Failure
Decomposition
Layers/Partitions
Coherence/Coupling
7. Software
Control
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

5. The activities of system design (UML activity diagram)

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

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

8. System Design Phases Design Goals System Decomposition Concurrency
Hardware/Software Mapping
Data Management
Global Resource Handling
Software Control
Boundary Conditions

9. Section 1. 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

10. 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
Developer/
Maintainer

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

12. System Design Phases Design Goals System Decomposition Concurrency
Hardware/Software Mapping
Data Management
Global Resource Handling
Software Control
Boundary Conditions

13. Section 2. System Decomposition
Subsystem (UML: Package)
Collection of classes, associations, operations, events and constraints that are interrelated
Service:
A set of operations provided by the subsystem that share a common purpose
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 be used during implementation, not during System Design
Relation of subsystems to each other is similar to object model
System topology is similar functional model!

14. Services and Subsystem Interfaces
Service: A set of related operations that share a common purpose
Notification subsystem service (devoted to deal with communications between the FieldOfficer and the Dispatcher):
LookupChannel()
SubscribeToChannel()
SendNotice()
UnscubscribeFromChannel()
Services are defined in System Design
Subsystem Interface: Set of fully typed related operations. Also called application programmer interface (API)
Subsystem Interfaces are defined in Object Design
Also called application programmer interface (API)

15. 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 (discussed later):
How can we organize the subsystems?
Layer/partitions?

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

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

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

19. Coupling and Coherence
Goal: Reduction of complexity
Coherence measures the dependence among classes
High coherence: The classes in the subsystem perform similar tasks and are related to each other (via associations)
Low coherence: Lots of misc and aux objects, no associations
Coupling measures dependencies between subsystems
High coupling: Modifications 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 coherence and minimum coupling as possible:
How can we achieve loose coupling?
Which subsystems are highly coupled?

20. Decision tracking system
The decision tracking system purpose is to record design problems, discussions, alternative evaluations, decisions, and their implementations in terms of tasks
The DecisionSubsystem has a low coherence: The classes Criterion, Alternative, and DesignProblem have no relationships with Subtask, ActionItem, and Task.

21. Alternative subsystem decomposition for the decision tracking system
The coherence of the RationaleSubsystem and the PlanningSubsystem is higher than the coherence of the original DecisionSubsystem. Note also that we also reduced the complexity by decomposing the system into smaller subsystems.
subtasks *
assesses
solvableBy
resolvedBy
based-on
implementedBy
RationaleSubsystem
PlanningSubsystem
Criterion
Alternative
Decision
DesignProblem
SubTask
ActionItem
Task

22. 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 services to a higher 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.

23. Subsystem Decomposition into Layers
Subsystem Decomposition Heuristics:
No more than 7+/-2 subsystems
More subsystems increase coherence but also complexity (more services)
No more than 5+/-2 layers

24. Layer and Partition 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

25. A 3-layered Architecture
Repair
Inspection
Authoring
Augmented
Reality
Workflow
Modeling

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

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

28. Virtual Machine
A virtual machine is an abstraction that provides a set of attributes and operations.
A virtual machine is a subsystem connected to higher and lower level virtual machines by "provides services for" associations.
Virtual machines can implement two types of software architecture: closed and open 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)

29. Virtual Machine (Dijkstra, 1965)
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

30. Closed Architecture (Opaque Layering)
VM4
VM3
VM2
VM1 C1
attr op
A virtual machine can only call operations from the layer below
Design goal: High maintainability, flexibility

31. Open Architecture (Transparent Layering)
A virtual machine can call 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

32. Properties of Layered Systems
Layered systems are hierarchical. They are desirable because hierarchy reduces complexity.
Closed architectures are more portable.
Open architectures are more efficient.
If a subsystem is a layer, it is often called a virtual machine.

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

34. Client/Server Architecture
One or many servers provides services to instances of subsystems, called clients.
Main difference with repository style: service vs data
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

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

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

37. Peer-to-Peer Architecture
Generalization of Client/Server Architecture
Clients can be servers and servers can be clients
Control Flow design is more difficult because of possibility of deadlocks

38. Three-tier architectural style.
Subsystems are organized into three layers
All boundary objects that deal with the user
Interface
Application Logic
Storage
Connection
Form
Query
All control and entity objects that realize the processing and notification required by the application
All persistent objects related to storage, retrieval and query

39. Four-tier architectural style.
Subsystems are organized into four layers
Web-based applications
Presentation Server
Application Logic
Storage
Connection
Form
Query
Presentation Client
WebBrowser

40. Repository Architecture
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 on the data invoke peripheral systems) or by the subsystems (locks imposed by subsystems in the repository).
Subsystem
Repository
createData()
setData()
getData()
searchData()

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

42. 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 data structure, the Controller subsystem explicitly dictate the control flow
Controller
Model
subscriber
notifier
initiator *
repository 1
View

43. Example of a File System based on MVC Architecture

44. Sequence of Events for the MVC architecture example
: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

45. Pipe and Filter Architecture
Subsystems process data received from a set of inputs and send the results to other subsystems via a set of outputs
Subsystems are called filters
Associations between the subsystems are called pipes
Each filter is executed concurrently and synchronization is done via the pipes
Filters can be substituded for others or reconfigured to achieve a different purpose
Pipe
input
output * 1
Filter

46. An instance of the pipe and filter architecture (Unix command and UML activity diagram).
% 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
ps – process status
grep – search for a pattern
sort – sort input data
more – displays data one screen at a time

47. Summary System Design Design Goals Definition Subsystem Decomposition
Reduces the gap between requirements and the 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