Post on 11-Jan-2016
Autumn 1996 Week 3SEM510
1. Data-flow diagrams.
A graphical technique which depicts the information flow and the transforms applied as the data move from input to output.
It may be applied to a) a complete system. b) one complete program. c) one complete segment (procedure, function
etc.)
Different texts use slightly different symbols. The meaning is usually clear from the context.
Autumn 1996 Week 3SEM510
2. Notation used in Data-flow diagrams.
external entity.
process.
data item.
data store.
provider or user of information outside the system being modelled
transformer of information lying inside the system.
single data item or collection of data items. arrow indicates direction of flow.
repository of data stored for use by one or more processes.
or
or
oror
user interaction
Autumn 1996 Week 3SEM510
3. Simple Data-flow diagram.
input next guess
compare guess with code
when correct, output message and stop
input next guess
compare guess with code
when correct, output message and stop
Autumn 1996 Week 3SEM510
4. Control-flow Diagram.
Uses the same processes as the data-flow diagram, but show control flow.
They show how events flow among processes. They illustrate external events which cause various
processes to be activated. They use “process activation tables” (PATs) and “state transition diagrams” (STDs).
Study the chapter in Pressman and work out examples.
Autumn 1996 Week 3SEM510
5. Structure Charts.
Show the hierarchical component structure of a system.
functional component.
hierarchy
inputoutput
data stores user inputs
Autumn 1996 Week 3SEM510
6. Method for Data Flow Diagram.
(a) Start with a single large bubble and break it up into smaller bubbles.
(b) Start with output data stream from the software and trace the data flow backwards.
(c) Start with the input data flow and trace it forwards.
Autumn 1996 Week 3SEM510
7. Program Structure Chart.
To transform a data-flow diagram into a program structure chart, we use the following 5 steps.
1) Establish the type of information flow. 2) Indicate flow boundaries. 3) Map data flow diagram into program structure. 4) Define control hierarchy. 5) Refine the structure using design measures and
heuristics.
Autumn 1996 Week 3SEM510
8. Program Structure Chart.
Aims to produce highly modular design with re-usable modules.
“Correct” design is not unique. Several possible solutions exist.
Need to use ideas of “cohesion” and “coupling” to decide which is the most appropriate in any given case.
Result is based on “data-coupling” between the modules.
e.g. my classification of “input”, “output” and “local” variables in a procedure or function.
Autumn 1996 Week 3SEM510
9. Structure Charts. To produce good structure charts, it is necessary to
identify loosely-coupled, highly-cohesive units. This is simplified if the units are considered to be of the
following types. 1. Afferent units. These accept data from a unit at a lower
level and pass it on to a higher level unit in some modified form.
2. Efferent units. These accept data from a higher level unit and pass it on to a lower.
3. Transform units. These accept data from a higher level unit and return them to that unit.
4. Coordinate units. These control and manage other units.
Autumn 1996 Week 3SEM510
10. Producing structure charts. Step 1. Identify the highest level input and output units.
These are concerned with passing data up and down the hierarchy and are the furthest removed from physical input or output.
This does not usually include all transforms. Those remaining are called “central transforms”.
One possible approach is to trace the inputs until a transform is found whose output is such that its input cannot be deduced from output examination. The previous bubble is then the highest level input unit.
A similar criterion is used to find the highest level output transform.
Autumn 1996 Week 3SEM510
11. Structure Charts.
The first level is produced by representing the input and output units as single boxes, and each central transform as a single box.
This factoring process may then be repeated for the first level units in the structure chart until all bubbles in the data flow diagram are represented in the structure chart.
Consider the example in chapter 12 of Sommerville and make sure you understand it.
Autumn 1996 Week 3SEM510
12. Example of Data-Flow Diagram
thermocouple
convert to temperature
form temperature block
wind-speed guage
convert to speed
form wind block
pressure guage
convert to pressure
form pressure block
calculate statistics
print results
input output
central transforms
Autumn 1996 Week 3SEM510
13. First-level Factoring
1. introduce a top-level module 2. include one module for each central transform. 3. include one module for each bisected data-flow.
In the previous example there are 4 central transforms
3 input data flows and one output data flow. This gives a total of 9 modules, connected as shown
in the next slide.
Autumn 1996 Week 3SEM510
14. First-level Factoring.
Monitor
Get Temp
b
Print a Line
j
Get Wind Speed
e
Get Pressure
h
Form Temp Block
b
c
Form Wind Block
ef
Form Pressure Block
h
i
c
f
i
j
Calculate Statistics
denotes a predefined procedure
Autumn 1996 Week 3SEM510
15. Additional Factors Needed.
Get Temp
Get thermovolt
Convert to temp
a ab
Get Wind Speed
Get Wind Voltage
Convert to speed
dd
e
Get pressure
Get pressure voltage
convert to pressure
g gh
Autumn 1996 Week 3SEM510
16. Use of Data-Flow Diagrams.
These are required for large systems, not simple programming examples.
You will need to use these when you come to design your group projects.
You will need to use some or all of the methods we have discussed to obtain a clear definition of the project and then to split it in to sections which can be developed and tested independently.
Autumn 1996 Week 3SEM510
17. Requirements Definition
This is a statement of what the system is expected to provide.
It is often expressed as a mixture of natural language, tables and diagrams.
e.g. “write a computer program to calculate and print a histogram showing average marks for each computer science course”.
or “write a program to provide a word-processing system for the partially sighted”.
Autumn 1996 Week 3SEM510
18. Requirements Analysis
This establishes the services the system must provide and the constraints under which it must operate.
system services expected by the user are called “FUNCTIONAL REQUIREMENTS”.
The constraints under whoich it must operate and any standards which it must satisfy are called the “NON-FUNCTIONAL
REQUIREMENTS”. Both are important.
Autumn 1996 Week 3SEM510
19. Requirements Specification.
Once the analysis has been carried out, the requirements must be documented.
This activity is called “PROBLEM SPECIFICATION”.
A requirements specification is a statement of the problem
expressed as precisely as possible (use diagrams where suitable)
which sets out the system services in more detail probably in a more formal notation.
Autumn 1996 Week 3SEM510
20. Functional Specification.
These may include: 1. operation functions. e.g “move”, “delete”,
“change”, “save”, “scale”
2. Databases.
3. user interfaces. e.g. promts, menus, on-line help systems.
Autumn 1996 Week 3SEM510
21. Non-functional Specification.
this includes constraints which affect the system. e.g. volume requirements, such as the quantity of data or
users with which the system must cope. performance constraints. e.g. response time, size of
memory. operating constraints. e.g security and reliability. life-cycle constraints - relating to portability, ease of
maintenance etc. interface constraints. specified hardware and software on
which the system must run. other constraints. e.g user requires all information
expressed in ASCII character set.
Autumn 1996 Week 3SEM510
22. Requirements Validation.
basically “are we building the right product?” Seven Criteria to apply during valiadation process Are the requirements -
– 1. correct?
– 2. consistent?
– 3. complete?
– 4. realistic?
– 5. verifiable?
– 6. testable?
– 7. traceable?
Does each requirement describe something that is NEEDED by the customer?
Autumn 1996 Week 3SEM510
23. Consistency of requirements.
Requirements should not conflict with one another. Unlikely to be a problem with small programs. The large the system and the more people involved
in its design, the more care must be taken to avoid such inconsistencies.
e.g. In one place, it is stated that a maximum of 10 users may use the system at any one time.
Another requirement may generate the situation where there are 20 simultaneous users.
Such contradictions should be found and resolved before the system is written.
Autumn 1996 Week 3SEM510
24. Completeness of Requirements
The definition should include all functions and constraints intended by the system user.
Time should be taken to examine this. Additional questions may be asked. e.g. “what do you want the system to do if ----- ?”
Analyse all possible situations (however rarely they occur) and provide responses to deal with them.
e.g. in addition to the normal functions, a payroll system should allow for someone taking leave without pay etc.
Autumn 1996 Week 3SEM510
25. Feasability of Requirements.
No point in offering things which are not possible with existing hardware and software.
Allow for improvements in technology during the lifetime of a lengthy development time.
Give customer a choice - with your existing system, we can provide the following
If you buy the following extras, we can provide these improvements.
Don’t promise what you cannot deliver.
Autumn 1996 Week 3SEM510
26. Testability of Requirements.
Specify the conditions in such a way that you can test to see whether they have been satisfied or not.
e.g. “system shall provide a real-time response to queries” cannot be tested.
“system shall respond to queries in not more than 2 seconds” can be tested.
Similarly for all other descriptions.