LNCT GROUP OF COLLEGES
Name of Faculty: Huma Gupta
Designation: Assistant Professor
Department: IT
Subject: Software Engineering IT604
Unit: III
Topic: Software Design
LNCT GROUP OF COLLEGES
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 yields three levels of results:
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- 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. It defines logical structure of each
module and their interfaces to communicate with other modules.
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.
LNCT GROUP OF COLLEGES
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
Concurrency
Back in time, all software are meant to be executed sequentially. By sequential execution we
mean that the coded instruction will be executed one after another implying only one portion
of program being activated at any given time. Say, a software has multiple modules, then
only one of all the modules can be found active at any time of execution.
In software design, concurrency is implemented by splitting the software into multiple
independent units of execution, like modules and executing them in parallel. In other words,
concurrency provides capability to the software to execute more than one part of code in
parallel to each other.
It is necessary for the programmers and designers to recognize those modules, which can be
made parallel execution.
Example
The spell check feature in word processor is a module of software, which runs along side the
word processor itself.
Coupling and Cohesion
When a software program is modularized, its tasks are divided into several modules based
on some characteristics. As we know, modules are set of instructions put together in order to
achieve some tasks. They are though, considered as single entity but may refer to each other
to work together. There are measures by which the quality of a design of modules and their
interaction among them can be measured. These measures are called coupling and cohesion.
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.
LNCT GROUP OF COLLEGES
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.
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.
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.
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 common data structure and work on
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 parameter). If a module passes data structure as parameter,
then the receiving module should use all its components.
Ideally, no coupling is considered to be the best.
Design Verification
The output of software design process is design documentation, pseudo codes, detailed logic
diagrams, process diagrams, and detailed description of all functional or non-functional
requirements.
The next phase, which is the implementation of software, depends on all outputs mentioned
above.
It is then becomes necessary to verify the output before proceeding to the next phase. The
early any mistake is detected, the better it is or it might not be detected until testing of the
product. If the outputs of design phase are in formal notation form, then their associated
LNCT GROUP OF COLLEGES
tools for verification should be used otherwise a thorough design review can be used
for verification and validation.
By structured verification approach, reviewers can detect defects that might be caused by
overlooking some conditions. A good design review is important for good software design,
accuracy and quality.
Software Design Methodology
Software design is a process to conceptualize the software requirements into software
implementation. Software design takes the user requirements as challenges and tries to find
optimum solution. While the software is being conceptualized, a plan is chalked out to find
the best possible design for implementing the intended solution.
There are multiple variants of software design. Let us study them briefly:
Structured Design
Structured design is a conceptualization of problem into several well-organized elements of
solution. It is basically concerned with the solution design. Benefit of structured design is, it
gives better understanding of how the problem is being solved. Structured design also makes
it simpler for designer to concentrate on the problem more accurately.
Structured design is mostly based on ‘divide and conquer’ strategy where a problem is
broken into several small problems and each small problem is individually solved until the
whole problem is solved.
The small pieces of problem are solved by means of solution modules. Structured design
emphasis that these modules be well organized in order to achieve precise solution.
These modules are arranged in hierarchy. They communicate with each other. A good
structured design always follows some rules for communication among multiple modules,
namely -
Cohesion - grouping of all functionally related elements.
Coupling - communication between different modules.
A good structured design has high cohesion and low coupling arrangements.
Function Oriented Design
In function-oriented design, the system is comprised of many smaller sub-systems known as
functions. These functions are capable of performing significant task in the system. The
system is considered as top view of all functions.
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.. These functional
LNCT GROUP OF COLLEGES
modules can share information among themselves by means of information passing
and using information available globally.
Another characteristic of functions is that when a program calls a function, the function
changes the state of the program, which sometimes is not acceptable by other modules.
Function oriented design works well where the system state does not matter and
program/functions work on input rather than on a state.
Design Process
The whole system is seen as how data flows in the system by means of data flow
diagram.
DFD depicts how functions changes data and state of entire system.
The entire system is logically broken down into smaller units known as functions on
the basis of their operation in the system.
Each function is then described at large.
Object Oriented Design
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.
Let us see the important concepts of Object Oriented Design:
Objects - All entities involved in the solution design are known as objects. For
example, person, banks, company and customers are treated as objects. Every entity
has some attributes associated to it and has some methods to perform on the attributes.
Classes - A class is a generalized description of an object. An object is an instance of
a class. Class defines all the attributes, which an object can have and methods, which
defines the functionality of the object.
In the solution design, attributes are stored as variables and functionalities are
defined by means of methods or procedures.
Encapsulation - In OOD, the attributes (data variables) and methods (operation on
the data) are bundled together is called encapsulation. Encapsulation not only bundles
important information of an object together, but also restricts access of the data and
methods from the outside world. This is called information hiding.
Inheritance - OOD allows similar classes to stack up in hierarchical manner where
the lower or sub-classes can import, implement and re-use allowed variables and
methods from their immediate super classes. This property of OOD is known as
inheritance. This makes it easier to define specific class and to create generalized
classes from specific ones.
Polymorphism - OOD languages provide a mechanism where methods performing
similar tasks but vary in arguments, can be assigned same name. This is called
polymorphism, which allows a single interface performing tasks for different types.
Depending upon how the function is invoked, respective portion of the code gets
executed.
LNCT GROUP OF COLLEGES
Design Process
Software design process can be perceived as series of well-defined steps. Though it varies
according to design approach (function oriented or object oriented, yet It may have the
following steps involved:
A solution design is created from requirement or previous used system and/or system
sequence diagram.
Objects are identified and grouped into classes on behalf of similarity in attribute
characteristics.
Class hierarchy and relation among them is defined.
Application framework is defined.
Software Design Approaches
Here are two generic approaches for software designing:
Top Down Design
We know that a system is composed of more than one sub-systems and it contains a number
of components. Further, these sub-systems and components may have their on set of sub-
system and components and creates hierarchical structure in the system.
Top-down design takes the whole software system as one entity and then decomposes it to
achieve more than one sub-system or component based on some characteristics. Each sub-
system or component is then treated as a system and decomposed further. This process keeps
on running until the lowest level of system in the top-down hierarchy is achieved.
Top-down design starts with a generalized model of system and keeps on defining the more
specific part of it. When all components are composed the whole system comes into
existence.
Top-down design is more suitable when the software solution needs to be designed from
scratch and specific details are unknown.
Bottom-up Design
The bottom up design model starts with most specific and basic components. It proceeds
with composing higher level of components by using basic or lower level components. It
keeps creating higher level components until the desired system is not evolved as one single
component. With each higher level, the amount of abstraction is increased.
Bottom-up strategy is more suitable when a system needs to be created from some existing
system, where the basic primitives can be used in the newer system.
Both, top-down and bottom-up approaches are not practical individually. Instead, a good
combination of both is used.