The Traditional Approach To Design

Overview

• Traditional approach to designing software – Overview of structured models, model development process, related terminology – How data flow diagrams are annotated with automation boundary information – How analysis phase models are transformed into design models using system flowcharts, structure charts, and module pseudocode – Integration into other design phase activities – Applying approach to a three-layer architecture 2

The Structured Approach to Designing the Application Architecture

• Application software programs – Designed in conjunction with database and user interface – Hierarchy of modules • A module is a small section of program code that carries out a single function.

• A computer program is a set of modules that are complied into a single executable entity.

• Top-down approach – DFDs with automation boundaries – System flowcharts , structure charts , pseudocode 3

The Structured Approach to Designing the Application Architecture

• System flowchart – A diagram that describes the overall flow of control b/w computer programs in a system.

– Shows the relationships among the various programs, subsystems, and their files or databases – Documents the architectural structure of the overall system.

• Pseudocode – Structured programming-like statements that describe the logic of a module.

– Designs the internal logic of individual modules.

4

Structured Design Models

5

The Automation System Boundary

• Partitions data flow diagram processes into manual processes and automated systems • Processes can be inside or outside boundary • Data flows can be inside and outside of boundary – Data flows that cross system boundary represent inputs and outputs of system – Data flows that cross boundaries between programs represent program-to-program communication 6

DFD with Automation System Boundary

7

The System Flowchart

• Representation of various computer programs, files, databases, and associated manual processes that make up complete system • Frequently constructed during analysis activities • Graphically describes organization of subsystems into automated and manual components • Can show type of transaction processing system – Batch – Real time 8

Common System Flowchart Symbols

9

Sample System Flowchart for Payroll System

10

System Flowchart for RMO

11

The Structure Chart

• Describes functions and subfunctions of each part of system • Shows relationships between modules of a computer program • Simple and direct organization – Each module performs a specific function – Each layer in a program performs specific activities – Single point of entry and exit • Chart is tree-like with root module and branches 12

A Simple Structure Chart for the Calculate Pay Amounts Module

13

The Structure Chart

• Communicate with each other by passing parameters – Data couple • A diagrammatic representation of the data exchanged between two modules in a structure chart – Flag • A diagrammatic representation of a message passed between two modules 14

The Structure Chart

• Special Symbols – Diamond • Only one subordinate will be called – Curved Line • Subordinates are called repeatedly until terminating condition is met – Predefined modules – Hat • Subordinate module is important logically but code is contained in superior module 15

Structure Chart Symbols

16

Structure Chart for Entire Payroll Program

17

Developing a Structure Chart

• Transaction Analysis – The development of a structure chart based on a DFD that describes the processing for several types of transactions • Transform Analysis – The development of a structure chart based on a DFD that describes the input-output data flow 18

Types of Data Flow

Transform flow Transaction flow

19

Create a Structure Chart from a DFD Fragment: Transaction Analysis incoming flow

action path T 20

Create a Structure Chart from a DFD Fragment: Transaction Analysis

e a b d t g h b a data flow model d x2 e f x1 l m n g t x3 h i x3.1

j k l j i f k Mapping x4 m n 21

Event-partitioned DFD for the Order Entry Subsystem

22

High-level Structure Chart for the Customer Order Program

23

Create a Structure Chart from a DFD Fragment: Transaction Analysis

BOUNDARY A TRANSACTION P INPUT FUNCTION A VALID TRANSACTION P TRANSACTION CENTER A P PROCESS TRANSACTION TYPE A TRANSACTION TYPE A TRANSACTION TYPE B P PROCESS TRANSACTION TYPE B TRANSACTION TYPE C P PROCESS TRANSACTION TYPE C BOUNDARY B TYPE A RESULT TYPE B RESULT RESULT P DISPLAY RESULT TYPE C RESULT 24

Create a Structure Chart from a DFD Fragment: Transaction Analysis

BOSS TRANSACTION INPUT FUNCTION A TYPE A, B, OR C RESULT TRANSACTION CENTER VALID TRANSACTION TYPE A, B, OR C RESULT DISPLAY RESULT TYPE A RESULT TRANSACTION TYPE A PROCESS TRANSACTION TYPE A TRANSACTION TYPE B TYPE B RESULT PROCESS TRANSACTION TYPE B TYPE C RESULT TRANSACTION TYPE C PROCESS TRANSACTION TYPE C 25

Create a Structure Chart from a DFD Fragment: Transform Analysis

• Determine primary information flow – Main stream of data transformed from some input form to output form • Find process that represents most fundamental change from input to output • Redraw DFD with inputs to left and outputs to right process goes in middle • The portion consisting of processes that perform input and editing is called the • The portion consisting of processes that do actual processing or transformations of data is called the

central transform

• The portion consisting of processes that do output is called the • Generate first draft structure chart based on redrawn data flow

efferent

.

.

afferent

.

26

Create a Structure Chart from a DFD Fragment: Transform Analysis

b x2 a c a c b d e f data flow model i g j h x1 "Transform" mapping x3 x4 d e f g h i j 27

The Create New Order DFD Fragment

28

Exploded View of Create New Order DFD

29

Rearranged Create New Order DFD

30

First Draft of the Structure Chart

31

Steps to Create a Structure Chart from a DFD Fragment ( continued )

• Add other modules – Get input data via user-interface screens – Read from and write to data storage – Write output data or reports • Add logic from structured English or decision tables • Make final refinements to structure chart based on quality control concepts 32

The Structure Chart for the Create New Order Program

33

Combination of Structure Charts

34

Evaluating the Quality of a Structure Chart

• Module coupling – Measure of how module is connected to other modules in program – Goal is to be loosely coupled • Module cohesion – Measure of internal strength of module – Module performs one defined task – Goal is to be highly cohesive 35

Examples of Module Cohesion

36

Module Coupling

• In structured design, the decomposition of a program in manageable modules should be done in such a way that the modules are independent as possible from one another. • In structured design programs appearing on a structure chart are evaluated relative to their degree coupling.

• Coupling refers to the level of dependency that exists between modules. • Loosely coupled modules are less likely to be dependent on one another.

37

Module Coupling

• Types of coupling: (from best to worst) – Data coupling — two modules are said to be data coupled if their dependency is based on the fact that they communicate by passing of data (e.g., interest rate, term, sum borrowed). – Stamp coupling — two modules are said to be stamp coupled if their communication of data is in the form of an entire data structure or record (e.g., customer-record, order-record). – Control coupling — two modules are said to be control coupled if their dependency is based on the fact that they communicate by passing of control information or flags (e.g., account-number-valid, read-next-record). – Common coupling — modules are said to be common coupled if they refer to the same global data area.

– Content coupling — two modules are said to be content coupled (also referred to as hybrid coupled) when one module actually modifies the procedural contents of another module.

38

Common coupling

Find Part Name Part Name Part Name Exists Parts Table Previous Stock New Stock Remove Stock Out of Stock Non Existent Part Error Flag 3 39

Content Coupling

ROUTINE A … … JUMP TO SRCH + 352 … … END ROUTINE A ROUTINE B … … SRCH: MOVE 1 TO REGISTER D … … END ROUTINE B 40

Module Cohesion

• Cohesion refers to the degree to which a module's instructions are functionally related. • Highly cohesive modules contain instructions that collectively work together to solve a specific task.

• The goal is to ensure that modules exhibit a high degree of cohesiveness. • Programs that are implemented with highly cohesive modules tend to be easier to understand, modify, and maintain.

41

Module Cohesion

• Types of cohesion (from most desirable to least desirable) – Functional cohesion — are modules whose instruction are related because they collectively work together to accomplish a single well-define function. • e.g., calculate current GPA – Sequential cohesion — are modules whose instructions are related because the output data from one instruction is used as input data to the next instruction. • e.g., format and validate current GPA 42

Module Cohesion

– Communicational cohesion — are modules whose instructions accomplish tasks that utilize the same piece(s) of data. • e.g., calculate current and cumulative GPA – Procedural cohesion — are modules whose instructions accomplish different tasks, yet have been combined because there is a specific order in which the tasks are to be completed. • e.g., calculate cumulative GPA, and print cumulative GPA – Temporal cohesion — are modules whose instructions appear to have been grouped together into a module because of “time”.

• e.g., initialize all attributes 43

Module Cohesion

– Logical cohesion — are modules that contain instructions that appear to be related because they fall into the same logical class of functions. • e.g., the called module could open a checking account, open a saving account, or calculate a loan, depending on the message that is send by its calling module – Coincidental cohesion — are modules that contain instructions that have little or no relationship to one another.

• e.g., the module could update customer records, calculate loan payments and print exception reports 44

Module Algorithm Design: Pseudocode

• Describes internal logic of software modules • Variation of structured English that is closer to programming code • Syntax should mirror development language • Three types of control statements used in structured programming: – Sequence : sequence of executable statements – Decision : if-then-else logic – Iteration : do-until or do-while 45

Module Algorithm Design: Pseudocode

46

Module Algorithm Design: Flowchart

47

Module Algorithm Design: Nassi Shneiderman

Process Decision Iteration 48

Do daily Clear Summary Totals Do for each newspaper Clear newspaper Totals Print date Print newspaper Do it for each subscriber update Search for existing subscriber record Renewal Update Type New subscription Cancellation Y Address Correct?

N Null Set subscription length to zero Null Input new address Set subscription length Issue refund check Change of address Change Update totals for newspaper Print updated subscriber information Get next subscriber update Print summary totals for newspaper Get next newspaper Print summary totals for all newspaper

Module Algorithm Design: Nassi Shneider man

49

Integrating Structured Application Design with Other Design Tasks

• Structure chart must be modified or enhanced to integrate design of user interface and database – Are additional modules needed?

– Does pseudocode in modules need modification?

– Are additional data couples needed to pass data?

• Structure charts and system flowcharts must correspond to planned network architecture – Required protocols, capacity, and security 50

Three-Layer Design

• Three-layer architecture: – View layer, business logic layer, and data layer • Structure charts and system flowcharts describe design decisions and software structuring • Employs multiple programs for user interface, business logic, and data access modules • Modules in different layers communicate over 51 real-time links using well-defined protocols

System Flowchart Showing Three Layer Architecture for Customer Order

52

Structure Chart Showing Three-Layer Architecture for Create New Order

53

Summary

• For traditional structured approach to systems design, primary input is data flow diagram – DFD is enhanced by adding system boundary – Designer describes processes within each DFD boundary using one or more structure charts • Structure charts developed using: – Transaction analysis – multiple transaction types – Transform analysis – single transaction from input to output 54

Summary (

continued

)

• Structure charts may be based on three-layer architecture – Modules will be clearly identified by layer – Structure chart may be decomposed if layers execute on multiple systems • Structured design may also include: – System flowcharts to show data movement – Module pseudocode to describe internal logic of structure chart module 55