Lecture - 5

System Design:
Decomposing the System
Why is Design so Difficult?

• Analysis: Focuses on the application domain

• Design: Focuses on the solution domain
• The solution domain is changing very rapidly
• Halftime knowledge in software engineering: About
3-5 years
• Cost of hardware rapidly sinking
 Design knowledge is a moving target

• Design window: Time in which design decisions

have to be made.
The Scope of System Design

Problem
• Bridge the gap
• between a problem and
an existing system in a
manageable way
System
• How? Design
• Use Divide & Conquer:
1) Identify design goals
2) Model the new system
design as a set of
subsystems
3-8) Address the major
design goals. Existing System
 System Design: Eight Issues
System Design

8. Boundary
1. Identify Design Goals Conditions
Additional NFRs Initialization
Trade-offs Termination
Failure.
2. Subsystem Decomposition 7. Software
Layers vs Partitions Control
Coherence & Coupling
Monolithic
Event-Driven
3. Identify Concurrency Conc. Processes
Identification of 4. Hardware/ 5. Persistent Data 6. Global Resource
Parallelism Software Mapping Management Handling
(Processes, Identification of Nodes Storing Persistent Access Control
Threads) Special Purpose Systems Objects vs Capabilities
Buy vs Build Filesystem vs Database Security
Network Connectivity
How the Analysis Models influence
System Design
• Nonfunctional Requirements
=> Definition of Design Goals
• Functional model
=> Subsystem Decomposition
• Object model
=> Hardware/Software Mapping, Persistent Data
Management
• Dynamic model
=> Identification of Concurrency, Global Resource
Handling, Software Control
• Finally: Hardware/Software Mapping
=> Boundary conditions
 From Analysis to System Design
Nonfunctional Functional Model
Requirements
8. Boundary
1. Design Goals Conditions
Definition Initialization
Trade-offs Termination
Functional Model Failure
2. System Decomposition Dynamic
Layers vs Partitions Model
Coherence/Coupling 7. Software
Control
Monolithic
Dynamic Object Model Event-Driven
Model Conc. Processes
4. Hardware/ 5. Data
6. Global Resource
3. Concurrency Software Mapping Management
Handlung
Special Purpose Systems Persistent Objects
Identification of Access Control List
Buy vs Build Filesystem vs
Threads vs Capabilities
Allocation of Resources Database
Connectivity Security
Example of Design Goals
• Reliability  Good documentation
• Modifiability  Well-defined interfaces
• Maintainability  User-friendliness
• Understandability  Reuse of components
• Adaptability  Rapid development
• Reusability  Minimum number of errors
• Efficiency  Readability
• Portability  Ease of learning
• Traceability of requirements  Ease of remembering
• Fault tolerance  Ease of use
• Backward-compatibility  Increased productivity
• Cost-effectiveness  Low-cost
• Robustness  Flexibility
• High-performance
Stakeholders have different Design
Goals

Low cost Functionality

Increased productivity User-friendliness
Backward compatibility Usability
Traceability of requirements Runtime Ease of learning
Rapid development Efficiency Fault tolerant
Flexibility Robustness
Reliability
Portability
Client Good documentation
End
(Customer) User
Minimum # of errors
Modifiability, Readability
Reusability, Adaptability
Well-defined interfaces Developer/
Maintainer
Typical Design Trade-offs

• Functionality v. Usability
• Cost v. Robustness
• Efficiency v. Portability
• Rapid development v. Functionality
• Cost v. Reusability
• Backward Compatibility v. Readability
Subsystem Decomposition

• Subsystem
• Collection of classes, associations, operations, events
and constraints that are closely interrelated with each
other
• The objects and classes from the object model are the
“seeds” for the subsystems
• In UML subsystems are modeled as packages
• Service
• A set of named operations that share a common purpose
• The origin (“seed”) for services are the use cases from
the functional model
• Services are defined during system design.
 Example: Services
provided by the
User Interface ARENA Subsystems
Manages advertisement
banners & sponsorships Manages Administers user
tournaments,promotions, accounts
applications

Tournament
Advertisement User Management

Adds games, styles,

and expert rating Services
Services
formulas aredescribed
are described
Component bysubsystem
by subsysteminterfaces
interfaces
Management
User Directory

Tournament
Session Statistics
Management Stores user profiles
Stores results of
Maintains state (contact info &
archived
during matches subscriptions)
tournaments
Subsystem Interfaces vs API
• Subsystem interface: Set of fully typed UML
operations
• Specifies the interaction and information flow from and
to subsystem boundaries, but not inside the subsystem
• Refinement of service, should be well-defined and small
• Subsystem interfaces are defined during object design
• Application programmer’s interface (API)
• The API is the specification of the subsystem interface in
a specific programming language
• APIs are defined during implementation
• The terms subsystem interface and API are often
confused with each other
• The term API should not be used during system design
and object design, but only during implementation.
Example: Notification subsystem

• Service provided by Notification Subsystem

• LookupChannel()
• SubscribeToChannel()
• SendNotice()
• UnscubscribeFromChannel()

• Subsystem Interface of Notification Subsystem

• Set of fully typed UML operations

• API of Notification Subsystem

• Implementation in Java
Subsystem Interface Object

• Good design: The subsystem interface object

describes all the services of the subsystem
interface

• Subsystem Interface Object

• The set of public operations provided by a subsystem

Subsystem Interface Objects can be realized with the

Façade pattern.
Properties of Subsystems: Layers
and Partitions
• A layer is a subsystem that provides a service to
another subsystem with the following
restrictions:
• A layer only depends on services from lower layers
• A layer has no knowledge of higher layers
• A layer can be divided horizontally into several
independent subsystems called partitions
• Partitions provide services to other partitions on the
same layer
• Partitions are also called “weakly coupled” subsystems.
 Relationships between Subsystems
• Two major types of Layer relationships
• Layer A “depends on” Layer B (compile time dependency)
• Example: Build dependencies
• Layer A “calls” Layer B (runtime dependency)
• Example: A web browser calls a web server
• Can the client and server layers run on the same machine?
• Yes, they are layers, not processor nodes
• Mapping of layers to processors is decided during the
Software/hardware mapping!
• Partition relationship
• The subsystems have mutual knowledge about each other
• A calls services in B; B calls services in A (Peer-to-Peer)
• UML convention:
• Runtime dependencies are associations with dashed lines
• Compile time dependencies are associations with solid lines.
 Example of a Subsystem
Decomposition

Partition Layer
relationship Relationship
A:Subsystem „depends on“ Layer 1

B:Subsystem C:Subsystem D:Subsystem Layer 2

E:Subsystem F:Subsystem G:Subsystem Layer 3

Layer
Relationship
„calls“
 ARENA
User Interface Subsystem
Decomposition

Tournament
Advertisement User Management

Component
Management
User Directory

Tournament
Session Statistics
Management
Example of a Bad Subsystem
Decomposition

User Interface
Component
Management

Advertisement Tournament

Tournament
Statistics

Session User Management

Management
Good Design: The System as set of
Interface Objects

User Interface
Tournament

User
Management

Component
Advertisement Management

Tournament Session
Statistics Management

Subsystem Interface Objects

Virtual Machine
• A virtual machine is a subsystem connected to
higher and lower level virtual machines by
"provides services for" associations
• A virtual machine is an abstraction that provides a
set of attributes and operations
• The terms layer and virtual machine can be used
interchangeably
• Also sometimes called “level of abstraction”.
 Building Systems as a Set of Virtual
Machines
A system is a hierarchy of virtual machines, each using
language primitives offered by the lower machines.

Virtual Machine 4 .

Virtual Machine 3

Virtual Machine 2

Virtual Machine 1

Operating System, Libraries Existing System

 Building Systems as a Set of Virtual
Machines
A system is a hierarchy of virtual machines, each using
language primitives offered by the lower machines.

Virtual Machine4

Virtual Machine 3

Virtual Machine 2

Virtual Machine 1

Operating System, Libraries Existing System

Closed Architecture (Opaque
Layering)

• Each virtual machine C1ass1

attr
C1ass2
attr
C1ass3
attr VM4
can only call operations
op op op

from the layer below C1assE

attr
C1assF
attr VM3
op op

Design goals: C1assC C1assD

attr attr VM2
Maintainability, op op

flexibility. Class A C1ass B

attr attr VM1
op op
Open Architecture (Transparent
Layering)

• Each virtual machine C1

attr
C1
attr
C1
attr VM1
can call operations
op op op

from any layer below C1

attr
C1
attr VM2
op op

C1 C1

Design goal: attr

op
attr
op
VM3

Runtime efficiency C1 C1
attr attr VM4
op op
 Properties of Layered Systems
• Layered systems are hierarchical. This is a
desirable design, because hierarchy reduces
complexity
• low coupling
• Closed architectures are more portable
• Open architectures are more efficient
• Layered systems often have a chicken-and egg
problem Symbol Table

A: Symbolic Debugger

How do you open the

symbol table when you are D: File System
debugging the File
System?
G: Operating System
Coupling and Coherence of
Subsystems
• Goal: Reduce system complexity while allowing
change
• Coherence measures dependency among classes
• High coherence: The classes in the subsystem perform
similar tasks and are related to each other via many
associations
• Low coherence: Lots of miscellaneous and auxiliary
classes, almost no associations
• Coupling measures dependency among
subsystems
• High coupling: Changes to one subsystem will have high
impact on the other subsystem
• Low coupling: A change in one subsystem does not affect
any other subsystem.
 Coupling and Coherence of
Subsystems
Good Design
• Goal: Reduce system complexity while allowing
change
• Coherence measures dependency among classes
• High coherence: The classes in the subsystem perform
similar tasks and are related to each other via
associations
• Low coherence: Lots of miscellaneous and auxiliary
classes, no associations
• Coupling measures dependency among
subsystems
• High coupling: Changes to one subsystem will have high
impact on the other subsystem
• Low coupling: A change in one subsystem does not affect
any other subsystem
How to achieve high Coherence

• High coherence can be achieved if most of the

interaction is within subsystems, rather than
across subsystem boundaries
• Questions to ask:
• Does one subsystem always call another one for a
specific service?
• Yes: Consider moving them together into the same
subystem.
• Which of the subsystems call each other for services?
• Can this be avoided by restructuring the
subsystems or changing the subsystem interface?
• Can the subsystems even be hierarchically ordered (in
layers)?
How to achieve Low Coupling

• Low coupling can be achieved if a calling class

does not need to know anything about the
internals of the called class (Principle of
information hiding, Parnas)
• Questions to ask:
• Does the calling class really have to know any
attributes of classes in the lower layers?
• Is it possible that the calling class calls only operations
of the lower level classes?