CHAPTER FIVE

System Design
Identifying Design goals
Decomposing the system
Addressing Design goals
System design
• System design is the transformation of an analysis model into a system design
model that takes into account the nonfunctional requirements described in the
requirements analysis document.

• During system design, we focus on the processes, data structures, and software
and hardware components necessary to implement it
Overview of system design

Figure 7-1 The activities of system design

 System Design Activities
8. Boundary
1. Design Goals Conditions
Definition Initialization
Trade-offs Termination
Failure
2. Subsystem Decomposition 7. Software
Layers vs Partitions Control
Coherence/Coupling
Monolithic
Event-Driven
3. Concurrency Conc. Processes
Identification of 4. Hardware/ 5. Data 6. Global Resource
Threads Software Mapping Management Handlung
Special Purpose Persistent Objects Access Control List
Buy vs Build File system vs Database vs Capabilities
Allocation of Resources Security
Connectivity
1, Identifying Design Goals
• The definition of design goals is the first step of system design.

• It identifies the qualities that our system should focus on.

• we can select design goals from a long list of highly desirable qualities.
Identifying Design Goals(Cont…)
• Performance criteria : include the speed and space requirements imposed on the
system.

Table 7-1 Performance criteria.

 Identifying Design Goals(Cont…)
• Dependability criteria : determine how much effort should be expended in
minimizing system crashes and their consequences.

Table 7-2 Dependability criteria

Identifying Design Goals(Cont…)

• Cost criteria : include the cost to develop the system, to deploy it, and to
administer it.

Table 7-3 Cost criteria

Identifying Design Goals(Cont…)

• Maintenance criteria : determine how difficult it is to change the system after

deployment

Table 7-4 Maintenance criteria

Identifying Design Goals(Cont…)

• End user criteria :include qualities that are desirable from a users’ point of view,
but have not yet been covered under the performance and dependability criteria.

Table 7-5 End user criteria

Identifying Design Goals(Cont…)
• When defining design goals, only a small subset of these criteria can be
simultaneously taken into account.
• Developers need to prioritize design goals and trade them off against each other as
well as against managerial goals.

Table 7-6 Examples of

design goal trade-offs.
 System Design Activities
8. Boundary
 1. Design Goals Conditions
Definition Initialization
Trade-offs Termination
Failure
2. Subsystem Decomposition 7. Software
Layers vs Partitions Control
Coherence/Coupling
Monolithic
Event-Driven
3. Concurrency Conc. Processes
Identification of 4. Hardware/ 5. Data 6. Global Resource
Threads Software Mapping Management Handlung
Special Purpose Persistent Objects Access Control List
Buy vs Build File system vs Database vs Capabilities
Allocation of Resources Security
Connectivity
2, Identifying Subsystems

• Finding subsystems during system design is similar to finding objects during

analysis.
Subsystem decomposition
• To reduce the complexity of the solution domain, systems are decomposed into
simpler parts, called subsystems.

• 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.

• subsystems provide services to other subsystems.

• A service is a set of related operations that share a common purpose

Subsystem decomposition(Cont…)

Figure 7-2 Subsystem decomposition for an accident management system (UML

component diagram)
Subsystem decomposition(Cont…)

Figure 7-3 Services provided by the Resource Management subsystem

Subsystem decomposition(Cont…)

• 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

• physical component corresponds to a subsystem that as an explicit run-time

equivalent, for example, a database server.
Coupling and Cohesion

• Coupling is the number of dependencies between two subsystems.

• If two subsystems are strongly coupled, modifications to one subsystem is likely

to have impact on the other and if they are loosely coupled , modifications to one
subsystem have little impact on the other.

• High coupling is an issue only if it is likely that any subsystem changes.

Figure 7-4 Example of reducing the coupling of subsystems
Coupling and Cohesion(Cont…)

• Cohesion is the number of dependencies within a subsystem.

• If a subsystem contains many objects that are related to each other and perform
similar tasks, its cohesion is high and vice versa.

• A desirable property of subsystem decomposition is that it leads to subsystems

with high cohesion.
Coupling and Cohesion(Cont…)

• In general, there is a trade-off between cohesion and coupling.

• We can often increase cohesion by decomposing the system into smaller

subsystems. However, this also increases coupling as the number of interfaces
increases.

• A good heuristic is that developers can deal with 7 ± 2 concepts at any one level
of abstraction.

• If there are more than nine subsystems at any given level of abstraction, or if a
subsystem provides more than nine services, you should consider revising the
decomposition.
Layers and Partitions

• A hierarchical decomposition of a system yields an ordered set of layers.

• A layer is a grouping of subsystems providing related services, possibly realized

using services from another layer.
. In a closed architecture, each layer can access only the layer immediately
below it. Ex (OSI model)
 In an open architecture, a layer can also access layers at deeper levels.

• A subsystem decomposition is the result of both partitioning and layering.

• Excessive partitioning or layering can increase complexity.

Layers and Partitions(Cont…)

Figure 7-5 Subsystem decomposition of a system into three layers

Architectural Styles

Different types of architectural styles

1, Repository architectural style subsystems access and modify a single data
structure called the central repository.

Figure 7-6 Repository architectural style

Architectural Styles(Cont…)

2, Model/View/Controller (MVC) architectural style: are classified into three

different types:
 model subsystems maintain domain knowledge
 view subsystems display it to the user
 controller subsystems manage the sequence of interactions with the user.

Figure 7-7 MVC architectural style

Architectural Styles(Cont…)

3,client/server architectural style: a subsystem, the server, provides

services to instances of other subsystems called the clients, which are responsible
for interacting with the user.

Figure 7-8 client/server architectural style

Architectural Styles(Cont…)

4, A peer-to-peer architectural style: 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.

Figure 7-9 peer-to-peer architectural style

Architectural Styles(Cont…)

5, Three-tier architectural style :organizes subsystems into three layers:

• 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.
Architectural Styles(Cont…)

Figure 7-10 three tier architectural style

Architectural Styles(Cont…)

• 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.

• The Presentation Client layer is located on the user machines, whereas the
Presentation Server layer can be located on one or more servers.
Architectural Styles(Cont…)

Figure 7-11 Four tier architectural style