1. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 1 Function-oriented design Software Engineering Ian Sommerville Chapter 15, 5 th Edition

2. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 2 Objectives l To explain how a software design may be represented as a set of functions which share state l To introduce notations for function-oriented design l To illustrate the function-oriented design process by example l To compare sequential, concurrent and object- oriented design strategies

3. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 3 Topics covered l Data-flow design l Structural decomposition l Detailed design l A comparison of design strategies

4. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 4 Function-oriented design l Design with functional units which transform inputs to outputs l Practised informally since programming began l Thousands of systems have been developed using this approach l Supported directly by most programming languages l Most design methods are functional in their approach

5. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 5 A function-oriented view of design

6. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 6 Natural functional systems l Some systems are naturally function-oriented l Systems which maintain minimal state information i.e. where the system is concerned with processing independent actions whose outcomes are not affected by previous actions l Information sharing through parameter lists l Transaction processing systems fall into this category. Each transaction is independent

7. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 7 ATM software design loop Print_input_message (” Welcome - Please enter your card”) ; exit when Card_input ; end loop ; Account_number := Read_card ; Get_account_details (PIN, Account_balance, Cash_available) ; if Validate_card (PIN) then loop Print_operation_select_message ; case Get_button is when Cash_only => Dispense_cash (Cash_available, Amount_dispensed) ; when Print_balance => Print_customer_balance (Account_balance) ; when Statement => Order_statement (Account_number) ; when Check_book => Order_checkbook (Account_number) ; end case ; Eject_card ; Print (“Please take your card or press CONTINUE”) ; exit when Card_removed ; end loop ; Update_account_information (Account_number, Amount_dispensed) ; else Retain_card ; end if ; end loop ;

8. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 8 Functional and object-oriented design l For many types of application, object-oriented design is likely to lead to a more reliable and maintainable system l Some applications maintain little state – function- oriented design is appropriate l Standards and methods for functional design are well-established l Existing systems must be maintained – function- oriented design will be practised well into the future

9. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 9 Functional design process l Data-flow design Model the data processing in the system using data- flow diagrams l Structural decomposition Model how functions are decomposed to sub- functions using graphical structure charts l Detailed design The entities in the design and their interfaces are described in detail. These may be recorded in a data dictionary and the design expressed using a PDL

10. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 10 Topics covered l Data-flow design l Structural decomposition l Detailed design l A comparison of design strategies

11. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 11 Data flow diagrams l Show how an input data item is functionally transformed by a system into an output data item l Are an integral part of many design methods l May be translated into either a sequential or parallel design. In a sequential design, processing elements are functions or procedures; in a parallel design, processing elements are tasks or processes

12. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 12 DFD notation l Rounded rectangle - function or transform l Rectangle - data store l Circles - user interactions with the system l Arrows - show direction of data flow l keywords and/ or. Used to link data flows

13. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 13 Design report generator Sort entity names Get entity names Design database Get design name Design name Look up entity names Data dictionary Sort by type Entity names Sorted names Design entity descriptions Produce node report Produce link report Integrate reports Print report Link descriptions Node descriptions Integrated report Node report Link report and

14. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 14 Topics covered l Data-flow design l Structural decomposition l Detailed design l A comparison of design strategies

15. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 15 l Structural decomposition is concerned with developing a model of the design which shows the dynamic structure i.e. function calls l This is not necessarily the same as the static composition structure l The aim of the designer should be to derive design units which are highly cohesive and loosely coupled l In essence, a data flow diagram is converted to a structure chart Structural decomposition

16. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 16 Decomposition guidelines l For business applications, the top-level structure chart may have three functions namely input, process and output l Data validation functions should be subordinate to an input function l Coordination and control should be the responsibility of functions near the top of the hierarchy

17. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 17 Decomposition guidelines l Each node in the structure chart should have between two and seven subordinates l The aim of the design process is to identify loosely coupled, highly cohesive functions. Each function should therefore do one thing and one thing only Cohesion – the degree to which a module performs one and only one function. Coupling – the degree to which a module is connected to other modules in the system.

18. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 18 Coupling and cohesion

19. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 19 Process steps l Identify system processing transformations Transformations in the DFD which are concerned with processing rather than input/output activities. Group under a single function in the structure chart l Identify input transformations Transformations concerned with reading, validating and formatting inputs. Group under the input function l Identify output transformations Transformations concerned with formatting and writing output. Group under the output function

20. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 20 Initial structure chart

21. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 21 Expanded structure chart

22. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 22 Final structure chart Data dictionary Produce design reports Collate entities Generate report Get design entity names entity names sorted entity data names Get design name Get entity names Sort entities by name Get entity data Sort entities by type Produce integrated report Print report design name entity names report entity data design name names sorted names entity data sorted entity data sorted entity data Integrated report Design database design name entity name Produce link report Produce node report Link data Link report Node data Node report sorted entity data

23. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 23 Topics covered l Data-flow design l Structural decomposition l Detailed design l A comparison of design strategies

24. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 24 Detailed design l Concerned with producing a short design specification (minispec) of each function. This should describe the processing, inputs and outputs l These descriptions should be managed in a data dictionary l From these descriptions, detailed design descriptions, expressed in a PDL or programming language, can be produced

25. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 25 Data dictionary entries

26. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 26 Design entity information

27. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 27 Other traditional design practices l Stepwise refinement l Structured Systems Analysis and Structured Design (SSA/SD) l Jackson System Development (JSD)

28. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 28 Stepwise refinement l Creator: Niklaus Wirth l Historically, this is the first “design method”. l A top-down process of successive refinement of specifications. l Program construction consists of a sequence of refinement steps, where a task is divided into subtasks. l Strengths: Simplicity of the process. Stepwise nature encourages an orderly development of ideas and also a means of backtracking. l Weaknesses: Potential problems with top-down approach which decides on a particular hierarchy early in the project. Lack of a stopping rule. Duplication of lower-level units.

29. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 29 Top-down decomposition

30. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 30 Structured Systems Analysis and Structured Design (SSA/SD) l Creators: Ed Yourdon, Larry Constantine, Tom DeMarco. l Based on stepwise refinement. l SSA process: Construct initial DFD to provide top-level description of the problem (this is its context diagram). Elaborate this into a layered hierarchy of DFDs, supported by a data dictionary. l SD process: Use Transaction Analysis to divide the DFD into tractable units. Perform a Transform Analysis on the DFD for each transaction, producing a Structure Chart for that transaction. Merge the Structure Charts to create the basic implementation plans. Refine them to include any necessary error-handling, initialization, and other exceptions.

31. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 31 SSA/SD details l DFD decomposition Functional decomposition. Event-partitioning – a thread of actions associated with each event is identified and used to form a simple bubble in the DFD (like a use case). l Two purposes of DFDs Physical DFDs – describe system in terms of concrete objects (names, actual forms, etc.) Logical DFDs – more abstract terms for operations and data flow. l Heuristics for creating DFDs: Consider the inputs and outputs of the system. Work inwards from these. Label carefully – be careful with terms. Ignore exceptions and errors at this point. Don’t flowchart – too detailed.

32. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 32 SSA/SD details l Transaction analysis Identification of transactions that are involved in the problem as a whole. Components of a transaction: Event – triggers the transaction. Stimulus – how the system is informed of the event. Activity – what the system does as a result of the stimulus. Response – output of the system. Effect – impact of system’s output on its environment. l Transform analysis Transforms the DFD of a transaction into a Structure Chart. Start with the “central transform” the DFD bubble that lies at the center of input and output data flow. This becomes the top level of the chart. The inputs and outputs to the central transform form the next level of the chart.

33. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 33 SSA/SD transaction and transform analysis

34. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 34 Jackson System Development (JSD) l Creator: Michael Jackson. l Modeling stage – problem is analyzed and modeled in terms of constituent entities and the actions they perform. An entity is any object that is important to the system. Each entity has a set of actions to perform. Actions take place in the real world at a given point in time. l Network stage – overall structure of the system is developed by adding details of interactions between entities. Represented by a system specification diagram (shows processes and how they communicate with each other). l Implementation stage – the abstract design is mapped to a physical design. Represented by a system implementation diagram The system is represented as a scheduler that calls modules that implement the processes. Datastreams are represented as calls to inverted processes

35. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 35 Example: Entity structure diagram Book

36. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 36 Topics covered l Data-flow design l Structural decomposition l Detailed design l A comparison of design strategies

37. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 37 A comparison of design strategies l An example of an office information retrieval system (OIRS) is used to compare different design strategies l Functional design, concurrent systems design and object-oriented design are compared l The OIRS is an office system for document management. Users can file, maintain and retrieve documents using it

38. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 38 OIRS user interface Get document Put document Search database Add index Delete index Delete document Known indexesCurrent indexes Chapter 15 ‘SE BOOK’ Document name Documents4 documents in workspace QUIT CLEAR d informally since programming began but it was only in the late 1960s and early 1970s that it Operations NEWSTYLEQualifier

39. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 39 Description of UI elements l Operation field. Pull-down menu allowing an operation to be selected. l Known and current indexes fields Pull-down menus of indexes l Document name. Name under which the document is to be filed. l Qualifier field Pattern used in retrieval. l Current workspace Contains the documents currently being used. May be edited with word processor

40. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 40 OIRS inputs and outputs

41. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 41 Fetch-execute model procedure Interactive_system is begin loop Command := Get_command; if Command = “quit” then -- Make sure files etc. are closed properly Close_down_system ; exit ; else Input_data := Get_input_data ; Execute_command (Command, Input_data, Output_data) ; end if ; end loop ; end Interactive_system ;

42. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 42 Top-level OIRS DFD Get command Update database Document database Current workspace Execute Command Update workspace Current workspace Document database Put status message Status message

43. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 43 l What strategy should be adopted in decomposing Execute command? l Are the input and output data flows processed independently or are they inter-dependent. If independent, there should be a central transform for each processing unit l Is the central transform a series of transforms? If so, each logical element in the series should be a single transformation Design decisions

44. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 44 Execute command DFD

45. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 45 OIRS design procedure OIRS is begin User := Login_user ; Workspace := Create_user_workspace (User) ; -- Get the users own document database using the user id DB_id := Open_document_database (User) ; -- get the user’s personal index list; Known_indexes := Get_document_indexes (User) ; Current_indexes := NULL ; -- command fetch and execute loop loop Command := Get_command ; exit when Command = Quit ; Execute_command ( DB_id, Workspace, Command, Status) ; if Status = Successful then Write_success_message ; else Write_error_message (Command, Status) ; end if ; end loop ; Close_database (DB_id) ; Logout (User) ; end OIRS ;

46. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 46 l Data flow diagrams explicitly exclude control information. They can be implemented directly as concurrent processes. l Logical groups of transformations can also be implemented as concurrent processes e.g. input data collection and checking l The OIRS system can be implemented as a concurrent system with command input, execution and status reporting implemented as separate tasks Concurrent systems design

47. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 47 OIRS process decomposition

48. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 48 Detailed process design procedure Office_system is task Get_command ; task Process_command is entry Command_menu ; entry Display_indexes ; entry Edit_qualifier ; -- Additional entries here. One for each command end Process_commands ; task Output_message is entry Message_available ; end Output_message ; task Workspace_editor is entry Enter ; entry Leave ; end Workspace_editor ;

49. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 49 Detailed process design task body Get_command is begin -- Fetch/execute loop loop Cursor_position := Get_cursor_position ; exit when cursor positioned in workspace or (cursor positioned over menu and button pressed) Display_cursor_position ; end loop ; if In_workspace (Cursor_position) then Workspace_editor.Enter ; elsif In_command_menu (Cursor_position) then Process_command.Command_menu ; elsif In_Known_indexes (Cursor_position) then Process_command.Display_indexes ; elsif In_Current_indexes (Cursor_position) then... Other commands here... end loop ; -- Fetch/execute end Get_command ; -- other task implementations here end Office_system ;

50. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 50 Object-oriented design l An object-oriented design focuses on the entities in the system rather than the data processing activities l Simplified OOD here which illustrates a different decomposition

51. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 51 Initial object identification

52. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 52 New objects required l Workspace Corresponds to the user’s workspace and provides operations to add and remove documents from the workspace l Index list Provides facilities to manage a list of indexes l Document database Corresponds to the database of documents. provides search and retrieval operations

53. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 53 Additional OIRS objects

54. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 54 Object refinement l Retrieval system does not provide services. It coordinates other objects. It has only attributes l Documents and indexes are explicitly named l The individual command components have been bundled into a single attribute User command in Retrieval system l The User object has been replaced by the Display object

55. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 55 Modified OIRS objects

56. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 56 l Function-oriented design relies on identifying functions which transform inputs to outputs l Many business systems are transaction processing systems which are naturally functional l The functional design process involves identifying data transformations, decomposing functions into sub-functions and describing these in detail Key points

57. Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 57 Key points l Data-flow diagrams are a means of documenting end-to-end data flow. Structure charts represent the dynamic hierarchy of function calls l Data flow diagrams can be implemented directly as cooperating sequential processes l Functional and object-oriented design result in different system decompositions. However, a heterogeous approach to design is often necessary