Autumn 1996 Week 3 SEM510 1. Data-flow diagrams. u A graphical technique which depicts the...

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.


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


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


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.


5. Structure Charts.

Show the hierarchical component structure of a system.

functional component.

hierarchy

inputoutput

data stores user inputs


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.


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.


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.


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.


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.


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.


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


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.


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


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


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.


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”.


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.


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.


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.


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.


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?


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.


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.


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.


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.

Autumn 1996 Week 3 SEM510 1. Data-flow diagrams. u A graphical technique which depicts the...

Documents

Transcript of Autumn 1996 Week 3 SEM510 1. Data-flow diagrams. u A graphical technique which depicts the...