Functionoriented Design Andrew Ireland School of Mathematical Computer

Function-oriented Design Andrew Ireland School of Mathematical & Computer Sciences Heriot-Watt University Edinburgh Software Design F 28 SD 2 © Andrew Ireland

Outline • • Motivations Data flow Structuring Detailed design Software Design F 28 SD 2 © Andrew Ireland

Motivations • Many significant software systems fall into this classification, e. g. transaction processing • Many legacy applications were developed using function-oriented design Software Design F 28 SD 2 © Andrew Ireland

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 Software Design F 28 SD 2 © Andrew Ireland

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 Software Design F 28 SD 2 © Andrew Ireland

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 Software Design F 28 SD 2 © Andrew Ireland

DFD Notation User interaction with the system, i. e. input/output Data store, e. g. database, files, etc System function or sub-function Labelled data flow Note: data flows can be combined logically, i. e. and/or Software Design F 28 SD 2 © Andrew Ireland

Example: Regression 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) Software Design F 28 SD 2 © Andrew Ireland

Example: Regression Testing Consider the following system requirements: 1. A user provides a name for a source code base 2. 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 3. The source code is executed against the regression tests 4. The test results are compared against the expected results, which are held in another database 5. If actual and expected results differ then a report is generated for the user, else a certificate is generated for the user 6. A log file summarizing the regression testing stored in a database Software Design F 28 SD 2 © Andrew Ireland

DFD Example l_file Source code db Gen Log s_file r_res Test case db t_file Run tests a_res Compare and report r_res id id Gen reports Validate Expected results db Gen reports Regression test db e_file r_file or c_file Gen certifs certif Data flow Software Design F 28 SD 2 © Andrew Ireland

Exercise: Wanted Persons Consider the following system requirements: 1. A user provides facial features based upon crime reports 2. 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 3. The feature template list is used to search for matching offender imagines which are stored within an offender records database 4. Any records for offenders already in prison are then pruned 5. 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 Software Design F 28 SD 2 © Andrew Ireland

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 Software Design F 28 SD 2 © Andrew Ireland

Structural Decomposition y A y x A x y A x input Software Design F 28 SD 2 output A x transform x Co-ordinate © Andrew Ireland

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. x B A z C A x x B v Software Design F 28 SD 2 C r u D z E s t F © Andrew Ireland

Structural Decomposition A C B E F G D H I J K input Software Design F 28 SD 2 process output © Andrew Ireland

Structural Decomposition decision making A C B E data processing Software Design F 28 SD 2 F G D H I J K © Andrew Ireland

Structure Chart: First Regression tester id res id Initialize Source code id Software Design F 28 SD 2 res Test Source code Test cases Report Expected results Regression results: • regression log • defect report • certificate © Andrew Ireland

Structure Chart: Second Regression tester id id Initialize id id id res Validate r_res Test a_res Run tests Source code r_res Test cases Report r_res Compare r_res Logger Generator Expected results Regression log Software Design F 28 SD 2 r_res Defect report Certificate © Andrew Ireland

Structure Chart: Third Regression tester id id Initialize id id res s_file Source code db r_res Test id Validate r_res Report r_res a_res Run tests t_file Test case db r_res Compare e_file r_res Logger Generator l_file r_file Gen report Expected results db report c_file Gen cert Regression test db Software Design F 28 SD 2 © Andrew Ireland

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 Software Design F 28 SD 2 © Andrew Ireland

Example: Data Dictionary Entity Type id string res boolean … … 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 … Software Design F 28 SD 2 Description Name of the source code base under test The result of validating the name of the source code base provided by the user … 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 … … © Andrew Ireland

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 Software Design F 28 SD 2 © Andrew Ireland

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 Software Design F 28 SD 2 © Andrew Ireland