software design deriving a solution which satisfies software requirements
TRANSCRIPT
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.