Chapter 7 n Requirements Modeling Flow Behavior Patterns

Chapter 7 n Requirements Modeling: Flow, Behavior, Patterns, and Web. Apps Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman For non-profit educational use only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is prohibited without the express written permission of the author. All copyright information MUST appear if these slides are posted on a website for student use. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 1

After my discussion of last chapter in Chapter 6, it’s reasonable to ask, “Aren’t those requirements modeling representations enough? ” The only reasonable answer is, “That depends. ” These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 2

For some types of software, the use case may be the only requirements modeling representation that is required. For others, an object-oriented approach is chosen and class-based models may be developed. But in other situations, complex application requirements may demand an examination of how an application behaves as a consequence of external events; These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 3

What is it? The requirements model has many different dimensions. In this chapter you’ll learn about flow oriented models, behavioral models, and…. Each of these modeling representations supplements the use cases, data models, and class based models discussed in Chapter 6. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 4

Why is it important? Your insight into software requirements grows in direct proportion to the number of different requirements modeling dimensions. Although you may not have the time, the resources, or the inclination to develop every representation suggested in this chapter and Chapter 6, recognize that each different modeling approach provides you with a different way of looking at the problem. As a consequence, you (and other stakeholders) will be better able to assess whether you’ve properly specified what must be accomplished. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 5

Flow-Oriented Modeling n n n Represents how data objects are transformed at they move through the system data flow diagram (DFD) is the diagrammatic form that is used Considered by many to be an “old school” approach, but continues to provide a view of the system that is unique —it should be used to supplement other analysis model elements These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 6

The Flow Model Every computer-based system is an information transform. . input computer based system These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. output 7

Flow Modeling Notation external entity process data flow data store These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 8

External Entity A producer or consumer of data Examples: a person, a device, a sensor Another example: computer-based system Data must always originate somewhere and must always be sent to something These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 9

Process A data transformer (changes input to output) Examples: compute taxes, determine area, format report, display graph Data must always be processed in some way to achieve system function These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 10

Data Flow Data flows through a system, beginning as input and transformed into output. base height compute triangle area These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 11

Data Stores Data is often stored for later use. sensor # report required look-up sensor data sensor number sensor #, type, location, age sensor data These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 12

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 13

Creating Data Flow Diagrams Lemonade Stand Example

Creating Data Flow Diagrams Example The operations of a simple lemonade stand will be used to demonstrate the creation of dataflow diagrams. Steps: 1. Create a list of activities • Old way: no Use-Case Diagram • New way: use Use-Case Diagram 2. Construct Context Level DFD (identifies sources and sink) 3. Construct Level 0 DFD (identifies manageable sub processes ) 4. Construct Level 1 - n DFD (identifies actual data flows and data stores )

Creating Data Flow Diagrams Example 1. Create a list of activities Think through the activities that take place at a lemonade stand. Customer Order Serve Product Collect Payment Produce Product Store Product

Creating Data Flow Diagrams Example 1. Create a list of activities Also think of the additional activities needed to support the basic activities. Customer Order Serve Product Collect Payment Produce Product Store Product Order Raw Materials Pay for Labor

Creating Data Flow Diagrams Example 1. Create a list of activities Group these activities in some logical fashion, possibly functional areas. Customer Order Serve Product Collect Payment Produce Product Store Product Order Raw Materials Pay for Labor

Creating Data Flow Diagrams Example Create a context level diagram identifying the sources and sinks (users). 2. Construct Context Level DFD (identifies sources and sink) Context Level DFD Order Customer Order Serve Product Collect Payment Produce Product Store Product Order Raw Materials Pay for Labor CUSTOME R Product Served 0. 0 Lemona de System Payment Received Goods Payment Sales Forecast Production EMPLOYE Schedule E Pay Time Worked Purchase Order VENDOR

Creating Data Flow Diagrams Example Create a level 0 diagram identifying the logical subsystems that may exist. 3. Construct Level 0 DFD (identifies manageable sub processes ) Level 0 DFD 1. 0 Sale Customer Order Serve Product Collect Payment CUSTOME R Produce Product Store Product Order Raw Materials Pay for Labor Sales Forecast Customer Order Product Ordered Payment 2. 0 Production Producti Schedule Product Served on Received Goods VENDOR Purchase Order EMPLOYE E Inventory 3. 0 Procurement Payment Order Decisions Pay 4. 0 Payroll Time Worked

Creating Data Flow Diagrams Example Create a level 1 decomposing the processes in level 0 and identifying data stores. 4. Construct Level 1 - n DFD (identifies actual data flows and data stores ) Level 1 DFD CUSTOME R Customer Order Serve Product Collect Payment Produce Product Store Product Order Raw Materials Pay for Labor ORDER 1. 1 Record Order Severed Order Payment 1. 2 Receive Paymen t PAYMENT Request for Forecast 1. 3 Produce Sales Forecast

Creating Data Flow Diagrams Example Create a level 1 decomposing the processes in level 0 and identifying data stores. 4. Construct Level 1 (continued) Level 1 DFD Product Order ORDER Customer Order Serve Product Collect Payment Produce Product Store Product Order Raw Materials Pay for Labor 2. 1 Serve Product Quantity Severed RAW MATERIALS Production Schedule 2. 2 Produce Production Data 2. 3 Store Product Quantity Used INVENTOR TY Quantity Produced & Location Stored

Creating Data Flow Diagrams Example Create a level 1 decomposing the processes in level 0 and identifying data stores. Customer Order Serve Product Collect Payment 4. Construct Level 1 (continued) Level 1 DFD Order Decision Received Goods 3. 2 Receive Items Produce Product Store Product Order Raw Materials Pay for Raw Materials PURCHASE 3. 1 ORDER Produce Purchas e Order Quantity On-Hand RAW Quantity MATERIALS Payment Approval 3. 3 Pay Vendor Pay for Labor Payment RECEIVED ITEMS VENDOR

Creating Data Flow Diagrams Example Create a level 1 decomposing the processes in level 0 and identifying data stores. Customer Order Serve Product Collect Payment 4. Construct Level 1 (continued) Level 1 DFD Time Worked 4. 1 Record Time Worked TIME CARDS Employee ID EMPLOYEE Payroll Request 4. 2 Calculat e Payroll Produce Product Store Product Unpaid time cards PAYROLL Payment Approval Order Raw Materials Pay for Raw Materials 4. 3 Pay Employ ee Pay for Labor Payment PAYMENT S

Process Decomposition 0. 0 Lemona de System Context Level 1. 0 Sale 1. 1 Record Order 1. 2 Receive Paymen t 2. 0 Producti on 2. 1 Serve Product 2. 2 Produce Product 2. 3 Store Product 3. 0 Procurement 3. 1 Produce Purchas e Order 3. 2 Receive Items 3. 3 Pay Vendor 4. 0 Payroll 4. 1 Record Time Worked 4. 2 Calculat e Payroll 4. 3 Pay Employ ee Level 0 Level 1

Data Flow Diagramming: Guidelines n n n all icons must be labeled with meaningful names the DFD evolves through a number of levels of detail always begin with a context level diagram (also called level 0) always show external entities at level 0 always label data flow arrows do not represent procedural logic These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 26

Constructing a DFD—I n n n review user scenarios and/or the data model to isolate data objects and use a grammatical parse to determine “operations” determine external entities (producers and consumers of data) create a level 0 DFD These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 27

Level 0 DFD Example user processing request digital video processor video source requested video signal monitor NTSC video signal These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 28

Constructing a DFD—II n n n write a narrative describing the transform parse to determine next level transforms “balance” the flow to maintain data flow continuity develop a level 1 DFD use a 1: 5 (approx. ) expansion ratio These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 29

The Data Flow Hierarchy x a a b P c p 2 level 1 p 4 p 3 level 0 f p 1 d y e g These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 5 b 30

Flow Modeling Notes n n each bubble is refined until it does just one thing the expansion ratio decreases as the number of levels increase most systems require between 3 and 7 levels for an adequate flow model a single data flow item (arrow) may be expanded as levels increase (data dictionary provides information) These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 31

Process Specification (PSPEC) bubble PSPEC narrative pseudocode (PDL) equations tables diagrams and/or charts These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 32

DFDs: A Look Ahead analysis model Maps into design model These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 33

Behavioral Modeling n The behavioral model indicates how software will respond to external events. To create the model, the analyst must perform the following steps: • Evaluate all use-cases to fully understand the sequence of interaction within the system. • Identify events that drive the interaction sequence and understand how these events relate to specific objects. • Create a sequence for each use-case. • Build a state diagram for the system. • Review the behavioral model to verify accuracy and consistency. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 34

State Representations n In the context of behavioral modeling, two different characterizations of states must be considered: n n n the state of each class as the system performs its function and the state of the system as observed from the outside as the system performs its function The state of a class takes on both passive and active characteristics [CHA 93]. n n A passive state is simply the current status of all of an object’s attributes. The active state of an object indicates the current status of the object as it undergoes a continuing transformation or processing. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 35

State Diagram for the Control. Panel Class These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 36

The States of a System n n state—a set of observable circumstances that characterizes the behavior of a system at a given time state transition—the movement from one state to another event—an occurrence that causes the system to exhibit some predictable form of behavior action—process that occurs as a consequence of making a transition These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 37

Behavioral Modeling n n make a list of the different states of a system (How does the system behave? ) indicate how the system makes a transition from one state to another (How does the system change state? ) n n n indicate event indicate action draw a state diagram or a sequence diagram These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 38

Sequence Diagram These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 39

Writing the Software Specification Everyone knew exactly what had to be done until someone wrote it down! These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 40