STRUCTURE CHARTS

1
STRUCTURE CHARTS

• Elements and Definitions

2
(No Transcript)
3
Software System Design

• translates SRS into a
• gt software system architecture
• systems static structure
• systems possible dynamic behaviour
• data structures
• user interface design

4
Structured Analysis and Design

• prepare and analyse a
• Data Flow Diagram - DFD
• derive from the DFD a
• Structure Chart

5
Structure Chart

• supports the system and module design phase
• diagramming technique with annotations
• hierarchy of modules
• control (invocation) is explicitly modelled
• data flows follow control hierarchy
• decomposition is shown in the control hierarchy
• software / computer oriented
• derived from the DFD and further refined

6
System Structure - Control Hierarchy
S
I1
C1
O1
I2
I11
I12
I21
C11
O11
O12
7
Complete SC Design

• Structure Chart Diagram
• Data Dictionary (e.g. BNF)
• Module Specifications (e.g. PDL)
• gt consistent with DFD!

8
Structure Charts - Module

• process / subroutine / task
• unit of execution
• accepts parameters as inputs
• produces parameters as outputs
• parameters data or control
• can be invoked and can invoke
• label verb
• linked to module specification

label
9
Structure Charts - Special Modules

• predefined (reused) module
• highly useful

label

• macro module
• avoid

label

• multi-entry module
• avoid

label
10
Structure Charts - Invocation / Call

• call of subordinate module
• connector element
• NOT a data flow
• one specific form of control flow
• has a direction
• no split or join
• NO label

11
Structure Charts - Invocation / Jump to Address

• call jumps INTO
• invoked module
• assembler type of programming
• modification at run-time
• avoid

12
Structure Charts - Sequence of Execution

• sequence of subordinate modules in the diagram is
  not reflecting a binding sequence of invocation
• sequence of invocation is defined in the
  specification of the super-ordinate module
• module specification is
• the decisive element

X
X1
X2
X3
13
Structure Charts - Conditional Execution

• call of subordinate module depends on a condition
• no label
• condition is defined in the module specification
• module specification is
• the decisive element

14
Structure Charts - Loops in the Execution

• call of subordinate modules runs in a loop
• no label or condition
• loop (and its condition) is defined in the module
  specification
• module specification is
• the decisive element

15
Structure Charts - Data Flow

• flow of information
• data transfer
• bound to invocation
• has a direction
• no splits or joins
• label noun
• specified in data-dictionary

label
label
label
16
Structure Charts - Control Flow

• flow of control (ltgt invocation)
• gt control execution path
• of targeted module
• bound to invocation
• has a direction
• no splits or joins
• label flag, decision, condition
• specified in data-dictionary

label
label
label
17
Structure Charts - Data Store

• storage for permanent data
• database / file
• passive no activity beyond
• basic retrieval capacity
• serviced by a module
• label noun
• specified in data-dictionary
• and/or with an ER-diagram

label
18
Structure Charts - Devices / Interfaces

• provides connection to
• peripheral devices
• origin / destination of
• external data flows (controls)
• not part of the software
• to be developed
• label noun
• specified in data-dictionary

label
19
Structure Charts - SW Infrastructure

• provides connection to
• external systems, databases, operating system,
  etc.
• origin / destination of
• external data flows (controls)
• not part of the software
• to be developed
• label noun
• specified in data-dictionary

label
20
DFD ltgt SC????

• A Structure Chart
• is derived from a
• Data Flow Diagram
• and is a
• mapping and refinement
• of the DFD.
• gt Algorithms? / Heuristics?

21
STRUCTURE CHARTS

• An Example
• The Registration System

22
registration system
0
conf
reg
conf
invoice
reg
invoice
read check registration
compute registration
produce registration outputs
1
2
3
23
registration system
0
conf
reg
conf
invoice
reg
invoice
read check registration
compute registration
produce registration outputs
2
1
3
24
read check registration
1
reg_i
error_reason
reg_i
reg_flag
read registration
check registration
error-handler registration
1.1
1.2
1.3
error-msg
registration
CRT
25
registration system
0
conf
reg
conf
invoice
reg
invoice
read check registration
compute registration
produce registration outputs
1
2
3
26
compute registration
2
reg
reg
invoice
conf
prepare invoice
accept registration
2.1
2.2
reg_profile
reg_info
prices
registration db
27
registration system
0
conf
reg
conf
invoice
reg
invoice
read check registration
compute registration
produce registration outputs
2
3
1
28
produce registration outputs
3
invoice
conf
print invoice
write confirmation
3.1
3.2
invoice_prt
conf_msg
CRT
PRT
29
0
2
3
1
1.1
1.2
1.3
2.1
2.2
3.1
3.2
crt
db
prt
crt
center of transformation
input-driven
output-driven
30
Remember during Composition

• a module is a unit of execution
• invocation between modules is directed
• data flows and control flows must follow the
  invocation hierarchy
• data stores, devices, and external systems are
  typically at the lowest level of your SC
• sequence of execution depends on the internal
  specification

31
Suggestions for a Good Style

• have a balanced system
• input gt processing gt output
• think in terms of stepwise-refinement
• module encapsulates a single function
• limit the use of control flows
• reflect the sequence of execution in your SC

32
DFD ltgt SC????

• A Structure Chart
• is derived from a
• Data Flow Diagram
• and is a
• mapping and refinement
• of the DFD.
• gt Algorithms? / Heuristics?

33
MAPPINGDATA FLOW DIAGRAMS INTO STRUCTURE
CHARTS

• Transform and Transaction Analysis

34
Requirements
System Design
Detailed Design
Implementation
Installation Testing
Maintenance
35
Goals and Concepts of Structured Analysis and
Design

• structured development of software
• methodology
• notation (DFD, SC)
• integration of analysis and design
• quality control (cohesion, coupling)
• based on the flow of information (data)
• provides proven heuristics

36
The Focus is the Mapping

• prepare and analyse a
• Data Flow Diagram - DFD
• prepare and check
• a Structure Chart - SC

37
Design ...

• ... is an activity concerned with making major
  decisions, often of a structural nature.
• ... builds coherent, well planned
  representations of programs that concentrate on
  the interrelationship of parts at the higher
  level ...
• P. Freeman

38
Structured Analysis and DesignInformation Flow
Analysis

• 1 - specify the flow of information in your
  system
• gt DFD
• 2 - identify typical structural patterns in the
  DFD
• gt analysed annotated DFD
• 3 - use a proven heuristic to map DFD into SC
• gt first SC
• 4 - refine and check your Structure Chart
• gt final SC

39
Two Major Structural Patterns -Two Major
Alternatives

• Transform (Flow) Analysis
• Transaction (Flow) Analysis

40
Transform Flow
input-driven
center of transformation
output-driven
41
Transform Flow Characteristics

• the system has a single, coherent objective
• transformation center executes algorithms, data
  transformation, database manipulation, ...
• input-driven processes filter, check and
  translate external data flows
• output-driven processes format results for
  presentation to the environment (user)
• multiple paths to obtain input

42
Transform Analysismapping heuristic
i1
o1
o2
ct1
i2
ct2
o3
sys
I-ctrl
P-crtl
O-ctrl
i1
i2
ct1
ct2
o1
o2
o3
43
Transaction Flow
action-path
T
reception-path
T ... transaction center
44
Transaction Flow Characteristics

• single line of reception processes
• transaction a single data item that includes all
  necessary information for execution
• transaction center evaluates transaction
  initialises correct action-path gt distribution
• action-paths implement (clearly) different types
  of functionality gt execution
• an action-path could be a complete
• (sub-)system with transform flow characteristics

45
Transaction Analysis mapping heuristic
r1
sys
r2
r2
trc
r1
trc
s1
s2
i1
i2
i1
cot
o1
cot
i2
o1
46
Transaction Analysismay include Transform
Analysisas an element.
47
Transform Analysis as element of Transaction
Analysis
r1
sys
r2
r2
trc
r1
trc
s1
s2
i1
i2
i1
cot
o1
cot
i2
o1
48
TRANSFORM ANALYSIS

• Heuristics and Rules

49
DFD with Transform Flow Characteristics
input-driven
center of transformation
output-driven
50
Structured Analysis and DesignInformation Flow
Analysis

• 1 - specify the flow of information in your
  system
• gt DFD
• 2 - identify typical structural patterns in the
  DFD
• gt analysed annotated DFD
• 3 - use a proven heuristic to map DFD into SC
• gt first SC
• 4 - refine and check your Structure Chart
• gt final SC

51
Structured Analysis and DesignTransform Analysis

• 1 - specify the flow of information in your
  system
• 2 - a) confirm transform flow characteristics
• b) identify the center of transformation
• gt annotated DFD
• 3 - transform your DFD into a first Structure
  Chart
• using IPO structure as design heuristic
• 4 - refine and check your Structure Chart
• gt complete SC

52
Transform Analysis - Step 1

• the DFD should exist as a result of systems
  requirements engineering and systems analysis
• check completeness of the DFD, data dictionary,
  and process dictionary
• refine the DFD (decompose, etc.) if that is
  necessary

53
printer
user
invoice
prepare invoice
print invoice
invoice_prt
registration
reg
reg-profile
read check reg.
prices
registration db
conf_msg
reg_info
reg
write conf.
error_msg
accept reg.
conf.
user
54
registration
reg
read registration
reg_i
check registration
reg
error_reason
error-handler registration
error_msg
55
Transform Analysis - Step 2

• Step 2a
• check the list of properties for transform flow
  characteristics
• be aware that this is a guideline only
• Step 2b
• find and mark the center of transformation in the
  DFD

56
Transform Analysis - Step 2b

• locate the center of transformation
• follow input-driven flows into the center until
  the data is in an internal format, correct and
  complete gt mark position
• trace back output-driven flows to the center
  until the data is complete and ready for
  presentation, but not yet in external format gt
  mark position
• connect all markings center of transformation

57
center of transformation
printer
user
invoice
prepare invoice
print invoice
registration
invoice_prt
reg
reg-profile
read check reg.
prices
registration db
conf_msg
reg_info
reg
write conf.
accept reg.
error_msg
conf.
user
58
registration
reg
read registration
reg_i
check registration
reg
error_reason
error-handler registration
error_msg
59
Transform Analysis - Step 3IPO mapping heuristic
i1
o1
o2
ct1
i2
ct2
o3
sys
I-ctrl
P-crtl
O-ctrl
i1
i2
ct1
ct2
o1
o2
o3
60
The IPO Mapping Design Heuristic

• establish a top level main controller (system)
• always introduce
• Input-driven flow controller
• transform flow controller (Processing)
• Output-driven flow controller
• translate DFD processes into SC modules and hang
  them from the correct controller
• allocate subprocesses gt submodules

61
reg. sys.
comp reg.
prod. output
read check
read reg.
error hdlg. reg.
prep. inv.
print inv.
write conf.
check reg.
acc. reg.
crt
db
prt
crt
62
Transform Analysis - Step 4

• add data (and control) flows
• further decompose (factor) were necessary
• user interface handling modules
• error-handling modules
• add initialisation termination modules
• check quality of design
• cohesion
• coupling
• reconfirm mapping with DFD

63
TRANSFORM ANALYSIS

• An Example

64
The DFD used in this example is the Patient
Information Systemfrom section 2c.The
resulting Structure Chartis described on the
following pages.
65
patient information system
0
AD
PI
PI
AD
AQ
Q
Q
U
AQ
UR
U
UR
get patient info
compute patient info
produce query/update outputs
1
2
3
66
get patient info
1
PI
U
Q
check accum. PDR
read check Query
read check Update
1.1
1.2
1.3
67
check accum. PDR
1.1
PI
PDRI
PDR_OK?
PDRI
PDRI
PDRI
PDREI
PDREI
read PDR
check PDR
error-hdlg for PDR
accum. PDR
1.1.1
1.1.2
1.1.3
1.1.4
PDR-
PDR
CRT
68
read check Query
1.2
QI
QI
QI
Q_OK?
QEI
QEI
read Query
check Query
error-handling for Query
1.2.1
1.2.2
1.2.3
Query-
Query
CRT
69
read check Update
1.3
UI
UI
UI
U_OK?
UEI
UEI
read Update
check Update
error-handling for Update
1.3.1
1.3.2
1.3.3
Update-
Update
CRT
70
compute patient info
2
Q
PI
U
AQ
UR
AD
evaluate Alarm
process Request
2.1
2.2
AD
UR
ND
U
AQ
ORD
Q
handle Alarm
process Pat.
process Query
process Update
2.1.1
2.1.2
2.2.1
2.2.2
STD
NT
CT
Summary
PH
patient db
71
produce query/update outputs
3
AD
UR
AQ
answer Query
give Alarm
give Feedback
3.1
3.2
3.3
AO
FQ
FU
CRT
72
Figure 18-2An Illustration of the Hierarchy of a
Structure Chart
73
Special Symbols Used in Structure Charts
74
How to Read a Structure Chart
75
A Central Transform in a Data Flow Diagram
76
The Data Flow Diagram from with the Central
Transform Circled