Chapter
p
7,, System
y
Design
g – Architecture
Organization
Object-Oriented
SoftwareConstruction
Armin B. Cremers, Tobias Rho, Daniel Speicher &
Holger Mügge
(based on Bruegge & Dutoit)
Overview
♦
Where are we right now? (last Lecture):
Š Overview of System Design
Š Subsystem Decomposition

♦
Architectural Styles (Client-Server, Peer-to-Peer, … )
Overview of this Lecture:
Š Architecture Organization


Refinement of Decomposition
Involvement of more technical issues
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
2
Software Lifecycle Activities
Requirements
Elicitation
Analysis
System
Design
...system design
System design is concerned with
Object
Implementhe overall
aspects of the
Testing
Design
tation
system.
The main goals are:
Low cost, good response time,
high reliability.
Expressed in
Terms of
Structured
by
Realized
by
Implemented
by
class...
class
class...
class...
Use Case
Model
Application
Domain
Objects
Subsystems
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Solution
Domain
Objects
Verified
by
?
class.... ?
Source
Code
Object-Oriented Software Construction
Test
Cases
3
Activities during System Design
Activities during
g
System
Design
1. Identify
1
Id tif
Design Goals
2. Decompose
into Subsystems
3. Map Hardware
to Software
4. Define Data
Persistency
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
8 Anticipate
8.
A ti i t
Change
7. Find Boundary
Conditions
6. Design Global
Control Flow
5. Define Access
Control
Object-Oriented Software Construction
4
Aspects for Architecture Organization
♦
♦
♦
♦
♦
♦
3. Mapping of Subsystem to Hardware
Š Determine the hardware configuration
Selection of Off-The-Shelf
Off The Shelf Components
Š Purchase existing components to realize subsystems more
economically
4. Design of Persistent Data Management
Š Realize Storage System for objects that outlive a single execution of
the system
5. Define Access Control
Š Protect
P t t Shared
Sh d objects
bj t ffor concurrentt access
6. Define Global Control flow
Š Determine the sequence of operations within the subsystems
7 D
7.
Define
fi B
Boundary
d
C
Conditions
diti
Š Determine conditions for system initialization and shut-down
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
5
3. Hardware Mapping
This activity addresses two questions:
♦ What is the most appropriate
pp p
hardware environment?
♦ How are objects and subsystems mapped on the chosen hardware?
Š Mapping Objects onto Reality: Processor, Memory, Input/Output
Š Mapping Associations onto Reality: Connectivity
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
6
Hardware Mapping:
Mapping the Subsystems – Important Issues
♦
♦
♦
Processor issues:
Š Is the computation rate too demanding for a single processor?
Š Can we get a speedup by distributing tasks across several
processors?
Š How many processors are required to maintain steady state load?
Memory issues:
Š Is there enough memory to buffer bursts of requests?
I/O issues:
Š Does the response time exceed the available communication
bandwidth between subsystems ?
Î Still worth considering in the 21th century ;-) ?
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
7
Hardware Mapping:
Mapping the Subsystems Associations
♦
Describe the physical connectivity of the hardware:
Š Which associations in the object model are mapped to physical
connections?
Š Which of the client-supplier relationships in the analysis/design model
correspond to physical connections?
♦
Describe the logical connectivity (subsystem associations):
Š Identify associations that do not directly map into physical connection.
Distinction:

Logical Connection within a local system
Logical Connection within a distributed system

Æ How should these associations be implemented?

Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
8
Hardware Mapping:
Logical vs. Physical Connectivity
Subsystem 1
Layer
y 1
Subsystem
y
2
Layer 2
Layer 1
Layer 3
Layer 2
Layer 4
Layer 3
Application
Presentation
Session
T
Transport
t
Network
DataLink
Physical
Bidirectional
associations for each
layer
Processor 1
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Application
Presentation
Session
Transport
Network
DataLink
Physical
Processor 2
Object-Oriented Software Construction
Logical
C
Connectivity
ti it
Layers
Physical
Connectivity
9
Hardware Mapping:
Connectivity Mapping Questions
♦
What is the connectivity among physical units?
ring
♦
♦
star
tree
What is the appropriate communication protocol between the
subsystems, especially Distributed Systems?
Š Function of required bandwidth, latency and desired reliability,
quality
y of service (Q
(QoS))
desired q
Is certain functionality already available in hardware?
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
10
Software Mapping:
Selecting additional Software
♦
♦
Selection of existing software subsystems (components, services,
frameworks) that realize technical aspects
Š Communication subsystems
Š Data Management subsystems
COTS ((Commercial Off-the-Shelf)) Components
p
Š Products that are designed to be easily installed and to interoperate with
existing system components.
Š Mostly no adaptation at client-side is necessary
Š Mass-produced Æ relatively low cost.
♦
Selecting a Virtual Machine:
Š Environment including operating system and any additional software
components that are needed (e.g. DBMS)
Š Reduces the distance between the system and hardware
Š Reduction of development work (concentration on business code)
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
11
Drawing Hardware/Software Mappings
in UML (Excurse)
♦
System design must model static and dynamic structures:
Š Component Diagrams for static structures

show the structure at design time or compilation time
Š Deployment Diagram for dynamic structures

show the structure of the run-time system
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
12
Component Diagram
♦
♦
Component Diagram (UML 2.0)
Š A graph of components connected by dependency relationships.
Š Shows the dependencies among software components
Dependencies are shown as dashed arrows from the client
p
to the supplier
pp
component.
p
component
WebServer
FireFox
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Database
Object-Oriented Software Construction
13
Component Diagram
♦
Components can be refined to include information about the
interfaces they provide (through ports) and the parts (classes,
subsystems) they contain:
WebServer
port
port name
URI
GET
provided interface
POST
HttpRequest
DBQuery
required
i d iinterface
t f
FireFox
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
14
Deployment Diagram
♦
Deployment diagrams are useful for showing a system
design
g after the following
g decisions are made
Š Subsystem decomposition
Š Hardware Mapping
Š Selection of additional Software Components
♦
A deployment diagram is a graph of nodes connected by
communication associations.
Š Nodes are shown as 3-D boxes.
Š Nodes
N d may contain
t i componentt iinstances.
t
Š Components may contain objects (indicating that the object is
part of the component)
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
15
Deployment Diagram Example
Compile Time
Dependency
:Unixhost
:DB2
:WebServer
Runtime
Dependency
:PC
:FireFox
:CookieMgT
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
16
Software Mapping:
Problems with Connecting Subsystems
♦
Connecting subsystems yields additional problems:
Š Subsystems are implemented in different programming
languages
Š The intention (semantics) cannot be derived exactly from the
interface (Example: difference between POST and GET?!)
Š Subsystems might be built on different abstraction levels /
communication layers
Provider
<<Interface>>
Æ How to achieve
interoperable subsystems?
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Client
Object-Oriented Software Construction
17
Software Mapping:
Demand: Interoperability
♦
Interoperability: The ability of two or more systems or components to
exchange information and to use the information that has been
exchanged
h
d
IEEE Glossary, 1990
♦
Interoperability denote systems that work together
Microsoft Webpage
♦
♦
In general: Use standards!
(Selected) Requirements for interoperable Systems:
Š Standards
St d d ffor Communication
C
i ti ffor distributed
di t ib t d systems
t
Š Semantic descriptions for interfaces
Š Mediator components
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
18
Software Mapping:
Standards for distributed systems
♦
Standards for integrating distributed Subsystems:
Š Middleware Frameworks (CORBA, RMI, COM, SOAP)
<<Interface>>
Provider
(Java)
Client
(C++)
Skeletons
Stub
Marshaling arguments
Unmarshaling arguments
Remote Reference Layer (RMI),
Object Request Broker (CORBA)
Š Interface Definition Languages (IDL) are used to formulate Interfaces
of Subsystems in an language neutral way
Š Compiler transforms IDL description to concrete components (Java,
C++) and generates Stubs and Skeletons
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
19
Software Mapping:
Semantic Descriptions
♦
Semantic Descriptions (Annotations) are instrumental to clarify the
intention of a subsystem
requestData()
Provider
requestSession()
Questions:
requestNewSession()
Æ Order?
Od ?
closeSession()
Æ Any Iterations()?
query()
Æ(Exact) Purpose?
ÆDependencies?
getSemantics( )
♦
♦
Hardly implemented in standard technologies, only in academic fields
or in terms of proprietary solutions
New Approach:
pp
Ontology:
gy Notation for describing
g the semantic
concepts of an interface
Š To-Date: Promising, but still hardly implemented
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
20
Software Mapping:
Adapters
♦
Problem: Incompatible Interfaces and/or different data formats
(syntax):
Generate
RandomNumber
getNextNumber( )
Produces
P
d
„one“,
“
„two“, „three“...
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
German Number
Printer
Expects
E
t „eins“,
i “
„zwei“, „drei“...
Object-Oriented Software Construction
21
Software Mapping:
Adapters
♦
♦
Problem: Incompatible Interfaces and/or different data formats
(syntax):
Solution: Adapter (implements both interfaces and transforms data in an
format, understandable for the client)
Generate
RandomNumber
Adapter
German Number
Printer
private GenerateRandomNumber myRandom;
public String getNextNumber( ) {
St i input
String
i
t = myRandom.getNextNumber(
R d
tN tN b ( ));
if (input == „one“) return „eins“;
if (input == „two“) return „zwei“;
}
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
22
4. Data Management
♦
Some objects in the models need to be persistent
Š In particular Entity Objects
Š Boundary
B
d
Obj
Objects
t as wellll ((e.g. user preferences
f
iin fforms))
♦
A persistent object can be realized with one of the
following
Š Files



Cheap, simple, permanent storage
Low level (Read
(Read, Write)
Applications must add code to provide suitable level of
abstraction
Š Database


Powerful, scalable, portable
Supports multiple writers and readers
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
23
File or Database?
♦
When should you choose a file system?
Š For extensive data (images)
Š For lots of raw data (core dump, event trace)
Š Temporary Data that is kept only for a short time
♦
When should you choose a database?
Š Data that require access at fine levels of details by multiple
users and/or applications (concurrent access)
Š Data that must be ported across multiple platforms
(heterogeneous systems)
Š Rollback and Transactions play an important aspect
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
24
Database Management System
♦
♦
A collection of routines that enables you to store, modify,
and extract information from a database
Main functions (realization depends on Vendor)
Š Concurrent (write) access to the stored data
Š Transaction
T
ti Management
M
t
Š Rollback Mechanisms
Š Crash Recoveryy
Š Optimizer for complex Queries
Š Integrity Checks
Š Authorization
A th i ti
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
25
Relational Databases
♦
Data are stored in tables that comply with a predefined type called a
(relational) schema
Š Column represents an attribute of a schema
Š Row represents data item as a tuple of attribute values
Š Several tuples in different tables represent the attribute values of an
object
♦
Mapping rules to convert object-oriented model to a relation scheme
♦
Id l ffor querying
Ideal
i llarge d
data
t sets
t with
ith complex
l queries
i
♦
SQL is the standard language defining and manipulating tables
♦
Leading
g commercial databases:
Š DB2 (IBM)
Š Oracle
Š MySQL
M SQL
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
26
Object-Oriented Databases
♦
♦
♦
♦
♦
Support of all fundamental object modeling concepts
Š Stores data as objects and associations
Š Classes, Attributes, Methods, Associations, Inheritance
Reduce the time for the initial development of storage subsystem:
Š Easy Mapping of Object model to Database schema
Disadvantage:
Š Slower than relational databases even for simple queries
Commercial Vendor
Š ObjectStore
Š Realization as “add-ons” for Relational DB (DB2) Æ Sense?
New Hypes
Š XML Databases (mostly add-ons, many open source projects)
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
27
5. Defining Access Control
♦
In multi-user systems different actors have access to different
functionality and data.
Š Example:


♦
♦
♦
System Admin has unlimited access to any data
Client only has read access to data
Definition of access right during analysis:
Š Associate different use cases with different actors.
During system:
Š Determining which objects are shared among actors.
actors
Š Define access rights for each objects (Æ access matrix)
Subtopics here:
Š Authentication
Š Encryption
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
28
Access Matrix
♦
We model access on classes with an access matrix.
Š The rows of the matrix represents the actors of the system
Š The column represent classes whose access we want to control.
♦
Access
ccess Right:
g t An e
entry
t y in the
t e access matrix.
at
Itt lists
sts tthe
e ope
operations
at o s
that can be executed on instances of the class by the actor.
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
29
Access Matrix: Example
Objects
Actors
External
Organizer
Manager
PressRelease
Cashflow
read( )
read( )
read( )
write( )
compute( )
submit( )
annoyAbout( )
Reject( )
read( )
Employee
adjust( )
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
read( )
Object-Oriented Software Construction
30
Authentication and Encryption
♦
Authentication
Š Process of verifying the association between the identity of a user (or
calling subsystem) and the system



User name / password
Smart Cards
Biometric Sensors (analyzing patterns of blood vessels in eyes / fingers
♦
Encryption
Š Translating a message (plaintext) into an encrypted message
( i h t t)
(ciphertext).
Š A key is used to encrypt (sender) and decrypt (receiver) a message
♦
Both approaches are fundamentally difficult problems
Š Æ Select Off-the-Shelf packages !
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
31
Different Options for Access Control
Static:
♦ Global Access Tables ((as shown))
♦ Access Control Lists (who may does what on a given
object)
♦ Capabilities (given an actor: what can he do to what
objects?)
♦ Rules
Š more simple
i l tto write
it and
d read
d
Dynamic
y
♦ Rules
♦ Proxies
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
32
6. Design Global Control Flow
♦
Control Flow is the sequencing of actions in a system
Š Deciding
g which operations
p
will be executed in which order
Š Some order is represented explicitly in the code (e.g. order of
statements)
Š Some order is given implicitly by (object-oriented)
(object oriented) language
semantics (e.g. overloading, type of object decides which method
version is executed)
♦
Control flow is modeled by control objects
objects.
Š Record external events
Š Store temporary states about events
Š Issue the right sequence of method calls on both boundary and
entity objects
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
33
Design Global Control Flow
♦
Three main control models:
Š Procedure-driven control

explicit

easy to understand (most often … ;-) )

hard to change
Š Event-driven control

observer pattern (aka publisher subscriber)

callback methods in frameworks

somewhat implicit (you have to know where to look)

more flexible, reusable
Š Thread-based control

parallel execution (often only pseudo parallel)

implicit

sometimes difficult to understand, test, maintain

enable flexible UIs and non-blocking behavior in distributed systems
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
34
Decide on Software Control
♦
Event-driven control
Š Control object runs a loop managing external events

Example (Data) Model has changed
Š Whenever an event becomes available, it is dispatched to
appropriate receiver components
Š Very flexible
flexible, good for the design of graphical user interfaces
interfaces, easy
to extend
:Control
Update
Model has changed
:Model
Update
:View
i
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
:View
Update
:View
Object-Oriented Software Construction
35
Event-Driven Control Flow
Observer Pattern
Two phases
1 Configuration (who observes whom)
1.
2. Notification about changes
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
36
Decide on Software Control
♦
Thread-based (or decentralized) control
Š Control resides in several independent objects:

Each external event is assigned a single Thread

Each new Thread handles an event
Š Possible speedup by mapping the objects on different processors
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
37
7. Boundary Conditions (1/2)
♦
♦
Most of the system design effort is concerned with steady-state
behavior.
However, the system design phase must also address the initiation
and finalization of the system. This is addressed by a set of new use
cases called administration use cases
Š Initialization
I iti li ti describes
d
ib h
how th
the system
t
iis b
brought
ht ffrom an non
initialized state to steady-state ("startup use cases”).
 How does the system start up?
 What
Wh t data
d t need
d to
t be
b accessed
d att startup
t t time?
ti ?
 What services have to registered?
 What does the user interface do at start up time?
 How does it present itself to the user?
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
38
7. Boundary Conditions (2/2)
Š Termination

Describes what resources are cleaned up and which systems are
p termination (("termination use cases").
)
notified upon
ƒ Are single subsystems allowed to terminate?
ƒ Are other subsystems notified if a single subsystem terminates?
ƒ How are local updates communicated to the database?
Š Failure


Many possible causes: Bugs, errors, external problems (power supply).
Good system design foresees fatal failures (“failure use cases”).
ƒ How does the system behave when a node or communication link
f il ? A
fails?
Are th
there b
backup
k communication
i ti lilinks?
k ?
ƒ How does the system recover from failure? Is this different from
initialization?
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
39
8. Anticipating Change
♦
… in the next lecture …
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
40
Architecture Organization
Iterative Process
Define design
goals
Define
subsystems
implement
subsystems
Map subsystem to hardware/
software platform
Manage persistent data
Define access control
policies
Select a global control
flow
Describe boundary
conditions
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
41
Summary
♦
♦
♦
♦
♦
♦
Hardware/Software mapping
Persistent data management
g
Global resource handling
Software control selection
Boundary conditions
Each of these activities revises the subsystem decomposition to
address a specific issue
issue. Once these activities are completed
completed, the
interface of the subsystems can be defined.
Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit)
Object-Oriented Software Construction
42