Software Design and Architecture

System Design
 Software Design and Architecture

• Software Design and Architecture

– System Design Overview
– System Design Issues
– How the Analysis Models influence System Design
• Design Goals
• Subsystem Decomposition
 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.
 System Design: Eight Issues
System Design

8. Boundary
1. Identify Design Goals Conditions
Additional NFRs Initialization
Trade-offs Termination
Failure.
2. Subsystem Decomposition & Software Architecture 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 ACL vs Capabilities
Buy vs Build Filesystem vs Database Security
Network Connectivity
 Analysis Sources: Requirements and System Model

8. Boundary
1. Design Goals Conditions
Nonfunctional
Definition Functional Model
Initialization
Requirements
Trade-offs Termination
Failure
2. System Decomposition 7. Software
Functional Model
Layers vs Partitions Control
Coherence/Coupling
Monolithic
Event-Driven
3. Concurrency Dynamic
Conc. Processes
Identification of 4. Hardware/ 5. Data 6. Global Resource
Model
Dynamic
Threads Software Mapping Management Handlung
Special Purpose SystemsModel
Object Persistent Objects Access Control List
Model Buy vs Build Filesystem vs vs Capabilities
Allocation of Resources Database Security
Connectivity
 Functional Models

• Purpose: Represents the functional perspective of a system. It

focuses on what the system should do, in terms of functions and
services.
• Components: Includes functional requirements, use case
diagrams, and activity diagrams.
• Use : Useful for understanding the system's functionality from the
user's point of view.
 Dynamic Model

• Purpose: Represents the dynamic or behavioral aspects of the

system. It focuses on how the system behaves over time.
• Components: Includes state diagrams, sequence diagrams, and
interaction diagrams.
• Use : Helpful in modeling the temporal aspects of a system, like
state changes and interactions over time.
 Object Model

• Purpose: Represents the structural aspects of a system using

object-oriented concepts. It focuses on the organization of system
components.
• Components: Includes class diagrams, object diagrams, and
package diagrams.
• Use: Effective in modeling the static structure of a system,
showing how various objects are related and interact with each
other.
 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
 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 and system architecture 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
 Software Design and Architecture

• Software Design and Architecture

• Design Goals
– Non-Functional Requirements as Design Goals
– Trade-offs
• Subsystem Decomposition
 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
 Software Design and Architecture

• Software Design and Architecture

• Design Goals
• Subsystem Decomposition
– Overview of System Decomposition
– Subsystem Usage
– Identifying Subsystems
– Modeling Subsystems
– Subsystem Dependency Restrictions
– Coupling and Cohesion
– Subsystem Interfaces vs API
– Layered Systems
 System Decomposition

• Subsystem (UML: Package)

– Collection of classes, associations, operations, events and
constraints that are interrelated
– Seed for subsystems: UML Objects and Classes from the object
model
• Service:
– Group of operations provided by the subsystem
– A set of named operations that share a common purpose
– Seed for services: Subsystem use cases from the functional
model

• 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
 Subsystem Usage

Subsystems can be used in a number of complementary ways, to

partition the system into units which

• can be independently ordered, configured, or delivered

• can be independently developed, as long as the interfaces
remain unchanged
• can be independently deployed across a set of distributed
computational nodes
• can be independently changed without breaking other parts of
the systems
Thus, subsystems are ideal for modeling components - the
replaceable units of assembly in component-based development -
that are larger than a single design class.
 Subsystem Usage

In addition, subsystems can

• partition the system into units which can provide restricted
security over key resources
• represent existing products or external systems in the design.
 Identifying Subsystems

• A complex analysis class is mapped to a design subsystem if it

appears to embody behavior that cannot be the responsibility of a
single design class acting alone.
• A complex design class may also become a subsystem, if it is
likely to be implemented as a set of collaborating classes.
• Subsystems are also a good means of identifying parts of the
system that are to be developed independently by a separate
team.
• If the collaborating design elements can be completely
contained within a package along with their collaborations, a
subsystem can provide a stronger form of encapsulation than that
provided by a simple package.
• The contents and collaborations within a subsystem are
completely isolated behind one or more interfaces, so that the
client of the subsystem is only dependent upon the interface
 Identifying Subsystems
Hint Details
If a particular collaboration (or sub-collaboration) represents
optional behavior, enclose it in a subsystem.
Look for optionality
Features which may be removed, upgraded, or replaced with
alternatives should be considered independent.

If the user interface is relatively independent of the entity classes in

the system (i.e. the two can and will change independently), create
subsystems which are horizontally integrated: group related user
interface boundary classes together in a subsystem, and group
Look to the user interface of the related entity classes together in another subsystem.
system.
If the user interface and the entity classes it displays are tightly
coupled (i.e. a change in one triggers a change in the other), create
subsystems which are vertically integrated: enclose related
boundary and entity classes in common subsystem.

Separate functionality used by two different actors, since each actor

may independently change their requirements on the system.
Look to the Actors
Create subsystems to encapsulate access to an external system or
device.
 Identifying Subsystems
Hint Details
Highly coupled or cohesive classes/subsystems collaborate to
provide some set of services. Organize highly coupled elements
Look for coupling and cohesion into subsystems, and separate elements along lines of weak
between design elements coupling. In some cases, weak coupling can be eliminated entirely
by splitting classes into smaller classes with more cohesive
responsibilities, or repartitioning subsystems appropriately.
If there are several levels of service specified for a particular
capability (example: high, medium and low availability), represent
Look at substitution each service level as a separate subsystem, each of which will
realize the same set of interfaces. By doing so, the subsystems are
substitutable for one another.
Although there can be multiple instances of a particular subsystem,
each executing on different nodes, in many architectures it is not
possible for a single instance of a component to be split across
nodes. In the cases where subsystem behavior must be split
across nodes, it is recommended that you decompose the
Look at distribution subsystem into smaller subsystems (each representing a single
component) with more restricted functionality. Determine the
functionality that must reside upon each node and create a new
subsystem to 'own' that functionality, distributing the responsibilities
and related elements of the original subsystem appropriately. The
new subsystems are internal to the original subsystem.
Subsystems That Represent Existing
Products
• Where an existing product is one that exports interfaces, i.e.
operations (and perhaps receptions), but otherwise keeps all details of
implementation hidden, then it may be modeled as a subsystem in the
logical view.

• Examples of products the system uses that you may be able to

represent by a subsystem include:
– Communication software (middleware).
– Database access support (RDBMS mapping support).
– Application-specific products.

• When defining the subsystem to represent the product, also define one
or more interfaces to represent the product interfaces.
 Modeling Subsystems
Design Subsystems are modeled using UML components. This construct
provides the following modeling capabilities:
– can group classes to define a larger granularity part of a system
– can separate the visible interfaces from internal implementation
– can have execution at run-time
Some other considerations are:
– Each Design Subsystem must be given a name and a short description.
– The responsibilities of the original analysis class should be transferred to the
newly-created subsystem, using the description of the subsystem to
document the responsibilities
• UML 2.0 also defines a stereotype for component named
<<subsystem>>.
• This is an issue for the software architect to decide (whether to
choose for example to label components that are composed of
components as <<subsystem>>).
Subsystem Dependency Restrictions
In order to ensure that subsystems are replaceable elements in the model,
a few rules need to be enforced:
• A subsystem should minimize exposing of its contents. Ideally no
element contained by a subsystem should have 'public' visibility,
and thus no element outside the subsystem depends on the existence of
a particular element inside the subsystem
• A subsystem should define its dependencies on subsystem
interfaces .
• In addition, a number of subsystems may share a set of interfaces or
class definitions in common, in which case those subsystems 'import' the
contents of the packages which contain the common elements.
Subsystem Dependency Restrictions
An example of Subsystem and Package dependencies is shown below:
• A specification should define its dependencies. These are the
interfaces and visible elements from other subsystems and packages
that must be available in all compliant realizations of the subsystem.
 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:
 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
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 (make, ant, maven)
– 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“
 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 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

• 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?