Unit3 Software engineering UPTU

SoftwareDesign
2
More creative than analysis
Problem solving activity
‘HOW’
Software design document (SDD)
The goal of the design process is to product a model or
representation of a system, which can be used later to build that
system.

Whydesignisimportant?
3
A good design is the key to successful product. Few desirable
characteristics that every good software design must possess
are:
1. Correctness
2. Understandability
3. Efficiency
4. Maintainability
Without well-design system, we risk building an unstable
system.
• One that will fail when small changes are made.
• One that will be difficult to maintain.

GooddesignvsBadDesign
4
Characteristics Good design Bad design
Change Change in one part of
the system does not
always require a
change in another part
of the system.
One change
requires changes to
many parts of the
system.
Cost Small High
Nature Simple Complex
Extension System can be
extended with changes
in only one place
System cannot be
extended easily.

Objectivesof Design
5
It deals with transforming the customer requirements as
described in the SRS document into a form that is
implementable using a programming language. The
design needs to be :
 CorrectandComplete
 Understandable
Attherightlevel
 Maintainable

SoftwareDesign
9
Conceptual Design and Technical Design

SoftwareDesign
1
0
Conceptual design answers :
 Wherewillthedatacomefrom?
 Whatwillhappentothedatainthesystem?
 Howwillthesystemlooktousers?
 Whatchoiceswillbeofferedtousers?
 Whatisthetimingofevents?
 Howwillthereportsandscreenslooklike?

SoftwareDesign
1
1
Technical design describes :-
 Hardwareconfiguration
Softwareneeds
CommunicationInterfaces
 I/Oofthesystem
 SoftwareArchitecture
 NetworkArchitecture
Any other thing that translates the requirements into a solution to the
customer’s problem.

HLDandLLD
1
2
High Level Design Low Level Design
Also known as macro level/
system design
Also known as micro level/
detailed design
Overall architecture of the
application
Detailed description of the each
and every module
participants are design team,
review team and client
participants are only design team
input criteria is Software
Requirement Specification(SRS)
input criteria is HLD, which are
reviewed and authorized
Output criteria is database design,
functional design and review
record
Output criteria is Program
specification and unit test plan

LOWLEVELDESIGN
1
3
MODULARIZATION
A system is considered modular, if it consists of discrete components
so that each component can be implemented separately and a
change to one component has minimal impact on other components.

AdvantagesofModularSystems
1
4
• Modular systems are easier to understand and explain because their
parts are functionally independent.
• Modular systems are easier to document because each part can be
documented as an independent unit.
• Programming individual modules is easier because the programmer
can focus on just one small, simple problem rather than a large complex
problem.
• Testing and debugging individual modules is easier because they
can be dealt with in isolation from the rest of the program.
• Bugs are easier to isolate and understand and they can be fixed
without fear of introducing problems outside the module.

DESIGNMODEL
1
5
After analyzing and specifying all the requirements, the process of
software design begins. Each of the elements of analysis model is
used to create the design model. The elements of design model are:-
1. Data Design (ER Diagram + Data Dictionary)
2. Architectural Design (DFD)
3. Interface Design (DFD + Control flow diagrams)
4. Component-level Design (Process + Control specification)

SOFTWARE DESIGN
16
Software design is a creative process, just like designing anything else
To see a wrong design, we can check with the requirements in the
analysis model
To see a bad design, we need to assess the design model and analyze the
components, whether the performance can be improved by changing the
modules or the interfaces
In analyzing the software Design, many factors are used, out of which
two important factors are –
Coupling
Cohesion

COUPLING
17
Coupling is the measure of “the degree of
interdependence between modules".
We aim to minimize coupling – to make modules as
independent as possible.
Low coupling can be achieve by:
eliminating unnecessary relationships
reducing the number of necessary relationships

COUPLING
(Uncoupled : no dependencies)
(a)
18
Uncoupled modules have no interconnections at all,
they are completely independent.

Loosely coupled:
some dependencies
(B)
Highly coupled:
many dependencies
(C)
Fig. : Module coupling
19

Consider the example of editing a student record in a
‘student information system’.
Edit student
record
Retrieve
student record
Student name,
student ID,
address,
course
Student
record
Edit student
record
Retrieve
student record
Student
record
20
Student
ID
Poor design: Tight Coupling Good design: Loose Coupling
Fig. : Example of coupling

Given two procedures A & B, we can identify number of
ways in which they can be coupled.
Fig : The types of module coupling
21
Data coupling Best (Most required)
Stamp coupling
Control coupling
External coupling
Common coupling
Content coupling Worst (Least required)

Data coupling
22
Stamp coupling
Stamp coupling occurs between module A and B when
complete data structure is passed from one module to another.
The dependency between module A and B is said to be data
coupled if their dependency is based on the fact they
than
are
communicate
communicating
independent.
by only
through
passing
data,
of data.
the two
Other
modules

Control coupling
23
Module A and B are said to be 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.
External coupling
A form of a coupling in which 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 such as the operating system, shared
libraries or the hardware .
Common coupling
With common coupling, module A and module B have shared data.
Global data areas are commonly found in programming languages.
Making a change to the common data means tracing back to all the
modules which access that data to evaluate the effect of changes.

Fig : Example of common coupling
24

Content coupling
25
Content coupling occurs when module A changes data of
module B or when control is passed from one module to the
middle of another.

Impact of Coupling on Design
26
A good design process should aim at reducing coupling.
Reduction of coupling -> reduction of dependence of one
module on another -> increase the independence of module ->
increase the ability to change or maintain the modules.

COHESION
27
Cohesion measures how a single module is related to a particular
functionality in the system.
– only one module is involved
– ideally, a highly cohesive module should do only one task/
activity/function
– example:
• a sorting module that contains only one sorting function and this
function sorts integers only.
• a sorting module that contains several sorting functions that implement
various sorting techniques but all sort integers only.
• a sorting module that contains several sorting functions that implement
various sorting techniques but sort integers and floats.

Cohesion is a measure of the degree to
elements of a module are functionally related.
which the
COHESION
Fig : Cohesion=Strength of relations within modules
28
Module
strength

Types of cohesion
29
➢ Functional cohesion
➢ Sequential cohesion
➢ Procedural cohesion
➢ Temporal cohesion
➢ Logical cohesion
➢ Coincident cohesion

Fig : Types of module cohesion
30
Functional Cohesion Best (high)
Sequential Cohesion
Communicational Cohesion
Procedural Cohesion
Temporal Cohesion
Logical Cohesion
Coincidental Cohesion Worst (low)
Given a procedure that carries out operations A & B, we can
describe various forms of cohesion between A & B.

Functional Cohesion
31
➢. This is very good reason for them to be contained in the same
procedure.
➢ All elements contribute to the execution of one and only one
problem-related task
➢ Examples of functional cohesive modules:
• Compute cosine of angle
• Read transaction record
• Assign seat to airline passenger
➢A and B are part of a single functional task

Sequential Cohesion
32
➢Module A outputs some data which forms the input to B. This
is the reason for them to be contained in the same procedure.
➢ Elements are involved in activities such that output data from one
activity becomes input data to the next
➢Usually has good coupling and is easily maintained

Communicational Cohesion
33
➢ A and B both operate on the same input data or contribute
toward the same output data .
 Not flexible, for example, if we need to focus on some activities
and not the others
Example of Communicational Cohesion
- module determine customer details
use customer account no
find customer name
find customer loan balance
return customer name, loan balance
end module

34
Procedural Cohesion
 Procedural cohesion occurs in modules whose instructions
accomplish different tasks yet have been combined
because there is a specific order in which the tasks are to be
completed.
 Example: an input function receiving a data, a function that
processes the data, and a function that outputs the result of that
computation, all placed in the same module
 Example: report module of an examination system includes
the following –
 calculate student GPA
 print student record
 calculate cumulative GPA
 print cumulative GPA

35
 Module exhibits temporal cohesion when it contains tasks that
are related by the fact that all tasks must be executed in the
same time-span.
 functions that are related by time, all placed in the same
module
 example: the alarm system, automatic telephone dialing unit of a
security system both placed in the same module; these two must
be activated at the same time
 moderate level of cohesion
Temporal Cohesion

36
Logical Cohesion
➢ Logical cohesion occurs in modules that contain
instructions that appear to be related because they fall into
the same category.
- module display record
if record-type is student then
display student record
else if record-type is staff then
display staff record
end module
➢ functions that are logically related to each other, all placed
in the same module
- example: a set of functions that output a given data in various
formats (bar chart, graph, pie-chart, …)
➢ moderate level of cohesion

37
➢Coincidental cohesion exists in modules that
contain instructions that have little or no relationship to one
another.
➢ functions that are not at all related to each other but are placed
in a single module (happen to be a coincidence)
- example: a function that performs sorting and a printer driver,
both in the same module
➢ functions that are somewhat related but do not have much in
common also fall in this category.
- example: a function that computes an average of a sequence
and a function that sorts a sequence, both being placed in the
same module
 low-level cohesion
Coincidental Cohesion

Examples of Cohesion
Function A
Function
B
Function
D
Function
C
Function
E
Coincidental
Parts unrelated
Function A
Function A’
Function A’’
logic
Logical
Similar functions
Time t0
Time t0 + X
Time t0 + 2X
Temporal
Related by time
Function A
Function B
Function C
Procedural
Related by order of functions

Examples of Cohesion
Function A part 1
Function A part 2
Function A part 3
Functional
Sequential with complete, related functions
Function A
Function B
Function C
Communicational
Access same data
Function A
Function B
Function C
Sequential
Output of one is input to another

Impact of Cohesion on Design
40
A good design process should try to maximize cohesion
of each module
maximizing cohesion -> maximizing the use of the module
towards particular functionality -> appropriate modularization of
the design

Relationship between Cohesion & Coupling
Fig : View of cohesion and coupling
If the software is not properly modularized, a host of
seemingly trivial enhancement or changes will result into death of
the project. Therefore, a software engineer must design the modules
with goal of high cohesion and low coupling.
41

Evaluating Coupling and Cohesion
42
• Coupling can be evaluated using metrics tools.
- metrics will be discussed later.
• Cohesion is generally evaluated manually by experts /
software engineers.
– walk through the design documents and iterate the design
until cohesion is improved to a satisfactory level .

HIGHLEVELDESIGN
4
3
ARCHITECTURAL DESIGN
The HLD, also called architectural design.
Large systems are always decomposed into subsystems that provide some
related set of services. The initial design process of identifying these sub-
systems and establishing a framework for sub-system control and
communication is called architectural design.
Architectural design methods look into various alternate architectural style
of designing a system. These are:
• Data centric architecture
• Data flow architecture
• Object oriented architecture
• Layered architecture

ARCHITECTURALDESIGN
4
4
Data centric architecture approach involves the use of a central
database operations of inserting, updating it in the form of a table.
Data flow architecture is applied when input data takes the form of
output after passing through various phases of transformations.
These transformations can be through various computations done on
data.
In Object oriented architecture, the software design moves around
the classes and objects of the system. The class encapsulates the
data and methods.
Layered approach defines the number of layers and each layer
performs tasks. The outermost layer handles the functionality of user
interface and the innermost layer handles interaction with the
hardware.

ObjectiveofArchitecturalDesign
4
5
• To develop a model of software architecture, this gives overall
organization of program module in the software product.
• To control relationship between modules. One module may
control another module or may be controlled by another
module.
• The organization of module can be represented through a
tree like structure.
•In addition, HLD possess some attributes such as height,
depth, width and module fan-in, fan-out.

Attributes
4
6
The height or depth of the design hierarchy is the number of
modules along the longest path from the top-level module
down to the lowest module in the hierarchy.
The width of the design hierarchy is the largest number of
modules existing at a given level of the hierarchy.
The no. of components which controls a said component is
called fan-in i.e, the no of incoming edges to a component.
The no. of components that are controlled by a module is
called fan-out i.e, the no of outgoing edges.

STRATEGY OF DESIGN
47
A good system design strategy is to organize the program modules in
such a way that are easy to develop and latter to, change.
Structured design techniques help developers to deal with the size
and complexity of programs. Analysts create instructions for the
developers about how code should be written and how pieces of
code should fit together to form a program. It is important for two
reasons:
➢ First, even pre-existing code, if any, needs to be understood,
organized and pieced together.
➢ Second, it is still common for the project team to have to write
some code and produce original programs that support the
application logic of the system.

Bottom-Up Design
Fig : Bottom-up tree structure
These modules are collected together in the form of a
“library”.
48

Top-Down Design
• A top down design approach starts by
identifying the major modules of the system,
decomposing them into their lower level
modules and iterating until the desired level of
detail is achieved. This is stepwise refinement;
starting from an abstract design, in each step
the design is refined to a more concrete level,
until we reach a level where no more
refinement is needed and the design can be
implemented directly. 49

Hybrid Design
For top-down approach to be effective, some bottom-up approach
is essential for the following reasons:
➢ To permit common sub modules.
➢ Near the bottom of the hierarchy, where the intuition is simpler,
and the need for bottom-up testing is greater, because there are
more number of modules at low levels than high levels.
➢ In the use of pre-written library modules, in particular, reuse of
modules.
50

Structure Chart
It partition a system into block boxes. A black box means
that functionality is known to the user without the knowledge of
internal design.
Fig : Hierarchical format of a structure chart 51

Fig. 17 : Structure chart notations
52

Fig : Update file
A structure chart for “update file” is given in fig.
53

Fig: Transaction-centered structure
A transaction centered structure describes a system that processes a
number of different types of transactions. It is illustrated in Fig.
54

In the above figure the MAIN module controls the system operation its
functions is to:
55
➢ invoke the INPUT module to read a transaction;
➢ determine the kind of transaction and select one of a number
of transaction modules to process that transaction, and
➢ output the results of the processing by calling OUTPUT
module.

Pseudocode
• Pseudocode notation can be used in both the
preliminary and detailed design phases.
• Using pseudocode, the designer describes
system characteristics using short, concise,
English language phrases that are structured by
key words such as If-Then-Else, While-Do, and
End.
56

Unit3 Software engineering UPTU

More Related Content

What's hot

Similar to Unit3 Software engineering UPTU

More from Mohammad Faizan

Recently uploaded

Unit3 Software engineering UPTU