Transcript Design - It works

310313
SOFTWARE ENGINEERING
SYSTEM DESIGN
310313
SYSTEM DESIGN
1
LEARNING OBJECTIVES
1. Understand the role and importance of system design in the
software development process.
2. Understand that system analysis and system design are
intertwined activities.
3. Know some major architectural styles and design patterns for
realizing system design goals.
4. Know the major activities that take place during system design
310313
SYSTEM DESIGN
2
SIGN OUTLINE SYSTEM
The Unified Process and System Design — Overview
– System Design — Life Cycle Role
– Moving from System Analysis to System Design
– The Importance of System Design
– Some Design Considerrations
The Unified Process — System Design Activities
– Use-case Design
– Class Design
– Subsystem Design
– Architectural Design
310313
SYSTEM DESIGN
3
LIFE CYCLE ROLE
Core Workflows
Phases
Inception
Elaboration
Construction
Transition
Requirements
Iteration
Analysis
Design
Implementation
Testing
iter.
#1
iter.
#2
—
—
—
—
—
iter.
#n-1
iter.
#n
Increments
310313
SYSTEM DESIGN
4
ARTIFACTS & WORKERS
Design
Model
310313
Architect
Use-Case
Engineer
Component
Engineer
responsible for
responsible for
responsible for
Deployment Architecture
Model
Description
Use-Case
Realization
—Design
Design
Class
Interfaces
Design
Subsystem
SYSTEM DESIGN
5
SYSTEM DESIGN : WORKERS

The architect is responsible for the integrity and the
architecture of the design and deployment models

The use-case engineer is responsible for one or more usecase realizations—design. He makes all textual descriptions and
diagrams describing the use-case realization readable and
suited for their purpose

The component engineer is defines and maintains the
operations, methods, attributes, relationships and
implementation of one or more design classes
may also maintain the integrity of one or more subsystems
310313
SYSTEM DESIGN
6
SYSTEM DESIGN : ARTIFACTS

The design model is describes the physical realization of a use
case; focuses on how functional and nonfunctional
requirements, together with implementation environment
constraints, impact the system

The deployment model is describes the physical distribution of
the system in terms of how functionality is distributed among
computational nodes

The architecture description is contains the architecturally
significant artifacts of the design model and all of the
deployment model
 In the design model there are two views of architecture :
 the deployment model specifies the system architecture (physical).
 the design model specifies the software architecture (logical).
310313
SYSTEM DESIGN
7
SYSTEM DESIGN : ARTIFACTS

A use-case realization—design - describes how a specific use
case is realized and performed in terms of design classes and
their objects

A design class is an abstraction of a class or similar construct
in the system’s implementation
 We use programming language to specify a design class

A design subsystem - organizes artifacts of the design model
into more manageable pieces

An interface - specifies the operations provided by design
classes and subsystems
 An interface separates operations from their implementation
310313
SYSTEM DESIGN
8
6
THE PURPOSE OF SYSTEM DESIGN
To adapts the logical structure of the Analysis Model to the
implementation environment and prepares for implementation
When to transition from system analysis to system design?
The system is gradually structured into basic “parts” with
welldefined relationships among them in two stages:
1. building the skeleton is the process by which the parts come
together to produce a stable basis.
 The skeleton is provided by the software architecture.
2. growing the system is the process by which the parts aggregate
around the skeleton to produce a finer system structure.
 The growing is accomplished by the analysis and design
workflows.
310313
SYSTEM DESIGN
9
FROM SYSTEM ANALYSIS TO SYSTEM DESIGN
Analysis and design activities may be combined in various ways.
310313
SYSTEM DESIGN
10
THE IMPORTANCE OF DESIGN
Why not go straight to implementation?

We need to consider issues preveiously ignored, such as :
– the nonfunctional requirements
– the implementation environment.

the system must be adapted to the implementation environment

Since the analysis model is not sufficiently formal so we need to:
– refine analysis classes
– determine operations
– determine how classes should communicate

we also want to validate the analysis results
310313
How well do the Analysis Model and the Requirements Model
describe the system? What is not yet clear?
SYSTEM DESIGN
11
ANALYSIS MODEL


Conceptual model
Generic –> many designs
possible
DESIGN MODEL


Physical model
Specific –> for one
implementation

Less formal

More formal

Less expensive to develop

More expensive to develop

Package have few layers

Subsystem have many layers

Focus is on interactions

Focus is on sequence

Outline of design

Implementation of design

Created by developer
meetings

Created by software
engineering environments

May not be maintained

Should be maintained
310313
SYSTEM DESIGN
12
6.2
REALIZING DESIGN GOALS
We need to decide how system design goals wiill be realized.
 Design goals come mainly from nonfunctional
requirements(i.e., system qualities we try to optimize)

Design goals guide the decisions made by developers,
especially when implementation trade-offs are needed
 usually only a small subset of the nonfunctional
requirements can be considered simultaneously
THEREFORE we need to prioritize design goals and possibly
develop trade-offs against each other as well as against
managerial goals (e.g., schudule, budget)
Examples: space vs. speed; delivery time vs. functionality, etc.
310313
SYSTEM DESIGN
13
6.4.2
DESIGN GOALS — SOME DESIRABLE QUALITIES
Performance
response time
throughput
memory
Dependability
robustness
reliability
availability
fault tolerance
security
safety
End user
Maintenance
extensibility
modifiability
adaptability
portability
readability
Cost
development
deployment
upgrade
maintenance
administration
traceability
utility
usability
310313
SYSTEM DESIGN
14
6.4.4
REALIZING DESIGN GOALS :
IMPLEMENTATION ENVIRONMENT
Need to consider the technical and managerial
constraints under which the system should be built

What hardware/software will the system run on?
– hardware (limitations)
– distribution

What programming language will be used?
– OO, non-OO

– memory management
What existing software do we need to use?
– DBMS
– UIMS

– system software
– network facilities
– legacy systems
What development people/organizations will be involved?
– distributed location
310313
– team competencies
SYSTEM DESIGN
15
REALIZING DESIGN GOALS :
IMPLEMENTATION ENVIRONMENT (cont’d)
General design strategy:
localize and encapsulate implementation environment
To accomplish this, we create “bridge” classes that represent
occurrences of components in the implementation environment
application system classes that require file access
?
FileManager can
use the Bridge
design pattern
FileManager
WinXP
Unix
Mac-OS
 We often need to define many additional classes to deal
with the implementation environment
310313
SYSTEM DESIGN
16
6.4.5
6.4.6
6.4.7
6.4.8
REALIZING DESIGN GOALS :
SYSTEM-WIDE DESIGN ISSUES
We need to develop consistent approaches to
handle issues that have system-wide implications.
data management — How is persistent data handled?
 files? relational DBMS? object-oriented DBMS?
access control — How is access control specified and realized?
 global access table? access control list? capability?
control flow — How is processing initiated and controlled?
 procedure-driven? event-driven? threaded?
boundary conditions —
How are system start-up, shutdown,
failure and exceptions handled?
 administration use cases for start-up, shutdown, recovery
 exceptional handling mechanism for errors
310313
SYSTEM DESIGN
17
7.4.6
GENERIC DESIGN MECHANISMS
A generic design mechanism is a well-tried solution to
a common occing design requirements.
architectural style/design pattern – a named, well-understood
solution to a common problem in context
What
described in literary form
– Help novices to learn by example to behave more like experts
– Pattern catalog documents particular designs that are useful in a
certain context
framework – a reusable “chunk” of architecture
– Describes how a collection of objects work together to implement
How
the structural part of, usually, several design patterns
– Usually define generic classes that describe the collaborations
between the objects and which will be sub-classed (specialized)
when the framework is applied to a problem
310313
SYSTEM DESIGN
18
GENERIC DESIGN MECHANISMS :
ARCHITECTURAL STYLES/DESIGN PATTERNS

Architectural styles/design patterns represent solutions
to problems that arise when developing software within
a particular context.
 architectural styles/design patterns ≡
problem/solution pairs in a context

Architectural styles/design patterns capture the static
and dynamic structure and collaboration among key
participants in software architectures and designs.
 They are particularly useful for describing how and why to
resolve nonfunctional requirements.

Architectural styles/design patterns facilitate reuse of
successfulsoftware architectures and designs.
310313
SYSTEM DESIGN
19
GENERIC DESIGN MECHANISMS :
ARCHITECURAL STYLES
An architecture style specifies how to organize
and connect a set of software modules.

It is a pattern of system organization that defines the software
architecture of a system.

It includes the specification of:
– system decomposition
– global control flow
– error handling
– inter module communication protocols
310313
SYSTEM DESIGN
20
ARCHITECTURAL STYLES: MULTI-LAYER
Goal: To build the software in
layers so that each layer
communicates only with
the layers below it.
Top layer: user interface
Middle layers: application
functions
Bottom layers: common
services
(e.g., data storage,
communication, etc.)
 Each layer has a welldefined
API defining the services it
provides.
310313
Often combined with other styles.
SYSTEM DESIGN
21
ARCHITECTURAL STYLES: REPOSITORY
Goal: To centralize the
management of data.

Control flow can be dictated by:
– repository via triggers on the
data.
– subsystems using locks to
synchronize.

Possible drawbacks:
– repository can be a bottleneck.
A typical style for applications
requiring data management.
– high coupling between
repository and subsystems.
310313
SYSTEM DESIGN
22
ARCHITECTURAL STYLES: CLIENT-SERVER
Goal: To separate and
distribute
the system’s functionality.
three-tier
The server communicates
with both a client (usually via
the Internet) and with a
database server (usually via
an intranet).
peer-to-peer
Each subsystem can be both
a server and a client and can
set up a communication
channel to exchange
information as required
310313
SYSTEM DESIGN
23
ARCHITECTURAL STYLES: BROKER
Goal: To distribute aspects of
the system transparently
to different nodes.
 The Proxy design pattern
can be used to achieve
this goal.
Examples:
CORBA - Common Object
Request Broker
Architecture
Microsoft’s COM - Common
Object Mode
310313
SYSTEM DESIGN
24
ARCHITECTURAL STYLES: TRANSACTION
PROCESSING
Goal: To direct input to
specialized subsystems
(handlers).

A transaction dispatcher
decides what to do with
each input transaction,
dispatching a procedure
call or message to a
handler that will handle
the transaction.
Example:
– A database engine.
310313
SYSTEM DESIGN
25
ARCHITECTURAL STYLES: PIPE-AND-FILTER
Goal: To provide flexibility,
modifiability and
reuseability of subsystem .

A stream of data is passed
through a series of
subsystems,
called a pipeline, each of
which
transforms it in some way.
Examples:
– UNIX shell
310313
SYSTEM DESIGN
26
ARCHITECTURAL STYLES:
MODE-VIEW-CONTROLLER (MVC)




Goal: To separate the user
interface layer from
other parts of the
system.
The model contains the
classes (data) to be viewed
and manipulated.
The view contains objects
used to render the data from
the model and also the
various controls with which
the user can interact.
The controller contains the
objects that control and
handle the user􀀁s interaction
with the view and the model.
310313
The Observer design pattern
is normally used to separate
the model from the view.
SYSTEM DESIGN
27
DESIGN PATTERNS

Design patterns are described using the following main parts:
1. Name and intent.
2. Problem and context.
3. Concern(s) addressed.
4. Abstract description of structure and collaborations in
solution.
5. Positive and negative consequence(s) of use.
6. Implementation guidelines and sample code.
7. Known uses and related patterns.
 Design pattern makes extensive use of inheritance and
delegation.
Design patterns descriptions are usually independent
of programming language or implementation details.
310313
SYSTEM DESIGN
28
DESIGN PATTERN: BRIDGE — MOTIVATION
Problem: When an abstraction can have several possible
implementations, inheritance is usually used to handle
this. However, this binds an implementation to an
abstraction permanently making it difficult to modify,
extend and reuse abstractions and implementations
independently.
e.g., implementation of a portable Window abstraction in a
user interface toolkit
Window
MSWindow
MacWindow
Window
MSWindow
Problem:We are mixing design and
implementation inheritance hierarchies.
310313
MacWindow
IconWindow
MSWindow
MacWindow
SYSTEM DESIGN
29
DESIGN PATTERN: BRIDGE — MOTIVATION
Solution: Separate the Window abstraction and implementation
class hierarchies and connect them using a bridge
bridge
Window
imp
WindowImp
drawText()
drawRect()
devDrawText()
devDrawRect()
impdevDrawLine()
impdevDrawLine()
impdevDrawLine()
impdevDrawLine()
IconWindow
drawBorder()
drawRect();
drawText()
310313
ApplicationWindow
drawCloseBox()
drawRect();
MSWindowImp
devDrawText()
devDrawLine()
msDrawLine();
MacWindowImp
devDrawText()
devDrawLine()
msDrawString();
SYSTEM DESIGN
30
DESIGN PATTERN: BRIDGE
Intent
Decouple an abstraction from its implementation so that the two can vary independently.
Solution
1. Create an Implementor class that defines a public interface.
2. Create subclasses of the Implementor class to implement each operation as needed.
3. Create an Abstraction class that maintains an association to the Implementor class
and provides a set of methods to invoke those operations.
4. For each RefinedAbstraction class that needs to use an Implementor subclass,
subclass the RefinedAbstraction from the Abstraction.
Consequences





Avoids permanent bindings between an abstraction and its implementation.
Both abstractions and implementations are extendable via subclassing.
Changes to the implementation have little or not impact on clients.
Hides implementation of an abstraction from clients.
Allows sharing an implementation among multiple objects and hiding that fact from
clients.
310313
SYSTEM DESIGN
31
DESIGN PATTERN: BRIDGE
Client
Abstraction
imp
Implementor
operation()
realOperation()
imprealOperation()
RefinedAbstraction
ConcreteImplementorA
realOperation()
ConcreteImplementorB
realOperation()
Abstraction – defines the Abstraction’s interface; maintains a reference to an object
of type Implementor.
RefinedAbstraction – extends the interface defined by Abstraction.
Implementor – defines the interface for implementation classes. This interface does
not have to correspond exactly to Abstraction’s interface. Typically, Implementor
provides only primitive operations; Abstraction defines higher-level operations
based on these primitives.
ConcreteImplementor – implements the Implementor interface and defines its
concrete implementation.
310313
SYSTEM DESIGN
32
DESIGN PATTERN: FAÇADE – MOTIVATION
Problem:
Structuring a system into subsystems helps reduce
complexity. A common design goal is to minimize the
communication and dependencies between subsystems.
How best to achieve this?
Solution: Introduce a Façade class that provides a single,
simplified interface to the more general facilities of a
subsystem.
310313
SYSTEM DESIGN
33
DESIGN PATTERNS: FAÇADE — DESCRIPTION
Intent
Provide a unified interface to a set of interfaces in a subsystem. Façade
defines a higher-level interface that makes the subsystem easier to use.
Solution
1. Clients communicate with subsystem objects by calling operations in
Façade.
2. Clients never (or as seldom as possible) directly access objects in
subsystem—any such access weakens the encapsulation.
3. Subsystem objects usually retain no knowledge of Client.
4. Subsystem objects do not normally maintain any reference to Façade.
Consequences

Eliminates hard to control tangled networks of object associations.

Reduces the number of objects with which Clients need to interface.

Promotes weak coupling, which enhances overall flexibility.
310313
SYSTEM DESIGN
34
DESIGN PATTERNS: FAÇADE — DESCRIPTION

Façade – knows which subsystem classes are responsible for a request
and delegates client requests to appropriate subsystem objects.

Subsystem classes – implement subsystem functionality; handle work
assigned by the Façade object; have no knowledge of Façade.
310313
SYSTEM DESIGN
35
DESIGN PATTERN: PROXY — MOTIVATION
Problem: Sometimes we want to defer the full cost of creating and
initializing an object until we actually need to use it
– e.g., in a document editor that can embed graphical objects in a
document, objects like large raster images can be expensive to create
– but, opening a document should be fast  avoid creating expensive
objects at once when the document is opened (also, usually not all
objects are visible at the same time anyway)
 expensive objects should be created on demand
Solution: Use another object, an image proxy, that acts as a
stand-in for the real image
– the proxy acts just like the image, instantiates it when needed and
forwards request to it after creating it
aTextDocument
anImageProxy
image
fileName
in memory
310313
anImage
data
on disk
SYSTEM DESIGN
36
DESIGN PATTERN: PROXY-DESCRIPTION
Intent
Provide a surrogate or placeholder for another object to control access to it.
Solution
1.
2.
3.
Create an abstract Subject class that defines the complete public interface of a
class, but does not implement it.
Derive a RealSubject class from Subject and implement the public interface as
needed to perform all required behaviour.
Derive a Proxy that creates the RealSubject and passes all requests to it.
Consequences


Proxy is extremely good for patching inflexible OO designs in a well-controlled
manner, often adding flexibility to the design.
Proxys can be used to
–
distribute objects to different object spaces or across networks (remote
proxy)
–
perform optimizations (virtual proxy)
–

allow additional housekeeping tasks to be done when an object is accessed
(smart reference).
Proxy can enhance RealSubject’s behaviour—particularly important when used
to encapsulate third party libraries.
310313
SYSTEM DESIGN
38
DESIGN PATTERN: PROXY-DESCRIPTION
Client
Subject
request()
..
.
RealSubject
request()
..
.
realSubject
Proxy
request()
..
.
realSubjectrequest();
Proxy – maintains a reference that lets Proxy access RealSubject. Proxy may refer
to Subject if the RealSubject and Subject interfaces are the same.
– provides an interface identical to Subject’s so that Proxy can be substituted for
RealSubject.
– controls access to RealSubject and may be responsible for creating and
deleting it.
Subject – defines the common interface for RealSubject and Proxy so that Proxy
can be used anywhere RealSubject is expected.
RealSubject – defines the real object that Proxy represents.
310313
SYSTEM DESIGN
39
GENERIC DESIGN MECHANISM :
MAKING DATA PERSISTENT USING AN RDBMS
Volatile memory-object structure
Our goal is to encapsulate
database access to hide its
implementation details!
Persistent memory-table structure

issues to consider for mapping classes/objects to a RDBMS:
– class /object structure  table structure
– OIDS -how to create and assign them (if required by the OO PL)
– inheritance ( if not supported in a relational DBMS)
– data type mismatches (programming language  DBMS)
310313
SYSTEM DESIGN
40
GENERIC DESIGN MECHANISM :
MAKING DATA PERSISTENT USING AN RDBMS
1. Brute Force
– Embed SQL in application
classes (e.g. JDBC class
libraries, ODBC API)
Application
classes
Not a database
encapsulation strategy!
SQL
database
Pros
– Can write code very quickly
– O.K. for small applications
and prototypes
One approach
: Customer
Cons
– Couples application classes
directly with database
schema making schema
changes require reworking
the code
310313
Database
build select
statement
select statement
result set
set data
values
SYSTEM DESIGN
41
GENERIC DESIGN MECHANISM :
MAKING DATA PERSISTENT USING AN RDBMS
2. Using Data Access Objects
– Encapsulate SQL statements
in one or more “data
classes”(e.g. Java Data
Object,Activex Data Object)
Data
classes
Application
classes
SQL
database
Pros
– Encapsulates the source
code that handles hardcoded transactions in one
place
Cons
– Needs recompilation of data
classes when changes are
made to the database
One approach
: Customer
Database
: CustData
read(customer)
get key values
key value(s)
build select
statement
select statement
result set
set data values
310313
SYSTEM DESIGN
42
EXAMPLE DATA ACCESS OBJECTS
310313
SYSTEM DESIGN
43
APPROACHES TO MAKING RDBMS DATA PERSISTENT
3. Using a Persistence
Framework
Application
classes
– A persistence layer maps
objects to the database so
that simple changes to the
database schema do not
affect the object code
Pros
– Application classes do not
know anything about the
database schema (they do
not even know that a
database is being used!)
310313
database
One approach
: Customer
: Persistence
Framework
: Mapping
Classes
Database
read(customer)
get key values
get maps
build select
statement
Cons
– Impacts performance
SQL
Persistence
Layer
select statement
set data values
SYSTEM DESIGN
44
EXAMPLE
Make
an
objects persistent
PERSISTENT DATA FRAMEWORK
1..*
0..1
PersistentObject
-isProxy : Boolean
-isPersistent : Boolean
-timestamp : DateTime
created
from
ClassMap
1
-name : String
+getInsertSqlFor()
+getDeleteSqlFor()
+getUpdateSqlFor()
+getSelectSqlFor()
1
1
PersistentTransaction
*
-tasks : Collection
+processTransaction()
+retry()
+addTransaction()
+addSaveObject()
+addRetrieveObject()
+addDeleteObject()
+addCriteria()
-attempt()
-rollback()
-commit()
Provides
Query and
Transaction
Processing
Cursor
-size : Integer
+nextObjects()
+nextProxies()
+nextRows()
+previousObjects()
+previousProxies()
+previousRows()
-defaultSize()
310313
-statementComponents : Collection
+buildForObjects()
+buildForCriteria()
+asString()
maps
+save()
+retrieve()
+delete()
*
*
creates
1
Maps
Objects to
Tables
SqlStatement
processed by
1
processed by
*
PersistentCrteria
-areSubclassesIncluded : Boolean
-forClass : Class
+addSelectXXX()
+addOrCriteria()
+perform()
1
processed by
PersistenceBroker
*
uses
-singleInstance : Object
-connections : Collection
+saveObject()
+retrieveObject()
+deleteObject()
+processCriteria()
connects to
+processTransaction()
1
+processSql()
-connectTo()
-disconnectFrom()
-retrieveClassMaps()
*
Interact with
Persistence
Mechanism
Encapsulate
Persistence
Mechanism
PersistenceMechanism
-connection : Connection
-name : String
+open()
+open()
+close()
+isOpen()
SYSTEM DESIGN
45
UP — SYSTEM DESIGN ACTIVITIES
Architect
Architectural
Design
Design
Use Cases
Use-Case
Engineer
Component
Engineer
310313
Design
Classes
Design
Subsystems
SYSTEM DESIGN
46
UP — SYSTEM DESIGN PROCESS

Design use cases
– identify design classes and/or subsystems for a use case
– distribute use case behaviour to design classes and/or subsystems
– specify requirements on operations of design classes and/or
subsystems and their interfaces
– capture nonfunctional implementation requirements

Design classes
– create design classes that fulfill all their functional and
nonfunctional requirements by specifying completely their:
 attributes, relationships, operations, interfaces, dependencies on
generic design mechanisms, etc.

Design subsystems
– define dependencies among subsystems
– define interfaces that subsystems provide
310313
SYSTEM DESIGN
47
UP — SYSTEM DESIGN ACTIVITIES
Architect
Architectural
Design
Design
Use Cases
Use-Case
Engineer
Component
Engineer
310313
Design
Classes
Design
Subsystems
SYSTEM DESIGN
48
USE-CASE DESIGN

Identify the participating design classes
– analysis classes that participate in the use case
– additional classes to handle any special requirements of analysis
use case (e.g., design goals)
– any other classes needed to implement the use case
(e.g., to accommodate the implementation environment)
 preserve traceability:
use-case realization–design  use-case realization–analysis  use case

Specify:
– class diagrams  show participating classes
 identify active classes
a thread or process  shown with a thicker border
– implementation requirements  collect the nonfunctional
requirements that will be handled during implementation
310313
SYSTEM DESIGN
49
UP — SYSTEM DESIGN ACTIVITIES
Architect
Architectural
Design
Design
Use Cases
Use-Case
Engineer
Component
Engineer
310313
Design
Classes
Design
Subsystems
SYSTEM DESIGN
50
7.4
CLASS DESIGN
A Design class is class whose specifications has been
completed to such a degree that it can be implemented.

design classes come from two places:
1. the problem domain
 refine analysis classes by adding implementation details
 may require analysis classes to be divided into two or more detailed
design classes
2. the solution domain
 utility class libraries, reusable components, component frameworks
(DCOM, CORBA, Enterprise JavaBeans, etc.)
 provides the technical tools to implement a system
310313
SYSTEM DESIGN
51
CLASS DESIGN — SOLUTION DOMAIN
For boundary classes we need to consider
– specific user interface technologies used
 in Visual Basic need design classes:
(1) stereotyped as «form» (2) representing “controls”
For entity classes we need to consider
– specific data management technologies used
 design classes that encapsulate a relational database
For control classes we need to consider
– distribution issues –> do we need a separate design class at each
node?
– performance issues –> do we merge with boundary/entity class?
– transaction issues –> do we need to incorporate transaction
management technology?
310313
SYSTEM DESIGN
52
7.4
CLASS DESIGN — ACTIVITIES

complete the specification by identifying/specifying:
– missing attributes, associations and operations
 not all messages become operations (e.g., actors, boundary classes)
 not all operations appear in interaction diagrams
– type signatures and visibility of attributes and operations
– constraints on operations –> invariants; preconditions; postconditions
– exceptions –> values that operations should not accept

select reusable components by identifying and adapting:
– class libraries –> conversion/“glue” classes and operations may be
needed
– generic design mechanisms for handling nonfunctional requirements
 persistence; object distribution; security; transaction management; error
handling, etc.
310313
SYSTEM DESIGN
53
CLASS DESIGN — ACTIVITIES (cont’d)

restructure the design model
– realize associations –> often realized as variables that provide
references among objects
 refine multiplicities, role names, association classes, qualified roles,
navigability of associations; consider programming language support
– increase reuse by use of inheritance/delegation

optimize the design model
– revise access paths to speed up access –> add new associations
– collapse classes –> classes with few attributes and little behavior
– cache expensive computations –> use derived attributes
– delay expensive computations –> e.g., image display
Describe using the syntax of the programming language.
310313
SYSTEM DESIGN
54
CLASS DESIGN: ACTIVE CLASSES
An active class has its own thread of control. It is usually boundary or
control classes and is shown with a thicker border in class diagram


Active classes can be identified by considering:
 The performance, throughput and availability requirements of different actors
as they interact with the system
e.g., a need for fast response time might be managed by a dedicated active object for
taking input and providing output
 The system’s distribution onto nodes — active objects needed to support
distribution onto several nodes
e.g., one active object per node and separate active objects to handle node intercommunication
 Other requirements
e.g., system startup and termination, liveness, deadlock avoidance, starvation
avoidance, reconfiguration of nodes, capacity of connections, etc.
310313
SYSTEM DESIGN
55
CLASS DESIGN GOAL: WELL-FORMED CLASSES
1.
High cohesion
 A class should model a single abstract concept and should have
operations that support the intent of the class
2.
Low coupling
 A class should be associated with just enough other classes to
allow it to realize its responsibilities
3.
Completeness and sufficiency
 A class should do what users of the class expect – no more and no
less
4.
Primitiveness
 A class should always make available the simplest and smallest
possible set of operations
310313
SYSTEM DESIGN
56
UP — SYSTEM DESIGN ACTIVITIES
Architect
Architectural
Design
Design
Use Cases
Use-Case
Engineer
Component
Engineer
310313
Design
Classes
Design
Subsystems
SYSTEM DESIGN
60
6.3.1
SUBSYSTEM DESIGN
m
subsystem
name

A subsystem is used to organize artifacts of the
design model into more manageable pieces
A subsystem can contain:
– design classes
– other subsystems

– use-case realizations
– interfaces
A use case can be designed as a collaboration of subsystems
rather than classes
 Can be represented as a class diagram of subsystems

Subsystems can be used on interaction diagrams
 This allows hierarchical decomposition
Subsystem can be refinements of packages or be directly identified
in the design workflow (if there is no analysis model)
310313
SYSTEM DESIGN
61
SUBSYSTEM DESIGN — COHESION & COUPLING
Goal: independent and loosely coupled but highly cohesive
cohesion - a measure of the number of functionally different things
a package has to do
 a package is most cohesive when it does only one thing
coupling - a measure of the number and types of interconnections
(dependencies) a package has with other packages
 a package has the lowest coupling when it has minimal
dependencies with other packages
There is a trade-off between cohesion and coupling
(7 ± 2 heuristic)
310313
SYSTEM DESIGN
62
SUBSYSTEM DESIGN — COHESION
coincidental
logical
Low
worst
“scatter-brained”
temporal
communicational
procedural
cohesion spectrum
functional
sequential
High
“single-minded”

coincidental - The subsystem does not achieve any definable function.

logical - The subsystem contains several similar, but slightly different functions.

temporal - The subsystem contains various functions that happen to be
executed at the same time.

procedural - The subsystem functions must be executed in a pre-specified
order.

communicational - All subsystem functions operate on the same data stream
or data structure.

sequential - The output from one part of the subsystem is input to the next
part.

functional - The subsystem has one and only one identifiable function.
best
310313
SYSTEM DESIGN
63
SUBSYSTEM DESIGN — COUPLING
no direct
stamp
data
Low







external
control
coupling spectrum
content
common
High
no direct - The subsystems are not related.
data - The subsystems pass only simple data (e.g., a parameter list). BEST!
stamp - The subsystems pass a portion of a data structure as an argument.
control - The subsystems pass control information (e.g., via a flag or
switch).
external - The subsystems are tied to an environment external to the
system.
common - Several subsystems reference a global common data area.
content - One subsystem makes use of data or control information
maintained within another subsystem. AVOID!
310313
SYSTEM DESIGN
64
6.3.4
SUBSYSTEM DESIGN — LAYERS AND PARTITIONS

Recursively dividing subsystems into smaller and simpler
subsystems leads to a hierarchy of subsystems/layers

Each layer (subsystem) provides higher-level services and uses
services of lower-level layers (subsystems)

Subsystem layer architecture:
1. closed layered architecture: each layer can only depend on the
layer immediately below it  lower coupling (more overhead)
2. open layered architecture: each layer can depend on any layer
below it  higher coupling (less overhead)

subsystem partitions:
– divide services in one layer into different subsystems
– results in peer to peer services within a layer
Usually there are 3 to 5 subsystem layers in practice.
310313
SYSTEM DESIGN
65
SUBSYSTEM DESIGN — LAYERS AND PARTITIONS
Application-specific layer
Application-general layer
Middleware layer
(Provides middleware services)
System-software layer
(Provides OS services)
310313
SYSTEM DESIGN
66
SUBSYSTEM DESIGN — LAYERS AND PARTITIONS

Application subsystems – come mainly from decomposing the
analysis packages
– application-specific: the part of the system that is not shared by
other subsystems
– application-general: the part of the system that is reusable within a
business or application domain

Middleware subsystems – reusable building blocks for utility
frameworks and services that are platform-independent
– generic design mechanisms, object request brokers, GUI toolkits

System-software subsystems – software for computing and
network infrastructure that is platform dependent
– O.S., DBMS, hardware interfaces, communication software
 encapsulate middleware and system-software subsystems
310313
SYSTEM DESIGN
67
RECALL ASU PACKAGES : DESIGN 4
Interfaces
People
Maintenance
Application-specific layer
Course
Registration
Course
Maintenance
Application-general layer
People
Data
310313
Course
Data
SYSTEM DESIGN
69
ASU SUBSYSTEMS AND DEPENDENCIES
m
Interfaces
m
System
Security
m
Application-specific layer
m
People
Maintenance
m
Course
Registration
Course
Maintenance
m
Report
Generation
Application-general layer
m
People
Data
310313
m
Course
Data
SYSTEM DESIGN
70
6.3.2
SUBSYSTEM DESIGN : INTERFACES
m
An interface is the set of operations that are accessible
from “outside” the subsystem to other subsystems.
Interface name

 also called the application programmer interface (API)
interface specification includes:
– operation names
– parameters and their type

– return values (if any)
the interface implementation is provided by classes or other
subsystems within the subsystem
 if a subsystem has a dependency directed toward it,
it is likely that it needs to provide an interface
 any client using an interface is independent of the
implementation of the subsystem
310313
SYSTEM DESIGN
71
ASU Course Registration System
CourseRegistration Subsystem
Interfaces
310313
SYSTEM DESIGN
72
ASU INTERFACES — COURSEREGISTRATION
SUBSYSTEM
CourseRegistration
Student
RegistrationMgr
Request
EnrollmentMgr
IEnrollment
IRegistration
PrepareBilling
InfoMgr
IBilling
310313
SelectCourse
ToTeachMgr
ICourses
SYSTEM DESIGN
73
ASU INTERFACES — COURSEREGISTRATION
SUBSYSTEM
Façade
class
CourseRegistration
Student
RegistrationMgr
Course
RegistrationMgr
ICourseRegistration
Student
RegistrationMgr
PrepareBilling
InfoMgr
SelectCourses
ToTeachMgr
Use the Façade design pattern to minimize coupling.
310313
SYSTEM DESIGN
74
ASU INTERFACES: ICOURSEREGISTRATION

An interface consists of a list of all the operations that
a
subsystem makes visible to the outside world.

For the CourseRegistration subsystem these can be
obtained by examining the sequence diagrams—
design containing the control classes inside the
subsystem and extracting the operations to which
these control classes respond.
310313
SYSTEM DESIGN
75
UP — SYSTEM DESIGN ACTIVITIES
Architect
Architectural
Design
Design
Use Cases
Use-Case
Engineer
Component
Engineer
310313
Design
Classes
Design
Subsystems
SYSTEM DESIGN
76
UP SYSTEM DESIGN ACTIVITIES:
ARCHITECTURAL DESIGN

Architectural design outlines the deployment model
by
– specifying the (physical) system architecture in terms of
physical computing nodes and their network
configuration.
– mapping subsystems onto the computing nodes.
310313
SYSTEM DESIGN
77
6.3.6
ARCHITECTURAL DESIGN :DEPLOYMENT MODEL
node
name
A deployment model describes how the
functionality of the system is physically
distributed to processing nodes
A deployment diagram shows:
– nodes: computational resources (e.g., processors)
– relationships: means of communication among nodes (e.g., network)

common distributed configurations use a three-tier architecture
– clients (to handle user interactions)  boundary classes
– database functionality (to store persistent data)  entity classes
– business/application logic  control classes
Client/server Architecture
(special case of three-tier architecture where business/
application logic is relocated to one of the other two tiers)
310313
SYSTEM DESIGN
78
DEPLOYMENT MODEL — DESIGN ISSUES

Which nodes are involved, and what are their capacities in
terms of processing power and memory size?

What types of connections are between the nodes, and what
communication protocols will be used?

What are the characteristics of the connections and
communication protocols ( e.g., bandwidth, availability, quality,
etc.)?

Is there any need for redundant processing capacity, fail-over
nodes, process migration, keeping backup data, etc.?
310313
SYSTEM DESIGN
79
ASU Course Registration System
Architectural Design
Deployment Model
310313
SYSTEM DESIGN
80
ASU DEPLOYMENT MODEL
Registrar
«intranet»
Dorm
310313
Web
server
«intranet»
«intranet»
Main
Building
«intranet»
Database
server
«intranet»
Library
SYSTEM DESIGN
81
ASU Course Registration System
Architectural Design
Subsystem Deployment
310313
SYSTEM DESIGN
82
ASU DEPLOYMENT MODEL — WEB SERVER NODE
Web Server
m
System
Security
310313
m
People
Maintenance
m
Course
Registration
m
Course
Maintenance
m
Report
Generation
SYSTEM DESIGN
83
ASU DEPLOYMENT MODEL — REGISTRAR NODE
Registrar
System
Security
Interfaces
People
Maintenance
Course
Registration
People
Data
310313
Course
Maintenance
Report
Generation
Course
Data
SYSTEM DESIGN
84
ASU DEPLOYMENT MODEL — DORM NODE
Dorm
m
Interfaces
310313
SYSTEM DESIGN
85
ASU DEPLOYMENT MODEL — DORM NODE
Dorm
System
Security
Interfaces
Course
Registration
People
Data
310313
Course
Data
SYSTEM DESIGN
86
SYSTEM DESIGN ACTIVITIES — RETROSPECTIVE
Use-case design
– Identifies active classes and additional classes needed to meet design
goals and handle the implementation environment
Class design
– Completes the specification of each class (attributes, operations);
– Identifies reusable components;
– Restructures and optimizes the design model
Subsystem design  subsystem, interfaces
– Organize classes into cohesive, loosely coupled units;
Architectural  deployment model
– Outlines the deployment of the system onto processing nodes.
– Specifies the physical distribution of subsystem onto nodes.
310313
SYSTEM DESIGN
87
SUMMARY — SYSTEM DESIGN
Design Model contains:

Use-case realizations—design
 used to construct “builds” during implementation

Design classes, their operations, attributes, relationships and
implementation requirements
 implemented by files containing source code

Subsystems, their dependencies and their interfaces
 implemented by implementation subsystems containing
source code, scripts, binaries, executables, etc.

Deployment Model
These are all documented in the
System Design Specification (SDS)
310313
SYSTEM DESIGN
88