CMT 311 -

FUNDAMENTALS OF
SOFTWARE
ENGINEERING

MOD 6: Software Design

Learning Objectives
• Design Principles
• Design Concepts
• Modular Design
• Design Effective Modularity (Cohesion & Coupling)
• Introduction to Software Architecture
• Data Design

MOD 6: Software Design 2

 Software Design
• Software design is an iterative process during which the software
requirements specified in SRS are analyzed and converted into description of
the internal structure and organization of the system.
• The document thus produced is called the software design specification
document and serves as the basis for construction of the software.
• Design Process for software system has two levels: Software Architectural
Design or High Level Design: In this system is decomposed and organized
into high level components or modules and the interfaces between these
components are also described.
• Software Implementation or Detailed Design: In it, each component is
described in sufficient detail so that it can be easily coded by the
programmers.
MOD 6: Software Design 3
Goal of Design Process
• The design must implement all of the explicit requirements contained
in the analysis model, and it must accommodate all of the implicit
requirements desired by the customer.
• The design must be a readable, understandable guide for those who
generate code and for those who test and subsequently support the
software.
• The design should provide a complete picture of the software,
addressing the data, functional, and behavioral domains from an
implementation perspective.

MOD 6: Software Design 4

Characteristics of good design
i. A design should exhibit an architecture that is been created using
recognizable architectural styles or patterns.
ii. A design should be modular; that is, the software should be
logically partitioned into elements or subsystems
iii. A design should contain distinct representations of data,
architecture, interfaces, and components.
iv. A design should lead to data structures that are appropriate for the
classes to be implemented and are drawn from recognizable data
patterns.
v. A design should lead to components that exhibit independent
functional characteristics
MOD 6: Software Design 5
Characteristics of good design
vi. A design should lead to interfaces that reduce the complexity of
connections between components and with the external environment.
vii. A design should be derived using a repeatable method that is driven
by information obtained during software requirements analysis.
viii. A design should be represented using a notation that effectively
communicates its meaning.

MOD 6: Software Design 6

Design Framework
• Design Framework starts with the initial requirements and ends up
with the final design
• Data is gathered on user requirements and analyzed accordingly.
• Design is refined in every cycle and finally it is documented to
produce software design document.

MOD 6: Software Design 7

 Design Principles - What are Software Design Principles?

• Software Design Principles are a set of guidelines that helps

developers to make a good system design.
• In the development process, the time for writing code will only
consume from 20 to 40 percent, remaining we will read code and
maintain the system.
• So, Making a good system design is very important.
• In my opinion, a good system should have a good code base: easy to
read, easy to understand, easy to maintain(add/modify feature and fix
bugs), and easy to extend the system in the future.
• That will reduce development time, resources, and make us happy
more.

MOD 6: Software Design 8

• Basically, Software Design is only a part of the development process in
the Design Step(Please take a look at the below image about the
development process).
• Before we do Software Design(low-level) we have to
complete Software Architecture (high-level).
• Choosing an architecture will determine how to deal with
performance, fault tolerance, scalability, and reliability.
• Software Design is responsible for code level(low-level) such as,
what each module is doing, class scope, methods purposes, and so
on.
• You can imagine like when you build a house or a building.

MOD 6: Software Design 9

MOD 6: Software Design 10
 Design Principles
• The design process should not suffer from ‘tunnel vision” - Designer
should consider alternative approaches.
• The design should be traceable to the analysis model - a single
element of the design model often traces to multiple requirements, it
is necessary to have a means for tracking how requirements have
been satisfied by the design model.
• The design should not reinvent the wheel - use already exists design
pattern because time is short and resource are limited.
• The design should “minimize the intellectual distance” between the
software and the problem as it exists in the real world. – design
should be self-explanatory

MOD 6: Software Design 11

Design Principles
• The design should exhibit uniformity and integration – before design
work begins rules of styles and format should be defined for a design
team.
• The design should be structured to accommodate change
• The design should be structured to degrade gently, even when
unusual data, events, or operating conditions are encountered.
• Design is not coding, coding is not design.
• The design should be assessed for quality as it is being created, not
after the fact
• The design should be reviewed to minimize conceptual (semantic)
errors.
MOD 6: Software Design 12
 Importance of Software Design Principles
• You can write code without Software Design Principles.
• That’s the truth.
• If you want to become a Senior level you should understand and apply
Sofware Design Principles in your work.
• We have many solutions to apply Software Design Principles to your
project.
• You can think and apply your solution or use the Design Patterns.
• The design pattern is the best solution to resolve common problems that
repeat many times in software development.
• Using the design pattern will reduce risks and make your code easy to
maintain.
MOD 6: Software Design 13
• Besides, if you want to contribute to open-source which often uses a
lot of Design Patterns: Singleton, Factory Method, Decorator Pattern,
Strategy Pattern, Proxy, and so on.
• You have to understand those patterns then you can contribute to it.
• Moreover, if you can want to create a framework like Lavarel
Framework(Taylor Otwell), you should deeply understanding
Software Design Principles and Design Patterns.
• Learning Design Pattern isn’t difficult, you can search on the internet
or watch them on youtube but identify and apply them in the real
project is very difficult. Y
• ou can achieve it after working with many projects in many years.
• Basically, Sofware Design Principles are Object-Oriented Design
Principles which based on OOP.

MOD 6: Software Design 14

 Design Concepts - An overview of what is
software design in software engineering
• The process of creating software methods, functions, objects, and the
general structure and interaction of your code such that the resulting
functionality meets the needs of your users is known as software design.
• There are numerous approaches to software design.
• Various developers prefer varying levels of design upfront or during the
execution process.
• Generally, before beginning coding, the overall design should be
thoroughly thought out and reviewed.
• It is easier to try out different designs early in the development cycle and
find problems than to make a significant design change after most of the
code has been written.
MOD 6: Software Design 15
What is Software Design?
• Software design is a method that converts user requirements into a
suitable form for the programmer to employ in software coding and
implementation.
• It is concerned with converting the client's requirements as defined in
the SRS (Software Requirement Specification) document into a form
that can be easily implemented using a programming language.
• A good software designer needs to have knowledge of what software
engineering is.

MOD 6: Software Design 16

Software Design Concepts
• Let us look at some software design concepts that assist a software
engineer in creating the model of the system or software product to
be developed or built.
• The following ideas should be grasped before designing a software
system.

MOD 6: Software Design 17

i. Abstraction
• One of the fundamental concepts of object-oriented programming
(OOP) languages is an abstraction.
• Its primary purpose is to deal with complexity by concealing internal
details from the user.
• This allows the user to build more complicated logic on top of the
offered abstraction without having to understand or even consider all
the hidden complexity.

MOD 6: Software Design 18

ii. Modularity

• Modularity refers to breaking a system or project into smaller

sections to lessen the system's or project's complexity.
• Similarly, modularity in design refers to the division of a system into
smaller elements that can be built independently and then used in
multiple systems to execute different purposes.
• Sometimes to deal with Monolithic software, which is difficult to
grasp for software engineers, it is required to partition the software
into components known as modules.
• As a result, modularity in design has become a trend that is also
essential.
MOD 6: Software Design 19
MOD 6: Software Design 20
iii. Architecture
• A system's software architecture represents the design decisions linked
to the general structure and behavior of the system.
• Architecture assists stakeholders in comprehending and analyzing how
the system will attain critical characteristics such as:
a. Modifiability
b. availability, and
c. security
• It specifies how components of a software system are constructed, as
well as their relationships and communication.
• It acts as a software application blueprint and a development foundation
for the developer team.
MOD 6: Software Design 21
iv. Refinement
• Refinement means removing any impurities and improving the
quality of something.
• The software design refinement idea is a process of building or
presenting the software or system in a detailed manner, which implies
elaborating on a system or software.
• In addition, refinement is essential for identifying and correcting any
possible errors.

MOD 6: Software Design 22

 v. Design Patterns
• A Software Design Pattern is a general, reusable solution to a commonly
occurring problem within a given context in software design.
• They are templates to solve common software engineering problems,
representing some of the finest practices experienced object-oriented
software engineers utilize.
• A design pattern systematically describes and explains a general design
that handles a recurring design challenge in object-oriented systems.
• It discusses the problem, the remedy, when to use it, and the
repercussions.
• It also provides implementation guidance and examples.

MOD 6: Software Design 23

vi. Information/Data Hiding

• Simply put, information hiding implies concealing information so that

an unauthorized entity cannot access it.
• In software design, information hiding is accomplished by creating
modules in such a way that information acquired or contained in one
module is concealed and cannot be accessible by other modules.

MOD 6: Software Design 24

 Applying Information Hiding principle
• The Buyer component should not need to know how a house is built.
• As such, we can encapsulate the functions used to build a house into another component called Builder.
• Below is the modified version.

MOD 6: Software Design 25

 vii. Refactoring
• Refactoring is the process of reorganizing code without affecting its
original functionality.
• Refactoring aims to improve internal code by making modest changes
that do not affect the code's exterior behavior.
• Computer programmers and software developers refactor code to
improve the software's design, structure, and implementation.
• As a result, Refactoring increases code readability while decreasing
complications.
• Refactoring can also assist software engineers in locating faults or
vulnerabilities in their code.

MOD 6: Software Design 26

EFFECTIVE MODULAR DESIGN

• Effective modular design consist of two things:

i. Cohesion
ii. Coupling

MOD 6: Software Design 27

i. Cohesion
• Cohesion is a natural extension of the information hiding concept.
• It is the extent to which all instructions in a module relate to a single
function.
• Cohesion in modules should be maximized.
• A cohesive module performs a single task within a software procedure,
requiring little interaction with procedures being performed in other parts
of a program
• We always strive for high cohesion, although the mid-range of the spectrum
is often acceptable.
• A strongly cohesive module implements functionality that is related to one
feature of the solution and requires little or no interaction with other
modules.
MOD 6: Software Design 28
 Types of cohesion
i. Functional Cohesion: All activities in a module are functionally related or they are
performing a similar function. It is the best cohesion as the module perform a single
specific function.
ii. Sequential Cohesion: Modules are divided into a series of activities such that the
output of one module becomes the input to the next module and the chain continues.
iii. Communicational Cohesio : All the functions of the module refer to or update the
same data structure. It has clearly defined boundaries, inputs and outputs but it suffers
from one major weakness, ie., if the common area is changed then all modules have to
be checked out again.
iv. Procedural Cohesion: In it activities share the same procedural implementation. If
procedural cohesion is done on a module of a system, it will be in a situation where a
number of modules share some common procedures and the common procedure is
being automated. Eg. The algorithm for decoding a messageAs an example of low
cohesion, consider a module that performs error processing for an engineering analysis
package. MOD 6: Software Design 29
• The module is called when computed data exceed prespecified
bounds.
• It performs the following tasks:
1) computes supplementary data based on original computed data,
2) produces an error report (with graphical content) on the user's
workstation,
3) performs follow-up calculations requested by the user,
4) updates a database, and
5) enables menu selection for subsequent processing.

MOD 6: Software Design 30

• Although the preceding tasks are loosely related, each is an
independent functional entity that might best be performed as a
separate module.
• Combining the functions into a single module can serve only to
increase the likelihood of error propagation when a modification is
made to one of its processing tasks.

MOD 6: Software Design 31

Types of cohesion
v. Temporal Cohesion: When a module contains functions that are related by
the fact that all the functions must be executed in the same time span, the
module is said to exhibit temporal cohesion.
vii. Logical Cohesion: Activities belonging to the same category are grouped
together, we can group all reporting activities together or all querying
activities together.
viii. Coincidental Cohesion: Instructions have no relationship to each other ,
they just coincidental fall in the same module.
• It is the worst type of cohesion.
• As an example of low cohesion, consider a module that performs error
processing for an engineering analysis package.
MOD 6: Software Design 32
• The module is called when computed data exceed prespecified
bounds.
• It performs the following tasks:
1) computes supplementary data based on original computed data,
2) produces an error report (with graphical content) on the user's
workstation,
3) performs follow-up calculations requested by the user,
4) updates a database, and
5) enables menu selection for subsequent processing.

MOD 6: Software Design 33

• Although the preceding tasks are loosely related, each is an
independent functional entity that might best be performed as a
separate module.
• Combining the functions into a single module can serve only to
increase the likelihood of error propagation when a modification is
made to one of its processing tasks.

MOD 6: Software Design 34

 ii. Coupling
• Coupling is the measure of the degree of the interdependence between
modules.
• Coupling depends on the interface complexity between modules, the
point at which entry or reference is made to a module, and what data
pass across the interface
• In software design, we strive for lowest possible coupling.
• Simple connectivity among modules results in software that is easier to
understand and less prone to a "ripple effect" caused when errors occur
at one location and propagate through a system.
• Coupling is characterized by passage of control between modules.

MOD 6: Software Design 35

Modules in Coupling
i. Highly Coupled: When the modules are highly dependent on each
other then they are called highly coupled.
ii. Loosely Coupled: When modules depend on each other but the
interconnection between them is weak then they are called loosely
coupled.
iii. Uncoupled: When the different modules have no interconnection
among them then it is called uncoupled module.

MOD 6: Software Design 36

 Types of Coupling
i. Data Coupling: The dependency between two modules is said to be
data coupled if their dependency is based on the fact they
communicate by only passing of data. This data item should be
problem related and not used for the control purpose. It occurs
when module passes non – global variable to another module.
ii. Stamp Coupling: Two modules are stamp coupled, if they
communicate using a composite data item such as record,
structure, object etc. It occurs when module passes non global data
structure or entire structure to another module. Here modules are
more dependent to each other.

MOD 6: Software Design 37

 Types of Coupling
iii. Control Coupling: Two modules are control coupled if they communicate
by passing of control information. This is usually accomplished by means of
flags that are set by one module and reacted upon by the dependent
module.
iv. External Coupling: In it, a module has a dependency to other module
external to the software being developed or to a particular type of hardware.
This is basically related to the communication to external tools and devices.
v. Common Coupling: It occurs when modules refer to the same data items
or data structure. Making a change to common data means tracking back to
all the modules which access that data to evaluate the effect of change.

MOD 6: Software Design 38

Types of Coupling
vi. Content Coupling: It occurs when module directly refer to the inner
workings of another module. In this coupling one module can alter data
in other module or change a statement coded in other module.
• High coupling among modules not only makes a design difficult to
understand and maintain, but it also increases development effort as
the modules having high coupling cannot be developed
independently by different team members.
• Modules having high coupling are difficult to implement and debug.

MOD 6: Software Design 39

Introduction to Software Architecture
• Software Architecture defines fundamental organization of a system
and more simply defines a structured solution.
• It defines how components of a software system are assembled, their
relationship and communication between them.
• The software architecture of a system represents the design decisions
related to overall system structure and behavior.

MOD 6: Software Design 40

• Software architecture refers to how you organize stuff in the process
of creating software.
• And "stuff" here can refer to:
i. Implementation details (that is, the folder structure of your repo)
ii. Implementation design decisions (Do you use server side or client
side rendering? Relational or non-relational databases?)
iii. The technologies you choose (Do you use REST or GraphQl for your
API? Python with Django or Node with Express for your back end?)
iv. System design decisions (like is your system a monolith or is it
divided into microservices?)
v. Infrastructure decisions (Do you host your software on premise or
on a cloud provider?)

MOD 6: Software Design 41

 Important Software Architecture Concepts
• What's the Client-server Model?
• Client-server is a model that structures the tasks or workloads of an
application between a resource or service provider (server) and a service or
resource requester (client).
• Put simply, the client is the application that requests some kind of
information or performs actions, and the server is the program that sends
information or performs actions according to what the client does.
• Clients are normally represented by front-end applications that run either on
the web or mobile apps (although other platforms exist too and back-end
applications can act as clients as well).
• Servers are usually back-end applications.
MOD 6: Software Design 42
What are APIs?
• We just mentioned that clients and servers are entities that
communicate with each other to request things and respond to
things.
• The way in which these two parts usually communicate is through an
API (application programming interface).
• An API is nothing more than a set of defined rules that establishes
how an application can communicate with another.
• It's like a contract between the two parts that says "If you send A, I'll
always respond B. If you send C, I'll always respond D..." and so on.

MOD 6: Software Design 43

• Having this set of rules, the client knows exactly what it has to require
in order to complete a certain task, and the server knows exactly
what the client will require when a certain action has to be
performed.
• There're different ways in which an API can be implemented.
• The most commonly used are REST, SOAP and GraphQl.

MOD 6: Software Design 44

 What is Modularity?
• When we talk about "modularity" in software architecture, we refer to the
practice of dividing big things into smaller pieces.
• This practice of breaking things down is performed to simplify big
applications or codebases.
• Modularity has the following advantages:
i. It's good for dividing concerns and features, which helps with the
visualization, understanding, and organization of a project.
ii. The project tends to be easier to maintain and less prone to errors and
bugs when it's clearly organized and subdivided.
iii. If your project is subdivided into many different pieces, each can be
worked on and modified separately and independently, which is often
very useful.
MOD 6: Software Design 45
 Data Design
• Data design is the first design activity, which results in less complex,
modular and efficient program structure.
• The information domain model developed during analysis phase is
transformed into data structures needed for implementing the software.
• The data objects, attributes, and relationships depicted in entity relationship
diagrams and the information stored in data dictionary provide a base for
data design activity.
• During the data design process, data types are specified along with the
integrity rules required for the data.
• For specifying and designing efficient data structures, some principles
should be followed.
MOD 6: Software Design 46
• These principles are listed below.
i. The data structures needed for implementing the software as well-as the
operations that can be applied on them should be identified.
ii. A data dictionary should be developed to depict how different data objects
interact with each other and what constraints are to be imposed on the
elements of data structure.
iii. Stepwise refinement should be used in data design process and detailed
design decisions should be made later in the process.
iv. Only those modules that need to access data stored in a data structure
directly should be aware of the representation of the data structure.
v. A library containing the set of useful data structures along with the
operations that can be performed on them should be maintained.
vi. Language used for developing the system should support abstract data
types.
MOD 6: Software Design 47
• The structure of data can be viewed at three levels,
namely, program component level, application level, and business
level.
• At the program component level, the design of data structures and
the algorithms required to manipulate them is necessary, if high-
quality software is desired.
• At the application level, it is crucial to convert the data model into
a database so that the specific business objectives of a system could
be achieved.
• At the business level, the collection of information stored in different
databases should be reorganized into data warehouse, which enables
data mining that has an influential impact on the business.

MOD 6: Software Design 48

***END**

MOD 6: Software Design 49