1. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.1 Software Engineering: Analysis and Design - CSE3308 Structured Analysis - Part 1 CSE3308/DMS/2005/10 Monash University - School of Computer Science and Software Engineering

2. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.2 Lecture Outline u History of Structured Analysis u Context Diagrams u Event Lists u Data Flow Diagrams u Control Flows and Processes u Levelled Data Flow Diagrams

3. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.3 History of Structured Analysis (SA) u First texts appeared in 1977 v Tom de Marco - Structured Analysis and System Specification v Gane and Sarson - Structured Systems Analysis u 1984 - SA is extended v McMenamin and Palmer - Essential Structured Analysis u 1989 - SA reaches its peak v Yourdon publishes Modern Structured Analysis v Integrates Chen’s Entity-Relationship Models u 1991 Yourdon moves to Object-Oriented Analysis u 1995 38% of organisations used SA vSince much — if not most — expenditure of software organizations is on maintenance, there is still a lot of work being done on systems produced using SA, and coded in languages such as Fortran, COBOL and C

4. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.4 Context Diagrams u Indicate the people, organisations and systems which communicate with our system u Show the data which our system receives from the outside world u Show the data produced by the system and sent to the outside world u Show the data which is shared by the system with the outside world u Show the boundary between the system and the rest of the world

5. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.5 ( or ) Constructing a Context Diagram u Four components vThe System vTerminators » also know as external entities vData Flows vData Stores Students

6. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.6 CD for Student Enrolment System

7. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.7 Guidelines for Context Diagrams u Use appropriate names u Don’t be too specific with names Student Fred Flintstone YesNo Student Enrolment System Ready to send input Okay, send input Here’s the input Great, I got the input

8. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.8 Guidelines (2) u Can have Dialogue Flows representing two- way data flow Student Enrolment System Finance System Check fees paid fees check response u Duplicate terminators if necessary to simplify the diagram

9. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.9 Event Lists u List of the external events that occur in the outside world which affect the system, i.e. events generated by terminators u Events can be v Flow - some data flows between the external world and the system v Temporal - an event occurs as a result of some timing v Control - special case of a temporal event, an external stimulus that occurs at some unpredictable point in time u Events are always viewed from the terminator’s point of view

10. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.10 Event examples u Student enrolls in subject (Flow) u Administrator creates subject (Flow) u Administrator receives student transcript (Flow) u Subject creation is disabled because semester starts in one month (Temporal) vThere is no control event in this list since they are unusual in business systems. They are, however, common in real-time systems (see slide 4A.23)

11. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.11 Constructing the Event List u Examine each terminator, and ask what effects the terminator’s actions can have on the system u Take care to distinguish between separate events coincidently “packaged” together in the requirements specification vEvent “Customer places order” might in fact be both “Customer places order” and “Salesperson places customer order” »Clue could be different data present in the two cases u Need to allow for failure conditions on the part of the terminator, but no need to allow for system failures

12. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.12 Events u Look at a system which controls the sales of goods at a supermarket u Entities to think about vCash register vCheckout Operator vCustomer vScanner vReceipt printer u What events can you identify?

13. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.13 Your answer?

14. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.14 Data Flow Diagrams u Extends the Context Diagram by defining the processes which make up a system u 4 components vProcesses »A process is a part of the system that transforms inputs to outputs. It has: n Number - identifies process and indicates place in DFD level hierarchy n Name - what the process does vData Flows vData Stores vTerminators as in Context Diagram }

15. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.15 u Indicate movement of packets of information from one part of the system to another part u Flows are named vInput flow vOutput flow vDiverging flows - see next slide Data Flows Validate Phone No. Phone No. Generate Flight Schedule Flight Schedule Information

16. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.16 Diverging Data Flows Validate postcode Validate phone no. Validate street address personal-details postcode phone no. street address Produce Valid Order Generate Invoice Update Inventory Generate Shipping Docs Order Invalid orders Order details

17. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.17 Typical Figure 0 DFD Note: some analysts do not show terminators on the Figure 0 DFD Note: some flows may be physical, such as the student-transcript

18. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.18 An example u For the checkout operator example vWhat are the terminators? vWhat are the main processes? vWhat are the main data flows? u Draw a data flow diagram to put the above elements together

19. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.19 Your elements

20. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.20 Your DFD

21. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.21 Guidelines for constructing DFDs u Choose meaningful names u Number the processes u Redraw the DFD as many times as necessary for aesthetics u Avoid overly complex DFDs v Fit on one A4 page v approximately 6-7 processes and related data stores and terminators

22. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.22 Guidelines (2) u Make sure the DFD is internally consistent and consistent with any associated DFDs v Avoid infinite sinks - processes with inputs but no outputs v Avoid spontaneous generation processes - processes with outputs but no inputs (possible exception is a random number generator) v Beware of unlabelled flows and processes v Beware read-only/write-only stores v Make sure that incoming and outgoing flows from the DFD match those on the DFD at the level above

23. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.23 Control Flows and Processes u Real-time systems need a means to model control (signals/interrupts) u Shown with dashed lines and circles u A control flow can be regarded as a binary signal - does not carry value-bearing data u Used to trigger/wake-up a dormant process u Internal behaviour of a control process described by a state-transition diagram u Generally one control process in a DFD u inputs and outputs of control process consist only of control flows

24. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.24 Example Control Surveillance System Process Radar Data Process Satellite Data Surveillance data radar data satellite data enable satellite processing enable radar processing satellite signal radar signal

25. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.25 Action Game Example Administer Game Play Game Game Details Control Game start administrating start playing enter administration mode enter play mode

26. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.26 Levelled DFDs u Most systems are far too complex to depict on one DFD

27. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.27 Levelled DFDs (2) u Break each process down into sub-processes u Numbering of processes indicates their parents process, and thus their position in the hierarchy of levelled DFDs

28. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.28 Guidelines for Levelled DFDs u How many levels? v Each level should have approximately 6 processes v Simple systems: 2-3 levels v Medium size: 3-6 levels v Large size: 5-8 levels u All parts of the system may not need the same numbers of levels u Levels must be consistent with each other v Data flows coming into and going out of a process at one level must correspond to the data flows coming into and out of the entire figure at the next lower level - this is known as balancing

29. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.29 Balanced DFDs

30. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.30 Unbalanced DFDs Can you see the problems?

31. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.31 Data Stores and Levelled DFDs Show datastores at every level at which they are used

32. CSE3308 - Software Engineering: Analysis and Design, 2005Lecture 4A.32 References u Yourdon, E., Modern Structured Analysis, Prentice Hall, 1989. vThere is now a condensed edition, called Just Enough Structured Analysis, available online via the Resources page on the unit web site.