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 function’s 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 and or Data flow l_file Regression test db s_file r_res
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. 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 system’s sub-processes

13. A Context Diagram (Level 0)

14. Level 1 DFD 1 2

15. Level 2 DFD
1.1
1.2
2.1
2.2

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

17. Structural Decompositiony x y y A A A A x x x x
input
output
transform
Co-ordinate

18. 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 z x x B C B C x v r t u s D E F

19. Structural DecompositionB E F G H I J K
input
process
output

20. Structural Decomposition
decision
making A C D B E F G H I J K
data
processing

21. Structure Chart: First
Regression tester id
res id
res
Initialize
Test
Report
Source code id
Source code
Test cases
Expected results
Regression results:
regression log
defect report
certificate

22. Structure Chart: Second
Regression tester id
r_res id
r_res
Initialize
Test
Report 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

23. Structure Chart: Third
Regression tester id
r_res id
r_res
Initialize
Test
Report id
r_res
r_res
r_res id id
res
a_res
Validate
Run tests
Compare
Logger
Generator
l_file
s_file
t_file
e_file
r_file
c_file
Gen report
Gen cert
Source code db
Test case db
Expected results db
report
cert
Regression test db

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

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

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

27. Summary Learning outcomes: Recommended reading:
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