3.

Subsystem Design

Objectives :
 Understand the purpose of Subsystem Design and where in the
lifecycle it is performed
 Define the behaviors specified in the subsystem's interfaces
in terms of collaborations of contained classes (mentioned in Use
Case Design)
 Document internal structure of the subsystem
 Determine the dependencies upon elements external to the
subsystem that may be needed to support the responsibilities of
the interface.
Overview
System Design I
0. Overview of System Design
1. Design Goals
2. Subsystem Decomposition

System Design II: Addressing Design Goals

3. Concurrency More Self reading
4. Hardware/Software Mapping
5. Persistent Data Management
6. Global Resource Handling and Access Control
7. Software Control
8. Boundary Conditions
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
 “Design window”:
 Time in which design decisions have to be made
 Technique
 Time-boxed prototyping
System Design
System Design

1. Design Goals
Definition
8. Boundary
Trade-offs
Conditions
Initialization
Termination
Failure
2. System
Decomposition
Layers/Partitions 7. Software
Cohesion/Coupling
Control
Monolithic
Event-Driven
3. Concurrency Threads
Identification of 4. Hardware/ 6. Global Conc. Processes
Threads Software 5. Data Resource Handling
Mapping Management
Access control
Special purpose Persistent Objects Security
Files
Buy or Build Trade-off Databases
Allocation Data structure
Connectivity
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
List of Design Goals
 Reliability  Good documentation
 Modifiability  Well-defined interfaces
 Maintainability  User-friendliness
 Understandability  Reuse of components
 Adaptability  Rapid development
 Reusability
 Minimum # of errors
 Efficiency
 Readability
 Portability
 Ease of learning
 Traceability of requirements
 Ease of remembering
 Fault tolerance
 Backward-compatibility  Ease of use
 Cost-effectiveness  Increased productivity
 Robustness  Low-cost
 High-performance  Flexibility
How do we get the Design Goals?

Let’s look at a small example

 Current Situation:
 Computers must be used in the office
Why? Problem

 What we want:
 A computer that can be used in mobile situations.

What are the technical terms describing the two?

 Identify Current Technology
Constraints

Direction where the

user looks is
Single Output Device irrelevant

Fixed Network
Connection
Location of
user does not
matter

Precise Input
 Generalize Constraints using Technology
Enablers

Direction where the

user looks is
Single Output
Multiple Device
Output irrelevant
relevant
Devices

Fixed Network
Dynamic Network
Connection
Location of
user does not
Location-based
matter

PreciseInput
Vague Input

Any concrete scenarios?

Establish New Design Goals

 Mobile Network Connection

 Multiple Output Devices
 Location-Based
 Multimodal Input (Users Gaze, Users Location, …)
 Vague input
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
 Relationship Between Design Goals
End User
Low cost Functionality
Increased Productivity User-friendliness
Backward-Compatibility Ease of Use
Traceability of requirements Runtime Ease of learning
Rapid development Efficiency Fault tolerant
Flexibility Robustness
Reliability
Portability
Good Documentation
Client
(Customer,
Sponsor) Minimum # of errors
Task Analysis Modifiability, Readability
Reusability, Adaptability
Well-defined interfaces
Developer/
Maintainer
What does “Reliability” mean?
Typical Design Trade-offs
 Functionality vs. Usability
 Cost vs. Robustness
 Efficiency vs. Portability
 Rapid development vs. Functionality
 Cost vs. Reusability
 Backward Compatibility vs. Readability
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: From what spec.?
 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
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:
Can you illustrate these using UML conventions?
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

What are other architectural styles?

 Subsystem Decomposition into Layers

A: Subsystem Layer 1

B:Subsystem C:Subsystem D:Subsystem Layer 2

E:Subsystem F:Subsystem G:Subsystem Layer 3

Ideally use one package for each subsystem

 Subsystem Decomposition Heuristics:

 More subsystems increase cohesion but also complexity (more
services)
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

Actually, this will depend on the directionality?

Closed Architecture (Opaque Layering)

 Any layer can only invoke

C1 C1 C1
attr attr attr VM1
op op op
operations from the
immediate layer below C1
attr
C1
attr VM2
op op

 Design goal: High

maintainability, flexibility
C1 C1
attr attr VM3
op op

C1 C1
attr attr VM4
op op

Only vertical communications?

Open Architecture (Transparent Layering)

C1 C1 C1
 Any layer can invoke operations attr attr attr VM1
from any layers below
op op op

Design goal: Runtime efficiency

C1 C1
 attr attr VM2
op op

C1 C1
attr attr VM3
op op

C1 C1
attr attr VM4
op op
Properties of Layered Systems

 Layered systems are hierarchical. They are desirable because

hierarchy reduces complexity (by low coupling).

 Closed architectures are more portable, High maintainability,

flexibility
 Open architectures are more efficient, Runtime efficiency
So, which is better?
 If a subsystem is a layer, it is often called a virtual machine(VM).

What are examples of systems using a layered architectural style?

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 Patterns = styles?

 Client/Server
 Peer-To-Peer
 Repository
 Model/View/Controller
 Pipes and Filters
What are other architectural styles?
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
Server

* *
Client
requester provider service1()
service2()
…
serviceN()

Is “interface” the same as “interface of the server” in UML?

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)

Does a system use a single style or multiple styles?

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 Is this what performance means to you?
 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
Is thissurvive node or means
what realiability communication
to you? link problems
Problems with Client/Server Architectural Styles

 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 What does this mean?
Peer-to-Peer communication [Wikipedia]

Peer-to-peer (P2P) networking is a method of delivering c

omputer network services in which the participants share a
portion of their own resources, such as processing power, disk
storage, network bandwidth, printing facilities. Such resources
are provided directly to other participants without intermediary
network hosts or servers.[1] Peer-to-peer network participants
are providers and consumers of network services
simultaneously, which contrasts with other service models,
such as traditional client-server computing.

A server based network

A peer-to-peer based network (i.e: not peer-to-peer).
Peer-to-Peer Architectural Style Peer
 Generalization of Client/Server Architecture
 Clients can be servers and servers can be clients Client Server

requester
Peer
*

service1()
service2() *
… provider
serviceN()

1. updateData
application1:DBUser

database:DBMS
application2:DBUser
2. changeNotification

This is where the chicken-and-egg problem exists!

Example of a Peer-to-Peer
Layer

Architectural Style
 ISO’s OSI Reference Application
Model
 ISO = International Presentation
Standard
Organization
 OSI = Open System

Level of abstraction
Session
Interconnection
 Reference model
defines 7 layers of Transport
network protocols and
strict methods of Network
communication
between the layers.
 Closed software DataLink
architecture
Physical
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.
Another View at the ISO Model
• A closed software
Application
architecture
• Each layer is a Presentation Format
UML package
containing a set of Session Connection
objects
Transport Message

Network Packet

DataLink Frame

Physical Bit
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: What is this?
 Model subsystem implements the central datastructure, the
Controller subsystem explicitly dictate the control flow

initiator
Controller
* 1 repository
Model
1 notifier
subscriber
View
*
Which interacts with the user?
 Sequence of Events (Collaborations)

2.User types new filename

:Controller 3. Request name change in model

1. Views subscribe to event

:Model
5. Updated views
:InfoView 4. Notify subscribers

:FolderView
Repository Architectural Style (Blackboard
Architecture, Hearsay II Speech Recognition System)
What’s blackboard? Are all repository architectural styles mean blackboard?

 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)

Repository

Subsystem
createData()
setData()
getData()
searchData()
 Examples of Repository Architectural Style
Compiler

SemanticAnalyzer
SyntacticAnalyzer
Optimizer

LexicalAnalyzer CodeGenerator

 Hearsay II speech Repository

understanding system
SymbolTable
(“Blackboard ParseTree

architecture”)
 Database Management
Systems SourceLevelDebugger SyntacticEditor
 Modern Compilers
Subsystem Decomposition Example

Authoring
Augmented
Reality

Modeling Workflow

Inspection

Workorder Repair
Summary I

 System Design
 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
Nonfunctional Requirements may give a clue for the
use of Design Patterns
 Read the problem statement again
 Use textual clues 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
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
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
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?
The Purpose of System Design

Problem

 Bridging the gap between desired and

existing system in a manageable way
 Use Divide and Conquer New
 We model the new system to be System
developed as a set of subsystems

Existing System
Services and Subsystem Interfaces

 Service: A set of related operations that share a common

purpose
e.g 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)
Summary of the chapter…

 Subsystems define design/build-time system structure,

interfaces, and dependencies.
 The subsystem viewpoints described in this chapter provide
information on the system’s build-time and organizational
dependencies.
 These views are especially critical to the implementation
teams, as they will document the static software structures.
 These concepts include package(classes, interfaces,
components, nodes, collaborations, use cases, and other
packages), system (is shown graphically as a stereotyped
package, and is a representation of the entire scope of the
development effort), and subsystem( is a part of the system
and, as with the system, is shown as a stereotyped package).
…cont..

 Subsystems are typically the lowest-level entity for which the

software architecture team manages interfaces. In addition, a
subsystem is a unit for which design documentation will be
produced.
 Subsystems are also the unit at which testing is performed.
 Another technique to help abstract a system design is the use of
layers. Layers decompose the functions of a software system into
clearly defined groups where functions of the higher layers
depend on functions of the lower layers.
 There are many variations on layering, including strict layering,
relaxed layers, and inheritance across layers. In all cases,
however, the higher layers depend on the lower layers.
 Subsystems and layers are two fundamental tools for structuring
large-scale systems into smaller, more manageable parts.
E.g Subsystem Interface Dependency View –
focused on billing
E.g. Mapping layers and subsystems to a directory
structure