Software Engineering

MODULE:V
SOFTWARE DESIGN
01/13/24 MODULE-V SOFTWARE DESIGN 1

Software Design
 Design phase transforms SRS document into

the design document.
 The design document produced at the end of

the design phase should be implementable
using a programming language in the coding
phase.
Software Design

Items Designed During Design Phase
 Different modules
 Control relationship (call/invocation
relationship) among modules
 Interface among modules(data items
exchanged among different modules)
 Data structure of individual modules
 Algorithm required to implement individual
module.
Software Design

Software Design
 A module consists of:
--several functions
--associated data structures.
A High Level Design identify…
 Modules
 control relationships among modules
 interfaces among modules.

Software Design
 Several notations are available to represent

high-level design:
 Usually a tree-like diagram called structure
chart is used.

Software Design
 Detailed design
For each module, design:

--data structure
--algorithms

Attributes of a good software design
 Correctness
 Should correctly implement all the functionalities of
the system.
 Understandability
 Easily understandable
 Efficiency
-- A good design solution should adequately address

resource ,time and cost optimization issues.
 Maintainability
 Easily amenable to change

Goals of a good design
 Three characteristics that serves as a guide for the
evaluation of a good design:
 Design must
o Implement all the explicit requirements
o Accommodate all the implicit requirements
 Design must be
o Readable
o Understandable guide for those who generate the code, who
test and who support the software
 Design should provide a complete picture of the software,
addressing data, functions, and behavioral domain from
an implementation perspective.

Understandability
 Unless a design is easy to understand,
tremendous effort needed to maintain it.
 We already know that about 60% effort
is spent in maintenance.
 If the software is not easy to understand:
maintenance effort would increase many

times.

Understandability
 Use consistent and meaningful names
for various design components.
 Design solution should consist of: a cleanly
decomposed set of modules (modularity).
 Different modules should be neatly arranged
in a hierarchy: in a neat tree-like diagram.

Modularity
 Modularity is a fundamental attribute of any
good design.
 Decomposition of a problem cleanly into
modules facilitates the design by taking
advantage of the divide and conquer principle.
-Modules are almost independent of each
other.

Example of Cleanly and Non cleanly
Decomposed Modules

Modularity…
Neat arrangement of modules in a hierarchy
means:
 low fan-out
 abstraction

Modularity…
 If modules are independent:
- modules can be understood separately,
 To understand why this is so,
 remember that it is very difficult to break a
bunch of sticks but very easy to break the
sticks individually.

Modularity…
 Reduces complexity
 Facilitate changes
 Results in easier implementations by
encouraging parallel development

of different parts of a system.

Modularity…

Functional Independence
Benifits:
 Better understandability and good design:
 Complexity of design is reduced,
 Different modules easily understood in
isolation:
 Since different modules are independent

Functional Independence...
 Functional independence reduces error
propagation.
 degree of interaction between modules is
low.
 an error existing in one module does not
directly affect other modules.

 Reuse of modules is possible.

Modularity…
 In technical terms, modules should display:
--high cohesion
--low coupling.

Cohesion and Coupling
 Cohesion is a measure of:
 functional strength of a module.
 A cohesive module performs a single task or
function.
 Coupling between two modules:
 a measure of the degree of interdependence
or interaction between the two modules .

Classification of Cohesiveness
Classification is often subjective: yet gives us
some idea about cohesiveness of a module.
 By examining the type of cohesion exhibited
by a module:
we can roughly tell whether it displays high
cohesion or low cohesion

Classification of Cohesiveness

Coincidental Cohesion
 The module performs a set of tasks which
relate to each other very loosely .
 Data elements or instructions within module
have no relation to each other.

 the module contains a random collection of
functions.
 functions have been put in the module out of pure
coincidence without any thought or design.

 Example:(Coincidental Cohesion)
FILE PROCESSING
OPEN EMPLOYEE UPDATE FILE
READ EMPLOYEE REC
PRINT_PAGE_HEADING
OPEN MASTER FILE(EMPLOYEE)
SET PAGE_COUNT TO 1
SET ERR_FLAG TO FALSE
END

Logical cohesion
 All elements of the module perform similar
operations:
 e.g. error handling, data input, data output,
etc.
 Components are logically related to each

other.
 Modules which contains routines to support
different types of input.

 Example(Logical Cohesion)
READ_ALL_FILES
CASE OF FILE_CODE
1:READ CUST_TRAN REC
IF NOT EOF
INCREMENT_TRAN_COUNT
ENDIF
2:READ CUST_MASTER REC
IF NOT EOF
INCREMENT CUST_MASTER_COUNT
ENDIF
3:READ PRODUCT_MASTER REC
IF NOT EOF
INCREMENT PRODUCT_MASTER_COUNT
ENDIF
ENDCASE
END

Temporal cohesion
 The module contains tasks that are related by the
fact that all the tasks must be executed in the same
time span.
 Example:
 Cancel all tasks
 Cancel all windows
 Cancel all data files
 Shuts down the machines
 These tasks which are not logically or functionally related
to each other, but takes place when a failure occurs.

 Example(Temporal cohesion)
INITIALIZATION
OPEN TRAN_FILE
ISSUE PROMPT ‘ENTER DATE’
READ TODAYS_DATE
SET TRAN_COUNT TO ZERO
SET REPORT_TOTAL TO ZERO
OPEN REPORT_FILE
END

Procedural cohesion
 The set of functions of the module:
all part of a procedure (algorithm)
 certain sequence of steps have to be carried
out in a certain order for achieving an
objective.

 Example(Procedural cohesion)
READ STUD_REC AND TOTAL_STUD_AGES
NO_OF_REC=0
TOTAL_AGE=0
READ STUD_REC
DO WHILE MORE_REC_EXIST
ADD AGE TO TOTAL_AGE
ADD 1 TO NO_OF_REC
READ STUD_REC
ENDDO
END

Communicational cohesion
All functions of the module reference or update
the same data structure.
 Different outputs are generated on same input
 i.e. Communicational cohesion occurs when two
operations share common data, but are otherwise
unrelated.

 Example(Communicational cohesion)
PROCEDURE ERR_REPORT
VALIDATE PRODUCT_REC
IF TRAN_TYPE NOT=0 THEN
WRITE_ERR_REPORT
ENDIF
IF CUST_NO NOT NUMERIC THEN
WRITE ERR REPORT
ENDIF
IF PRODUCT_NO=BLANKS
WRITE ERR REPORT
ENDIF
END

Sequential cohesion
 Elements of a module form different parts of a
sequence, i.e., the output from one element of the
sequence is input to the next.
 Example-1
Example-2

 Example(Sequential cohesion)
PROCESS PURCHASES
TOTAL_PURCHASE=0
READ NO_OF_PURCHASES
DO LOOP_INDEX=1 TO NO_OF_PURCHASES
GET PURCHASES
ADD PURCHASES TO TOTAL_PURCHASES
ENDDO
SALES_TAX=TOTAL_PURCHASES*SALE_TAX_PERCENT
AMT_DUE=TOTAL_PURCHASES+ SALES_TAX
END

Functional cohesion
 Different elements of a module cooperate to

achieve a single function,
 A simple example of functional cohesion is a math function.

Pick any of them, sin(), cos (), or atan ()

 Example(Functional cohesion)
CALCULATE_SALES_TAX
IF PRODUCT IS SALES_TAX EXEMPT THEN
SALES_TAX=0
ELSE
IF PRODUCT_PRICE<$50 THEN
SALES_TAX=PRODUCT_PRICE*0.25
ENDIF
ENDIF

Coupling
 Coupling indicates:
 how closely two modules interact or
how interdependent they are.
 The degree of coupling between two
modules depends on their interface

complexity.

Classes of coupling

Data coupling
 Two modules are data coupled, if they

communicate via an elementary data item,
---e.g. an integer, a float, a character, etc.
 The data item should be problem related,

but not used for control purpose.

Stamp coupling
 Two modules are stamp coupled, if they
communicate via a composite data item.
 such as a record in PASCAL
 or a structure in C.

 Control coupling
 Data from one module is used to direct the order of
instruction execution in another.
 Example of control coupling:
 a flag set in one module and tested in another module.
 Common Coupling
 Two modules are common coupled, if they share some
global data.
 Content coupling
 Content coupling exists between two modules
share code,
 e. g, branching from one module into another
module.
 When customer not found, component calls the
AddCustomer( ) method that is responsible for
maintaining customer data.

Characteristics of Module
Structure
 Depth :number of levels of control
 Width: overall span of control.
 Fan-out: a measure of the number of modules
directly controlled by given module.
 Fan-in: indicates how many modules directly
invoke a given module.
 High fan-in represents code reuse and is in
general encouraged.
Fan-in & Fan-out

 A design having modules:
with high fan-out numbers is not a good
design:
 a module having high fan-out lacks cohesion.

Visibility and Layering
 A module A is said to be visible by another

module B, if A directly or indirectly calls B.
 The layering principle requires modules at a
layer can call only the modules immediately
below it.

Abstraction
 Lower-level modules:
do input/output and other low-level functions.
 Upper-level modules:
do more managerial functions.
 The principle of abstraction requires:
lower-level modules do not invoke functions
of higher level modules.
 Also known as layered design.
Design Concepts & Principles

 DFD serves two purposes:
 Provides an indication of how data are transformed
as they move through the system
 To depict the functions (& sub-functions) that
transform the data flow.
 A description of each function presented in the
DFD is contained in a processes specification
(PSPEC).

 STD indicates how system behaves as a
consequence of external events. It represents
various modes of behavior (state) of the
system & the manner in which transitions are
made from state to state.
 Additional information about the control
aspects of the software is contained in the
control specifications (CSPEC)

 The attributes of each data objects noted in the ER
diagram can be described using data object
description.
 Data Design
 Transforms the information domain model created
during analysis into the data structure that will be
required to implement the software.
 The data objects and the relationships defined in the
ER diagram and the detailed data contents depicted in
data dictionary provides the basis for the data design
activity.
 Part of the design occurs in conjunction with the design
of s/w architecture and more detailed data design
occurs as each s/w component is designed.

 Architectural Design
 Defines the relationships between major
structural elements.
 Can be derived from the system specification, the
analysis model and the interactions of
subsystems.
 Interface Design
 Describes how the software communicates
within itself, with the system that interoperate
with it and with humans who use it.
 Component Level Design
 Transforms structural elements of the software
architecture into procedural description of software
component.
 Information obtained from PSPEC, CSPEC, &
STD serves as basis for component design.
 Software design serves as the foundation for
all the software engineering and software
support steps that follow.

Design Concepts…
 A set of fundamental software design concepts has evolved
over past four decades. Each provides the software designer
with a foundation from which more sophisticated design
methods can be applied.
1. ABSTRACTION
2. REFINEMENT
3. MODULARITY
4. SOFTWARE ARCHITECTURE
5. CONTROL HIERARCHY
6. STRUCTURAL PARTITIONING
7. DATA STRUCTURE
8. SOFTWARE PROCEDURE
9. INFORMATION HIDING

Abstraction

 Procedural Abstraction
 It is a named sequence of instructions that has a
specific and limited function.
 E.g. OPEN A DOOR is a long sequence of
procedural steps
1. walk to the door
2. Reach out and grasp the knob
3. Turn knob & pull door
4. Step away from moving door etc.

 Data Abstraction
 Is a named collection of data describes a data
object
 E.g. DOOR; The attributes are
1. Door type
2. Swing direction
3. Opening mechanism
4. Weight
5. Dimension etc.

 Control Abstraction
It implies a program control mechanism without
specifying internal details
 e.g.Thread management in a multithreading
environment

Refinement
-It is the top down design strategy.

-In each step(of refinement), one or several
instructions of the given program are
decomposed into more detail instructions.
-Refinement is actually a process of elaboration.

Architecture
 Architecture is the hierarchical structure of a

program components (modules), the manner in
which these components interact and the
structure of data that are used by the
component.
-- Client Server Architecture
-- Main program/Subprogram Architecture
-- Layered Architecture(core layer, utility layer,
application layer, user interface layer)

Control Hierarchy
(program structure)
 It represents the organization of the program

components (modules) and implies a hierarchy
of control.
 It does not represents the procedural aspect of
software.

Control Hierarchy CONT…

Structural partitioning
 For a hierarchical style of architecture the program module
can be partitioned into:
 Horizontal
 Vertical
 Horizontal partitioning defines separate branches of the modular
hierarchy for each major program function.
Simplest way is to partition a system into: input, data transformation

(processing), and output.
Advantages of horizontal partition:

- easy to test, maintain, and extend
- fewer side effects in change propagation or error propagation
Disadvantage: more data to be passed across module interfaces -
complicate the overall control of program flow

 Vertical partitioning suggests the control and
work should be distributed top-down in
program structure.
Advantages:
- good at dealing with changes:
- easy to maintain the changes
- reduce the change impact and and
propagation

Data Structure
 Represents the logical relationship among individual
elements of data.
 It indicates the
 Organization of data
 Method of access
 Degree of associativeness
 Process alternatives for information

Software Procedure
 Program structure define control hierarchy without
regard to the sequence of processing and decision.
 Software focuses on the processing details of each
module individually.
 Procedure must provide a precise specification of
processing including
 Sequence of events
 Exact decision points
 Repetitive operations, data organization and structure

Information Hiding
 Modules be characterized by design decision
that each module hides from all others .
 i.e. information (data & procedure) contained
within a module is inaccessible to other
modules that have no need for such
information.

Structured Analysis
 Transforms a textual problem description into
a graphic model.
– Done using Data Flow Diagrams (DFDs).
 – DFDs graphically represent the results of
structured analysis.

 DFD is an elegant modeling technique:
 – Useful not only to represent the results of
structured analysis.
 – Applicable to other areas also:
e.g. for showing the flow of documents or
items in an organization,
 DFD technique is very popular:
– It is powerful and yet simple to understand
and use.
 DFD is a hierarchical graphical model:
 – Shows the different functions (or processes)
of the system and
 – Data interchange among the processes.

It is useful to consider each function as a
processing station:
 –Each function consumes some input data.
 –Produces some output data.

 Data Flow Model of a Car Assembly Unit

 A DFD model:
– Uses limited types of symbols.
– Simple set of rules
– Easy to understand:
It is a hierarchical model.

 Primitive Symbols Used for Constructing
DFDs:

External Entity Symbol
 Represented by a rectangle
 External entities are real physical entities:
– input data to the system or
– consume data produced by the system.
– Sometimes external entities are called
terminator, source, or sink.

Function Symbol
 A function such as “search-book” is
represented using a circle:
 – This symbol is called a process or bubble or
transform.
 – Bubbles are annotated with corresponding
function names.
 – Functions represent some activity:
 Function names should be verbs.

Data Flow Symbol
 A directed arc or line.

 – Represents data flow in the direction of the
arrow.
 – Data flow symbols are annotated with names
of data they carry.

Data Store Symbol
 Represents a logical file:

 – A logical file can be:
- a data structure
- a physical file on disk.
 – Each data store is connected to a process:
by means of a data flow symbol.

 Direction of data flow arrow:
– Shows whether data is being read from or
written into it.
 An arrow into or out of a data store
– Implicitly represents the entire data of the
data store
 – Arrows connecting to a data store need not
be annotated with any data name.

Output Symbol
 Output produced by the system

Synchronous Operation
 If two bubbles are directly connected by a data

flow arrow: they are synchronous.

Asynchronous Operation
 If two bubbles are connected via a data store:

they are not synchronous.

 Initially represent the software at the most
abstract level:
– Called the context diagram.
 – The entire system is represented as
a single bubble,
 – This bubble is labeled according to the main
function of the system.

Tic-tac-toe: Context Diagram

 A context diagram shows:
–Data input to the system,

–Output data generated by the system,
–External entities

 Context diagram captures:
– Various entities external to the system
and interacting with it.
– Data flow occurring between the system and
the external entities.
 The context diagram is also called as the level
0 DFD.

 Context Diagram Establishes the context of the
system, i.e.
–Represents:
Data sources
Data sinks.

Level 1 DFD
Examine the SRS document:
 – Represent each high-level function as a
bubble.
 – Represent data input to every high level
function.
 – Represent data output from every
high-level function.

Higher Level DFDs
 Each high-level function is separately
decomposed into sub functions:
– Identify the sub-functions of the function
– Identify the data input to each sub-function
– Identify the data output from each sub-
function
 These are represented as DFDs.

Decomposition of a bubble:
– Also called factoring or exploding.
 Each bubble is decomposed to
– Between 3 to 7 bubbles.

Example 1: RMS Calculating
Software
 Consider a software called RMS calculating
software:
 – Reads three integers in the range of - 1000
and +1000
 – Finds out the root mean square (rms) of
the three input numbers
 – Displays the result.

 Accept input numbers from the user:
– Validate the numbers,
– Calculate the root mean square of the input
numbers
– Display the result.

Level 1 DFD for RMS Software



 Decomposition is never carried on up to basic
instruction level:
– A bubble is not decomposed any further:
 If it can be represented by a simple set of
instructions

Balancing a DFD
 Data flowing into or out of a bubble:
 – Must match the data flows at the next level
of DFD. In the level 1 of the DFD,
 – Data item c flows into the bubble P3 and the
data item d and e flow out.
 ● In the next level, bubble P3 is decomposed.
 – The decomposition is balanced as data item
c flows into the level 2 diagram and d and e
flow out.
 Number the bubbles in a DFD:
 – Numbers help in uniquely identifying any
bubble from its bubble number.
 The bubble at context level: Assigned number 0.
 Bubbles at level 1: – Numbered 0.1, 0.2, etc.
 When a bubble numbered x is decomposed,
 – Its children bubble are numbered x.1, x.2, x.3,
etc.

Data Dictionary
 A DFD is always accompanied by a data dictionary.
 A data dictionary lists all data items appearing in a
DFD:
 Definition of all composite data items in terms of
their component data items.
 All data names along with the purpose of the data
items.
 For example, a data dictionary entry may be:
 grossPay = regularPay+overtimePay

Importance of Data Dictionary
 Provides all engineers in a project with
standard terminology for all data:
 – A consistent vocabulary for data is very
important
 – Different engineers tend to use different
terms to refer to the same data, Causes
unnecessary confusion.

Importance of Data Dictionary
 Data dictionary provides the definition of
different data: In terms of their component
elements.
 For large systems, The data dictionary grows
rapidly in size and complexity.
 – Typical projects can have thousands of data
dictionary entries.
– It is extremely difficult to maintain such a
dictionary manually.
 CASE (Computer Aided Software
Engineering) tools come handy:
– CASE tools capture the data items appearing
in a DFD automatically to generate the data
dictionary

 Composite data are defined in terms of
primitive data items using following operators:
 +: denotes composition of data items ,
e.g. – a+b represents data a and b.

 [,,,]: represents selection,
 – i.e. any one of the data items listed inside the
square bracket can occur.

 – For example, [a,b] represents either a occurs
or b occurs.

 ( ): contents inside the bracket represent
optional data
– which may or may not appear.
e.g. – a+(b) represents either a or a+b occurs.
 {}: represents iterative data definition,
– e.g. {name}5 represents five name data.

 {name}* represents
– zero or more instances of name data.
 = represents equivalence,
– e.g. a=b+c means that a represents b and c.

 * *: Anything appearing within * * is
considered as comment.

Data Dictionary for RMS Software
numbers=valid-numbers=a+b+c
a:integer * input number *
b:integer * input number *
c:integer * input number *
asq:integer
bsq:integer
csq:integer
squared-sum: integer
Result=[RMS,error]
RMS: integer * root mean square value*
error: string * error message*

 During structured design,
 – The DFD representation is transformed to a
structure chart representation.
 ● DFDs are very popular:
 – Because it is a very simple technique.

 A DFD model:
– Difficult to implement using a programming
language:
 Structure chart representation can be easily
implemented using a programming language.

Trading-House Automation
System (TAS)
 A large trading house wants us to develop a
software:
 – To automate book keeping activities
associated with its business.

 It has many regular customers:
– Who place orders for various kinds of

commodities.

 The trading house maintains names and
addresses of its regular customers.
 Each customer is assigned a unique
customer identification number (CIN).

 As per current practice when a customer
places order:
 – The accounts department first checks the
credit-worthiness of the customer

 The credit worthiness of a customer is
determined:
 – By analyzing the history of his payments
to the bills sent to him in the past.

 If a customer is not credit-worthy:
 – His orders are not processed any further
– An appropriate order rejection message is

generated for the customer.

 If a customer is credit-worthy:
 – Items he/she has ordered are checked
against the list of items the trading house

deals with.
 The items that the trading house does not
deal with:
– Are not processed any further
– An appropriate message for the customer for
these items is generated.

 The items in a customer's order that the
trading house deals with:
 – Are checked for availability in inventory.
 If the items are available in the inventory in
desired quantities:
 – A bill with the forwarding address of the
customer is printed.
 – A material issue slip is printed.

 The customer can produce the material issue
slip at the storehouse:
 – Take delivery of the items.
 – Inventory data adjusted to reflect the sale to
the customer.

 If an ordered item is not available in the
inventory in sufficient quantity:
 – To be able to fulfill pending orders store
details in a "pending-order" file :
 out-of-stock items along with quantity
ordered. customer identification number

 The purchase department: would periodically
issue commands to generate indents.
 When generate indents command is issued:
 – The system should examine the
"pendingorder“ file
– Determine the orders that are pending
– Total quantity required for each of the items.

 TAS should find out the addresses of the
vendors who supply the required items:
– Examine the file containing vendor
details (their address, items they supply etc.)
– Print out indents to those vendors

 TAS should also answers managerial queries:
 – Statistics of different items sold over any
given period of time
 – Corresponding quantity sold and the price
realized.

Context Diagram for TAS

Level 1 DFD for TAS

Data Dictionary for TAS
 response: [bill + material-issue-slip, reject-
message]
 query: period /* query from manager
regarding sales statistics*/
 period: [date+date,month,year,day]
 date: year + month + day
 year: integer
 month: integer
 day: integer
 order: customer-id + {items + quantity}*
 accepted-order: order /* ordered items
available in inventory */
 reject-message: order + message /* rejection
message */
 pending-orders: customer-id +
{items+quantity}*
 customer-address: name+house#+street#+city+pin

 item-name: string
 house#: string
 street#: string
 city: string
 pin: integer
 customer-id: integer
 bill: {item + quantity + price}* + total-amount +
customer-address
 material-issue-slip: message + item + quantity + customer-
address
 message: string
 statistics: {item + quantity + price }*
 sales-statistics: {statistics}*
 quantity: integer
 Guidelines For Constructing DFDs
 Context diagram should represent
the system as a single bubble:

 – Many beginners commit the mistake of
drawing more than one bubble in the context

diagram.

 All external entities should be represented in
the context diagram:
 – External entities should not appear at any
other level of DFD.

 Only 3 to 7 bubbles per diagram should be
allowed: Each bubble should be decomposed to

between 3 and 7 bubbles.

 A common mistake committed by many
beginners:
 – Attempting to represent control
information in a DFD.
 – e.g. trying to represent the order in which
different functions are executed.

 A DFD does not represent control
information:
 – The conditions under which different
functions are invoked are not represented.
 – For example, a function might invoke one
function or another depending on some
condition.
 – Many beginners try to represent this aspect
by drawing an arrow between the
corresponding bubbles.

Shortcomings of the DFD Model
DFD models suffer from several shortcomings:
● DFDs leave ample scope to be imprecise.
– In a DFD model, we infer about the function
performed by a bubble from its label.
– A label may not capture all the functionality
of a bubble

For example, a bubble named find-bookposition
has only intuitive meaning:
– Does not specify several things:
● What happens when some input information
is missing or is incorrect.
● Does not convey anything regarding what
happens when book is not found
● or what happens if there are books by different
authors with the same book title.

A DFD does not specify synchronization
aspects:
– For instance, the DFD in TAS example does
not specify:
● Whether process-order may wait until the
accept-order produces data
● Whether accept-order and handle-order
may proceed simultaneously with some
buffering mechanism between them

The way decomposition is carried out to arrive at
the successive levels of a DFD is subjective.
● The ultimate level to which decomposition is
carried out is subjective:
– Depends on the choice and judgement of the
analyst.
● Even for the same problem,
– Several alternative DFD representations are
possible:
– Many times it is not possible to say which
DFD representation is superior or preferable.
DFD technique does not provide:
– Any clear guidance as to how exactly one
should go about decomposing a function:
– One has to use subjective judgement to carry
out decomposition.
● Structured analysis techniques do not specify
when to stop a decomposition process:
– To what length decomposition needs to be
carried out.

Structured Design
 Aim is to transform the result of structured
analysis ( i.e. DFD )into structured chart.
 A structured chart represents the software

architecture, i.e. the various modules making
up the system, the module dependency and the
parameters that are passed among the different
modules
The building blocks of structured chart:

 One and only one module at the top
• At most one control relationship between any two
modules. (modules arranged in Layers / levels)
 The principle of abstraction doses not allow
the lower level modules to be aware of the
existence of the higher level modules

Transformation of a DFD into a
Structured Chart:
1) Transform Analysis
2) Transaction Analysis
 Start with 1 Level DFD and then proceed to
lower level DFDs
 At each level of transformation, determine
whether it is transform or transaction
analysis applicable??

Transform Analysis
 If all data input to the diagram are processed
in a similar ways (i.e. if all input data are
incident on the same bubble in the DFD), then
transform analysis is applicable.
 It is applicable to very small problems or at
the lower level DFD.

Transaction Analysis
 Each different way in which data is processed
corresponds to a separate transaction.
 Each transaction corresponds to a
functionality.
 Useful for transaction processing system
 For each transaction, we trace the input data to
the output data.

 The transaction is identified by studying the
discrete event types that drive the system
 The three transaction types here are: Check
Availability (an enquiry), Reserve Ticket
(booking) and Cancel Ticket (cancellation).

Transform Analysis
 Transform analysis is strategy of converting

each piece of DFD (may be from level 2 or
level 3, etc.) for all the identified transaction
centers.
 In case, the given system has only one
transaction (like a payroll system), then we can
start transformation from level 1 DFD itself.

 Transform analysis is composed of the
following five steps:
1. Draw a DFD of a transaction type (usually done
during analysis phase)
2. Find the central functions of the DFD
3. Convert the DFD into a first-cut structure chart
4. Refine the structure chart
5. Verify that the final structure chart meets the
requirements of the original DFD
Partitioning DFD
 Transformation-Centered Application:
 Data flow in a sequence, i.e. in a straight line
manner.
 Focus is on file handling and manipulation of data.
 Example: Sequential processing of a purchase

order

Transformation Analysis…

Transaction Analysis…


Software Engineering

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engineering

Uploaded by

Copyright:

Available Formats

MODULE:V

01/13/24 MODULE-V SOFTWARE DESIGN 1

 Design phase transforms SRS document into

 The design document produced at the end of

01/13/24 MODULE-V SOFTWARE DESIGN 3

01/13/24 MODULE-V SOFTWARE DESIGN 5

 control relationships among modules

 interfaces among modules.

01/13/24 MODULE-V SOFTWARE DESIGN 6

 Several notations are available to represent

01/13/24 MODULE-V SOFTWARE DESIGN 7

For each module, design:

01/13/24 MODULE-V SOFTWARE DESIGN 8

-- A good design solution should adequately address

01/13/24 MODULE-V SOFTWARE DESIGN 9

01/13/24 MODULE-V SOFTWARE DESIGN 10

maintenance effort would increase many

01/13/24 MODULE-V SOFTWARE DESIGN 11

01/13/24 MODULE-V SOFTWARE DESIGN 12

01/13/24 MODULE-V SOFTWARE DESIGN 13

01/13/24 MODULE-V SOFTWARE DESIGN 14

01/13/24 MODULE-V SOFTWARE DESIGN 15

01/13/24 MODULE-V SOFTWARE DESIGN 16

 Results in easier implementations by

encouraging parallel development

01/13/24 MODULE-V SOFTWARE DESIGN 17

01/13/24 MODULE-V SOFTWARE DESIGN 18

 Complexity of design is reduced,

 Different modules easily understood in

01/13/24 MODULE-V SOFTWARE DESIGN 19

directly affect other modules.

01/13/24 MODULE-V SOFTWARE DESIGN 20

01/13/24 MODULE-V SOFTWARE DESIGN 21

01/13/24 MODULE-V SOFTWARE DESIGN 22

01/13/24 MODULE-V SOFTWARE DESIGN 23

01/13/24 MODULE-V SOFTWARE DESIGN 24

have no relation to each other.

01/13/24 MODULE-V SOFTWARE DESIGN 25

01/13/24 MODULE-V SOFTWARE DESIGN 26

 Components are logically related to each

different types of input.

01/13/24 MODULE-V SOFTWARE DESIGN 28

 Cancel all windows

 Cancel all data files

 Shuts down the machines

 These tasks which are not logically or functionally related

to each other, but takes place when a failure occurs.

01/13/24 MODULE-V SOFTWARE DESIGN 30

01/13/24 MODULE-V SOFTWARE DESIGN 31

01/13/24 MODULE-V SOFTWARE DESIGN 32

01/13/24 MODULE-V SOFTWARE DESIGN 33

01/13/24 MODULE-V SOFTWARE DESIGN 34

01/13/24 MODULE-V SOFTWARE DESIGN 35

01/13/24 MODULE-V SOFTWARE DESIGN 36

 Different elements of a module cooperate to

 A simple example of functional cohesion is a math function.

01/13/24 MODULE-V SOFTWARE DESIGN 37

01/13/24 MODULE-V SOFTWARE DESIGN 38

modules depends on their interface

01/13/24 MODULE-V SOFTWARE DESIGN 39

01/13/24 MODULE-V SOFTWARE DESIGN 40

 Two modules are data coupled, if they