Documente Academic
Documente Profesional
Documente Cultură
Design
Design Phase
SRS SDD
d1 d2
d3 d1 d4
High-level design
F P
SF SF SF SP SP
EF EF EP EP EP
Business Functions
M a te r ia l M a n a g e m e n t
In d e n t P u rc h a s e S to re s P a y m e n ts ....
E n q u ir y
Q u o ta tio n
O rd e r
F o llo w u p
...
System Processes
MMS
In d e n t In d e n t
O rd e r O rd e r
R e c e ip t
Is s u e
...
Fundamental Concepts
Stepwise Refinement
Abstraction
Software Architecture
Program Structure
Data Structure
Modularity
Software Procedure
Information Hiding
Stepwise Refinement
Stepwise refinement is a top-down approach
where a program is refined as a hierarchy of
increasing levels of detail. This process may
be begun during requirements analysis and
conclude when the detail of the design is
sufficient for conversion into code.
Processing procedures and data structures are
likely to be refined in parallel
Abstraction
Abstraction is a means of describing a
program function, at an appropriate level of
detail.
Highest level of abstraction - requirements
analysis.
Lowest level of abstraction - programming.
Abstraction
Procedural Abstraction
Data Abstraction
Control Abstraction
Software Architecture
While refinement is about the level of detail,
architecture is about structure. The architecture of
the procedural and data elements of a design
represents a software solution for the real-world
problem defined by the requirements analysis. It is
unlikely that there will be one obvious candidate
architecture.
Software Architecture
Properties: Structural
Extra-functional
Families of related systems
Models:
1. Structural
2. Framework
3. Dynamic
4. Process
5. Functional
Program Structure
The program structure represents the hierarchy of
control. Program structure is usually expressed as a
simple hierarchy showing super-ordinate and
subordinate relationships of modules.
It represents two different characteristics of SA:
Visibility & Connectivity
Control Hierarchy
Width
M
a b c
Depth
d e f g h
i j k
Data Structure
Data structure dictates the organization,
access methods, degree of associativity, and
processing alternatives for problem-related
information. Classic data structures include
scalar, sequential, linked-list, n-dimensional,
and hierarchical. Data structure, along with
program structure, makes up the software
architecture.
Modularity
Modularity derives from the architecture.
Modularity is a logical partitioning of the
software design that allows complex software to be
manageable for purposes of implementation and
maintenance.
The logic of partitioning is based on related
functions, implementation considerations, data
links, or other criteria.
Modularity does imply interface overhead related
to information exchange between modules and
execution of modules.
Modularity
C(p1) > C(p2) E(p1) > E(p2)
C(p1+p2) > C(p1)+C(p2) E(p1+p2) >
E(p1)+E(p2)
• Modular Decomposability
• Modular Composability
• Modular understandability
• Modular continuity
• Modular protection
Example of Cleanly and Non-cleanly
Decomposed Modules
Modularity
In technical terms, modules should
display:
– high cohesion
– low coupling.
We will shortly discuss:
– cohesion and coupling.
Modularity
Neat arrangement of
modules in a hierarchy
means:
– low fan-out
– abstraction
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.
Cohesion and Coupling
functional
sequential
communicational Degree of
cohesion
procedural
temporal
logical
coincidental
Coincidental cohesion
search
display
Functional cohesion
data
stamp Degree of
coupling
control
common
content
Data coupling
Two modules are data coupled,
– if they communicate via a
parameter:
• an elementary data item,
• e.g an integer, a float, a character, etc.
– The data item should be problem
related:
• 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
– order of instruction execution in
another.
Example of control coupling:
– a flag set in one module and
tested in another module.
Common Coupling
Essentially means:
– low fan-out
– abstraction
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.
Characteristics of Module
Structure
Fan-in:
– indicates how many modules
directly invoke a given
module.
– High fan-in represents code
reuse and is in general
encouraged.
Module Structure
Fan out=2
Fan out=1
Fan in=1
Fan in=2
Fan out=0
Software Procedure
Software procedure provides a precise specification
of the software processing, including sequence of
events, exact decision points, repetitive operations,
and data organization. Processing defined for each
module must include references to all subordinate
modules identified by the program structure.
Information Hiding
Information hiding is an adjunct of
modularity. It permits modules to be
designed and coded without concern for the
internals of other modules. Only the access
protocols of a module need to be shared with
the implementers of other modules.
Information hiding simplifies testing and
modification by localizing these activities to
individual modules.
Structural Partitioning
Horizontal partitioning:
Separate branches of modular hierarchy of
each major
program function
Vertical partitioning:
Factoring, suggests control or decision making
and work should be distributed top-down
Structured Design
DFD Software Architecture
is the development of a blueprint of a
computer system solution to a business
application.
seeks to conquer the complexity of large
systems through partitioning and
hierarchical structuring.
uses graphical tools to render systems
more understandable.
Structured Design
offers a set of strategies for developing a
design solution from a well-defined
statement of a problem.
offers a set of objective and empirically
justified criteria for evaluating the quality
of a given design solution with respect to
the problem on hand.
Structured Design
Type of information flow established
Flow boundaries are indicated
DFD mapped to program structure
Control hierarchy defined
Resultant structure refined
Architectural description is refined
Information Flow
Transform Flow
External data internal form : Incoming
flow
Data led out : Outgoing flow
Transform center
Transaction Flow
Transaction triggers other data flow along
one of many paths
Hub of information flow from which many
action paths emanate – Transaction Centre
Structure Chart
The structure chart has three components:
Modules
connections between modules
communication between modules.
Structure Chart
Structure chart representation
– easily implementable using programming
languages.
Main focus of a structure chart:
– define the module structure of a software,
– interaction among different modules,
– procedural aspects (e.g, how a particular
functionality is achieved) are not
represented.
Basic building blocks of
structure chart
Rectangular box:
– A rectangular box represents a
module.
– annotated with the name of the
module it represents.
Processorder
Arrows
An arrow between two modules implies:
– during execution control is passed from one
module to the other in the direction of the
arrow.
root
root
order
Processorder
Library modules
Library modules represent
frequently called modules:
– a rectangle with double side edges.
– Simplifies drawing when a module is
called by several modules.
Quicksort
Selection
The diamond symbol represents:
– one module of several modules connected to the
diamond symbol is invoked depending on some
condition.
root
root
Validate
Getdata data
Bad Design
Shortcomings of Structure
Chart
By looking at a structure chart:
– we can not say whether a module
calls another module just once or
many times.
Also, by looking at a structure
chart:
– we can not tell the order in which the
different modules are invoked.
Flow Chart
We are all familiar with the flow chart
representations:
– Flow chart is a convenient technique to represent the flow
of control in a system.
A=B A=B
if(c == 100)
P=20 yes no
else p= 80
P=20 P=80
while(p>20)
print(student mark) dummy
yes no
Print
Flow Chart versus Structure
Chart
A structure chart differs from a flow
chart in three principal ways:
– It is difficult to identify modules of a
software from its flow chart
representation.
– Data interchange among the modules is
not represented in a flow chart.
– Sequential ordering of tasks inherent in a
flow chart is suppressed in a structure
chart.
Transformation of a DFD Model into
Structure Chart
Data Compute
items RMS
0
User result
Context Diagram
Example 1: RMS
Calculating Software
From a cursory analysis of the
problem description,
– easy to see that the system needs to
perform:
• accept the input numbers from the user,
• validate the numbers,
• calculate the root mean square of the input
numbers,
• display the result.
Example 1: RMS Calculating
Software
numbers
Read Validate
numbers numbers
0.1 0.2
Valid
Data numbers
items error
Compute
Display rms
0.4 0.3
result RMS
Example 1: RMS
Calculating Software
Validate
Getdata data
Example 2: Tic-Tac-Toe
Computer Game
As soon as either of the human player or the
computer wins,
– a message congratulating the winner should be
displayed.
If neither player manages to get three
consecutive marks along a straight line,
– and all the squares on the board are filled up,
– then the game is drawn.
The computer always tries to win a game.
Context Diagram for
Example 2
Tictactoe
display software
0
move
Human Player
Level 1 DFD
game
Display
move board result
Validate Check
move board winner
Play
move
Structure Chart
root
Transaction
center
trans 3
trans 1
trans 2
Handle
indent Salesstatistics
Indentrequest request
Indents
pendingorder
Structure Chart
root
order query
indent