Debre Berhan University
ደብረ ብርሃን ዩንቨርሲቲ
Chapter Six:
Software Design
DBU-SE - 2022 1
Outlines
Software Design
Levels in design
Strategy of design
Phases of design
Principles Leading to Good Design
Design methods
Function oriented design
Object oriented design
DBU-SE - 2022 2
Software Design
Design is the highly significant phase in the software development where the
designer plans “how” a software system should be produced in order to make it.
Functional
Reliable
Reasonably easy to understand, modify and maintain.
It is about solution of the problems mentioned in requirement document.
Design is a creative activity
It determines the major characteristics of a system
Design has great impact on testing and maintenance
The output of this phase is a design document to be used for implementing the
system.
3
Software Design…
Definition: Design is a problem-solving process whose objective is to find and describe
a way:
To implement the system’s functional requirements...
while respecting the constraints imposed by the non-functional requirements...
, platform and process requirements including the budget and
adhering to general principles of good design quality
A Designer is Faced with a series of design issues
These are sub-problems of the overall design problem.
Each issue normally has several alternative solutions: design options.
The designer makes a design decision to resolve each issue.
This process involves choosing the best option from among the alternatives.
4
Software Design…
To make each design decision, the software engineer uses:
Knowledge of
—the requirements
—the design as created so far
—the technology available
—software design principles and ‘best practices’ (e.g., MVC)
—what has worked well in the past
The space of possible designs that could be achieved by choosing different sets of alternatives is
often called the design space
The diagram below show example of design space
5
Understanding Design
It is the transformation of the analysis model into a system design model.
A logical description of how a system will work.
Emphasizes a conceptual solution (in software and hardware) that fulfills the
requirements, rather than its implementation.
“do the right thing (analysis), and do the thing right (design)”.
During requirements elicitation and analysis, we concentrated on the purpose
and the functionality of the system.
During system design, we focus on :-
the processes
data structures, and
software and hardware components necessary to implement it.
Analysis Versus Design
Example
The design of a House plan in architecture is similar to system design
in software engineering.
The house is divided into :-
simpler components (i.e., rooms, subsystems) and
interfaces (i.e., doors, services)
non-functional requirements (i.e., living area, response time)
functional requirements (i.e., number of bedrooms, use cases).
implementation activities (i.e., the kitchen layout, the coding complexity of
individual subsystems)
results in costly rework if changed later (i.e., moving walls, changing subsystem
interfaces).
DBU-SE - 2022 9
What is component , module and System ?
Component
Any piece of software or hardware that has a clear role.
A component can be isolated, allowing you to replace it with a different component that has equivalent functionality.
Many components are designed to be reusable.
Conversely, others perform special-purpose functions.
Java concept of component: Javabean
Module
A component that is defined at the programming language level
For example, methods, classes and packages are modules in Java.
System
A logical entity, having a set of definable responsibilities or objectives, and consisting of hardware, software
or both.
A system can have a specification which is then implemented by a collection of components.
A system continues to exist, even if its components are changed or replaced. (The “Ship of Theseus”)
The goal of requirements analysis is to determine the responsibilities of a system.
Subsystem: A system that is part of a larger system, and which has a definite interface
DBU-SE - 2022 10
Levels in Design Process
The design process for software systems often has two levels.
Top-level design (System design or conceptual design ):
Identifies the components needed for the system, their behavior, and relationships
(architectural design)
Decides which modules are needed for the system, the specifications of these
modules, and how the modules should be interconnected.
Detailed design (Logic design):
The internal design of the modules, or how the specifications of the module can
be satisfied, is decided.
For each module data structures and algorithms are designed.
Outcome of detailed design is module specification.
11
Strategy of design
Top-down design
First design the very high level structure of the system.
Then gradually work down to detailed decisions about low-level constructs.
Finally arrive at detailed decisions such as:
the format of particular data items;
the individual algorithms that will be used.
Bottom-up design
Make decisions about reusable low-level utilities.
Then decide how these will be put together to create high-level constructs.
12
Strategy of design…
bottom-up top-down
Hybrid Design: Normally a mix of top-down and bottom-up approaches
are used
Top-down design is almost always needed to give the system a good
structure.
Bottom-up design is normally useful so that reusable components can be
created. 13
Phases of Design
Architectural design - Identify sub-systems
Abstract specification - Specify sub-systems
Interface design - Describe sub-system interfaces
Component design - Decompose sub-systems into components
Data structure design - Design data structures to hold problem data
Algorithm design - Design algorithms for problem functions
Requir
em ents
specifica
tion
Design vities
acti
Arc hitectur
al Abstr
act Interface Component Data Algorithm
design specifica
tio design design structur
e design
n design
Sy stem Softw
a re Interface Component Data Algorithm
arc hitectur
e specifica
tion specifica
tion specifica
tion structur
e specifica
tion
specifica
tion
Designoducts
pr
14
Principles Leading to Good Design
A design is said to be good design if:-
Increasing profit by reducing cost and increasing revenue
Ensuring that we actually conform with the requirements
Accelerating development
Increasing qualities such as: Usability, Efficiency, Reliability, Maintainability, Reusability
In order to achieve the design goals (especially for object oriented systems) we need to
follow the following design principles
Divide and conquer Reuse existing designs and code
Increase cohesion where possible where possible
Decrease coupling where Design for flexibility
possible Anticipate obsolesce
Keep the level of abstraction as Design for Portability
high as possible Design for Testability
Increase reusability where Design defensively
possible
15
1: Divide and conquer (Modularity)
Trying to deal with something big all at once is normally much harder than
dealing with a series of smaller things.
A system could be subdivided in the following way:
A distributed system is divided up into clients and servers
a system is divided up into subsystems
a subsystem can be divided up into one or more packages
a package is divided up into classes
A class is divided up into methods
Some of the advantages of dividing and tackling a problem are:-
Separate people can work on each part.
An individual software engineer can specialize in his or her component, becoming expert
on it.
Each individual component is smaller, and therefore easier to understand.
Parts can be replaced or changed without having to replace or extensively change other
parts.
Opportunities arise for making the component reusable
16
2: Increase cohesion where possible
Cohesion is a measure of the degree to which the elements of a
module are functionally related.
A subsystem or module has high cohesion if it keeps together things
that are related to each other, and keeps out other things.
This makes the system as a whole easier to understand and change
Type of cohesion:
Functional, Layer, Communicational, Sequential, Procedural, Temporal,
Utility
Classification is often subjective yet gives us some idea about cohesiveness
of a module.
17
Functional cohesion
This is achieved when all the code that computes a particular result is kept
together - and everything else is kept out
i.e. when a module only performs a single computation, and returns a result,
without having side-effects.
Modules that computes a mathematical function such as sine and cosine, a module
that takes a set of equation and solves for the unknowns are examples of
functionally cohesive modules.
Modules that update a database, create a new file or interact with the user are not
functionally cohesive.
Benefits to the system:
Easier to understand
More reusable
Easier to replace
18
Layer cohesion
All the facilities for providing or accessing a set of related services are kept
together, and everything else is kept out
The layers should form a hierarchy
Higher layers can access services of lower layers,
Lower layers do not access higher layers
The set of procedures through which a layer
provides its services is the application
programming interface (API)
You can replace a layer without having any
impact on the other layers - You just replicate
the API
19
Communicational & Sequential Cohesions
Communicational Cohesion : all the modules that access or manipulate
certain data are kept together (e.g. in the same class) and everything else
is kept out
A class would have good communicational cohesion
if all the system’s facilities for storing and manipulating its data are contained in
this class.
if the class does not do anything other than manage its data.
Main advantage: When you need to make changes to the data, you find all
the code in one place.
Sequential Cohesion: Procedures, in which one procedure provides input
to the next, are kept together and everything else is kept out
20
Procedural, Temporal & Utility Cohesion
Procedural Cohesion : Procedures that are used one after another
are kept together, even if one does not necessarily provide input to
the next.
Temporal Cohesion : operations that are performed during the
same phase of the execution of the program are kept together, and
everything else is kept out
For example, placing together the code used during system start-up or
initialization.
Utility Cohesion: When related utilities which cannot be logically
placed in other cohesive units are kept together
A utility is a procedure or class that has wide applicability to many different
subsystems and is designed to be reusable.
For example, the [Link] class. 21
3:Reduce Coupling where possible
Coupling occurs when there are interdependencies between one
module and another
When interdependencies exist, changes in one place will require changes
somewhere else.
A network of interdependencies makes it hard to see how some
component works.
Types of coupling:
—Content, Common, Control, Stamp, Data, Routine Call,
Type use, Inclusion/Import, External
22
4: Keep the level of abstraction as high as possible
Ensure that your designs allow you to hide or defer consideration of details,
thus reducing complexity
A good abstraction is said to provide information hiding
Abstractions allow you to understand the essence of a subsystem without having to
know unnecessary details
Abstraction and classes
Classes are data abstractions that contain procedural abstractions
Abstraction is increased by defining all variables as private.
The fewer public methods in a class, the better the abstraction
Super classes and interfaces increase the level of abstraction
Attributes and associations are also data abstractions.
Methods are procedural abstractions: Better abstractions are achieved by giving
methods fewer parameters
23
Design Principles 5 & 6
Increase reusability where possible
Design the various aspects of your system so that they can be used again in other contexts
Generalize your design as much as possible
Follow the preceding four design principles
Simplify your design as much as possible
Reuse existing designs and code where possible
Design with reuse is complementary to design for reusability
Actively reusing designs or code allows you to take advantage of the
investment you or others have made in reusable components
Cloning should not be seen as a form of reuse
24
Design Principles 7 & 8
Design for flexibility: actively anticipate changes that a design may have to
undergo in the future, and prepare for them
Reduce coupling and increase cohesion
Create abstractions
Do not hard-code anything
Leave all options open - do not restrict the options of people who have to modify the
system later
Use reusable code and make code reusable
Design for Portability: Have the software run on as many platforms as possible
Avoid the use of facilities that are specific to one particular environment
E.g. a library only available in Microsoft Windows
25
9: Anticipate obsolescence
Plan for changes in the technology or environment so the
software will continue to run or can be easily changed
Avoid using early releases of technology
Avoid using software libraries that are specific to particular environments
Avoid using undocumented features or little-used features of software
libraries
Avoid using software or special hardware from companies that are less
likely to provide long-term support
Use standard languages and technologies that are supported by
multiple vendors
26
Design principle 10 and 11
Design for Testability: Take steps to make testing easier
Design a program to automatically test the software
Ensure that all the functionality of the code can by driven by an external
program, bypassing a graphical user interface.
In Java, you can create a main() method in each class in order to exercise the
other methods
Design defensively: Never trust how others will try to use a
component you are designing
Handle all cases where other code might attempt to use your component
inappropriately
Check that all of the inputs to your component are valid: the preconditions
Unfortunately, over-zealous defensive design can result in unnecessarily
repetitive checking
27
Design methods
Two fundamentally different software design approaches are: Function-
oriented design & Object-oriented design
a) Function oriented design (FOD)
A system is looked upon as something that performs a set of functions.
Starting at this high-level view of the system each function is successively refined
into more detailed sub functions & functions are mapped to a module structure.
This can be done either in bottom-up or top-down fashion
Example:
The function to create-new-library- member consists of the following sub-
functions:
creates the record for a new member,
assigns a unique membership number,
prints a bill towards the membership
28
Design methods…
b) Object Oriented Design (OOD)
System is viewed as a collection of objects (i.e. entities).
System state is decentralized among the objects: each object
manages its own state information.
Similar objects constitute a class: each object is a member of
some class.
29
Design methods…
Example: Library Automation Software:
Each library member is a separate object - with its own data and functions.
Functions defined for one object: cannot directly refer to or change data of
other objects.
These two design approaches (FOD & OOD) are radically different.
However, the two approaches are complementary rather than competing
techniques and each technique is applicable at different stages of the design
process.
30
Thank You !!!
DBU-SE - 2022 31