Chapter 4

Software design
Introduction To Software Design
• Process to transform user requirements into some suitable form.
• Helps the programmer in software coding and implementation.
• For assessing user requirements, an SRS (software requirement specification)
document is created whereas, for coding and implementation, there is a need
for more specific and detailed requirements in software terms.
• The output of this process can directly be used into implementation in
programming languages.
• Software design is the first step in SDLC (software design life cycle), which
moves the concentration from the problem domain to the solution domain.
• It tries to specify how to fulfill the requirements mentioned in srs.
Good software designs

Characteristics Good Design Bad Design

Change is one part of the system does
Change not always require a change in another One conceptual change requires changes
part of the system. to many parts of the system.

Every piece of logic has one and only

Logic one home. Logic has to be duplicated.

Nature Simple Complex

Cost Small Very high
Link The logic link can easily be found. The logic link cannot be remembered.

Extension System can be extended with changes in System cannot be extended so easily.
only one place.
Objectives of Software Design
Objectives of Software Design

1. Correctness: Software design should be correct as per requirement.

2. Completeness: The design should have all components like data
structures, modules, and external interfaces, etc.
3. Efficiency: Resources should be used efficiently by the program.
4. Flexibility: Able to modify to changing needs.
5. Consistency: There should not be any inconsistency in the design.
6. Maintainability: The design should be so simple so that it can be
easily maintainable by other designers.
Design Principle

Providing means to handle the complexity of the design process effectively.

Effectively managing the complexity will not only reduce the effort needed for design but can also
reduce the scope of introducing errors during design.
1. Problem Partitioning

For small problems, we can handle the entire problem at once

Benefits of Problem Partitioning
a) Software is easy to understand
b) Software becomes simple
c) Software is easy to test
d) Software is easy to modify
e) Software is easy to maintain
f) Software is easy to expand
These pieces cannot be entirely independent of each other as they together form the system.
They have to cooperate and communicate to solve the problem.
This communication adds complexity.
2. Abstraction

• An abstraction is a tool that enables a designer to consider a

component at an abstract level without bothering about the internal
details of the implementation.
• Abstraction can be used for existing elements as well as the
component being designed.
Here, there are two common abstraction mechanisms
1. Functional Abstraction
2. Data Abstraction
Conti..
Functional Abstraction
• A module is specified by the method it performs.
• The details of the algorithm to accomplish the functions are not visible
to the user of the function.
• Functional abstraction forms the basis for Function oriented design
approaches.
2.Data Abstraction
• Details of the data elements are not visible to the users of data.
• Data Abstraction forms the basis for Object Oriented design
approaches.
4.Modularity

• Modularity specifies to the division of software into separate modules

which are differently named and addressed and are integrated later
on in to obtain the completely functional software.
• It is the only property that allows a program to be intellectually
manageable.
• Single large programs are difficult to understand and read due to a
large number of reference variables, control paths, global variables,
etc.
The desirable properties of a modular system are:

1. Each module is a well-defined system that can be used with other

applications.
2. Each module has single specified objectives.
3. Modules can be separately compiled and saved in the library.
4. Modules should be easier to use than to build.
5. Modules are simpler from outside than inside.
Advantages of Modularity
• It allows large programs to be written by several or different people
• It encourages the creation of commonly used routines to be placed in
the library and used by other programs.
• It simplifies the overlay procedure of loading a large program into
main storage.
• It provides more checkpoints to measure progress.
• It provides a framework for complete testing, more accessible to test
• It produced the well designed and more readable program.
Disadvantages of Modularity

• Execution time maybe, but not certainly, longer

• Storage size perhaps, but is not certainly, increased
• Compilation and loading time may be longer
• Inter-module communication problems may be increased
• More linkage required, run-time may be longer, more source lines
must be written, and more documentation has to be done
Modular design
Modular design reduces the design complexity and results in easier and
faster implementation by allowing parallel development of various
parts of a system.
Different section of modular design are :-
A. Functional Independence
B. Information Hiding
A. Functional Independence:
Functional independence is achieved by developing functions that perform only
one kind of task and do not excessively interact with other modules.
Independence is important because it makes implementation more accessible and
faster.
The independent modules are easier to maintain, test, and reduce error
propagation and can be reused in other programs as well.
Thus, functional independence is a good design feature that ensures software
quality.
It is measured using two criteria:
i. Cohesion: It measures the relative function strength of a module.
ii. Coupling: It measures the relative interdependence among modules.
I. Cohesion
• Cohesion is a measure that defines the degree of intra-dependability within
elements of a module.
• The greater the cohesion, the better is the program design.
There are seven types of cohesion, namely –
• Co-incidental cohesion - It is unplanned and random cohesion, which might be the
result of breaking the program into smaller modules for the sake of modularization.
Because it is unplanned, it may serve confusion to the programmers and is
generally not-accepted.
• Logical cohesion - When logically categorized elements are put together into a
module, it is called logical cohesion.
• Temporal Cohesion - When elements of module are organized such that they are
processed at a similar point in time, it is called temporal cohesion.
I. Cohesion
• Procedural cohesion - When elements of module are grouped together, which are
executed sequentially in order to perform a task, it is called procedural cohesion.
• Communicational cohesion - When elements of module are grouped together,
which are executed sequentially and work on same data (information), it is called
communicational cohesion.
• Sequential cohesion - When elements of module are grouped because the output
of one element serves as input to another and so on, it is called sequential
cohesion.
• Functional cohesion - It is considered to be the highest degree of cohesion, and it is
highly expected. Elements of module in functional cohesion are grouped because
they all contribute to a single well-defined function. It can also be reused.
II. Coupling
Coupling is a measure that defines the level of inter-dependability
among modules of a program.
It tells at what level the modules interfere and interact with each other.
The lower the coupling, the better the program.
There are five levels of coupling, namely -
• Content coupling - When a module can directly access or modify or
refer to the content of another module, it is called content level
coupling.
• Common coupling- When multiple modules have read and write
access to some global data, it is called common or global coupling.
II. Coupling
• Control coupling- Two modules are called control-coupled if one of
them decides the function of the other module or changes its flow of
execution.
• Stamp coupling- When multiple modules share a common data
structure and work on a different part of it, it is called stamp coupling.
• Data coupling- Data coupling is when two modules interact with each
other by means of passing data (as a parameter). If a module passes
data structure as a parameter, then the receiving module should use
all its components.
Ideally, no coupling is considered to be the best.
II. Coupling
B. Information hiding:
• Modules should be specified that data include within a module is
inaccessible to other modules that do not need for such information.
• The use of information hiding as design criteria for modular system
provides the most significant benefits when modifications are
required during testing's and later during software maintenance.
• This is because as most data and procedures are hidden from other
parts of the software, inadvertent errors introduced during
modifications are less likely to propagate to different locations within
the software.
Software Design Strategy
A good system design strategy is to organize the program modules in such
a method that are easy to develop and latter too, change.
Structured design methods help developers to deal with the size and
complexity of programs.
Analysts generate instructions for the developers about how code should
be composed and how pieces of code should fit together to form a
program.
To design a system, there are two possible approaches:
a) Top-down Approach
b) Bottom-up Approach
a. Top-down Approach
• Informal design strategy for breaking problem into smaller problems.
• Design activity must begin with the analysis of the requirements
definition and should not consider implementation details at first.
• The specification is viewed as describing a black box for the program.
• A software project is decomposed into subprojects and this procedure
is repeated until the sub task has become so simple that an algorithm
can be formulated as a solution.
Conti..
b. Bottom-up Approach:
A bottom-up approach begins with the lower details and moves
towards up the hierarchy, as shown in fig.
This approach is suitable in case of an existing system.
Design Process
The software design process can be divided into the following three
levels of phases of design:
1. Interface Design
2. Architectural Design
3. Detailed Design
Design Process
Interface Design
Specification of the interaction between a system and its environment.
This phase proceeds at a high level of abstraction with respect to the
inner workings of the system
During interface design, the internal of the systems are completely
ignored and the system is treated as a black box.
Attention is focused on the dialogue between the target system and
the users, devices, other systems with which it interacts.
The design problem statement produced during the problem analysis
step should identify the people, other systems, and devices which are
collectively called agents.
Interface design should include the
following details
• Precise description of events in the environment, or messages from
agents to which the system must respond.
• Precise description of the events or messages that the system must
produce.
• Specification on the data, and the formats of the data coming into and
going out of the system.
• Specification of the ordering and timing relationships between
incoming events or messages, and outgoing events or outputs.
Architectural Design

• Specification of the major components of a system, their

responsibilities, properties, interfaces, and the relationships and
interactions between them.
• The overall structure of the system is chosen, but the internal details
of major components are ignored.
Detailed Design:
Design is the specification of the internal elements of all major system components, their
properties, relationships, processing, and often their algorithms and the data structures.
The detailed design may include:
1. Decomposition of major system components into program units.
2. Allocation of functional responsibilities to units.
3. User interfaces
4. Unit states and state changes
5. Data and control interaction between units
6. Data packaging and implementation, including issues of scope and visibility of program
elements
7. Algorithms and data structures
Design Concepts
• The software design concept simply means the idea or principle
behind the design.
• How you plan to solve the problem of designing software, the logic,
or thinking behind how you will design software.
• It allows the software engineer to create the model of the system or
software or product that is to be developed or built.
• The software design concept provides a supporting and essential
structure or model for developing the right software.
Design Concepts
Abstraction- hide Irrelevant data
• Abstraction simply means to hide the details to reduce complexity
and increases efficiency or quality.
• Different levels of Abstraction are necessary and must be applied at
each stage of the design process so that any error that is present can
be removed to increase the efficiency of the software solution and to
refine the software solution.
• The solution should be described in broad ways that cover a wide
range of different things at a higher level of abstraction and a more
detailed description of a solution of software should be given at the
lower level of abstraction.
Modularity- subdivide the system
• Modularity simply means dividing the system or project into smaller parts to
reduce the complexity of the system or project.
• In the same way, modularity in design means subdividing a system into smaller
parts so that these parts can be created independently and then use these parts
in different systems to perform different functions.
• It is necessary to divide the software into components known as modules
because nowadays there are different software available like Monolithic software
that is hard to grasp for software engineers.
• So, modularity in design has now become a trend and is also important. If the
system contains fewer components then it would mean the system is complex
which requires a lot of effort (cost) but if we are able to divide the system into
components then the cost would be small.
Architecture- design a structure
• Architecture simply means a technique to design a structure of
something. Architecture in designing software is a concept that
focuses on various elements and the data of the structure.
• These components interact with each other and use the data of the
structure in architecture.
Refinement- removes impurities
• Refinement simply means to refine something to remove any
impurities if present and increase the quality.
• The refinement concept of software design is actually a process of
developing or presenting the software or system in a detailed manner
that means to elaborate a system or software.
• Refinement is very necessary to find out any error if present and then
to reduce it.
Pattern- a repeated form
• The pattern simply means a repeated form or design in which the
same shape is repeated several times to form a pattern.
• The pattern in the design process means the repetition of a solution
to a common recurring problem within a certain context.
Information Hiding- hide the information
• Information hiding simply means hiding the information so that it
cannot be accessed by an unwanted party.
• In software design, information hiding is achieved by designing the
modules in a manner that the information gathered or contained in
one module is hidden and can’t be accessed by any other modules.
Refactoring- reconstruct something
• Refactoring simply means reconstructing something in such a way
that it does not affect the behavior of any other features.
• Refactoring in software design means reconstructing the design to
reduce complexity and simplify it without affecting the behavior or its
functions.
Design Quality
• A quality product does precisely what the users want it to do.
• For software products, the fitness of use is generally explained in terms of
satisfaction of the requirements laid down in the SRS document.
• Although "fitness of purpose" is a satisfactory interpretation of quality for
many devices such as a car, a table fan, a grinding machine, etc.
• For software products, "fitness of purpose" is not a wholly satisfactory
definition of quality.
• Example: Consider a functionally correct software product. That is, it
performs all tasks as specified in the SRS document. But, has an almost
unusable user interface. Even though it may be functionally right, we cannot
consider it to be a quality product.
Software Architecture And Its Types
• Software architecture is the blueprint of building software.
• It shows the overall structure of the software, the collection of
components in it, and how they interact with one another while
hiding the implementation.
• This helps the software development team to clearly communicate
how the software is going to be built as per the requirements of
customers.
Different Software Architecture Patterns :

1. Layered Pattern
2. Client-Server Pattern
3. Repository Architecture
1. Layered Pattern :
• As the name suggests, components(code) in this pattern are
separated into layers of subtasks and they are arranged one above
another.
• Each layer has unique tasks to do and all the layers are independent
of one another.
• One can modify the code inside a layer without affecting others.
• Commonly used pattern for designing the majority of software.
• This layer is also known as ‘N-tier architecture’.
• Basically, this pattern has 4 layers.
1. Layered Pattern
1. Layered Pattern :
• Presentation layer (The user interface layer where we see and enter
data into an application.)
• Business layer (this layer is responsible for executing business logic as
per the request.)
• Application layer (this layer acts as a medium for communication
between the ‘presentation layer’ and ‘data layer’.
• Data layer (this layer has a database for managing data.)
Ideal for:
E-commerce web applications development like Amazon.
2. Client-Server Pattern
Client-server pattern has two major entities.
There are a server and multiple clients.
Here the server has resources(data, files or services) and a client requests the server for a
particular resource.
Then the server processes the request and responds back accordingly.
Examples of software developed in this pattern:
• Email.
• WWW.
• File sharing apps.
• Banking, etc…
So this pattern is suitable for developing the kind of software listed in the examples.
2. Client-Server Pattern
3. Repository Architecture
• Data is stored in a central shared repository.
• Components interact through the repository only.
• Suited to applications whose data is generated by one component
and used by another.
Advantages: - Components are independent/separate. - Changes to
data are automatically available to other components.
• Communication between components may be inefficient
3. Repository Architecture
4.Model-View-Controller (MVC)
• The Model-View-Controller (MVC) is an architectural pattern that
separates an application into three main logical components:
the model, the view, and the controller.
• Each of these components are built to handle specific development
aspects of an application.
• MVC is one of the most frequently used industry-standard web
development framework to create scalable and extensible projects.
Model-View-Controller (MVC)
Model

• The Model component corresponds to all the data-related logic that

the user works with.
• This can represent either the data that is being transferred between
the View and Controller components or any other business logic-
related data.
• For example, a Customer object will retrieve the customer
information from the database, manipulate it and update it data back
to the database or use it to render data.
View

• The View component is used for all the UI logic of the application.
• For example, the Customer view will include all the UI components
such as text boxes, dropdowns, etc. that the final user interacts with.
Controller
• Controllers act as an interface between Model and View components
to process all the business logic and incoming requests, manipulate
data using the Model component and interact with the Views to
render the final output.
• For example, the Customer controller will handle all the interactions
and inputs from the Customer View and update the database using
the Customer Model.
• The same controller will be used to view the Customer data.
Pipe and Filter architectures

• Pipe and Filter is a simple architectural style that connects a number of

components that process a stream of data.
• Each is connected to the next component in the processing pipeline via a Pipe.
• The Pipe and Filter architecture is inspired by the Unix technique of
connecting the output of an application to the input of another via pipes on
the shell.
• The pipe and filter architecture consists of one or more data sources.
• The data source is connected to data filters via pipes.
• Filters process the data they receive, passing them to other filters in the
pipeline.
• The final data is received at a Data Sink:
Pipe and Filter architectures
Application Architecture
• An application architecture describes the patterns and techniques
used to design and build an application.
• The architecture gives you a roadmap and best practices to follow
when building an application, so that you end up with a well-
structured app.
• Patterns can be linked together to create more generic application
architectures.
• Instead of completely creating the architecture yourself, you can use
existing design patterns.
Application Architecture
• As part of an application architecture, there will be both front-end and back-end
services.
• Front-end development is concerned with the user experience of the app, while
back-end development focuses on providing access to the data, services, and
other existing systems that make the app work.
• The architecture is a starting point or roadmap for building an application, but
you’ll need to make implementation choices not captured in an architecture.
• For example, a first step is to choose a programming language in which to write
the application.
• There are many programming languages used for software development. Certain
languages may be used to build certain types of applications, such as Swift for
mobile apps or JavaScript for front-end development.
User Interface Design
• Design of the interface or system which is directly accessible by the user and
they interact with in order to do a task.
• It establishes the way with which the user will interact with the product.
• Its main aim is to enhance the appearance of the product, the quality of
technology used and the usability of the product.
• It refers to the software or the hardware of the system which the user can
see and also the various ways or commands to control or use the product.
• It focuses on the looks or how the app or software is looking. Attributes like
theme, animations, colors, etc constitute the user interface.
Principles of User Interface Design

• Minimize actions − Minimize action means steps per screen. The tasks and actions are
streamlined so that they can be done in as few steps as possible. The interface should be
designed keeping in mind to maintain the steps as few as possible for performing any tasks.
• Simplicity − The user interface should not be complex. It should always be designed simple
and elegant.
• Consistent − The user interface should be consistent. The design should be consistent.
Increasing consistency increases the familiarity, and hence increases the usability.
• Proving useful feedback − The user should be provided with feedback for every action. This
keeps the user informed and helps them to know whether some action was successful or not.
• Clarity − Content should provide the user with clarity. There should not be anything which
confuses the user, as it becomes an obstacle for the user in interacting with the product.
Human-Computer interaction
• Cross-disciplinary area that deals with the theory design,
implementation, and evaluation of the ways humans use and interact
with computing devices.
• User interaction means issuing commands and associated data to the
computer system.
• Designer focuses on how the information from the user be provided
to the computer system and how can information from the computer
system is presented to users.
Five basic method of user interactions
• Direct Manipulation
• Menu selection
• Form fill-in
• Command language
• Natural Language
Information Presentation
Information presentation is concerned with presenting system
information to system users
The information may be presented directly (e.g. text in a word
processor) or may be transformed in some way for presentation (e.g. in
some graphical form)
The Model-View-Controller approach is a way of supporting multiple
presentations of data
Information Presentation
Interface evaluation

• Interface evaluation in software engineering is the process of assessing the

effectiveness of the user interface (UI) design of a software application. The
objective of interface evaluation is to determine whether the UI design meets the
needs of the users and provides a positive user experience.
• There are various techniques that can be used to evaluate the interface of a
software application. Some common techniques include:
• Heuristic evaluation: This technique involves a group of evaluators examining the
interface of the software application and identifying potential usability issues
based on a set of heuristics or guidelines.
• Usability testing: This technique involves observing users as they interact with the
software application and collecting data on their interactions and feedback. This
can be done in a controlled lab setting or in the user's natural environment.
Conti..
• Cognitive walkthrough: This technique involves a step-by-step analysis of how a
user would complete specific tasks using the software application. This helps
identify potential usability issues and areas for improvement.
• A/B testing: This technique involves comparing two different interface designs
and collecting data on user behavior to determine which design is more
effective.
• Surveys and questionnaires: This technique involves collecting feedback from
users through surveys or questionnaires to assess their satisfaction with the
interface design and identify areas for improvement.
• Overall, interface evaluation is an important aspect of software engineering as it
helps ensure that software applications are user-friendly and meet the needs of
their intended audience.
Design Notation
Design notation in software engineering is a standardized visual language used to
represent and communicate the design of a software system. Design notations are
used to describe the structure, behavior, and relationships between components
of a software system.
Some common design notations in software engineering include:
1. Unified Modeling Language (UML): UML is a standardized visual language
used to represent the design of a software system. It includes a set of
diagrams, such as class diagrams, sequence diagrams, and activity diagrams,
which can be used to represent the various aspects of a software system.
2. Data Flow Diagrams (DFD): DFD is a diagrammatic representation of the flow
of data within a software system. It shows how data is input, processed, and
output from a system.
Conti..
1. Entity Relationship Diagrams (ERD): ERD is a diagrammatic
representation of the relationships between different entities within
a software system. It is commonly used to design relational
databases.
2. State Transition Diagrams: State Transition Diagrams are used to
represent the states and transitions of an object in a software
system. It is commonly used to model the behavior of a system.
3. Flowcharts: Flowcharts are a graphical representation of the flow of
control in a software system. It shows the steps involved in a
process and the decision points that determine the flow of control.