CSE 3308DMS200510 Monash University School of Computer Science

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

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

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 Mc. Menamin 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 Since 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 CSE 3308 - Software Engineering: Analysis and Design, 2005 Lecture 4 A. 3

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 CSE 3308 - Software Engineering: Analysis and Design, 2005 Lecture 4 A. 4

Constructing a Context Diagram Four components The System Terminators » also know as external entities Data Flows Data Stores CSE 3308 - Software Engineering: Analysis and Design, 2005 ( or Lecture 4 A. 5 )

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

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

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

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 CSE 3308 - Software Engineering: Analysis and Design, 2005 Lecture 4 A. 9

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

Constructing the Event List Examine each terminator, and ask what effects the terminator’s actions can have on the system Take care to distinguish between separate events coincidently “packaged” together in the requirements specification Event “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 Need to allow for failure conditions on the part of the terminator, but no need to allow for system failures CSE 3308 - Software Engineering: Analysis and Design, 2005 Lecture 4 A. 11

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? CSE 3308 - Software Engineering: Analysis and Design, 2005 Lecture 4 A. 12

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

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

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

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

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 CSE 3308 - Software Engineering: Analysis and Design, 2005 Lecture 4 A. 17

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

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

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

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 A 4 page approximately 6 -7 processes and related data stores and terminators CSE 3308 - Software Engineering: Analysis and Design, 2005 Lecture 4 A. 21

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 CSE 3308 - Software Engineering: Analysis and Design, 2005 Lecture 4 A. 22

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 CSE 3308 - Software Engineering: Analysis and Design, 2005 Lecture 4 A. 23

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

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

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

Levelled 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 CSE 3308 - Software Engineering: Analysis and Design, 2005 Lecture 4 A. 27

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 CSE 3308 - Software Engineering: Analysis and Design, 2005 Lecture 4 A. 28

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

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

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

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