Function-oriented Design

1
Function-oriented Design
Andrew Ireland School of Mathematical Computer
Sciences Heriot-Watt University Edinburgh
2
Outline

• Motivations
• Data flow
• Structuring
• Detailed design

3
Motivations

• Many significant software systems fall into this
  classification, e.g. transaction processing

• Many legacy applications were developed using
• function-oriented design

4
Function-oriented Design

• Applicability
• Minimal system state
• Information is typically communicated via
  parameters or shared memory
• No temporal aspect to functions, i.e. the result
  of a function invocation is not dependent upon
  the functions earlier invocations
• Approach
• Promotes a top-down functional decomposition
  style of design

5
Function-oriented Activities

• Data flow design
• Model data flow through the system as a set of
  data flow diagrams
• Structural decomposition
• Model the functionality of the system as a
  hierarchy of sub-functions via the structure
  chart notation
• Detailed design
• Provide detailed data and functional
  descriptions, typically supported by the notion
  of a data dictionary

6
Data Flow Diagrams

• Data Flow Diagrams (DFDs) are used to represent
  the flow of information through a system, i.e.
  how the system outputs are derived by the
  functional transformation of input data sources
• DFDs are used within many design methods and are
  supported by numerous computer assisted software
  engineering (CASE) tools
• No standard notation

7
DFD Notation
User interaction with the system, i.e.
input/output

Data store, e.g. database, files, etc
System function/operation/process
Labelled data flow
Note data flows can be combined logically, i.e.
and/or
8
Example Regression Testing
Testing that code modifications have not
regressed the correctness of the system as a
whole Also as a consequence of the
introduction of new bugs, program maintenance
requires far more system testing per statement
written than any other programming.
Theoretically, after each fix one must run the
entire batch of test cases previously run against
the system, to ensure that it has not been
damaged in an obscure way. In practice, such
regression testing must indeed approximate this
theoretical idea, and it is very costly." Fred
Brooks, The Mythical Man Month (p 122)
9
Example Regression Testing

• Consider the following system requirements
• A user provides a name for a source code base
• If valid, then the source code base is retrieved
  from a database along with its associated
  regression test suit, which is held in a separate
  database
• The source code is executed against the
  regression tests
• The test results are compared against the
  expected results, which are held in another
  database
• If actual and expected results differ then a
  report is generated for the user, else a
  certificate is generated for the user
• A log file summarizing the regression testing
  stored in a database

10
DFD Example
l_file
Regression test db
Source code db
Gen Log
s_file
r_res
report
t_file
a_res
Test case db
Gen reports
and
Run tests
Compare
r_res
id
r_file
id
Gen reports
or
Validate
c_file
e_file
Expected results db
certif
Gen certifs
Data flow
11
Exercise Wanted Persons

• Consider the following system requirements
• A user provides facial features based upon crime
  reports
• If valid, then the feature list is used to
  retrieve a list of relevant feature templates
  from a database. If the feature list is not valid
  then an error message is sent to the user
• The feature template list is used to search for
  matching offender imagines which are stored
  within an offender records database
• Any records for offenders already in prison are
  then pruned
• From pruned list, a suspect list is dispatched to
  the user, while the corresponding records are
  sent to a wanted persons database
• Exercise construct a DFD for the requirements
  above

12
Exercise Wanted Persons

• Consider the following system requirements
• A user provides facial features based upon crime
  reports
• If valid, then the feature list is used to
  retrieve a list of relevant feature templates
  from a database. If the feature list is not valid
  then an error message is sent to the user
• The feature template list is used to search for
  matching offender imagines which are stored
  within an offender records database
• Any records for offenders already in prison are
  then pruned
• From pruned list, a suspect list is dispatched to
  the user, while the corresponding records are
  sent to a wanted persons database
• Exercise construct a DFD for the requirements
  above

13
DFD Example
feature list
features
error-msg
validate features
get feature list
or
feature list
templates
feature template db
filter templates
template list
images
offender image db
match images
suspect list
images
and
prison records db
records
extract suspects
records
wanted persons db
14
Hierarchical DFDs

• As system complexity grows, so will the DFDs
• Hierarchical, or layered, DFDs provide a way of
  managing this complexity, i.e.
• Firstly, a Context Diagram (Level 0) is used to
  model the system as a single system process
  together with the environment in which it
  operates, e.g. users and external data stores
• Then, Level 1, 2, 3 DFDs are developed, which
  model the systems sub-processes

15
A Context Diagram (Level 0)
0
16
Level 1 DFD
1
2
17
Level 2 DFD
1.1
1.2
2.1
2.2
18
Structural Decomposition

• For a given DFD there will exist choices as to
  how it is implemented
• The structure chart notation provides a means of
  adding more structure to the design
• Each function (or procedure) is represented as a
  rectangle
• A high-level function is represented as a
  hierarchy of sub-functions
• Links between sub-functions are labelled with
  input/output data, i.e. parameters or shared data

19
Structural Decomposition
y
x
y
y
A
A
A
A
x
x
x
x
input
output
transform
Co-ordinate
20
Structural Decomposition

• Note that a structure chart shows the
  relationship between sub-functions, but not the
  order in which they are invoked
• Typically a series of structure charts are
  developed for a given DFD incrementally
  expanding level by level, e.g.

A
A
z
x
z
x
B
C
B
C
x
v
r
t
u
s
D
E
F
21
Structural Decomposition
A
C
D
B
E
F
G
H
I
J
K
output
process
input
22
Structural Decomposition
decision making
A
C
D
B
E
F
G
H
I
J
K
data processing
23
Structure Chart First
Regression tester
id
res
id
res
Initialize
Report
Test
Source code
Test cases
Expected results
Source code id

• Regression results
• regression log
• defect report
• certificate

24
Structure Chart Second
Regression tester
id
r_res
id
r_res
Initialize
Report
Test
id
r_res
r_res
r_res
id
id
res
a_res
Validate
Run tests
Compare
Logger
Generator
Source code
Test cases
Expected results
Regression log
Defect report
Certificate
25
Structure Chart Third
Regression tester
id
r_res
id
r_res
Initialize
Report
Test
id
r_res
r_res
r_res
id
id
res
a_res
Validate
Run tests
Compare
Logger
Generator
l_file
r_file
c_file
s_file
t_file
e_file
Gen cert
Gen report
Source code db
Test case db
Expected results db
report
cert
Regression test db
26
Detailed Design

• Detailed design involves getting inside the
  functional blocks represented with the structure
  chart notation
• At this level, Process Description Languages
  (PDL), i.e. pseudo code
• A useful intermediate representation is a Data
  Dictionary (DD) a structured, but informal,
  record of data items and functional
• DDs are useful to designers, programmers as well
  as during maintenance

27
Example Data Dictionary
Entity Type Description
id string Name of the source code base under test
res boolean The result of validating the name of the source code base provided by the user

r_res vector The regression test results, i.e. the actual results vs expected results
a_res vector The actual results obtained by executing the code base against the regression tests
test procedure Input name of source code base Function co-ordinates the execution of the regression tests and the comparison with the expected results Output results of regression testing

28
Sequential vs Concurrent

• Note that no explicit reference has been made as
  to how a design is implemented, i.e. sequential
  vs concurrent
• DFDs in particular do not impose a control
  paradigm
• A DFD representation of a function could be
  implemented as a
• sequence of sub-function invocations or
• set of communicating processes

29
Summary

• Learning outcomes
• Applicability of function-oriented design
• Data flow and DFDs
• Structure charts and functional hierarchy
• Detailed design and data dictionaries
• Recommended reading
• D. Budgen, Software Design, Addison-Wesley 2003
• I. Sommerville, Software Engineering,
  Addison-Wesley 2007