Software Design - SDLC Model

Software Engineering
Dr. Kamal Gulati
(Part 4) – Software Design

Contents for Software Design
1. Design principles
2. Problem partitioning
3. Abstraction
4. Top down and bottom
up-design
5. Structured approach
6. Functional versus object
oriented approach
7. Design specifications and
verification
9. Monitoring and control
10.Cohesiveness
11.Coupling
12.Fourth generation
techniques
13.Functional
independence
14.Software Architecture
15.Transaction and
Transform Mapping
16.Component – level
Design

Design Concepts And Principles
Software Design -- An iterative process
transforming requirements into a
“blueprint” for constructing the
software.

Relation of Analysis to Design

The Design Model
• Data Design
– Transforms information
domain model into data
structures required to
implement software
• Architectural Design
– Defines relationship among
the major structural
elements of a program
Procedural
Design
Interface Design
Architectural Design
Data Design
The Design Model
Which is mapped from the
Analysis model

The Design Model
• Interface Design
– Describes how the software
communicates with itself,
to systems that interact
with it and with humans.
• Procedural Design
– Transforms structural
elements of the
architecture into a
procedural description of
software construction
Procedural
Design
Interface Design
Architectural Design
Data Design
The Design Model
Which is mapped from the
Analysis model

Design methodology
….is a systematic approach to create a design by applying of
a set of techniques and guidelines.
Input – specifications of the system to be designed
Output – system design

Object Oriented Design
vs
Function Oriented Design
• Object - oriented : modules in the design represent data abstraction
• Function - oriented : consists of module definitions, with each
module supporting a functional abstraction
• Function-oriented design views a system as a set of modules with
clearly defined behavior that interact with each other in a clearly
defined manner to meet the system's requirements.

Design Objectives
• The goal of software design is to find the best
possible design that meets your needs
• You may have to explore different designs
• Unfortunately, evaluation criteria for a design
are often subjective and non-quantifiable

• Major criteria to evaluate a design
– Correctness
• A software design is correct if a system built precisely according to the
requirements of the system
• A design should be verifiable (does an implementation match the design),
complete (does the design address its specified requirements) and traceable
(all design elements can be traced back to specific requirements)
– Efficiency
• Does the design efficiently make use of scarce resources: such as memory on
a wireless sensor
– Maintainability and Simplicity
• How easy is it for the design of a system to be understood?
• Simpler designs make it easy for a developer to understand and then
maintain the system
– Cost
• Does the design help to reduce costs in later phases of software
development?
• Can one design achieve the same quality as another design while reducing
costs?

Problem analysis Vs Design Principles
• Constructing a model of
problem domain
• Model depends on the
system
• Model is used to understand
the problem
 Constructing a model of
solution domain
 System depends on the
model
 Model is used for
optimization

Design Principles
• Problem Partitioning and Hierarchy
• Abstraction
• Modularity
• Top-Down and Bottom-Up Strategies

Problem Partitioning and Hierarchy
• Divide and Conquer
• Decompose system into smaller and smaller pieces
– Ideally, each piece can be solved separately
– Ideally, each piece can be modified independent of other pieces
• Reality: each piece must communicate with other pieces
– This communication implies a certain cost
– At some point the cost is more than the benefit provided by the
individual pieces
– At this point, the decomposition process can stop

Abstraction
• Abstraction is a powerful concept used in all
engineering disciplines
• It is a tool that permits a developer to consider a
component in terms of the services (behaviors) it
provides without worrying about the details of its
implementation

Contd…
• Abstraction is an excellent tool for creating a hierarchical understanding of a
system's functionality
• In design contexts, you might see references to two “types” of abstraction
– functional abstraction: a module is specified by the functions it performs
– data abstraction: a data structure is manipulated in terms of pre-defined
operations; the implementation of the data structure is hidden from its
users (only operations are visible)
– The former is primarily used in functional design, the latter is used
primarily in object-oriented design

Data Abstraction
door
implemented as a data structure
manufacturer
model number
type
swing direction
inserts
lights
type
number
weight
opening mechanism

Modularity
• A system is considered modular if it consists of discreet
components so that each component can be implemented
separately, and a change to one component has minimal
impact on other components
• Helps in system repair and in system building
• Each component needs to support a well-defined
abstraction and have a specific interface that other modules
use to interact with it
• As Jalote says “Modularity is where abstraction and
partitioning come together”.

Top-Down vs Bottom-Up Design
• A system consists of a set of components, which have
subcomponents of their own
– The highest level component is the system itself, a concept we have
seen when discussing context diagrams
• We can design such a hierarchy using either a top-down approach or
a bottom-up approach
– In reality, we use both approaches and meet in the middle
• A top-down approach starts with the system as a whole, and using
stepwise refinement, decomposes it into sub-components that exist
at lower levels of abstraction

Contd…
• A bottom-up approach starts with primitive components that provide
foundational services and using layers of abstraction builds the
functionality the system needs until the entire system has been
realized
• A top-down approach is typically more useful in situations only if the
specifications of the system are clearly known and application is
being built from scratch (water fall model)
• A bottom-up approach is thus more useful in situations in which a
new application is being created from an existing (legacy) system
(Iterative enhancement model)

Module
• It is a logically separable part of a program
• It is a program unit that is discreet and identifiable with
respect to compiling and loading
• Can be a function, a procedure, a process or a package

Module-Level Concepts
– Coupling
– Cohesion

Coupling
• “how strongly” different modules are interconnected
• By definition,
“Coupling between modules is the strength of
interconnections between modules or a measure of
interdependence among modules”
• An abstract concept and is not easily quantifiable
• Highly coupled – strong interconnections
Loosely coupled – weak interconnections

Contd…
• Factors influencing coupling are :
type of connection between modules
the complexity of the interface
the type of information flow between
modules.
• Minimize the number of interfaces per module and the
complexity of each interface
• Depends up on the type of information flow, coupling varies
Data Flow – Minimal
Hybrid – Maximum (data and control)

Cohesion
• Cohesion is the concept that tries to capture intra-module bonds
• Shows how closely the elements of a module are related to each other.
• Shows how tightly bound the internal elements of the module are to one
another
• Usually, greater the cohesion of each module in the system, the lower the
coupling between module is.
• cohesion: how focused is an object (or module, or function, or package,
etc.) on a particular task or concern
– a highly cohesive object has attributes and behavior that relate only
to one task or concern

Levels of cohesion
• Coincidental Low
• Logical
• Temporal
• Procedural
• Communicational
• Sequential
• Functional
High

Details…
• Coincidental Cohesion occurs when there is no meaningful
relationship among the elements of a module.
• Logical Cohesion: if there is some logical relationship between the
elements of a module (input and output modules)
• Temporal cohesion: same as logical cohesion, except that the
elements are also related in time and are executed together
(initialization, clean-up, termination)
• Procedurally cohesive module contains elements that belong to a
common procedural unit (loop or a sequence of decision
statements)

Contd…
• Communicational cohesion has elements that are related by a
reference to the same input or output data (may perform more
than one function)
• Sequential cohesion occurs when output of one forms the input
to another.
• In functional cohesion all the elements of the module are
related to performing a single function (single function or single
goal – “compute square root” or “sort the array”)

How does one determine the cohesion level
of a module?
• Compound sentence : sequential or communicational
cohesion
• “first”, “next”, “when”, “after” : sequential or temporal
• “edit all data” : logical cohesion
• “initialize” or “cleanup” : temporal cohesion

We aim to create systems out of highly cohesive,
loosely coupled components…

Design Notations
• Structure charts
• UML

Structure Charts
 A structure chart is a graphical representation of a system's structure; in
particular, its modules and their interconnections
 Each module is represented by a box
 If A uses B, then an arrow is drawn from A to B
 B is called the subordinate of A
 A is called the superordinate of B
 An arrow is labeled with the parameters received by B as input and the
parameters returned by B as output
 Arrows indicate the direction in which parameters flow
 Parameters can be data (shown as unfilled circles at the tail of a label) or
control information (filled circles at the tail)

The structure chart of the sort program

Supports Iteration and Branching

Types of Modules
• Input: A module that only produces information that is
passed to its superordinate
• Output: A module that only receives information from its
superordinate for output to a device
• Transform: A module that converts data from one format
into another format, possibly generating entirely new
information.
• Coordinator: A module that manages the flow of data to and
from different subordinates
• Composite: Modules that combine one or more of the above
styles are composite modules

Design specification
• A designer must also create a textual specification for each
module that appears in the system's structure
• Design specification contains
1. Problem Specification
2. Major Data Structures
3. Modules and their Specifications
4. Design Decisions

Structured Design Methodology
The structured design methodology
(SDM) views a system as a transformation function
that transforms specified inputs into specified
outputs.

Factoring
• A key concept of SDM is factoring
• Factoring is the process of decomposing a
module so that the bulk of its work is done by its
subordinates
• SDM attempts to achieve a structure that is close
to being completely factored

SDM Strategy
• The overall strategy of SDM is to identify the input and output streams of the
system and the primary transformations that have to be performed to produce
the output
• High-level modules are then created to perform these major activities, which
are later refined (factored)
• There are four major steps in applying this strategy
– Restate the problem as a data flow diagram
– Identify the input and output data elements
– Perform first-level factoring
– Perform additional factoring on input, output and transform branches
created in the previous step

Step 1: Restate the problem as a
data flow diagram
• DFD represents how the data will flow in the system when it
is built.
• Data flow diagrams during design are focused on the solution
domain
– What are the inputs and outputs of our system (as
opposed to the inputs and outputs of the problem
domain)?
– What are the central transformations?

Example 2: DFD for a word-counting program

Step 2: Identify the input and output data
elements
• What we are looking for is the most abstract input elements (MAI) and
the most abstract output elements (MAO)
• The MAI elements are found by going as far as possible from physical
inputs without losing the incoming nature of the data element
• The MAO elements are found by identifying the data elements most
removed from the physical outputs without losing the outgoing nature
of the data element

Step 3: First-Level Factoring
• First-level factoring is the first step towards converting the DFD into a
structure chart
• You start by creating a module that represents the software system (the
main module)
– The main module acts as a coordinator module
• For each MAI data element, specify a subordinate input module that
delivers these items to the main module
• For each MAO data element, specify an output module
• For each central transform, specify a subordinate transform module
– The inputs and outputs of these transform modules are specified in the
DFD

Example 1: First-Level Factoring of word-
counting example

Example 2: First-Level Factoring of ATM example

Step 4: Perform Additional Factoring
• Now stepwise refinement is used to specify the sub-
modules required to realize the functionality of the
modules created in the previous step
• For each input module:
– assume that it is in the main module
– add input modules that takes its MAI data element closer to
the raw input
– add transform modules in order to transform the raw input
into the desired MAI data element

Example: additional factoring of the word count program

Contd…
• Output modules are treated in a similar fashion,
this time working from MAO data elements to
the raw output of the system
• Central transforms are also factored in a
stepwise manner until you have specified atomic
modules that can be implemented directly

Example: additional factoring of the word count
program

SDM Wrap-Up
• Each new module produced in step 4 can then
be examined to see if additional factoring is
necessary

Design Heuristics
 The strategy requires the designer to exercise sound judgment
and common sense
 Cohesion and coupling should be the primary guiding factors
 A very high fan-out is not very desirable (control and
coordinate more modules)
 Fan-in should be maximized
 Scope of effect of a decision should be subset of the scope of
control.

Verification
• Designs should be checked for internal consistency and for
completeness with respect to the SRS
• If a formal design notation is used, then tools may be able to
perform some of these checks (Automated Cross Checking)
• Otherwise, design reviews (as part of your inspection process)
are required to ensure that the finished design is of high
quality

Design Reviews
• To ensure “quality” of the design
• Aim of design reviews – detecting errors in design
• Review team – a member of both the system design team and the
detailed design team, the author of the requirements document, the
author responsible for maintaining the design document, and an
independent software quality engineer.

Metrics
• To provide quantitative data to the management process
• Cost and schedule metrics are needed for tracking the progress
of the project
• Size is always a product metric of interest
• Size: Number of Modules x Average LOC expected per module
– Or you can generate LOC estimates for each individual
module

Metrics
• Quality metrics
Simplicity – most important design quality attribute
• Complexity metrics
– Network Metrics
– Stability Metrics
– Information Flow Metrics

Network Metrics
• Network metrics focus on the structure chart of a system
• They attempt to define how “good” the structure or network is in an
effort to quantify the complexity of the call graph
• The simplest structure occurs if the call graph is a tree.
– As a result, the graph impurity (deviation of the tree) is defined as
nodes - edges - 1
– In the case of a tree, this metric produces the result zero since
there is always one more node in a tree than edges
– This metric is designed to make you examine nodes that have high
coupling and see if there are ways to reduce this coupling

Stability Metrics
• Stability of a design is a metric that tries to quantify the
resistance of a design to the potential ripple effects that are
caused by changes in modules
• The creators of this metric argue that the higher the stability of a
design, the easier it is to maintain the resulting system
• This provides a stability value for each particular module
• In essence, the lower the amount of coupling between modules,
the higher the stability of the overall system

Information Flow Metrics
• Information flow metrics attempt to define the
complexity of a system in terms of the total
amount of information flowing through its
modules
• Jalote discusses two information flow metrics
and how they can be used to classify modules

Approach 1
– A module's complexity depends on its intramodule complexity and its
intermodule complexity
– intramodule complexity is approximated by the (estimated) size of the module in
lines of code
– intermodule complexity is determined by the total amount of information
(abstract data elements) flowing into a module (inflow) and the total amount of
information flowing out of a module (outflow)
– The module design complexity Dc is defined as Dc = size * (inflow*outflow)2
– The term (inflow*outflow)2 refers to the total number of input and output
combinations, and this number is squared since the interconnections between
modules are considered more important to determining the complexity of a
module than its code size

Approach 2
– Approach 1 depends largely on the amount of information flowing in and out of
the module
– Approach 2 is a variant that also considers the number of modules connected
to a particular module; in addition, the code size of a module is considered
insignificant with respect to a module's complexity
– The module design complexity Dc is defined as Dc = (fan_in * fan_out) +
(inflow*outflow)
– fan_in above refers to the number of modules that call this module, fan_out is
the number of modules called by this module

Classification
– Neither of these metrics is any good, unless they can tell us when to
consider a module “too complex”
– To this end, an approach was developed to compare a module's complexity
against the complexity of the other modules in its system
– avg_complexity is defined as the average complexity of the modules in the
current design
– std_deviation is defined as the standard deviation in the design complexity
of the modules in the current design
– A module can be classified as error prone, complex, or normal using the
following conditions
Dc is the complexity of a particular module
A module is error prone if Dc > avg_complexity + std_deviation
A module is complex if avg_complexity < Dc < avg_complexity +
std_deviation
Otherwise a module is considered normal

Software Architecture
Desired properties of an architectural design
• Structural Properties
– This defines the components of a system and the
manner in which these interact with one
another.
• Extra Functional Properties
–This addresses how the design
architecture achieves requirements for
performance, reliability and security
• Families of Related Systems
– The ability to reuse architectural building blocks

Thank You & Keep Learning!
?Follow us :
You can find me at
https://www.linkedin.com/in/drkamalgulati/
https://mybigdataanalytics.in/
https://www.facebook.com/DrKamalGulatiBig
DATA/

Software Design - SDLC Model

In this document

More Related Content

What's hot

Similar to Software Design - SDLC Model

More from Amity University | FMS - DU | IMT | Stratford University | KKMI International Institute | AIMA | DTU

Recently uploaded

Software Design - SDLC Model