1. Elements of Software Analysis and Design - Structured Approaches - Structured Analysis - Functional Oriented Design 10/24/2015ICS 413 – Software Engineering1

2. 2 Introduction Function-oriented design techniques are very popular: – currently in use in many software development organizations. Function-oriented design techniques: – start with the functional requirements specified in the SRS document. 10/24/2015ICS 413 – Software Engineering

3. 3 Introduction During the design process: – high-level functions are successively decomposed: into more detailed functions. – finally the detailed functions are mapped to a module structure. 10/24/2015ICS 413 – Software Engineering

4. 4 Introduction Successive decomposition of high- level functions: – into more detailed functions. – Technically known as top-down decomposition. 10/24/2015ICS 413 – Software Engineering

5. 5 Introduction SA/SD methodology: – has essential features of several important function-oriented design methodologies --- if you need to use any specific design methodology later on, you can do so easily with small additional effort. 10/24/2015ICS 413 – Software Engineering

6. 6 SA/SD (Structured Analysis/Structured Design) SA/SD technique draws heavily from the following methodologies: – Constantine and Yourdon's methodology – Hatley and Pirbhai's methodology – Gane and Sarson's methodology – DeMarco and Yourdon's methodology SA/SD technique can be used to perform – high-level design. 10/24/2015ICS 413 – Software Engineering

7. 7 Overview of SA/SD Methodology SA/SD methodology consists of two distinct activities: – Structured Analysis (SA) – Structured Design (SD) During structured analysis: – functional decomposition takes place. During structured design: – module structure is formalized. 10/24/2015ICS 413 – Software Engineering

8. 8 Functional decomposition Each function is analyzed: – hierarchically decomposed into more detailed functions. – simultaneous decomposition of high- level data into more detailed data. 10/24/2015ICS 413 – Software Engineering

9. 9 Structured analysis Transforms a textual problem description into a graphic model. – done using data flow diagrams (DFDs). – DFDs graphically represent the results of structured analysis. 10/24/2015ICS 413 – Software Engineering

10. 10 Structured design All the functions represented in the DFD: – mapped to a module structure. The module structure: – also called as the software architecture: 10/24/2015ICS 413 – Software Engineering

11. 11 Detailed Design Software architecture: – refined through detailed design. – Detailed design can be directly implemented: using a conventional programming language. 10/24/2015ICS 413 – Software Engineering

12. 12 Structured Analysis vs. Structured Design Purpose of structured analysis : – capture the detailed structure of the system as the user views it. Purpose of structured design: – arrive at a form that is suitable for implementation in some programming language. 10/24/2015ICS 413 – Software Engineering

13. 13 Structured Analysis vs. Structured Design The results of structured analysis can be easily understood even by ordinary customers: – does not require computer knowledge – directly represents customer’s perception of the problem – uses customer’s terminology for naming different functions and data. The results of structured analysis can be reviewed by customers: – to check whether it captures all their requirements. 10/24/2015ICS 413 – Software Engineering

14. 14 Structured Analysis Based on principles of: – Top-down decomposition approach. – Divide and conquer principle: each function is considered individually (i.e. isolated from other functions) decompose functions totally disregarding what happens in other functions. – Graphical representation of results using data flow diagrams (or bubble charts). 10/24/2015ICS 413 – Software Engineering

15. Function-oriented design Design with functional units which transform inputs to outputs 10/24/2015ICS 413 – Software Engineering15

16. Objectives To explain how a software design may be represented as a set of functions which share state To introduce notations for function-oriented design To illustrate the function-oriented design process by example To compare sequential, concurrent and object-oriented design strategies 10/24/2015ICS 413 – Software Engineering16

17. Topics covered data-flow design Structural decomposition Detailed design A comparison of design strategies 10/24/2015ICS 413 – Software Engineering17

18. Function-oriented design Practiced informally since programming began Thousands of systems have been developed using this approach Supported directly by most programming languages Most design methods are functional in their approach CASE tools are available for design support 10/24/2015ICS 413 – Software Engineering18

19. A function-oriented view of design 10/24/2015ICS 413 – Software Engineering19

20. Natural functional systems Some systems are naturally function-oriented 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 Information sharing through parameter lists Transaction processing systems fall into this category. Each transaction is independent 10/24/2015ICS 413 – Software Engineering20

21. 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 ; ©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 15Slide 7 10/24/2015ICS 413 – Software Engineering21

22. Functional and object-oriented design For many types of application, object-oriented design is likely to lead to a more reliable and maintainable system Some applications maintain little state - function-oriented design is appropriate Standards, methods and CASE tools for functional design are well-established Existing systems must be maintained - function-oriented design will be practiced well into the 21st century 10/24/2015ICS 413 – Software Engineering22

23. Functional design process Data-flow design – Model the data processing in the system using data- flow diagrams Structural decomposition – Model how functions are decomposed to sub- functions using graphical structure charts 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/24/2015ICS 413 – Software Engineering23

24. Structured Systems Analysis and Structured Design (SSA/SD) Creators: Ed Yourdon, Larry Constantine, Tom DeMarco. Based on stepwise refinement. 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. 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. 10/24/2015ICS 413 – Software Engineering24

25. SSA/SD details 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). 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. 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. 10/24/2015ICS 413 – Software Engineering25

26. SSA/SD details 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. 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. 10/24/2015ICS 413 – Software Engineering26

27. SSA/SD transaction and transform analysis 10/24/2015ICS 413 – Software Engineering27