5 Design

System Design

Design Phase SRS

Analysis Repository

SDD

DESIGN

Design Repository

Design Model

PSPEC DFD

Component Level Design Interface Design Architectural Design

ERD Data Design

STD & CSPEC

Data Dictionary

Items Designed During Design Phase  module structure,  control relationship among the modules – call relationship or invocation relationship

 interface among different modules, – data items exchanged among different

modules,

 data structures of individual modules,  algorithms for individual modules.

Definition The practice of taking a specification of externally observable behavior and adding details needed for actual computer system implementation, including human interaction, task management, and data management details. Coad and Yourdon (1991)

Definition ... a process of inventing and selecting programs that meet the objectives for a software system. Input includes an understanding of the following: 1. Requirements. 2. Environmental constraints. 3. Design criteria. Stevens (1991)

The output of the design effort is composed of the following: 1. An architecture design which shows how pieces are interrelated. 2. Data design is translated from information flow model. 3. Interface design: SW communicating within itself, with incorporated systems and with users. 4. Component design: Structural elements of SW architecture into procedural description of software components.

Broad Characteristics  A mechanism for translating the physical problem to its design representation.  A notation for representing functional components and their interfaces.  Heuristics for refinement and partitioning.  Guidelines for quality assessment.

Broad Characteristics (contd.)  Design activities are usually classified into two stages: – preliminary (or high-level) design – detailed design.

 Meaning and scope of the two stages: – vary considerably from one methodology to

another.

High-level design  Identify:

– modules – control relationships among modules – interfaces among modules. d2

d1

d3

d1

d4

High-level design  The outcome of high-level design: – program structure (or software architecture).

Detailed design  For each module, design: – data structure – algorithms  Outcome of detailed design: – module specification.

System architecture Business Functions

F SF SF SF EF EF

System Processes

P SP SP 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 E n q u ir y Q u o ta tio n O rd e r F o llo w u p ...

S to re s

P a y m e n ts

....

System Processes MMS D a ta E n try

Q u e ry

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 ...

R e p o rt

Task

M is c e lla n e o u s

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. 2. 3. 4. 5.

Structural Framework Dynamic Process 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 i

f

g

h 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  A module having high cohesion and low coupling: – functionally independent of other

modules: • A functionally independent module has minimal interaction with other modules.

Advantages of Functional Independence  Better understandability and good design:  Complexity of design is reduced,  Different modules easily understood in isolation: – modules are independent

Advantages of 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.

Advantages of Functional Independence  A functionally independent module: – can be easily taken out and reused in a

different program. • each module does some well-defined and precise function • the interfaces of a module with other modules is simple and minimal.

Functional Independence  Unfortunately, there are no ways: – to quantitatively measure the degree of cohesion and coupling: – classification of different kinds of

cohesion and coupling: • will give us some idea regarding the degree of cohesiveness of a module.

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 functional sequential communicational procedural temporal logical coincidental

Degree of  cohesion

Coincidental cohesion  The module performs a set of tasks: – which relate to each other very

loosely, if at all. • the module contains a random collection of functions. • functions have been put in the module out of pure coincidence without any thought or design.

Logical cohesion  All elements of the module perform similar operations: – e.g. error handling, data input, data

output, etc.

 An example of logical cohesion:

– a set of print functions to generate an

output report arranged into a single module.

Temporal cohesion  The module contains tasks that are related by the fact: – all the tasks must be executed in the same

time span.

 Example: – The set of functions responsible for

• initialization, • start-up, shut-down of some process, etc.

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, • e.g. the algorithm for decoding a message.

Communicational cohesion  All functions of the module: – reference or update the same data

structure,

 Example: – the set of functions defined on an

array or a stack.

Sequential cohesion  Elements of a module form different parts of a sequence,

– output from one element of the

sequence is input to the next.

– Example:

sort search display

Functional cohesion  Different elements of a module cooperate: – to achieve a single function, – e.g. managing an employee's pay-roll.  When a module displays functional cohesion, – we can describe the function using a single sentence.

Determining Cohesiveness  Write down a sentence to describe the function of the module

– If the sentence is compound, • it has a sequential or communicational cohesion.

– If it has words like “first”, “next”,

“after”, “then”, etc.

• it has sequential or temporal cohesion. – If it has words like initialize, • it probably has temporal cohesion.

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.

Coupling  There are no ways to precisely determine coupling between two modules: – classification of different types of coupling

will help us to approximately estimate the degree of coupling between two modules.

 Five types of coupling can exist between any two modules.

Classes of coupling data stamp control common content

Degree of  coupling

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 Two modules are common coupled, – if they share some global data.

Content coupling  Content coupling exists between two modules: – if they share code, – e.g, branching from one module into

another module.

 The degree of coupling increases – from data coupling to content coupling.

Neat Hierarchy  Control hierarchy represents: – organization of modules. – control hierarchy is also called program

structure.

 Most common notation: – a tree-like diagram called structure

chart.

Neat Arrangement of modules 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. Process­order

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 Process­order

Handle­indent

Handle­query

Data flow Arrows  Data flow arrows represent: – data passing from one module to another in the

direction of the arrow. root order Process­order

Library modules  Library modules represent frequently called modules: – a rectangle with double side edges. – Simplifies drawing when a module is

called by several modules. Quick­sort

Selection  The diamond symbol represents: – one module of several modules connected to the

diamond symbol is invoked depending on some condition. root

Process­order

Handle­indent

Handle­query

Repetition  A loop around control flow arrows denotes that the concerned modules are invoked repeatedly. root

Process­order

Handle­indent

Handle­query

Structure Chart  There is only one module at the top: – the root module.

 There is at most one control relationship between any two modules: – if module A invokes module B, – module B cannot invoke module A.

 The main reason behind this restriction: – consider modules in a structure chart to be

arranged in layers or levels.

Structure Chart  The principle of abstraction: – does not allow lower-level

modules to invoke higher-level modules: – But, two higher-level modules can invoke the same lower-level module.

Example root rms

Valid­numbers Get­good­data

Get­data

Valid­numbers

Compute­solution

Validate­ data

rms Display­solution

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 if(c == 100) P=20 else p= 80 while(p>20) print(student mark)

A=B

no

yes P=20

P=80 dummy

yes Print

no

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

Two strategies exist to guide transformation of a DFD into a structure chart: – Transform Analysis – Transaction Analysis

Transform Analysis  The first step in transform analysis:

– divide the DFD into 3 types of

parts:

• input, • logical processing, • output.

Transform Analysis  Input portion in the DFD:

– processes which convert input data from

physical to logical form. – e.g. read characters from the terminal and store in internal tables or lists.

 Each input portion:

– called an afferent branch. – Possible to have more than one afferent

branch in a DFD.

Transform Analysis  Output portion of a DFD: – transforms output data from logical form

to physical form.

• e.g., from list or array into output characters.

– Each output portion: • called an efferent branch.

 The remaining portions of a DFD – called central transform

Transform Analysis  Derive structure chart by drawing one functional component for: – the central transform, – each afferent branch, – each efferent branch.

Transform Analysis  Identifying the highest level input and output transforms: – requires experience and skill.

 Some guidelines: – trace the inputs until a bubble is found whose

output cannot be deduced from the inputs alone. – Processes which validate input are not central transforms. – Processes which sort input or filter data from it are.

Transform Analysis  First level of structure chart: – draw a box for each input and output

units – a box for the central transform.

 Next, refine the structure chart: – add subfunctions required by each high-

level module. – Many levels of modules may required to be added.

Factoring  The process of breaking functional components into subcomponents.  Factoring includes adding:

– read and write modules, – error-handling modules, – initialization and termination modules,

etc.

 Finally check:

– whether all bubbles have been mapped to

modules.

Why Factor?  to reduce module size  to get the modular advantages of topdown design  to minimize duplication of code  to separate work from management  to provide more generally useful modules  to simplify implementation

Factoring  factor the modules intelligently  aim at a high fan-in factor  aim at a low fan-out factor  use an informational cluster to avoid undesirable coupling  keep the system balanced

Example 1: RMS Calculating Software Data­ items

User

Compute­  RMS 0 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­ numbers 0.1 Data­ items

Validate­ numbers 0.2 error

Compute­ rms 0.3

Display 0.4 result

Valid  ­numbers

RMS

Example 1: RMS Calculating Software  By observing the level 1 DFD: – identify read-number and

validate-number bubbles as the afferent branch – display as the efferent branch.

Example 1: RMS Calculating Software root rms

Valid­numbers Get­good­data

Get­data

Valid­numbers

Compute­solution

Validate­ data

rms Display­solution

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 display

Human Player

Tic­tac­toe  software 0 move

Level 1 DFD move Validate­ move

Display­ board

board

Play­ move

game result Check­ winner

Structure Chart root Get­good­move

Get­move

Compute­game

Validate­ move

play­move

Display

Check­ winner

Transaction Analysis  Useful for designing transaction processing programs. – Transform-centered systems: • characterized by similar processing steps for every data item processed by input, process, and output bubbles.

– Transaction-driven systems, • one of several possible paths through the DFD is traversed depending upon the input data value.

Transaction Analysis  Transaction: – any input data value that triggers an

action: – For example, selected menu options might trigger different functions. – Represented by a tag identifying its type.

 Transaction analysis uses this tag to divide the system into: – several transaction modules – one transaction-center module.

Transaction analysis Transaction­  center trans 1

type 1

trans 3

trans 2

type 2

type 3

Level 1 DFD for TAS Customer­history

Customer­file order

Accept­ order Accepted­orders

Vendor­list

Indent­request Indents

Item­file inventory

Process­ order

Handle­ indent­ request

query statistics

Handle­ query

Sales­statistics pending­order

Structure Chart root order

Handle­order

Get­order

Accept­ order

indent Handle­indent

Process­ order

query

Handle­query

Design Heuristics  Evaluate first iteration to reduce coupling & improve cohesion.  Minimize structures with high fan-out, strive for fan-in as depth increases  Keep the scope of effect of a module within the scope of control for the module  Evaluate module I/fs  Define predictable modules but avoid restrictive modules  Strive for “controlled” entry modules

How good is a design? Guidelines  initialize as late as possible, terminate as soon as possible  avoid making the modules too restrictive or too general  avoid redundancy  avoid state memory wherever possible  make the module that locates an error to report it

Editing  edit known before unknown (wait till user has decided to give you the data)  edit syntactic before semantic  edit single before cross (field level checks first)  edit internal before external (edit intrarecord checks first before going for interrecord checks)  prefer table-driven validations