Object-Oriented Software Engineering

Using UML, Patterns, and Java

Goals
Chapter 7
System Design:
Addressing Design
Overview

System Design I
 Overview of System Design
 Design Goals
 Subsystem Decomposition
 Architectural Styles

System Design II
• Hardware/Software Mapping
• Persistent Data Management
• Global Resource Handling and Access Control
• Software Control
• Boundary Conditions

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 2

Hardware Software Mapping
• This system design activity addresses two
questions:
• How shall we realize the subsystems: With hardware or
with software?
• How do we map the object model onto the chosen
hardware and/or software?
• Mapping the Objects:
• Processor, Memory, Input/Output
• Mapping the Associations:
• Network connections

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 3

Mapping Objects onto Hardware

• Control Objects -> Processor

• Is the computation rate too demanding for a single
processor?
• Can we get a speedup by distributing objects across
several processors?
• How many processors are required to maintain a
steady state load?
• Entity Objects -> Memory
• Is there enough memory to buffer bursts of requests?
• Boundary Objects -> Input/Output Devices
• Do we need an extra piece of hardware to handle the
data generation rates?
• Can the desired response time be realized with the
available communication bandwidth between
subsystems?

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 4

Mapping the Associations: Connectivity

• Describe the physical connectivity

• (“physical layer in the OSI Reference Model”)
• Describes which associations in the object model
are mapped to physical connections.
• Describe the logical connectivity (subsystem
associations)
• Associations that do not directly map into physical
connections.
• In which layer should these associations be
implemented?
• Informal connectivity drawings often contain
both types of connectivity
• Practiced by many developers, sometimes confusing.

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 5

Hardware-Software Mapping Difficulties

• Much of the difficulty of designing a system

comes from addressing externally-imposed
hardware and software constraints
• Certain tasks have to be at specific locations
• Example: Withdrawing money from an ATM
machine
• Some hardware components have to be used from a
specific manufacturer
• Example: To send DVB-T signals, the system has to
use components from a company that provides
DVB-T transmitters.

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 6

Hardware/Software Mappings in UML

• A UML component is a building block of the system.

It is represented as a rectangle with a tabbed
rectangle symbol inside
• Components have different lifetimes:
• Some exist only at design time
• Classes, associations
• Others exist until compile time
• Source code, pointers
• Some exist at link or only at runtime
• Linkable libraries, executables, addresses
• The Hardware/Software Mapping addresses
dependencies and distribution issues of UML
components during system design.
Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 7

Two New UML Diagram Types

• Deployment Diagram:
• Illustrates the distribution of components at run-time.
• Deployment diagrams use nodes and connections to
depict the physical resources in the system.
• Component Diagram:
• Illustrates dependencies between components at
design time, compilation time and runtime

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 8

Deployment Diagram
• Deployment diagrams are useful for showing a
system design after these system design
decisions have been made:
• Subsystem decomposition
• Concurrency :PC :Server
• Hardware/Software Mapping
• A deployment diagram is a graph of nodes and
connections (“communication associations”)
• Nodes are shown as 3-D boxes
• Connections between nodes are shown as solid lines
• Nodes may contain components
• Components can be connected by “lollipops” and
“grabbers”
• Components may contain objects (indicating that
the object is part of the component).
Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 9

UML Component Diagram
• Used to model the top-level view of the system
design in terms of components and dependencies
among the components. Components can be
• source code, linkable libraries, executables
• The dependencies (edges in the graph) are shown
as dashed lines with arrows from the client
component to the supplier component:
• The lines are often also called connectors
• The types of dependencies are implementation language
specific
• Informally also called “software wiring diagram“
because it show how the software components are
wired together in the overall application.

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 10

UML Interfaces: Lollipops and Sockets

• A UML interface describes a group of operations

used or created by UML components.
• There are two types of interfaces: provided and
required interfaces.
• A provided interface is modeled using the lollipop
notation
• A required interface is modeled using the socket
notation.
• A port specifies a distinct interaction point
between the component and its environment.
• Ports are depicted as small squares on the sides of
classifiers.

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 11

Component Diagram Example
Dependency.!

reservations
UML!
Component!

update

UML Interface!

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 12

Deployment Diagram Example
Dependency !
UML Node! (in a node)!

UML!
Interface!

Dependency !
(between nodes)!

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 13

ARENA Deployment Diagram

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 14

Data Management

• Some objects in the system model need to be

persistent:
• Values for their attributes have a lifetime longer than a
single execution
• A persistent object can be realized with one of
the following mechanisms:
• Filesystem:
• If the data are used by multiple readers but a
single writer
• Database:
• If the data are used by concurrent writers and
readers.

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 15

Data Management Questions

• How often is the database accessed?

• What is the expected request (query) rate? The worst
case?
• What is the size of typical and worst case requests?
• Do the data need to be archived?
• Should the data be distributed?
• Does the system design try to hide the location of the
databases (location transparency)?
• Is there a need for a single interface to access
the data?
• What is the query format?
• Should the data format be extensible?

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 16

Mapping Object Models

• UML object models can be mapped to relational

databases
• The mapping:
• Each class is mapped to its own table
• Each class attribute is mapped to a column in the table
• An instance of a class represents a row in the table
• One-to-many associations are implemented with a
buried foreign key
• Many-to-many associations are mapped own
tables
• Methods are not mapped

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 17

Global Resource Handling

• Discusses access control

• Describes access rights for different classes of
actors
• Describes how object guard against
unauthorized access.

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 18

Defining Access Control

• In multi-user systems different actors usually

have different access rights to different
functionality and data
• How do we model these accesses?
• During analysis we model them by associating different
use cases with different actors
• During system design we model them determining
which objects are shared among actors.

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 19

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 Right: An entry in the access matrix. It

lists the operations that can be executed on
instances of the class by the actor.

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 20

 Access Matrix Example
Classes Access Rights

Actors Arena League Tournament Match

Operator <<create>> <<create>>

createUser() archive()
view ()
LeagueOwner view () edit () <<create>> <<create>>
archive() end()
schedule()
view()
Player view() view() applyFor() play()
applyForOwner() subscribe() view() forfeit()

Spectator view() view() view() view()

applyForPlayer() subscribe() replay()

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 21

Global Resource Questions

• Does the system need authentication?

• If yes, what is the authentication scheme?
• User name and password? Access control list
• Tickets? Capability-based
• What is the user interface for authentication?
• Does the system need a network-wide name
server?
• How is a service known to the rest of the
system?
• At runtime? At compile time?
• By Port?
• By Name?

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 22

Decide on Software Control

Two major design choices:

1. Choose implicit control
2. Choose explicit control
• Centralized or decentralized
• Centralized control:
• Procedure-driven: Control resides within program code.
• Event-driven: Control resides within a dispatcher calling
functions via callbacks.
• Decentralized control
• Control resides in several independent objects.
• Examples: Message based system, RMI
• Possible speedup by mapping the objects on different
processors, increased communication overhead.

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 23

 Software Control

Explicit Control Implicit Control

Rule-based
Logic Programming
Control

Decentralized Centralized
Control Control

Event-based Procedural
Control Control.
Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 24

Centralized vs. Decentralized Designs

• Centralized Design
• One control object or subsystem ("spider") controls
everything
• Pro: Change in the control structure is very easy
• Con: The single control object is a possible
performance bottleneck
• Decentralized Design
• Not a single object is in control, control is distributed;
That means, there is more than one control object
• Con: The responsibility is spread out
• Pro: Fits nicely into object-oriented development

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 25

Centralized vs. Decentralized Designs (2)

• Should you use a centralized or decentralized

design?
• Take the sequence diagrams and control objects
from the analysis model
• Check the participation of the control objects in
the sequence diagrams
• If the sequence diagram looks like a fork =>
Centralized design
• If the sequence diagram looks like a stair =>
Decentralized design.

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 26

Boundary Conditions

• Initialization
• The system is brought from a non-initialized state to
steady-state
• Termination
• Resources are cleaned up and other systems are
notified upon termination
• Failure
• Possible failures: Bugs, errors, external problems
• Good system design foresees fatal failures and
provides mechanisms to deal with them.

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 27

Boundary Condition Questions

• Initialization
• What data need to be accessed at startup time?
• What services have to registered?
• What does the user interface do at start up time?
• Termination
• Are single subsystems allowed to terminate?
• Are subsystems notified if a single subsystem
terminates?
• How are updates communicated to the database?
• Failure
• How does the system behave when a node or
communication link fails?
• How does the system recover from failure?.

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 28

Modeling Boundary Conditions

• Boundary conditions are best modeled as use

cases with actors and objects
• We call them boundary use cases or
administrative use cases
• Actor: often the system administrator
• Interesting use cases:
• Start up of a subsystem
• Start up of the full system
• Termination of a subsystem
• Error in a subsystem or component, failure of a
subsystem or component.

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 29

Example: Boundary Use Case for ARENA

• Let us assume, we identified the subsystem

AdvertisementServer during system design
• This server takes a big load during the holiday
season
• During hardware software mapping we decide to
dedicate a special node for this server
• For this node we define a new boundary use
case ManageServer
• ManageServer includes all the functions
necessary to start up and shutdown the
AdvertisementServer.

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 30

 ManageServer Boundary Use Case

<<include>>

StartServer

Server <<include>>

Administrator

ManageServer
ShutdownServer

<<include>>

ConfigureServer

Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 31

Summary
• System design activities:
• Concurrency identification
• Hardware/Software mapping
• Persistent data management
• Global resource handling
• Software control selection
• Boundary conditions
• Each of these activities may affect the
subsystem decomposition
• Two new UML Notations
• UML Component Diagram: Showing compile time and
runtime dependencies between subsystems
• UML Deployment Diagram: Drawing the runtime
configuration of the system.
Bernd Bruegge & Allen H. Dutoit

Object-Oriented Software Engineering: Using UML, Patterns, and Java 32