Chapter Five

Software design and architecture

Prepared by: Marta G. (MSc.)1

5/14/2024 FSE_ CH5

Contents
 Software Design
 Levels of design
 Type of design
 Design objective
 Principles Leading to Good Design
 Design methods
✓ Function oriented design
✓ Object oriented design
 Function oriented design VS Object oriented design

5/14/2024 FSE_ CH5 2

Software Design
▪ Design is a problem-solving process whose objective is
to find and describe a way to implement the system’s
functional requirements..
 It is the most critical activity during system development
 It is the intermediate phase between requirements and
code
◦ Design activity begins with a set of requirements and is
done before the system is implemented

5/14/2024 FSE_ CH5 3

Cont…
▪ Analysis is about problem domain while design is about
solution domain.
▪ Proceeding from abstract to more concrete representations
▪ Design is a creative activity which
▪ Determines the major characteristics of a system
▪ Has great impact on testing and maintenance
▪ The end result of design phase is design document which is used
as a reference for later phases.
▪ The design document produced at the end of the design phase
should be implementable using a programming language in the
subsequent (coding) phase

5/14/2024 FSE_ CH5 4

Cont…
 A designer is faced with a series of design issues, which 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
 To make each design decision, the software engineer uses:
◦ Knowledge of the requirements
◦ The design created so far, the technology available,
◦ Software design principles and ‘best practices’ - what has worked
well in the past

5/14/2024 FSE_ CH5 5

Cont…

Levels in design process

 The design process for software systems often has three
levels:
 Architectural design: is the highest abstract version of the
system
◦ It identifies the software as a system with many components
interacting with each other

5/14/2024 FSE_ CH5 6

Cont…

High-level design:
 Breaks the architectural design into less-abstracted view of
subsystems and modules and depicts their interaction with
each other
 Focuses on how the system along with all of its components
can be implemented in forms of modules
 It recognizes modular structure of each sub-system and
their relation and interaction among each other

5/14/2024 FSE_ CH5 7

Cont…

Detailed design (Logic design):

 Deals with the implementation part of what is seen as a
system and its sub-systems in the previous two designs
 It is more detailed towards modules and their
implementations
 It defines logical structure of each module and their
interfaces to communicate with other modules

5/14/2024 FSE_ CH5 8

 Design objectives
▪ Some overall goals we want to achieve when doing good
design are:
▪ 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
▪ Major criteria to evaluate a design: Correctness, Efficiency,
Maintainability, Cost

5/14/2024 FSE_ CH5 9

 Principles Leading to Good Design

1. Divide and Conquer

2. Increase cohesion where possible
3. Reduce coupling where possible
4. Anticipate obsolescence
5. Keep the level of abstraction as high as possible
6. Increase reusability where possible
7. Reuse existing designs and code where possible
8. Design for flexibility
9. Design for Portability
10. Design defensively
1. Divide and conquer

▪ Trying to deal with something big all at once is normally much

harder than dealing with a series of smaller things
▪ Separate people can work on each part.
▪ An individual software engineer can specialize in his or her
component, becoming expert at 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
Ways of dividing a software system

 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
Cohesion and Coupling

 Cohesion and Coupling are degrees of module dependency.

 They are under decomposition concept in OO software engineering
Cohesion
➢ It indicates how closely the elements or the statements of a
module are associated with each other in the system inside a
specific module/subsystem.
➢ Cohesion is a measure of the internal strength of a module.
➢ The more closely the elements of a module are associated with
each other, the higher the cohesion of the module.
➢ Cohesion refers to the number and diversity of tasks that a single
unit is responsible for.
➢ If each unit is responsible for one single logical task, we say it
has high cohesion.
➢ Cohesion applies to classes and methods, We aim for high
cohesion.
Coupling

➢ The degree of interdependence between two or more

components in a system.
➢ Coupling is a measure of the extent of information
interchange between modules.
➢ Reduced coupling results Reduced Complexity
➢ Coupling assesses the interactions between modules
➢ It is important to distinguish kind and strength
➢ kind: A calls B, C inherits from D, etc., directionality
➢ strength: the number of interactions
2: Increase cohesion where possible
 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
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.
◦ Type of coupling: Content, Common, Control, Stamp, Data,
Routine Call, Type use, Inclusion/Import, External

Tightly coupled system

Loosely coupled system
4: Anticipate obsolescence
 Plan for changes in the technology or environment so the
software will continue to run or can be easily changed
5: 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
6: Increase reusability where possible
◦ Design the various aspects of your system so that they can be
used again in other contexts
◦ Simplify your design as much as possible
7. Reuse existing designs and code where possible
11: 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
Design methods

 Two fundamentally different software design approaches are:

◦ Function-oriented design (FOD)
◦ Object-oriented design (OOD)
 These two design approaches are radically different.
◦ However, are complementary
 rather than competing techniques.
◦ Each technique is applicable at
 different stages of the design process.
Function oriented design

 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 subfunctions.
◦ Functions are mapped to a module structure.
 Each subfunction:
◦ split into more detailed subfunctions and so on.
 Can be done in bottom-up or top-down fashion
Example
 The function create-new-library- member can be refined as:
◦ Creates the record for a new member,
◦ Assigns a unique membership number
◦ Prints a bill towards the membership
 Create-library-member function consists of the following sub-
functions:
◦ assign-membership-number
◦ create-member-record
◦ print-bill
Object-Oriented Design

 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.
 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.
 Object oriented design Vs function oriented design
 Emphasizes on concepts of  Emphasizes on evaluation of
objects functions
 The basic elements of OOP  The basic elements of
are objects and methods functional programming are
 OOP is used when there are variables and functions
many things with few  Functional programming is
operations used when there are few
 Begins by identifying objects and things with more operations
classes.  Begins by considering the use
 It is a bottom up approach. case diagrams and the
scenarios.
 It is a top down approach.

5/14/2024 FSE_ CH5 24

OOD VS FOD
 Unlike function-oriented design,
◦ in OOD the basic abstraction is not functions such as “sort”,
“display”, “track”, etc.,
◦ but real-world entities such as “employee”, “picture”, “machine”,
“radar system”, etc.
 In OOD:
◦ software is not developed by designing functions such as:
– update-employee-record,
– get-employee-address, etc.
◦ but by designing objects such as:
– employees,
– departments, etc.
OOD VS FOD
 In OOD:
◦ state information is not shared in a centralized data.
◦ but is distributed among the objects of the system.
 In FOD :
◦ the system state is centralized
◦ several functions accessing these data are defined.
 Example:
◦ In function oriented system for an employee pay-roll system, the
following can be global data:
 names of the employees,
 their code numbers,
 basic salaries, etc.
◦ Whereas, in object oriented systems:
 data is distributed among different employee objects of the
system.
OOD VS FOD
 Objects communicate by message passing.
◦ one object may discover the state information of another object
by interrogating it.
 Of course, somewhere or other the functions must be
implemented:
◦ the functions are usually associated with specific real-world
entities (objects)
◦ directly access only part of the system state information.
OOD VS FOD

 Grady Booch sums up this fundamental difference

saying:
◦ “Identify verbs if you are after procedural design and
nouns if you are after object-oriented design.”
Thank you for your
attention!!

5/14/2024 FSE_ CH5 29