Software Design

Study Notes
SDLC
 SOFTWARE DESIGN
• Software design is a process to transform user
requirements into some suitable form, which 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 of 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 problem domain
to solution domain. It tries to specify how to fulfill the
requirements mentioned in SRS.
Software Design Levels
 Software Design Levels
• Architectural Design - The architectural design is the highest
abstract version of the system. It identifies the software as a system
with many components interacting with each other. At this level,
the designers get the idea of proposed solution domain.
• High-level Design- The high-level design breaks the ‘single entity-
multiple component’ concept of architectural design into less-
abstracted view of sub-systems and modules and depicts their
interaction with each other. High-level design 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.
• Detailed Design- It defines logical structure of each module and
their interfaces to communicate with other modules. Detailed
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.
 Architectural Design
• The software needs the architectural design to represents the design of
software.
• IEEE defines architectural design as “the process of defining a collection of
hardware and software components and their interfaces to establish the
framework for the development of a computer system.” The software that
is built for computer-based systems can exhibit one of these many
architectural styles.

• Each style will describe a system category that consists of :

• A set of components (e.g.: a database, computational modules) that

will perform a function required by the system.
• The set of connectors will help in coordination, communication, and
cooperation between the components.
• Conditions that how components can be integrated to form the
system.
• Semantic models that help the designer to understand the overall
properties of the system.
• Architectural design in software engineering is about decomposing the
system into interacting components.
• It is expressed as a block diagram defining an overview of the system
structure, features of the components, and how these components
communicate with each other to share data.
• It identifies the components that are necessary for developing a
computer-based system and communication between them i.e.
relationship between these components.
• It defines the structure and properties of the components that are
involved in the system and also the interrelationships between these
components.
• The architectural design process is about identifying the components i.e.
subsystems that makeup the system and structure of the sub-system and
they’re interrelationship. It is an early stage of the system design phase. It
acts as a link between specification requirements and the design process.
 Architectural design models
• Architectural design models are application domain-specific
and the most common two types of domain-specific
models are:
• Generic model: These models are abstractions derived
from a number of real systems and encapsulated the
characteristics of these systems. This type of model usually
follows a bottom-up approach.
• Reference models: These models provide information
regarding the class of the system. They are derived from
the application domain rather than from existing systems. It
usually follows the top-down approach. It provides a
comparison between different Software architecture.
Objectives of Software Design
 Objectives of Software Design
• Correctness: A good design should be correct, which means
that it should correctly implement all of the system's
features.
• Efficiency: A good software design should consider
resource, time, and cost optimization parameters.
• Understandability: A good design should be easy to grasp,
which is why it should be modular, with all parts organized
in layers.
• Completeness: The design should include all components,
such as data structures, modules, and external interfaces,
among others.
• Maintainability: A good software design should be flexible
when the client issues a modification request.
Software Design Concepts
 Low Level Design
• Process of defining the detailed, functional design of
a software system or component.
• It involves specifying the individual modules, data
structures, algorithms, interfaces, and
inputs/outputs of a system.
• The purpose of low-level design is to provide a clear
and precise description of how the system should
behave and how its different components will
interact with each other.
 Types of Low-Level Design
• Data Flow Design
• Data Structure Design
• Algorithm Design
• Component-Level Design
• Architectural Design
 Data Flow Design
• To represent the flow of data and information
through a system or application.
• The purpose of DFD is to identify the different
components of the system and how they interact
with each other, in order to optimize the design and
improve its overall functionality.
• DFD consists of a set of interconnected diagrams that
illustrate the flow of data through the system.
• It shows how data enters and leaves the system,
what changes the information, and where data is
stored.
 DFD Diagrams
• The diagrams consist of four basic components:
• Data sources and sinks: These are the sources and destinations of data
within the system. A data source could be an external entity that provides
data to the system, while a data sink could be an external entity that
receives data from the system.
• Processes: These are the individual components of the system that
manipulate or transform the data. Processes are represented as boxes on
the DFD diagram, and each process is labeled with a name and a
description of its functionality.
• Data flows: These are the pathways through which data moves from one
component of the system to another. Data flows are represented as
arrows on the DFD diagram, and each arrow is labeled with a description
of the data being transferred.
• Data stores: These are the locations within the system where data is
stored for later use. Data stores are represented as rectangles on the DFD
diagram, and each data store is labeled with a description of the data it
contains.
 Levels in Data Flow Diagrams (DFD)

• Three levels in the data flow diagram, which

are:
• 0-level DFD
• 1-level DFD
• 2-level DFD
 0-level DFDM

• It is also known as fundamental system

model, or context diagram.
• This level work without providing any details
about the internal workings of these
processes.
• It is essential to preserve the number of inputs
and outputs between levels.
• if bubble "A" has two inputs x1 and x2 and one output y, then
the expanded DFD, that represents "A" should have exactly
two external inputs and one external output as shown in fig:
 1-level DFD
• In 1-level DFD, a context diagram is
decomposed into multiple bubbles/processes.
• This level provides a more detailed view of the
system
• In this level, we highlight the main objectives
of the system and breakdown the high-level
process of 0-level DFD into subprocesses.
 2-Level DFD

• 2-level DFD goes one process deeper into

parts of 1-level DFD.
• It can be used to project or record the
specific/necessary detail about the system's
functioning.
• This level provides an even more detailed
view of the system by breaking down the sub-
processes identified in the level 1 DFD into
further sub-processes.
 Modularization
• Modularization is a technique to divide a software system into multiple
discrete and independent modules, which are expected to be capable of
carrying out task(s) independently.
• These modules may work as basic constructs for the entire software.
Designers tend to design modules such that they can be executed and/or
compiled separately and independently.
• Modular design unintentionally follows the rules of ‘divide and conquer’
problem-solving strategy this is because there are many other benefits
attached with the modular design of a software.
• Advantage of modularization:
 Smaller components are easier to maintain
 Program can be divided based on functional aspects
 Desired level of abstraction can be brought in the program
 Components with high cohesion can be re-used again.
 Concurrent execution can be made possible
 Desired from security aspect.
Modularization
How should we decompose modules?

• The independence of a module can be

measured using coupling and cohesion.
• Coupling: Coupling is the measure of the degree of
interdependence between the modules. A good
software will have low coupling.
• Cohesion: Cohesion is a measure of the degree to
which the elements of the module are functionally
related. Basically, cohesion is the internal glue that
keeps the module together. A good software design
will have high cohesion.
 Structure Charts
• It represent hierarchical structure of modules.
• It breaks down the entire system into lowest
functional modules
• Structure Chart partitions the system into black
boxes (functionality of the system is known to the
users but inner details are unknown).
• Inputs are given to the black boxes and appropriate
outputs are generated.
Symbols used in construction of structured
chart
1. Module It represents the process or task of the system.
• Control Module
A control module branches to more than one sub module.
• Sub Module
Sub Module is a module which is the part (Child) of another module.
• Library Module
Library Module are reusable and invokable from any module.
2. Conditional Call :It represents that control
module can select any of the sub module on
the basis of some condition.
3. Loop (Repetitive call of module)
It represents the repetitive execution of module by the
sub module.
A curved arrow represents loop in the module.
 4. Data Flow It represents the flow of data between the
modules. It is represented by directed arrow with empty circle at
the end. .
5. Control Flow It represents the flow of control between the
modules. It is represented by directed arrow with filled circle at
the end.

Data Flow Control Flow

6. Physical Storage Physical Storage is that
where all the information are to be stored
Structure Chart of Email Server
 Pseudo code
• Pseudo code is a term which is often used in
programming and algorithm based fields.
• It is a methodology that allows the programmer
to represent the implementation of an algorithm.
• It’s simply an implementation of an algorithm in
the form of annotations and informative text
written in plain English.
• It has no syntax like any of the programming
language and thus can’t be compiled or
interpreted by the computer.
 Flowchart
• Flowchart is a graphical representation of an
algorithm.
• Programmers often use it as a program-
planning tool to solve a problem.
• It makes use of symbols which are connected
among them to indicate the flow of
information and processing.
• The process of drawing a flowchart for an
algorithm is known as “flowcharting”.
Basic Symbols used in Flowchart
Designs
Basic Symbols used in Flowchart
Designs
Basic Symbols used in Flowchart
Designs
Example : Draw a flowchart to input two numbers from the
user and display the largest of two numbers
 Advantages of Flowchart
• Flowcharts are a better way of communicating the logic of
the system.
• Flowcharts act as a guide for blueprint during program
designed.
• Flowcharts help in debugging process.
• With the help of flowcharts programs can be easily analyzed.
• It provides better documentation.
• Flowcharts serve as a good proper documentation.
• Easy to trace errors in the software.
• Easy to understand.
• The flowchart can be reused for inconvenience in the future.
• It helps to provide correct logic.
• Data flow diagram(DFD) for Online shopping
website
• Context Level DFD for Hospital Management
System
 Design Strategies
• Function Oriented Design
• Object Oriented Design
• Top-Down and Bottom-Up Design
 Function Oriented Design
• It is an approach to software design where the design is
decomposed into a set of interacting units where each unit
has a clearly defined function.
• These functions are capable of performing significant task in
the system.
• Function oriented design inherits some properties of
structured design where divide and conquer methodology is
used.
• This design mechanism divides the whole system into smaller
functions, which provides means of abstraction by concealing
the information and their operation
 Function Oriented Design Strategies

1. Entity Relationship Diagram

2. Decision Tree & Decision Table
3. Data Flow Diagrams (DFD)
4. Data Dictionary
5. Pseudo - Code
 Entity Relationship (ER) Diagram
• An Entity Relationship (ER) Diagram is a type of flowchart that
illustrates how “entities” such as people, objects or concepts
relate to each other within a system.
• ER Diagrams are most often used to design or debug
relational databases in the fields of software engineering,
business information systems, education and research. Also
known as ERDs or ER Models.
• They use a defined set of symbols such as rectangles,
diamonds, ovals and connecting lines to depict the
interconnectedness of entities, relationships and their
attributes.
• ER diagrams are related to data structure diagrams (DSDs),
which focus on the relationships of elements within entities
instead of relationships between entities themselves
Symbols of ER Diagram
Difference between DFD and ERD
 Decision Tree & Decision Table
• A Decision Tree provides a visual representation of the processing
logic involved in higher cognitive activity, allowing for the
appropriate actions.
• The perimeters of a choice tree represent conditions, and the leaf
nodes reflect the actions to be taken in response to the condition's
test result.
• A decision table is a valuable tool for dealing with various
combinations of inputs and results. It's a black box test design
technique for determining complex business logic test scenarios.
• Decision Table is just a tabular representation of all conditions and
actions. Decision Table are always used whenever the processing
logic is very complicated and involves multiple conditions. The main
components used for the formation of the Data Table are
Conditions Stubs, Action Stubs, and rules.
Decision table and Decision Tree
 Data Dictionaries
• A data dictionary is a file or a set of files that includes a
database's metadata.
• The data dictionary hold records about other objects in the
database, such as data ownership, data relationships to other
objects, and other data.
• The data dictionary is an essential component of any
relational database.
• it is invisible to most database users. Typically, only database
administrators interact with the data dictionary.
• It includes:
• Name of the data item
• Aliases
• Description/purpose
• Related data items
• Range of values
• Data structure definition/Forms
Data Dictionary Notations tables
 Object Oriented Design
• In the object-oriented design method, the system is viewed as a
collection of objects (i.e., entities).
• Object oriented design works around the entities and their
characteristics instead of functions involved in the software
system.
• This design strategies focuses on entities and its characteristics.
The whole concept of software solution revolves around the
engaged entities.
• The major system components are partitioned into subsystems (a
system-level “modular”), and data manipulation operations are
encapsulated into objects (a modular form that is the building
block of an OO system.).
• In addition, OOD must specify some data organization of attributes
and a procedural description of each operation. Shows a design
pyramid for object-oriented systems.
• E.g. banking System: customer object,account object
 Terminologies in Object-Oriented Design

1. Attributes: a collection of data values that describe a class.

2. Class: encapsulates the data and procedural abstractions
required to describe the content and behavior of some
real-world entity. In other words, A class is a generalized
description that describes the collection of similar objects.
3. Objects: instances of a specific class. Objects inherit a
class’s attributes and operations.
4. Operations: also called methods and services, provide a
representation of one of the behaviors of the class.
5. Subclass: specialization of the super class. A subclass can
inherit both attributes and operations from a super class.
6. Superclass: also called a base class, is a generalization of a
set of classes that are related to it.
 Advantages to using OOAD

• Reusability: OOAD emphasizes the use of reusable

components and design patterns, which can save time
and effort in software development.
• Scalability: OOAD can help developers design software
systems that are scalable and can handle changes in
user demand and business requirements over time.
• Maintainability: OOAD emphasizes modular design and
can help developers create software systems that are
easier to maintain and update over time.
• Flexibility: OOAD can help developers design software
systems that are flexible and can adapt to changing
business requirements over time.
 Top-Down Design Model
• The top-down model is one in which the
whole system is decomposed into smaller sub-
components, then each of these parts are
designed and developed till the completed
system is designed
 Bottom-Up Model
• Bottom-Up Model is a system design
approach where the parts of a system are
defined in details. Once these parts are
designed and developed, then these parts or
components are linked together to prepare a
bigger component. This approach is repeated
until the complete system is built.
• Bottom-Up Model
• Focus
• In Bottom-Up Model, the focus is on identifying and resolving smallest problems
and then integrating them together to solve the bigger problem.
• Language
• Bottom-Up Model is mainly used by object oriented programming languages
like Java, C++, etc.
• Redundancy
• Bottom-Up model is better suited as it ensures minimum data redundancy and
focus is on re-usability.
• Interaction
• Bottom-Up model have high interactivity between various modules.
• Bottom-up model is based on composition approach.
• Issues
• In Bottom-Up, sometimes it is difficult to identify overall functionality of system in
initial stages.
• Top-Down Model
• Focus
• In Top-down Model, the focus is on breaking the bigger problem into smaller one
and then repeat the process with each problem.
• Language
• Top-Down Model is followed by structural programming languages like C, Fortran,
etc.
• Redundancy
• Top-down model has high ratio of redundancy as the size of project increases.
• Interaction
• Top-down model has tight coupling issues and low interactivity between various
modules.
• Approach
• Top-down model is based on decomposition approach.
• Issues
• In Top-Down, it may not be possible to break the problem into set of smaller
problems.