Mrs.M.

Vijaya Bharathi
Assistant Professor
Department of CSE
GITAM Deemed to Be University
Visakhapatnam – 530045
Email: [email protected]
Mobile-8897987132

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
1
 UNIT-3

System Design
Decomposing the System

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
2
 Syllabus
PART 1 : System Design: Decomposing the System

System Design Concepts:

1.Subsystems and Classes

2.Services and Subsystem Interfaces,

3.Coupling and Cohesion

4.Layers and Partitions

Architectural Styles System Design Activities:

5.From Objects to Subsystems

6.Analysis Model for a Route Planning System

7.Identifying Design Goals

8.Identifying Subsystems

Design, ARENA Case study

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
3
PART 2 :System Design: Addressing Design Goals

An Overview of System Design Activities Concepts:

UML Deployment Diagrams,

System Design Activities

PART 3 Addressing Design Goals

Mapping Subsystems to Processors and Components

Identifying and Storing Persistent Data

Providing Access Control

Designing the Global Control Flow

Identifying Services

Identifying Boundary Conditions, Reviewing System

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
4
FLOOR PLAN EXAMPLE

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
5
 Example of floor plan design

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
6
Part 1 :system design concepts
♦ Subsystem :Collection of classes, associations, operations,
events and constraints that are interrelated
⬥ Seed for subsystems: UML Objects and Classes.

♦ (Subsystem) Service:
⬥ Group of operations provided by the subsystem
⬥ Seed for services: Subsystem use cases

♦ 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

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
7
• subsystem -- a smaller, simpler part of a larger system
• a subsystem is made of a number of solution domain classes
• often one developer or development team is responsible for one subsystem

• service -- a set of related operations that share a common purpose

• subsystem interface -- a set of operations of a subsystem available

to other subsystems.
• One subsystem provides services to others, specified through its interface
• Application Programmer Interface (API) -- refinement of general subsystem
interface
• subsystem decomposition -- the activity of identifying subsystems,
their services, and their relationships to each other

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
8
 1.Sub systems and classes

♦ A subsystem is a replaceable part of the system with well-

defined interfaces that encapsulates the state and behavior of its
contained classes.
♦ A subsystem typically corresponds to the amount of work that a
single developer or a single development team can tackle.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
9
 2.Services and sub systems interfaces
♦ A subsystem is characterized by the services it provides to other
subsystems. A service is a set of related operations that share a
common purpose.
♦ A subsystem providing a notification service, for example, defines
operations to send notices, look up notification channels, and
subscribe and unsubscribe to a channel.
♦ The set of operations of a subsystem that are available toother
subsystems form the subsystem interface.
♦ The subsystem interface includes the name of the operations, their
parameters, their types, and their return values. System design
focuses on defining the services provided by each subsystem, that
is, enumerating the operations, their parameters, and their high-
level behavior.
♦ Object design will focus on the application programmer interface
(API), which refines and extends the subsystem interfaces.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
10
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
11
♦ In UML, components can represent both logical and physical
components. A logical component corresponds to a subsystem
that has no explicit run-time equivalent
♦ for example, individual business components that are
composed together into a single run-time application logic
layer.
♦ A physical component corresponds to a subsystem that as an
explicit run-time equivalent, for example, a database server.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
12
 3.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:

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
13
 4.Partitions and Layers

Partitioning and layering are techniques to achieve low coupling.

A large system is usually decomposed into subsystems using
both, layers and partitions.

♦ Partitions vertically divide a system into several independent

(or weakly-coupled) subsystems that provide services on the
same level of abstraction.

♦ A layer is a subsystem that provides subsystem services to a

higher layers (level of abstraction)
⬥ A layer can only depend on lower layers
⬥ A layer has no knowledge of higher layers

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
14
Subsystem Decomposition into Layers

Layer 1

Layer 2

Layer 3

Ideally use one package for each

subsystem
♦ Subsystem Decomposition Heuristics:
♦ No more than 7+/-2 subsystems
⬥ More subsystems increase cohesion but also complexity (more
services)

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
15
Relationships between Subsystems

♦ Layer relationship
⬥ Layer A “Calls” Layer B (runtime)
⬥ Layer A “Depends on” Layer B (“make” dependency, compile
time)
♦ Partition relationship
⬥ The subsystem have mutual but not deep knowledge about each
other
⬥ Partition A “Calls” partition B and partition B “Calls” partition A

Actually, this will depend on the

directionality?

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
16
Architectural Styles System Design Activities:
♦ A software architecture includes system decomposition, global
control flow, handling of boundary conditions, and intersub
system communication protocols [Shaw & Garlan, 1996].
♦ subsystems access and modify a single data structure called the
central repository.
♦ Subsystems are relatively independent and interact only
through the repository.
♦ Control flow can be dictated either by the central
repository(e.g., triggers on the data invoke peripheral systems)
or by the subsystems (e.g., independent flow of control and
synchronization through locks in the repository)

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
17
Repository :component diagram

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
18
♦ The repository subsystem can also be used for implementing
the global control flow. In the compiler example of Figure
each individual tool (e.g., the compiler, the debugger, andthe
editor) is invoked by the user.
♦ The repository only ensures that concurrent accesses are
serialized. Conversely, the repository can be used to invoke the
subsystems based on the state of the central data structure.
These systems are called “blackboard systems.”
♦ The HEARSAY II speech understanding system [Erman et al.,
1980], one of the first blackboard systems, invoked tools based
on the current state of the blackboard.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
19
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
20
Software Architectural Styles
♦ Subsystem decomposition
⬥ Identification of subsystems, services, and their relationship to each
other.
♦ Specification of the system decomposition is critical.

♦ Patterns for software architecture

⬥ Client/Server
⬥ Peer-To-Peer
⬥ Repository
⬥ Model/View/Controller
⬥ Pipes and Filters

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
21
 MVC Architectural style
♦ Model/View/Controller (MVC) architectural style in Figure
subsystems are classified into three different types: model
subsystems maintain domain knowledge, view subsystems
display it to the user, and controller subsystems manage the
sequence of interactions with the user.
♦ The model subsystems are developed such that they do not
depend on any view or controller subsystem. Changes in their
state are propagated to the view subsystem via a
subscribe/notify protocol.
♦ The MVC is a special case of the repository where Model
implements the central data structure and control objects
dictate the control flow

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
22
 MVC

MVC is well suited for interactive systems, especially when multiple views of
the same model are needed. MVC can be used for maintaining consistency
across distributed data; however it introduces the same performance bottleneck
as for other repository styles

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
23
 Client/server Architectural style
♦ In the client/server architectural style (Figure), a subsystem,
the server, provides services to instances of other subsystems
called the clients, which are responsible for interacting with the
user.
♦ The request for a service is usually done via a remote
procedure call mechanism or a common object broker (e.g.,
CORBA, Java RMI, or HTTP).
♦ Control flow in the clients and the servers is independent
except for synchronization to manage requests or to receive
results.)

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
24
 A peer-to-peer architectural style
♦ style (see Figure) is a generalization of the client/server
architectural style in which subsystems can act both as client or
as servers, in the sense that each subsystem can request and
provide services.
♦ The control flow within each subsystem is independent from
the others except for synchronizations on requests.
♦ An example of a peer-to-peer architectural style is a database
that both accepts requests from the application and notifies to
the application whenever certain data are changed.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
25
 Thethree-tier architectural style

♦ organizes subsystems into three layers (Figure ):

The interface layer includes all boundary objects that deal with
the user, including windows, forms, web pages, and so on.
•The application logic layer includes all control and entity
objects, realizing the processing, rule checking, and
notification required by the application.
•The storage layer realizes the storage, retrieval, and query of
persistent objects.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
26
 Four -tier architectural style
♦ The four-tier architectural style is a three-tier architecture in
which the Interface layer is decomposed into a
Presentation Client layer and a Presentation
Server layer(Figure ).
♦ The Presentation Client layer is located on the user
machines, whereas the Presentation Server layer can
be located on one or more servers.
♦ The four-tier architecture enables a wide range of different
presentation clients in the application, while reusing some of
the presentation objects across clients.
♦ For example, a banking information system can include ahost
of different clients, such as a Web browser interface for home
users, an Automated Teller Machine, and an application client
for bank employees.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
27
 Pipe and filter architectural style
♦ In the pipe and filter architectural style (Figure), subsystems
process data received from a set of inputs and send results to
other subsystems via a set of outputs.
♦ The subsystems are called “filters,” and the associations
between the subsystems are called “pipes.” Each filter knows
only the content and the format of the data received on the
input pipes.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
28
 PART 2

Architectural Styles System Design Activities

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
29
♦ System design consists of transforming the analysis model into
the design model that takes into account the nonfunctional
requirements described in the requirements analysis document.
We illustrate these activities with an example, MyTrip, a route
planning system for car drivers.
♦ We start with the analysis model from MyTrip; then we
describe the identification of design goals and the design of an
initial system decomposition

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
30
♦ System design: consists of transforming the analysis model
into the design model that takes into account the nonfunctional
requirements described in the requirements analysis document.
♦ Starting Point: Analysis Model for a Route Planning System Using MyTrip,
a driver can plan a trip from a home computer by contacting a trip-planning
service on the Web (Plan Trip in Figure ). The trip is saved for later retrieval
on the server.
♦ The trip-planning service must support more than one driver .

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
31
Plan Trip use case of the MyTrip system

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
32
ExecuteTrip use case of the MyTrip system

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
33
 Identifying Design Goals

♦ definition of design goals is the first step of system design. It

identifies the qualities that our system should focus on. Many
design goals can be inferred from the nonfunctional requirements
or from the application domain.
♦ Others will have to be elicited from the client. It is, however,
necessary to state them explicitly such that every important design
decision can be made consistently following the same set of criteria

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
34
 Performance criteria

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
35
 Dependability

♦ determine how much effort should be expended in minimizing

system crashes and their consequences.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
36
 Cost criteria

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
37
 Maintenance criteria

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
38
 End user criteria

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
39
 Identifying Subsystems
♦ The initial subsystem decomposition should be derived from
the functional requirements.
♦ For example, in the MyTrip system, we identify two major
groups of objects: those that are involved during the
PlanTrip use case and those that are involved during the
ExecuteTrip usecase.

♦ The Trip,Direction,Crossing,Segment, and

Destination classes are shared between both use cases.
♦ This set of classes is tightly coupled as it is used as a whole to
represent a Trip.
♦ We decide to assign them with PlanningService to the
PlanningSubsystem, and the remainderof the classes are
assigned to the RoutingSubsystem

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
40
♦

ARENA CASE STUDEY

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
41
Outline

♦ Problem Statement
♦ Functional Requirements
♦ Nonfunctional Requirements
♦ User Interface
♦ Object Model
♦ System Decomposition
♦ Deployment

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
42
Problem Statement

♦ The problem statement is developed by the client as a

description of the problem addressed by the system

♦ A problem statement describes

⬥ The current situation
⬥ The objectives
⬥ The functionality the new system should support
⬥ The environment in which the system will be deployed
⬥ Deliverables expected by the client
⬥ Delivery dates
⬥ A set of acceptance criteria.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
43
Ingredients of a Problem Statement
1. Current situation
⬥ The problem to be solved
⬥ Description of one or more scenarios
2. Objectives
3. Requirements
⬥ Functional and nonfunctional requirements
⬥ Constraints (“pseudo requirements”)
4. Target environment
⬥ The environment in which the delivered system has to perform
a specified set of system tests
5. Project schedule
⬥ Major milestones including deadline for delivery
6. Client acceptance criteria
⬥ Criteria for the system tests.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
44
Current situation: The problem to be solved

♦ There is a problem in the current situation

⬥ Examples:
⧫ The response time when playing chess is too slow.
⧫ I want to play Go, but cannot find players on my level.
♦ What has changed? Why can address the problem now?
⬥ Change in the application domain
⧫ A new function (business process) is introduced into the business
⬥ Change in the solution domain
⧫ A new solution (technology enabler) has appeared

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
45
ARENA: The Current Situation

♦ The Internet has enabled virtual communities

♦ Multi-player computer games now include support for virtual
communities
⬥ Players can receive news about game upgrades, new game levels,
announcement of matches and scores
♦ Currently each game company develops such community
support in each individual game
⬥ Each company uses a different infrastructure, different concepts,
and provides different levels of support
♦ This redundancy leads to problems:
⬥ High learning curve for players joining a community
⬥ Game companies develop the support from scratch
⬥ Advertisers contact each community separately.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
46
ARENA: The Objectives

♦ Provide a generic infrastructure to

⬥ Support virtual game communities.
⬥ Register new games
⬥ Register new players
⬥ Organize tournaments
⬥ Keeping track of the players scores.
♦ Provide a framework for tournament organizers
⬥ to customize the number and sequence of matchers and the
accumulation of expert rating points.
♦ Provide a framework for game developers
⬥ for developing new games, or for adapting existing games into the
ARENA framework.
♦ Provide an infrastructure for advertisers.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
47
ARENA: The Objectives (2)

♦ Provide a framework for tournament organizers

⬥ to customize the number and sequence of matchers
and the accumulation of expert rating points
♦ Provide a framework for game developers
⬥ for developing new games, or for adapting existing
games into the ARENA framework
♦ Provide an infrastructure for advertisers.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
48
ARENA Functional Requirements

♦ Spectators must be able to watch matches in

progress without prior registration and without
prior knowledge of the match
♦ The operator must be able to add new games.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
49
ARENA Nonfunctional Requirements

♦ The system must support

⬥ 10 parallel tournaments,
⬥ Each involving up to 64 players
⬥ and several hundreds of spectators.
⬥ The ARENA server must be available 24 hours a day
♦ The operator must be able to add new games
without modifications to the existing system
♦ ARENA must be able to dynamically interface to existing
games provided by other game developers.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
50
Constraints

♦ Constraint: Any client restriction on the solution domain and

project management
⬥ Sometimes also called Pseudo Requirements
⬥ Constraints restrict the solution space
♦ Example of constraints
⬥ Delivery constraints (“must be delivered before Christmas”)
⬥ Organizational constraints (“must have a separate testing team”)
⬥ Implementation constraints (“must be written in Cobol”)
⬥ Target platform constraints (“must run on Windows 98”)

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
51
ARENA Target Environment
Example:
♦ Users must be able to run ARENA games as applets in any Web
Browser
♦ The web page must be validated through the W3C Markup
Validation Service
♦ Interaction with the ARENA Server must be via HTTP/1.1.
To be distinguished from development environment
♦ “Prototypes will be built with Revolution 2.6.1”
♦ “Games will be tested with Internet Explorer and Firefox”
♦ “The implementation language will be Java 1.4.2.”
♦ “The IDE will be Eclipse 3.2”

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
52
Project Schedule

♦ The project schedule is an optional part of the problem

statement
⬥ Managerial information
⬥ Often the seed for the schedule in the software project management
plan.
♦ Lists only major milestones negotiated with the client
⬥ 3 to 4 dates (fixed dates!)
♦ Example:
⬥ Project-kickoff April 15
⬥ System review May 15
⬥ Review of first prototype Jun 10
⬥ Client acceptance test July 30

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
53
Client Acceptance Criteria

♦ The system supports 10 parallel tournaments with 64 players

and 10 spectators per tournament
♦ The client supports the games Tic-Tac-Toe and Asteroids
♦ The average response time for a command issued by a client is
less than 1 second
♦ The average up-time of the ARENA server during one week of
testing is 95%.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
54
(Initial) ARENA Models

♦ Subsystem Decomposition
♦ User Interface of Client
♦ User Interface of Server
♦ Object Model

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
55
 ARENA Subsystem Decomposition

User Interface

Tournament User
Advertisement
Management

Component
Management
User Directory

Tournament
Session Statistics
Management
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
56
ARENA Object Model
Game

Tournament
League Style

Tournament KOStyle

RoundRobin
Round

Player Match

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
57
ARENA Object Model (2)
Game

TicTacToe
League TournamentStyle
Asteroids

Tournament KOStyle

RoundRobin
Round

Player Move
Match

MatchPanel creates MatchPanel

Factory
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
58
ARENA Instance-Diagram

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
59
ARENA User Interface (Client)

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
60
ARENA User Interface (Server)

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
61
More Information on ARENA
♦The ARENA Website:
http://sysiphus.in.tum.de/arena
♦ The ARENA case study is described at the end of each
chapter, starting with Chapter 4
♦ Read Chapter 4.6

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
62
 PART 2
System Design: Addressing
Design Goals

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
63
 GOALS

♦ Hardware/software mapping: What is the hardware •Data

management
♦ Mapping of subsystem to hardware. When the system is
deployed on several nodes, additional subsystems are required
for addressing reliability or performance issues.
♦ Design of a persistent data management infrastructure
♦ Design of the global control flow. Determining the sequence of
operations impacts theinterface of the subsystems.
♦ Handling of boundary conditions. Once all subsystems have
been identified, developersdecide on the order in which
individual components are started and shutdown.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
64
 ACTIVITIES OF SYSTEM DESIGN

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
65
 UMLdeployment diagrams

♦ UMLdeployment diagrams are used to depict the relationship

among run-time components and nodes. Components are self-
contained entities that provide services to other components or
actors.

♦ A Web server, for example, is a component that provides

services to Web browsers.

♦ A Web browser such as Safari is a component that provides

services to a user. A node is a physical device or an execution
environment in which components are executed.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
66
♦ UML deployment diagrams, nodes are represented by boxes
containing component icons. Nodes can be stereotyped to denote
physical devices or execution environments.
♦ Communication paths between nodes are represented by solid
lines. The protocol used by two nodes to communicate can be
indicated with a stereotype on the communication path.
♦ Figure 7-2depicts an example of a deployment diagram with two
Web browsers accessing a Web server.
♦ The Web server in turns accesses a database server. We can see
from the diagram that the Web browsers do not directly access the
database at any time

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
67
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
68
 PART 3
Addressing Design Goals

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
69
1. Mapping Subsystems to Processors and Components

2. Identifying and Storing Persistent Data

3. Providing Access Control

4. Designing the Global Control Flow

5. Identifying Services

6. Identifying Boundary Conditions, Reviewing System

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
70
 Mapping Subsystems to Processors and Components

♦ Selecting a hardware configuration also includes selecting a virtual

machine onto which the system should be built.
♦ The virtual machine includes the operating system and any
software components that are needed, such as a database
management system or a communication package.
♦ The selection of a virtual machine reduces the distance between
the system and the hardware platform on which it will run. The
more functionality the components provide, the less development
work is involved.
♦ The selection of the virtual machine, however, may be constrained
by a client who acquires hardware before the start of the project.
♦ The selection of a virtual machine may also be constrained by cost
considerations: it can be difficult to estimate whether building a
component costs more than buying it

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
71
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
72
Identifying and Storing Persistent Data

♦ Persistent data outlive a single execution of the system. For

example, at the end of the day, an author saves his work into a
file on a word processor.
♦ The file can then be reopened later. The word processor need
not run for the file to exist. Similarly, information related to
employees, their employment status, and their paychecks live
in a database management system.
♦ This allows all the programs that operate on employee data to
do so consistently

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
73
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
74
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
75
 Providing Access Control

♦ In multi-user systems, different actors have access to different

functionality and data. For example, an everyday actor may
only access the data it creates, whereas a system administrator
actor may have unlimited access to system data and to other
users’ data.

♦ During analysis, we modeled these distinctions by associating

different use cases to different actors. During system design,
we model access by determining which objects are shared
among actors, and by defining how actors can control access

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
76
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
77
♦ Defining access control for a multi-user system is usually more
complex than in MyTrip.
♦ In general, we need to define for each actor which operations
they can access on each shared object.
♦ For example, a bank teller may post credits and debits up to a
predefined amount.
♦ If the transaction exceeds the predefined amount, a manager
must approve the transaction. Managers can examine the
branch statistics; but cannot access the statistics of other
branches.
♦ Analysts can access information across all branches of the
corporation, but cannot post transactions on individual
accounts. We model access on classes with an access matrix.
The rows of the matrix represent the actors of the system

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
78
global access table represents explicitly every cell in the matrix
as a (actor,class,operation) tuple. Determining if an
actor has access to a specific object requires looking up the
corresponding tuple.
If no such tuple is found, access is denied.
•An access control list associates a list of (actor,operation)
pairs with each class to be accessed. Empty cells are discarded.
Every time an object is accessed, its access listis checked for the
corresponding actor and operation. An example of an access
control List is the guest list for a party.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
79
Designing the Global Control Flow
♦ Control flow is the sequencing of actions in a system. In object-
oriented systems, sequencing actions includes deciding which
operations should be executed and in which order. These
decisions are based on external events generated by an actor or
on the passage of time.There are two types
♦ Procedure-driven control:Operations wait for input whenever
they need data from an actor. This kind of control flow is mostly
used in legacy systems and systems written in procedural
languages. It introduces difficulties when used with object-
oriented languages. As the sequencing of operations is
distributed among a large set of objects.
♦ Event-driven control: A main loop waits for an external event.
Whenever an event becomes available, it is dispatched to the
appropriate object, based on information associated with the
event. This kind of control flow has the advantage of leading to
asimpler structure and to centralizing all input in the main loop.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
80
♦ Threads : Threads are the concurrent variation of procedure-
driven control: The system can create an arbitrary number of
threads, each responding to a different event. If a thread needs
additional data, it waits for input from a specific actor.

♦ Once a control flow mechanism is selected, we can realize it

with a set of one or morecontrol objects. The role of control
objects is to record external events, store temporary statesabout
them, and issue the right sequence of operation calls on the
boundary and entity objectsassociated with the external event.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
81
 Identifying Services
♦ In this activity, we refine the sub system decomposition by
identifying the services provided by each subsystems. We
review each dependency between subsystems and define an
interface for each service we identified (depicted in UML by a
lollipop). In this activity, we name the identified services.
During object design, we specify each service precisely in
terms of operations, parameters, and constraints.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
82
♦ ConnectionManager allows a subsystem to register with
the CommunicationSubsystem, to authenticate, find other
nodes, and initiate and close connections.

♦ •TripRequester allows a subsystem to request a list of

available trips and downloadselected trips.

♦ •TripProvider allows a subsystem to provide a list of

trips that are available for thespecified car driver and respond
to specific trip requests.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
83
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
84
♦ Boundary conditions of the system—that is, to decide how the
system is started, initialized, and shut down—and we need to
define how we deal with major failures such as data corruption
and network outages, whether they are caused by a software error.
Uses cases dealing with these conditions are called boundary use
cases.
♦ For example, we now have a good idea of how MyTrip should
work in steady state. We have, however, not yet addressed how
MyTrip is initialized.
♦ For example, how are maps loadedinto the
PlanningService? How is MyTrip installed in the car?
How does MyTrip know whichPlanningService to connect
to? How are drivers added to the PlanningService? We
quicklydiscover use cases that have not been specified

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
85
♦ An exception is an event or error that occurs during the execution
of the system. Exceptions are caused by three different sources:
•A hardware failure. Hardware ages and fails. A hard disk crash can
lead to the permanent loss of data. The failure of a network link,
for example, can momentarily disconnect two nodes of the system.
•Changes in the operating environment. The environment also
affects the way a system works. A wireless mobile system can
loose connectivity if it is out of range of a transmitter.
♦ A power outage can bring down the system, unless it is fitted with
back-up batteries.
•A software fault. An error can occur because the system or one of
its components contains a design error. Although writing bug-free
software is difficult, individual subsystems can anticipate errors
from other subsystems and protect against them.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
86
♦ Exception handling is the mechanism by which a system treats
an exception. In the case of a user error, the system should
display a meaningful error message to the user so that she can
correct her input.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
87
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
88
 Thank you

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
89