FUNDAMENTALS OF SOFTWARE

ENGINEERING
Chapter five
Software design

Compiled by: Atlaw M.

1
 Chapter Five: Software Design
 Software design is the transformation of the analysis model into
a system design model.

 It is a mechanism to transform user requirements into some

suitable form, which helps the programmer in software coding
and implementation.

 It deals with representing the client's requirement, as described

in SRS (Software Requirement Specification) document, into a
form, i.e., easily implementable using programming language.
2
 …Continued
 During software design, developers
 define the design goals of the project,

 decompose the system into smaller subsystems that can be realized

by individual teams.

 select strategies for building the system, such as

 the hardware/software platform on which the system will run,
 the persistent data management strategy,
 the global control flow,
 the access control policy, and
 the handling of boundary conditions.
3
…Continued
 The result of software design is a model that includes:
a clear description of each of these strategies,

a subsystem decomposition, and

a UML deployment diagram representing the hardware/software mapping

of the system.

4
 …Continued
 Software design includes:
 the definition of design goals
 the decomposition of the system into subsystems
 the mapping of subsystem to hardware
 the selection of a persistent data management
infrastructure
 the selection of an access control policy
 the selection of a global control flow mechanism
 the handling of boundary conditions

5
 An Overview of 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 functionality of the system
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
6
 …Continued
 The analysis model describes the system completely from the actors’
point of view and serves as the basis of communication between the
client and the developers.

 The analysis model, however, does not contain information about the
internal structure of the system, its hardware configuration, or, more
generally, how the system should be realized. System design is the
first step in this direction.

7
 …Continued
 System design results in the following products:
 list of 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

8
 …Continued
 The design goals are derived from the nonfunctional
requirements. Design goals guide the decisions to be made by
the developers especially when trade-offs are needed.
 The subsystem decomposition constitutes the bulk of system
design.
 Developers divide the system into manageable pieces to deal
with complexity: Each subsystem is assigned to a team and
realized independently.
 In order for this to be possible, though, developers need to
address system-wide issues when decomposing the system.

9
 …Continued
 In particular, they need to address the following issues:
 Hardware/software mapping:
 What is the hardware configuration of the system?
 Which node is responsible for which functionality?
 How is communication between nodes realized?
 Which services are realized using existing software components?
 How are these components encapsulated?

 Addressing hardware/software mapping issues often leads to the

definition of additional subsystems dedicated to moving data from one
node to another, dealing with concurrency, and reliability issues.

10
…Continued
 Off-the-shelf components enable developers to realize complex
services more economically.
 User interface packages and database management systems are
prime examples of off-the-shelf components.
 Components, however, should be encapsulated to minimize
dependencies on a particular component: A competing vendor may
come up with a better component.

11
…Continued
 Data management:
 Which data need to be persistent?
 Where should persistent data be stored?
 How are they accessed?

 Persistent data represents a bottleneck in the system on many

different fronts: Most functionality in system is concerned with
creating or manipulating persistent data.
 For this reason, access to the data should be fast and reliable.
 If retrieving data is slow, the whole system will be slow.
 If data corruption is likely, complete system failure is likely.

 These issues need to be addressed consistently at the system level.

Often, this leads to the selection of a database management system
and of an additional subsystem dedicated to the management of
persistent data.
12
…Continued
 Access control:
 Who can access which data?
 Can access control change dynamically?
 How is access control specified and realized?

 Access control and security are system-wide [Link] access control

must be consistent across the system; in other words, the policy used to
specify who can and cannot access certain data should be the same
across all subsystems.
 Control flow:
 How does the system sequence operations?
 Is the system event driven?
 Can it handle more than one user interaction at a time?

13
…Continued
 The choice of control flow has an impact on the interfaces of subsystems.
If an event-driven control flow is selected, subsystems will provide event
handlers. If threads are selected, subsystems need to guarantee mutual
exclusion in critical sections.
 Boundary conditions:
 How is the system initialized?
 How is it shut down?
 How are exceptional cases detected and handled?

14
 …Continued
 System initialization and shutdown often represent the larger part of the
complexity of a system, especially in a distributed environment.
Initialization, shutdown, and exception handling have an impact on the
interface of all subsystems.

15
 …Continued
 System Design Concepts
 A service is a set of related operations that share a common purpose.
 During system design, we define the subsystems in terms of the services
they provide.
 Later, during object design, we define the subsystem interface in terms of
the operations they provide.
 Next, we look at two properties of subsystems: coupling and
coherence.
 Coupling measures the dependencies between two subsystems, whereas
coherence measures the dependencies among classes within a
subsystem.
 Ideal subsystem decomposition should minimize coupling and maximize
coherence.
16
 …Continued
 Subsystems and Classes
 In order to reduce the complexity of the application domain, we
identified smaller parts called classes and organized them into
packages.
 Similarly, to reduce the complexity of the solution domain, we
decompose a system into simpler parts, called subsystems, which are
made of a number of solution domain classes. In the case of complex
subsystems, we recursively apply this principle and decompose a
subsystem into simpler subsystems.

17
 …Continued
 Software Architecture

 Any complex system is composed of sub systems that interact under

the control of system design such that the system provides the
expected behavior.

 While designing such a system, therefore, the logical approach is to

identify the sub-systems that should compose the system, the interfaces
of these subsystems, and the rules for interaction between the
[Link] is what software architecture aims to do.

18
…Continued
 At a top level, architecture is a design of a system which gives a very
high level view of the parts of the system and how they are related to
form the whole [Link] is, architecture partitions the system in
logical parts such that each part can be comprehended independently,
and then describes the system in terms of these parts and the
relationship between these parts.

 The software architecture of a system is the structure or structures of

the system, which comprise software elements, the externally visible
properties of those elements, and the relationships among them.
19
 …Continued
 UML deployment diagrams
 are used to depict the relationship among run-time components and
hardware 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 Netscape is a component that provides services
to a user.
 A distributed system can be composed of many interacting run-time
components.

20
 …Continued
 In UML deployment diagrams, nodes are represented by boxes containing
component icons.
 Dependencies between components are represented by dashed arrows.
The figure depicts an example of deployment diagram illustrating two
Web browsers accessing a Web server.
 The Web server in turns accesses data from a database [Link] can
see from the dependency graph that the Web browsers do not access
directly the database at any time.

21
…Continued

22
.

Thank You!

23