4. Non-Formal Development Methods
4.1 Hierarchy-Plus-Input-Process-Output (HIPO)
- Introduced by IBM in 1974 (as a "panacea"); however, mainly for design and specification.
- Two components
- VTOC (Visual Table of Components): Decomposition of the program into sub-functions
- IPO (Input-Process-Output) diagrams: Linking the output data of the VTOC functions with the input data
- Overview IPO Diagram - Detailed IPO Diagram
4.1.1 Example: Payroll Accounting VTOC (Visual Table of Contents)
Payroll
Accounting 1.0
Add
Gross Wage 2.0
Calculate Net Wage 3.0
Add Working Hours
2.1
Determine Wage
2.2
Determine Gross Wage 2.3
Calculate Deductions 3.1
Transfer 3.2
Validate Validate Determine Validate
Hierachy Diagram
IPO Diagram
Author: R. Ratlos System: Accounting Datum: 07.12.1997 Diagram ID: 1.0 Program: Payroll Page: 1 of 1
Input Process Output
Employee Wage Movement Data
Employee Master Data
Data for Deductions
Eymployee Master Data
Gross Wage
Net Wage
Error Message 2.0 Calculate Gross Wage
3.0 Calculate Net Wage
after 1.0
from 1.0
4.1.2 Comments on HIPO
– Easy to learn
– Good presentation of hierarchical relations
– DT, structure diagrams provide details on the functions.
– No tools available, expensive to maintain – Networking of the functions is problematic.
– “Large interfaces” between functions
– Exception handling, structured programming, modularization, data abstraction, information hiding, etc. are not supported.
4.2 Structured Analysis (SA)
– Introduced in the 70s by Tom deMarco
– For system analysis and requirements definition – Means of Representation
– Data Flow Diagrams (DFD): Data flows and functions – Data Dictionary: Definition / Description of the data – Mini Specification: Duties of individual functions
– "Data Preservation Principle"
– Each transformation generates outputs for which it receives the relevant input.
– Correspondence of I / O in different levels.
– Memory representation for multiple transformations: On the top
Example for Data Dictionary (Based on BNF - Backus-Naur Form) Legend: {... } := Iteration; + :=Link (Sequence)
(... | ...) := Optional Address file = {Address}
Address = Title + Name + Street + House Number + Postal Code + Place Name = (Title +) First Name + Last Name
Title = (Mr | Mrs | Company)
Mini Specification: User-oriented description of the transformations, by means of decision tables, structure diagrams, pseudo-code, etc.: Contains no program- technical details. A maximum of one DIN A4 page (if not, transformations should
4.2.1 Rules for Creating Data Flow Diagrams
– Each transformation generates outputs for which it receives the relevant input (Data Preservation Principle).
– If a diagram does not fit on one page (or it is confusing), transformations will be represented top-down as separate programs.
– The I/O of the parent diagrams must comply with the I/O of the child programs.
– The data storage required by multiple transformations is described at the topmost level.
– Only the data flow relations are described. Control flow (e.g., temporal- dependence of the functions) is disregarded.
– Data flows, transformations have meaningful names.
Data Flow Diagram
: Data flow
<Info. unit>
<Action> :Transformations/Functions
<Repository> : Data Storage
<Interface> : End Nodes
4.2.2 Example
Address Management (Storage, Evaluation, and Printing)
Record Check+
Evaluation
Print Address File
Evaluation File
Address User
Address List Address
Selection Criteria
Evaluated Addresses
Correct Address Addre
sses to be corrected
Address
4.2.3 Comments on SA
– Advantages
– Requirement validation by user involvement – Easily updatable
– Simple approach – Formal analysis
– Disadvantages
– Not an analysis mean (more of a representation mean), so not a definitive method – Can not be formalized, so no extensive computer support
– Design / detailed specification and real-time apllications are not supported.
4.3 Structured Analysis and Design Technique (SADT)
– Developed since the early 70s developed; commerical marketing – More than a representation mean; methods character.
– Mainly for system analysis, requirement definition, design.
– Four components: Actigrams, datagrams, node index (overview diagram), policy catalog.
GENERAL:
Datum (Object) Control
Input Output
Mechanism
DATAGRAM:
Input
Data Datum (Object) Control data
Output Data
"Activity Data" / Auxiliary Values Storage Elements / Data Transfer Unit
Input Activities
Datum (Object) Control Activities
Output Activities ACTIGRAM:
Actigram
(Surrounded by data)
No mirror image Datagram
(Surrounded by activities)
A ...
A∅...
A1...
A2...
A21...
A22...
A3...
A31...
A311...
...
Node Index (als overview of diagrams)
4.3.1 Example: Payroll Accounting S1: Tax Law / Tax Regulation
S2: premium policy Calculate
Wage E1: Employee Master Data
E2: Employee Movement Data E3: Tax File / Social Tax Data
Gross Wage: A1 Net Wage: A2
ACTIGRAM M1: Bank Transfer
Refinement yields:
S3: Operation Agreement ( )
( )
Spec. Software
S1
A2 S2
Calculate Gross Wage
Calculate Net Wage
E1 A1
E2
E3
S1: Determine wage group
S2: Check if tax law changes Lohn A1: Transfer tax
E1: Calculate
A2: Transfer net wage
M1: Calculate DATAGRAM
Refine
Determine tax Look up tax table Calculate
S1 S2
M1 M1
Gross Wage
Net Wage Income Tax E1
A2 A1
4.3.2 Comments on SADT
– The perspective (use, development) can be indexed.
– Supports top-down (hierarchical) approach
– Between three and six components for each level – Dual representation of the data and the functions – Control flow can not be represented explicitly.
– Detailed specification / implementation is not supported.
4.4 Composite Design/Structured Design (CD/SD)
– Originally: Initially developed by Larry L. Constantine (SD) since the mid-60s to mid 70s. Further developed by G.J. Myers (till the late '70s), then by W.P.
Stevens (till the early 80s).
– Method character and function orientation are gradually more pronounced.
– Components
– Decomposition scheme in five steps
– Quantitative evaluation scheme of modularization ("small/weak" data
coupling between modules, "high functional binding/rigidity" of the module) – Decomposition of the system into independent ("loosely coupled") sections
Step 1: Creation of the Data Flow Diagram with SA, SADT, etc.
Step 2: Transfer of main input/output data streams in a linear chain of functions Step 3: Transform Analysis: Determination of the points of congruent abstraction/concretization (Thesis of Optimal Decomposition)
Step 4: Identification of the modules of the optimal decomposition Step 5: If necessary, repeating steps 1 to 4 for partial functions
– Processing a file with n messages (strings) as follows
– Count the normal (e.g., length <25 characters) and long (otherwise) words of each message
– Calculate the fee for each message according to a predetermined schema – Make a list of results
– Assumptions
– End of file mark: "EOF"
– End of Message mark: "***"
4.4.1 Example
Get characters
Form normal/
long words
Determine the amount of
normal/long words
Calculate charges
List ...
User Message
File
Word Repository
Words
Charge Repositoy
Words
Step 1: Data Flow Diagram (Simplified)
Sentences
Charges
Characters
Character Stream Characters
Amounts
Amount Repository
Amounts
Amounts 1.
2.
3.
4.
Amounts
Step 2: Determination of Data Streams
Get characters
Form
normal/long words
Determine the amount of
normal/long words
Calculate charges
List ...
Messages/Sentences
Amounts + Charges Amounts Words
Characters Step 3:
Transformation Analysis
Boundary between output / process
Boundary between input / process
Step 4: Optimal Division
Message Processing
Count Words Get Words
List Relevant Amounts and Charges
Determine Relevant Amounts
Calculate Charges Structure Diagram
Legend:
# : Number of ...
4 5
3 1
2
6
Parameter Table
Input
—
“****“, #Words,
#Long Messages#, Words
#Long, Charge Characters
Words
—
Input/Output
—
#Words, #Long, Charge
—
—
#Words/#Long
—
Output
#Words, #Long
EOF Charges /
each Message
— Word, EOF
Number of Words Characters, EOF 1
2 3 4 5 6
4.4.2 Generalization
– SD/SC supports the decomposition according to a certain schema. In simplified terms, this schema is:
– In this decomposition, a module structure arises in staircase form with Coordination
Input Process Output
Source Transformation Sink
Carry out
Determine C
Transform C to D
Pass D on
Determine B
Transform D to E Transform
B to C
Pass E on
Transform Transform
≈ ≈
5 6 7
General:
_
3 4 8 9
1 2 10 11
with the parameter table:
# 1 2 3 4 5
In - B
- C
-
Out A B B C C
In C D D E E F
Out D
- E
- F
-
# 6 7 8 9 10 11
– There is no direct communication between “Determine ..." and “Pass ... on". All information is exchanged through transformations.
– The result is a tree hierarchy "x uses y", where the following special cases of the
4.4.3 Inter-Modular Relationships
Module A calls module B.
Module A calls modules B or C conditionally.
A
B
A
B C
usualstructures
Module A calls modules B and C successively on.
A
B C
usualstructures
Module A module B and C calls iteratively.
A
B C
sometimes useful
Module A calls itself (recursion).
A
improperstructures
A module contains a jump into module B.
A
B A
B
Module A calls module B and module B uses the data from the module A.
improper meaningless "Pathological"
A module has several outputs.
A
4.4.4 Comments on SD/CD
– The structure of the tree "left: input, middle: process, right: output" is common but not mandatory.
– The actions “Pass data up, distribute, transform" can collaborate with multiple modules.
– More than two points can also lead to the highest abstraction; accordingly, more than three sub-problems are possible.
– The two points of the highest abstraction can also coincide: Two sub-problems, the transformation is not necessary.
– Evaluation of module coupling:
– The coupling is more loose, as the interface is less complex (simpler, narrower) - (small number of specified parameters).
– The coupling is more loose, as the global data is used less.
• The coupling is stronger, as the interface of the called module gets more transparent.
• The coupling is (unnecessarily) strong, when the call contains control information in addition to data.
• The coupling is very (improperly) strong, when the call changes the code of the called module.
• The internal cohesion (module rigidity, functional binding), however,
must be as strong as possible with respect to (in order): random, logical, temporally causal, communicative, sequential and functional contexts.
– A system is better structured, as the internal connection of individual modules is stronger, and the couplings between the modules are more loose.
– SD/CD supports and evaluates the structuring by top-down, hierarchical approach (functional abstraction).
– Data Abstraction: Disregarded; no support of interface specification.
