Software Engineering: Analysis and Design - CSE3308

1. CSE3308/DMS/2002/5 Monash University - School of Computer Science and Software Engineering Software Engineering: Analysis and Design - CSE3308 Structured Analysis - Part 1

2. Lecture Outline • History of Structured Analysis • Context Diagrams • Event Lists • Data Flow Diagrams • Control Flows and Processes • Levelled Data Flow Diagrams

3. History of Structured Analysis (SA) • First texts appeared in 1977 • Tom de Marco - Structured Analysis and System Specification • Gane and Sarson - Structured Systems Analysis • 1984 - SA is extended • McMenamin and Palmer - Essential Structured Analysis • 1989 - SA reaches its peak • Yourdon publishes Modern Structured Analysis • Integrates Chen’s Entity-Relationship Models • 1991 Yourdon moves to Object-Oriented Analysis • 1995 38% of organisations used SA

4. Context Diagrams • Indicate the people, organisations and systems which communicate with our system • Show the data which our system receives from the outside world • Show the data produced by the system and sent to the outside world • Show the data which is shared by the system with the outside world • Show the boundary between the system and the rest of the world

5. Flights Constructing a Context Diagram • 4 components • The System • Terminators • also know as external entities • Data Flows • Data Stores Airline Booking System Customer reservation

6. Credit Card Data Airline Reservation System Customer Airline Request for reservation Flight confirmation Flight details Request for reservation Airline Reservation System Credit details Reports Transaction details Management Finance System

7. Guidelines for Context Diagrams Yes No • Use appropriate names • Don’t be too specific with names Customer Fred Flintstone Ready to send input Order Entry System Customer Okay, send input Here’s the input Great, I got the input

8. Guidelines (2) • Can have Dialogue Flows representing two-way data flow Flight status response Credit check request Finance System Airline Reservation System Customer Credit check response Flight status request • Duplicate terminators if necessary to simplify the diagram

9. Student Enrolment System • System • Student Enrolment system • Terminators • Student • University Management • University Staff • Data Stores • Student Results • Data Flows (7) • reports to management, enrolment details from student, confirmation of enrolment to student, payment details from staff, student lists to staff, student results from staff to system, student results from Student Results database to system

10. Your answer?

11. Event Lists • List of the external events that occur in the outside world which affect the system, i.e. events generated by terminators • Events can be • Flow - some data flows between the external world and the system • Temporal - an event occurs as a result of some timing • Control - special case of a temporal event, an external stimulus that occurs at some unpredictable point in time • Events are always viewed from the terminator’s point of view

12. Event examples • Customer places reservation (Flow) • Customer cancels reservation (Flow) • Accounting System receives transaction details (Flow) • Management requests weekly report (Temporal) • Airline confirms reservation (Temporal) • Credit card to be verified (Control)

13. Constructing the Event List • Examine each terminator in turn • Decide whether it generates a single event or possibly multiple events • Customer places order • Can be “Customer places order” and “Salesperson places order” • Need to allow for failure conditions on the part of the terminator, but no need to allow for system failures

14. Events • Look at a system which controls the sales of goods at a supermarket • Entities to think about • Cash register • Checkout Operator • Customer • Scanner • Receipt printer • What events can you identify?

15. Your answer?

16. Data Flow Diagrams • Extends the Context Diagram by defining the processes which make up a system • 4 components • Processes • Number - identifies process and indicates place in DFD level heirarchy • Name - what the process does • Part of system which transforms inputs to outputs • Data Flows • Data Stores • Terminators } as in context diagram

17. Data Flows • Indicate movement of packets of information from one part of the system to another part • Flows are named • Input flow • Output flow • Diverging flows - see next slide Validate Phone No. Phone No. Flight Schedule Information Generate Flight Schedule

18. Diverging Data Flows Order Customer Address Produce Valid Order Validate postcode Generate Shipping Docs Invalid orders postcode Order details phone no. Validate phone no. street address Update Inventory Generate Invoice Validate street address

19. Orders Customers Invoices Typical Figure 0 DFD Note:some analysts do notshow terminators on theFigure 0 DFD Customers Warehouse name,orders Order Order invalidorders 1. Receive Order books Note:physical flows 2. Ship Books Customer Invoice Customer books Customer Invoice 3. Collect Payment invoices, statements Customers payments, inquiries

20. An example • For the checkout operator example • What are the terminators? • What are the main processes? • What are the main data flows? • Draw a data flow diagram to put the above elements together

21. Your elements

22. Your DFD

23. Guidelines for constructing DFDs • Choose meaningful names • Number the processes • Redraw the DFD as many times as necessary for aesthetics • Avoid overly complex DFDs • Fit on one A4 page • approximately 6 processes and related data stores and terminators

24. Guidelines (2) • Make sure the DFD is internally consistent and consistent with any associated DFDs • Avoid infinite sinks - processes with inputs but no outputs • Avoid spontaneous generation processes - processes with outputs but no inputs (Possible exception is a random number generator) • Beware of unlabelled flows and processes • Beware read-only/write-only stores • Make sure that incoming and outgoing flows from the DFD match those on the DFD at the level above

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

26. Surveillance data Example Process Satellite Data satellite data satellite signal Control Surveillance System enable satellite processing radar signal enable radar processing Process Radar Data radar data

27. Doom Example Control Game enter playmode start playing startadministrating enteradministrationmode Play Game Administer Game Game Details

28. Leveled DFDs • Most systems are far too complex to depict on one DFD

29. Leveled DFDs (2) • Break each process down into sub-processes • Numbering of processes indicates their parents process, and thus their position in the hierarchy of levelled DFDs

30. Guidelines for Levelled DFDs • How many levels? • Each level should have approximately 6 processes • Simple systems: 2-3 levels • Medium size: 3-6 levels • Large size: 5-8 levels • All parts of the system may not need the same numbers of levels • Levels must be consistent with each other • 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

31. Balanced DFDs

32. An Unbalanced DFD Can you see the problem?

33. Data Stores and Levelled DFDs • Show the data store at all relevant levels

34. References • Yourdon, E., Modern Structured Analysis, Prentice Hall, 1989.