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