Software Design

• Deriving a solution which satisfies software re-quirements

Phases in the Design Process

Architecturaldesign

Abstractspecificatio

n

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

Systemarchitecture

Softwarespecification

Interfacespecification

Componentspecification

Datastructure

specification

Algorithmspecification

Requirementsspecification

Design activities

Design products

Design Phases

• Architectural design: Identify sub-systems.• Abstract specification: Specify sub-systems.• Interface design: Describe sub-system inter-

faces.• Component design: Decompose sub-systems

into components.• Data structure design: Design data struc-

tures to hold problem data.• Algorithm design: Design algorithms for

problem functions.

Hierarchical Design Struc-ture

System level

Sub-systemlevel

Top-down Design

• In principle, top-down design involves starting at the uppermost components in the hierarchy

and working down the hierarchy level by level.• In practice, large systems design is never

truly top-down. Some branches are designed before others. Designers reuse experience (and sometimes components) during the design process.

Design Methods

• Structured methods are sets of nota-tions for expressing a software de-sign and guidelines for creating a de-sign.

• Well-known methods include Struc-tured Design (Yourdon), and JSD (Jackson Method).

Method Components

• Many methods support comparable views of a system.

• A data flow view showing data trans-formations.

• An entity-relation view describing the logical data structures.

• A structural view showing system components and their interactions.

Design Description

• Graphical notations: Used to dis-play component relationships.

• Informal text: Natural language de-scription.

Design Strategies

• Functional design– The system is designed from a functional view-

point. The system state is centralized and shared between the functions operating on that state.

• Object-oriented design– The system is viewed as a collection of interact-

ing objects. The system state is decentralized and each ob-ject manages its own state. Objects may be in-stances of an object class and communicate by exchanging methods.

Structured Design

• Introduction– Structured design was developed by

Ed Yourdon and Larry Constantine.• This technique deals with the size and

complexity of a program by breaking up a the program into a hierarchy of modules that result in a computer program that is easier to implement and maintain.

Structured Design

• Structure Charts– The primary tool used in structured de-

sign is the structure chart.• Structure charts are used to graphically

depict a modular design of a program. – Specifically, they show how the program has been

partitioned into smaller more manageable mod-ules, the hierarchy and organization of those modules, and the communication interfaces be-tween modules.

– Structure charts, however, do not show the inter-nal procedures performed by the module or the in-ternal data used by the module.

MODULEB

MODULEA

LIBRARYMODULE

A

MODULEG

MODULEF

MODULEE

MODULED

MODULEC

SYSTEMMODULE

DATA A

DATA A DATA B

DATA B

DATA C

DATA B

FLAG B FLAG BFLAG A

DATA BAND C/D

DATA D

1

23

45 6

7

6

5

4

Structured Design

• Structure Charts– Structure chart modules are depicted by named rec-

tangles.– Structure chart modules are presumed to execute in a

top-to-bottom, left-to-right sequence. – An arc shaped arrow located across a line (represent-

ing a module call) means that the module makes itera-tive calls.

– A diamond symbol located at the bottom of a module means that the module calls one and only one of the other lower modules that are connected to the dia-mond.

– Program modules communicate with each other through passing of data.

Structured Design

• Structure Charts– Programs may also communicate with

each other through passing of mes-sages or control parameters, called flags.

– Library modules are depicted on a structure chart as a rectangle contain-ing an vertical line on each side.

Structured Design

• Data Flow Diagrams of Programs– Structured design requires that data flow diagrams

(DFDs) first be drawn for the program. – Processes appearing on the logical, elementary DFDs

may represent modules on a structure chart. – Logical DFDs need to be revised to show more detail

in order to be used by programmers– The following revisions may be necessary:

• Processes appearing on the DFD should do one function. • Processes need to be added to handle data access and

maintenance. • DFDs must be revised to include editing and error handling

processes, and processes to implement internal controls.

BOUNDARYA

BOUNDARYB

BOUNDARYB

BOUNDARYA

P

NEWPROCESS

B

P

NEWPROCESS

A

P

PROCESS A

P

PROCESS B

P

PROCESS B(DO NOTEXPAND)

P

PROCESS A(DO NOTEXPAND)

P

PROCESSWITH MANY

INPUTS &OUTPUTS

D DATA STORE B

D DATA STORE A

D DATA STORE B

D DATA STORE C

D DATA STORE C

D DATA STORE A

EXPANDED (ORREPLACED BY)

DATA B

DATA A

DATA B

DATA C

SUM OF DATA AAND DATA C

SCREENEDDATA B

FINAL TOTALSOF DATA A & C

RELEASED DATA D

REVISED XYZ STATUS

REVISED XYZ STATUS

RELEASED DATA D

FINAL TOTALSOF DATA A & C

SCREENEDDATA B

SUM OF DATA AAND DATA C

DATA C

DATA A

P

PROCESS X

P

PROCESS X

P

DELETED DETAILS

P

READA DETAILS

P

UPDATEC DETAILS

BOUNDARYA

BOUNDARYA

P

ADDNEW B

DETAILS

D DATA STORE A

D DATA STORE A

D DATA STORE D

D DATA STORE B

D DATA STORE D

D DATA STORE C

D DATA STORE C

D DATA STORE B

B DETAILS

B DETAILS

DELETED D DETAILS

UPDATED C DETAILS

NEW B DETAILS

C DETAILS TOBE UPDATED

D DETAILSTO BE DELETED

NEW B DETAILSTO BE ADDED

A DETAILS FORPROCESSING

A DETAILS

DELETED D DETAILS

UPDATED C DETAILS

NEW B DETAILSA DETAILS

Structured Design

• Transform Analysis– One approach used to derive a program structure

chart from program DFD is transform analysis.• Transform analysis is an examination of the DFD to

divide the processes into those that perform input and editing, those that do processing or data transforma-tion (e.g., calculations), and those that do output.

– The portion consisting of processes that perform input and editing is called the afferent.

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

P

OUTPUTFUNCTION

C

P

INPUTFUNCTION

B

P

INPUTFUNCTION

D

P

OUTPUTFUNCTION

A

P

INPUTFUNCTION

C

P

OUTPUTFUNCTION

B

P

TRANSFORMFUNCTION

A

P

TRANSFORMFUNCTION B

P

INPUTFUNCTION

A

BOUNDARYB

BOUNDARYA

D DATA STORE D

D DATA STORE B

D DATA STORE E

M

L

K

J

I

H

G

F

E

D

C

B

A

Afferent

CentralTransform

Efferent

Structured Design

• Transform Analysis– The strategy for identifying the affer-

ent, central transform, and efferent portions of a begins by first tracing the sequence of processing for each input.

• There may be several sequences of pro-cessing.

• A sequence of processing for a given in-put may actually split to follow different paths.

Structured Design

• Transform Analysis– Once sequence paths have been identified, each

sequence path is examined to identify process along that path that are afferent processes.

• The steps are as follows:– Step 1 - Beginning with the input data flow, the data flow is

traced through the sequence until it reaches a process that does processing (transformation of data) or an output func-tion.

– Step 2 - Beginning with an output data flow from a path, the data flow is traced backwards through connected pro-cesses until a transformation processes is reached (or a data flow is encountered that first represents output).

– Step 3 - All other processes are then considered to be part of the central transform!

P

OUTPUTFUNCTION

C

P

TRANSFORMFUNCTION

A

P

TRANSFORMFUNCTION B

P

INPUTFUNCTION

B

P

INPUTFUNCTION

D

P

OUTPUTFUNCTION

A

P

INPUTFUNCTION

C

P

OUTPUTFUNCTION

B

P

INPUTFUNCTION

A

BOUNDARYB

BOUNDARYA

D DATA STORE D

D DATA STORE B

D DATA STORE E

M

L

K

J

I

H

G

F

E

D

C

B

A

START FORTRACINGINPUT B

START FORTRACINGINPUT D

START FORTRACINGINPUT A

FINISH POINTSFOR TRACINGINPUTS A & B

FINISH POINTFOR TRACINGINPUT D

Structured Design

• Transform Analysis– Once the DFD has been partitioned, a structure

chart can be created that communicates the modu-lar design of the program.

• Step 1 - Create a process that will serve as a “comman-der and chief” of all other modules.

– This module manages or coordinates the execution of the other program modules.

• Step 2 - The last process encountered in a path that identifies afferent processes becomes a second-level module on the structure charts.

• Step 3 - Beneath that module should be a module that corresponds to its preceding process on the DFD.

• This would continue until all afferent processes in the se-quence path are included on the structure chart.

INPUTFUNCTION

A

INPUTFUNCTION

D

INPUTFUNCTION

B

INPUTFUNCTION

C

BOSS

GF

E

C

Structured Design

• Transform Analysis• Step 4 - If there is only one transforma-

tion process, it should appear as a single module directly beneath the boss mod-ule.

– Otherwise, a coordinating module for the transformation processes should be created and located directly above the transformation process..

• Step 5 - A module per transformation process on the DFD should be located di-rectly beneath the controller module.

TRANSFORMFUNCTION

A

TRANSFORMFUNCTION

B

INPUTFUNCTION

A

INPUTFUNCTION

D

INPUTFUNCTION

B

INPUTFUNCTION

C

BOSS

CENTRALTRANSFORMCONTROLLER

E & F

J & I

G & H

E, F, & G

J

G

I

F

E

C

Structured Design

• Transform Analysis• Step 6 - The last process encountered in

a path that identifies efferent processes becomes a second-level module on the structure chart.

• Step 7 - Beneath the module (in step 6) should be a module that corresponds to the succeeding process appearing on the sequence path.

– Likewise any process immediately following that process would appear as a module be-neath it on the structure chart.

TRANSFORMFUNCTION

A

TRANSFORMFUNCTION

B

INPUTFUNCTION

A

INPUTFUNCTION

D

INPUTFUNCTION

B

OUTPUTFUNCTION

A

INPUTFUNCTION

C

OUTPUTFUNCTION

C

BOSS

CENTRALTRANSFORMCONTROLLER

OUTPUTFUNCTION

B

E & F

J & I

J

G & H

E, F, & GI

J

G

I

F

K

E

C

P

READPRODUCT

CONTAINEDON ORDER

P

READMEMBER

P

CALCULATEORDER

VOLUMES

P

WRITEREPORTACTIVITYDETAILS

P

READMEMBERORDER

P

GETORDER

DETAILS

P

FORMATMEMBERACTIVITYDETAILS

D PRODUCT ON ANORDER

D ACTIVITY REPORT FILE

D MEMBER

D MEMBER ORDER

MEMBERORDER

ACTIVITY

FORMATEDACTIVITYDETAILS

UNFORMATTEDACTIVITYDETAILS

MEMBERORDER

DETAILS

CUSTOMERAND ORDER

DETAILS

PRODUCTON ANORDER

DETAILS

MEMBER DETAILS

PRODUCTON AN ORDER

DETAILS

MEMBERDETAILS

MEMBERORDER

DETAILS

MAINTAIN MEMBER

GET ORDER DETAILS

CALCULATE ORDER

VOLUMES

FORMAT MEMBER ACTIVITY DETAILS

WRITE REPORT ACTIVITY DETAILS

READ MEMBER

READ MEMBER ORDER

READ PRODUCT

CONTAINED ON ORDER

CUSTOMER AND ORDER

DETAILS

CUSTOMER AND ORDER

DETAILS

UNFORMATED ACTIVITY DETAILS

UNFORMATED ACTIVITY DETAILS

FORMATED ACTIVITY DETAILS

FORMATED ACTIVITY DETAILS

MEMBER DETAILS

MEMBER NUMBER

PRODUCT ON AN ORDER

DETAILSORDER

NUMBER

MEMBER ORDER

DETAILS

Structured Design

• Transaction Analysis– An alternative structured design strategy for de-

veloping structure charts is called transaction analysis.

• Transaction analysis is the examination of the DFD to identify processes that represent transaction centers.

– A transaction center is a process that does not do actual transformation upon the incoming data (data flow); rather, it serves to route the data to two or more processes.

» You can think of a transaction center as a traffic cop that directs traffic flow.

» Such processes are usually easy to recognize on a DFD, because they usually appear as a process containing a single incoming data flow to two or more other processes.

P

INPUTFUNCTION

A

P

PROCESSTRANSACTION

TYPE B

P

TRANSACTIONCENTER

A

P

PROCESSTRANSACTION

TYPE A

BOUNDARYA

P

PROCESSTRANSACTION

TYPE C

P

DISPLAYRESULT

BOUNDARYB

RESULT

TRANSACTION

VALIDTRANSACTION

TYPE CRESULT

TYPE BRESULT

TYPE ARESULT

TRANSACTIONTYPE C

TRANSACTIONTYPE B

TRANSACTIONTYPE A

TRANSACTIONCENTER

PROCESSTRANSACTION

TYPE C

PROCESSTRANSACTION

TYPE B

PROCESSTRANSACTION

TYPE A

DISPLAYRESULT

INPUTFUNCTION

A

BOSS

VALIDTRANSACTION

TRANSACTION

TYPE A, B, ORC RESULT

TYPE ARESULT

TRANSACTIONTYPE A

TYPE BRESULT

TYPE A, B, ORC RESULT

TRANSACTIONTYPE C

TYPE CRESULT

TRANSACTIONTYPE B

Structured Design

• Transaction Analysis– The primary difference between

transaction analysis and transform analysis is that transaction analysis recognizes that modules can be orga-nized around the transaction center rather than a transform center.