1. Data-flow diagrams. - PowerPoint PPT Presentation

Loading...

PPT – 1. Data-flow diagrams. PowerPoint presentation | free to download - id: ef0c9-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

1. Data-flow diagrams.

Description:

A graphical technique which depicts the information flow and the transforms ... c) one complete segment (procedure, function etc. ... 1. Afferent units. ... – PowerPoint PPT presentation

Number of Views:41
Avg rating:3.0/5.0
Slides: 27
Provided by: scie205
Learn more at: http://www.cs.bham.ac.uk
Category:
Tags: afferent | data | diagrams | flow

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 1. Data-flow diagrams.


1
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
2. Notation used in Data-flow diagrams.
external entity.
or
provider or user of information outside the
system being modelled
or
user interaction
transformer of information lying inside the
system.
process.
or
single data item or collection of data items.
arrow indicates direction of flow.
data item.
repository of data stored for use by one or more
processes.
data store.
or
3
3. Simple Data-flow diagram.
compare guess with code
when correct, output message and stop
input next guess
compare guess with code
input next guess
when correct, output message and stop
4
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
5. Structure Charts.
  • Show the hierarchical component structure of a
    system.

input
output
functional component.
hierarchy
user inputs
data stores
6
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
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
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
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
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
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
12. Example of Data-Flow Diagram
thermocouple
convert to temperature
form temperature block
wind-speed guage
calculate statistics
convert to speed
form wind block
pressure guage
print results
convert to pressure
form pressure block
input
output
central transforms
13
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
14. First-level Factoring.
Monitor
b
j
c
Get Temp
b
e
h
j
h
f
Print a Line
e
c
f
Get Wind Speed
i
i
Form Temp Block
Form Pressure Block
Get Pressure
Calculate Statistics
Form Wind Block
denotes a predefined procedure
15
15. Additional Factors Needed.
Get Wind Speed
Get Temp
b
d
e
a
a
d
Get thermovolt
Get Wind Voltage
Convert to temp
Convert to speed
Get pressure
h
g
g
Get pressure voltage
convert to pressure
16
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
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
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
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
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
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
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
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
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
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.
  • Dont promise what you cannot deliver.

26
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.
About PowerShow.com