Software Design

and Architecture
System Decomposition

Soha Makady
 Outline
• Architecture vs. Design
– A Floor Plan Example
• Overview of System Design
• Design Goals → Tradeoffs
• Subsystem Decomposition
A Floor Plan Example

• Consider the task of designing a

residential house.
• The architect agrees with the client on:
• the number of rooms and floors
• the size of the living area
• the location of the house
• What should the architect design?
• The floor plan (what does that mean?)

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3
A Floor Plan Example (Cont’d)

• Any functional requirements that the architect

should respect?
• The kitchen should be close to the dining room
and the garage
• the bathroom should be close to the bedrooms
• Any standards that the architect should respect
during establishing the different rooms dimensions,
and the location of the door?
• Kitchen cabinets come in fixed increments
• Beds come in standard sizes

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4
A Floor Plan Example (Cont’d)

• Any other constraints that the architect should

respect?
• The overall distance the occupants walk every
day should be minimized
• The living area should be maximized
• Does the architect need to know the exact
content of each room to do the floor plan?

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

Stairs Stairs
Study Bedroom2 Study Dining

Kitchen
Kitchen

Hallway Entrance Hallway Entrance

door door

Bath
Bath
Master Master
Dining Bedroom2
Bedroom Bedroom

N
Entrance
door

Stairs
Bath

Bedroom2

Study
Kitchen

Hallway

Master
Dining
Bedroom

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

Stairs Stairs
Study Bedroom2 Study Dining

Kitchen
Kitchen

Hallway Entrance Hallway Entrance

door door

Bath
Bath
Master Master
Dining Bedroom2
Bedroom Bedroom

N
Entrance
door

Stairs
Bath

Bedroom2

Study
Kitchen

Hallway

Master
Dining
Bedroom

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

Stairs Stairs
Study Bedroom2 Study Dining

Kitchen
Kitchen

Hallway Entrance Hallway Entrance

door door

Bath
Bath
Master Master
Dining Bedroom2
Bedroom Bedroom

N
Entrance
door

Stairs
Bath

Bedroom2

Study
Kitchen

Hallway

Master
Dining
Bedroom

Version 3
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 8
Mapping of Architectural land Software
Engineering Concepts

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 9
Why is Design so Difficult?

• Analysis: Focuses on the application domain

• Design: Focuses on the solution domain
• The solution domain is changing very rapidly
• Halftime knowledge in software engineering: About
3-5 years
• Cost of hardware rapidly sinking
➢ Design knowledge is a moving target

• Design window: Time in which design decisions

have to be made.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 10
The Scope of System Design

Problem
• Bridge the gap
• between a problem and
an existing system in a
manageable way
System
• How? Design
• Use Divide & Conquer:
1) Identify design goals
2) Model the new system Recall our floor
design as a set of plan example
subsystems
3-8) Address the major
design goals. Existing System
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11
 System Analysis vs. System Design
• Analysis results in the requirements model
described by the following products:
• a set of nonfunctional requirements and
constraints, such as maximum response time,
minimum throughput, reliability, operating
system platform, and so on
• a use case model, describing the system
functionality from the actors’ point of view
• an object model, describing the entities
manipulated by the system
• a sequence diagram for each use case, showing
the sequence of interactions among
objects participating in the use case.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12
 System Analysis vs. System Design
• System design results in the following products:
• design goals, describing the qualities of the
system that developers should optimize
• software architecture, describing the subsystem
decomposition in terms of subsystem
responsibilities, dependencies among
subsystems, subsystem mapping to hardware,
and major policy decisions such as control flow,
access control, and data storage
• boundary use cases, describing the system
configuration, startup, shutdown, and
exception handling issues.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13
 System Design: Eight Issues
System Design

8. Boundary
1. Identify Design Goals Conditions
Additional NFRs Initialization
Trade-offs Termination
Failure.
2. Subsystem Decomposition 7. Software
Layers vs Partitions Control
Coherence & Coupling
Monolithic
Event-Driven
3. Identify Concurrency Conc. Processes
Identification of 4. Hardware/ 5. Persistent Data 6. Global Resource
Parallelism Software Mapping Management Handlung
(Processes, Identification of Nodes Storing Persistent Access Control
Threads) Special Purpose Systems Objects ACL vs Capabilities
Buy vs Build Filesystem vs Database Security
Network Connectivity
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15
Analysis Sources: Requirements and System Model

8. Boundary
1. Design Goals Conditions
Nonfunctional
Definition Functional Model
Initialization
Requirements
Trade-offs Termination
Failure
2. System Decomposition 7. Software
Functional Model
Layers vs Partitions Control
Coherence/Coupling
Monolithic
Event-Driven
3. Concurrency Dynamic
Conc. Processes
Identification of 4. Hardware/ 5. Data 6. Global Resource
Model
Dynamic
Threads Software Mapping Management Handlung
Special Purpose SystemsModel
Object Access Control List
Model Persistent Objects
Buy vs Build Filesystem vs vs Capabilities
Allocation of Resources Database Security
Connectivity

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 16
System Design Activities:
From Objects to Subsystems
• System design consists of transforming the
analysis model into the design model, while
considering the non-functional
requirements described in the requirements
analysis document.
• Let us see an example.
• Consider My Trip, a route planning system for
car drivers. Our steps will be as follows:
1. Start with the analysis model My Trip.
2. Identify the design goals of My Trip.
3. Design an initial system decomposition.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17
System Design Activities:
Starting with the Analysis Model for My Trip
• Using MyTrip, a driver can plan a trip from a
home computer by contacting a trip-planning
service on the Web
• The trip-planning service must support more
than one driver.
• Let us see the PlanTrip use case description.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18
Starting with the Analysis Model for My Trip
(Cont’d) Analysis
• Use case name: PlanTrip objects?
• Flow of events:
1. The Driver activates her computer and logs into
the trip-planning Web service.
2. The Driver enters constraints for a trip as a
sequence of destinations.
3. Based on a DB of maps, the planning service
computes the shortest way of visiting the
destinations in the order specified.
The result is a sequence of segments binding a
series of crossings and a list of directions.
4. The Driver saves the planned trip by name in
the planning service DB for later retrieval.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 19
Starting with the Analysis Model for My Trip
(Cont’d) Analysis
• Use case name: Execute Trip objects?
• Flow of events:
1. The Driver starts her car and logs into the
onboard route assistant.
2. The Driver specifies the name of the trip to be
executed.
3. The onboard route assistant obtains a list of
destinations, directions, segments, and
crossings from the planning service.
4. Given the current position, the route assistant
provides the driver with the next set of
directions.
5. The driver arrives to destination and shuts
down the route assistant.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 20
Analysis model for the MyTrip route
planning and execution.

RouteAssistant PlanningService
Trip

Location Direction

Destination
Crossing
Segment

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 21
Starting with the Analysis Model for My Trip (Cont’d)
During requirements elicitation, the client specified the
following non-functional requirements for MyTrip:

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 23
Starting with the Analysis Model for My Trip (Cont’d)
During requirements elicitation, the client specified the
following non-functional requirements for MyTrip:
• MyTrip is in contact with the PlanningService via a
wireless modem. Assume that the wireless modem
functions properly at the initial destination.
• Once the trip has started, MyTrip should give correct
directions even if the modem fails to maintain a
connection with the PlanningService.
• MyTrip should minimize connection time to reduce
operation costs.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 24
Identify the Design Goals for My Trip (Cont’d)
• Design goals for MyTrip
• Reliability: MyTrip should be reliable [generalization
of nonfunctional requirement 2].
• Fault Tolerance: MyTrip should be fault tolerant to
loss of connectivity with the routing service
[rephrased nonfunctional requirement 2].
• Security: MyTrip should be secure, i.e., not allow
other drivers or nonauthorized users to access a
driver’s trips [deduced from application domain].
• Modifiability: MyTrip should be modifiable to use
different routing services [anticipation of change by
developers].

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 25
Identify the Subsystems for My Trip (Cont’d)
• Heuristics for grouping objects into subsystems
• Assign objects identified in one use case into the
same subsystem.
• Create a dedicated subsystem for objects used for
moving data among subsystems.
• Minimize the number of associations crossing
subsystem boundaries.
• All objects in the same subsystem should be
functionally related.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 26
Identify the Subsystems for My Trip
(Cont’d)

RouteAssistant PlanningService
Trip

Location Direction

Destination
Crossing
Segment

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 27
Design an initial system decomposition

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 28
Hardware/Software mapping for MyTrip

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

• Chapter 6 from Bruegge’s OOSE textbook:

Bruegge, Bernd, and Allen H. Dutoit. "Object-oriented
software Engineering." ed: Prentice Hall , Third Edtiton.

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