Topic:
Cleanroom software development
Topic:
decision table
Topic:
structured flow diagram
Topic:
visual programming
| |
Summary
Two important design methods specify requirements by interrelated diagrams: Ross's SADT and HIPO. In both methods, exploded diagrams represent program elements through graphic symbols. They are similar to structured flow charts but arrows between elements indicate interrelationships instead of control flow. (cbb 5/80)
Another system is SIAD. (cbb 11/92)
Subtopic: box structure 
| Quote: Cleanroom uses box structures for specification; before design starts, everyone must agree that the specification is correct [»lingRC10_1988]
| | Quote: box structures avoid the ambiguities and omissions for natural language specifications; detects gaps and misunderstandings early [»lingRC5_1993]
| | Quote: box structure design: all data and processing in boxes, boxes form a usage hierarchy, black/clear/state boxes [»lingRC5_1993]
| | Quote: black, state, and clear boxes have identical external behavior but increasing internal detail
| | Quote: building block of structured analysis is a box with controlled input/output and an implementation mechanism [»rossDT1_1977, OK]
|
Subtopic: state and black box structures
| Quote: Cleanroom's black-box view defines system responses in terms of stimuli histories; implementation-independent [»cobbRH11_1990]
| | Quote: Cleanroom's state-box view defines system responses in terms of state data and the current stimuli; data-driven, captures stimuli history [»cobbRH11_1990]
| | Quote: a black box specifies all visible behavior; i.e., a response for each stimulus and stimulus history, including erroneous histories [»lingRC5_1993]
| | Quote: record black box specifications by tables of stimulus and history conditions; scale up by behavior classes and specification functions [»lingRC5_1993]
| | Quote: a state box specification replaces the stimulus history of a black box with old state to new state transitions [»lingRC5_1993]
|
Subtopic: clear box structures
| Quote: both data (state-boxes) and process (clear-boxes) views are needed for designing software; related by box structures [»cobbRH11_1990]
| | Quote: Cleanroom's clear-box view defines system responses in terms of lower level black boxes, data abstractions for states, and current stimuli; process-driven [»cobbRH11_1990]
| | Quote: a clear box implements a state box with sequence, iteration, and concurrency; may invoke black boxes [»lingRC5_1993]
| | Quote: a clear box forces cooperation of lower level black boxes; defines a usage hierarchy and box interfaces [»lingRC5_1993]
|
Subtopic: time-line
| Quote: graphical time-line editor for writing requirements for a logic model checker; a requirement consists of a preamble, a response, constriants, and ignored events [»smitMH8_2001]
|
Subtopic: diagrams
| Quote: dual diagrams for entity behavior in terms of events and events in terms of affected entities and messages exchanged [»robiKA8_1979]
| | Quote: specify input domain for a software system by its symbolic input attribute decomposition (SIAD); for discipline, test plan, and statistical sampling [»choCK_1987]
| | Quote: 1000 HITACHI programmers use problem analysis diagrams instead of flowcharts [»futaY3_1981]
| | QuoteRef: rossDT1_1977a ;;11 SADT graphic language uses boxes (parts of a whole) and arrows (constraint or interfaces between parts) in diagrams (each one a whole)
| | QuoteRef: kralTM5_1975 ;;6-5 HIPO diagrams consist of input, process and output requirements
| | QuoteRef: kralTM5_1975 ;;6-2 HIPO consists of visual table of contents hierarchically arranged with overview diagrams and detail diagrams
| | QuoteRef: kralTM5_1975 ;;6-5 HIPO control top to bottom of process chart with calls, loops, conditionals (embedded blocks and exiting arrows)
| | QuoteRef: kralTM5_1975 ;;6-5 "HIPO is a tool which stresses function (i.e. what a program does) versus how it performs the functions"
|
Subtopic: tables
| Quote: use tables of mathematical expressions for practical, precise definitions; each cell defines a specific case [»parnDL8_1984]
|
Subtopic: graphical pseudocode
| Quote: problem analysis diagrams based on stepwise refinement, i.e., breaking down vagueness by sequence, repetition, and selection [»futaY3_1981]
| | Quote: schematic pseudocode provides graphical indications for sequential, repetitive, and conditional actions [»plamR7_1981]
|
Subtopic: problems with analysis
Quote: structured analysis leads to premature design; hard to visualize overall behavior
[»hsiaP11_1993]
|
Related Topics
Topic: Cleanroom software development (38 items)
Topic: decision table (29 items)
Topic: structured flow diagram (36 items)
Topic: visual programming
(32 items)
|
