1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e copyright © 1996, 2001 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited. This presentation, slides, or hardcopy may NOT be used for short courses, industry seminars, or consulting purposes.

2 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Chapter 12 Analysis Modeling

3 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Agenda  A Brief History  The Elements of The Analysis Model  Data Modeling  Functional Modeling and Information Flow  Behavioral Modeling  The Mechanisms of Structured Analysis  The Data Dictionary

4 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Structured Analysis (DeMarco)  Analysis products must be highly maintainable, especially the software requirements specification  Problems of size must be dealt with using an effective methods of partitioning  Graphics should be used whenever possible  Differentiate between the logical (essential) and physical (implementation) considerations.  Find something to help with requirements partitioning and document the partitioning before specification  Devise a way to track and evaluate user interfaces.  Devise tools that describe logic and policy better than narrative text

5 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Analysis Model Objectives  Describe what the customer requires  Establish a basis for the creation of a software design  Devise a set of requirements that can be validated once the software is built

6 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Analysis Model Elements  Data Dictionary – contains the descriptions of all data objects consumed or produced by the software  Entity Relationship Diagram (ERD) – depicts relationships between data objects  Data Flow Diagram (DFD) – provides a indication of how data are transformed as they move through the system; also depicts functions that transform the data flow ( a function is represented in a DFD using a process specification or PSPEC)  State Transition Diagram (STD) – indicates how the system behaves as a consequence of external events, states are used to represent behavior. Arcs are labeled with the events triggering the transitions from one state to another (control information is contained in control specification or CSPEC)

7 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Analysis Modeling: Where to Begin?  A statement of scope can be acquired from:  the FAST working document  A set of use-cases  the statement of scope must be “parsed” to extract data, function and behavioral domain information

8 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Statement of Scope  a relatively brief description of the system to be built  indicates data that are input and output and basic functionality  indicates conditional processing (at a high level)  implies certain constraints and limitations

9 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Identifying Objects and Operations  define “objects” by underlining all nouns in the written statement of scope  producers/consumers of data  places where data are stored  “composite” data items  define “operations” by double underlining all active verbs  processes relevant to the application  data transformations  consider other “services” that will be required by the objects

10 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Data Modeling and Entity Relationship (E-R) Diagramming

11 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Why Data Modeling?  examines data objects independently of processing  focuses attention on the data domain  creates a model at the customer’s level of abstraction  indicates how data objects relate to one another

12 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 What is a Data Object? Object —something that is described by a set of attributes (data items) and that will be manipulated within the software (system) eachinstance of an object (e.g., a book) of an object (e.g., a book) can be identified uniquely (e.g., ISBN #) each plays a necessary role in the system i.e., the system could not function without access to instances of the object each is described by attributes that are themselves data items

13 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Typical Objects external entities (printer, user, sensor) things (e.g, reports, displays, signals) (e.g, reports, displays, signals) occurrences or events (e.g., interrupt, alarm) roles (e.g., manager, engineer, salesperson) organizational units (e.g., division, team) (e.g., division, team) places (e.g., manufacturing floor) (e.g., manufacturing floor) structures (e.g., employee record)

14 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Data Objects and Attributes A data object contains a set of attributes that act as an aspect, quality, character- istic, or descriptor of the object object: automobile attributes: make make model model body type body type price price options code options code

15 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 What is a Relationship? relationship —indicates “connectedness”; a "fact" that must be "remembered" by the system and cannot or is not computed or derived mechanically  several instances of a relationship can exist  objects can be related in many different ways

16 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Cardinality and Modality  Cardinality – in data modeling, cardinality specifies how the number of occurrences of one object are related to the number of occurrences of another object (1:1, 1:N, N:M)  Modality – zero (0) for an optional object relationship and one (1) for a mandatory relationship

17 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 ERD Notation (0, m) (1, 1) object object relationship 1 2 One common form: (0, m) (1, 1) object 1 object 2 relationship Another common form: attribute

18 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Building an ERD  Level 1—model all data objects (entities) and their “connections” to one another  Level 2—model all entities and relationships  Level 3—model all entities, relationships, and the attributes that provide further depth

19 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 The ERD: An Example (1,1) (1,m) places Customer request for service generates (1,n) (1,1) workorder worktasks materials consistsof lists (1,1) (1,w) (1,1) (1,i) selectedfrom standard task table (1,w) (1,1)

20 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Creating a Flow Model

21 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 The Flow Model Every computer-based system is an information transform.... computerbasedsystem input output

22 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Flow Modeling Notation external entity process data flow data store

23 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 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

24 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 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

25 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Data Flow Data flows through a system, beginning as input and be transformed into output. computetrianglearea base height area

26 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Data Stores Data is often stored for later use. look-upsensordata sensor # report required sensor #, type, location, age sensor data sensor number type, location, age

27 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Ward and Mellor Extensions  An extended basic structured analysis notation to accommodate the following demands imposed by real-time systems:  Information is gathered or produced on a time- continuous basis  Control information is passed throughout the system and associated control processing

28 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Data Flow Diagramming: Guidelines  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

29 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Constructing a DFD—I  review ERD to isolate data objects and grammatical parse to determine “operations)  determine external entities (producers and consumers of data  create a level 0 DFD

30 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Level 0 DFD Example user processingrequest videosource NTSC video signal digitalvideoprocessor requestedvideosignal monitor

31 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Constructing a DFD—II  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

32 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 The Data Flow Hierarchy P a b xy p1 p2 p3 p4 5 a b c d e f g level 0 level 1

33 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Flow Modeling Notes  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)

34 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Maps into DFDs: A Look Ahead analysis model design model

35 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Behavioral Modeling and Process Specification

36 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Behavioral Modeling Outside world Application events behavior

37 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 The States of a System  state—a set of observable circum- stances 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

38 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Behavioral Modeling  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?)  indicate event  indicate action  draw a state transition diagram

39 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 State Transition Diagram Notation state new state event causing transition action that occurs

40 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 State Transition Diagram reading operator commands making copies reloading paper problem state full invoke read-op-input full and start invoke manage-copying copies done invoke read-op-input empty invoke reload paper jammed invoke problem-diagnosis not jammed invoke read-op-input

41 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Control Specification (CSPEC) The CSPEC can be: state transition diagram (sequential spec) state transition table decision tables activation tables combinatorial spec

42 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Process Specification (PSPEC) PSPEC narrative pseudocode (PDL) equations tables diagrams and/or charts bubble

43 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 A Design Note one or more ”components" in the software design PSPEC

44 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Creating Mini-Specs Software Specification

45 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Real-Time Analysis Methods  each introduces its own notation, but all:  propose an approach for representing control and separating it from data  provide a mechanism for specifying events, states, and distributed processing  begin at the analysis level and work to derive processor assignments, tasks and program architectures

46 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Control Flow Diagrams  Begin by stripping all the data flow arrows from the DFD  Events (solid arrows) and control items (dashed arrows) are added to the diagram  Add a window to the CSPEC (contains and STD that is a sequential specification of the behavior) for each bubble in the final CFD7

47 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 The Data Dictionary

48 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Building a Data Dictionary

49 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Data Dictionary Notation

50 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Data Dictionary Example

51 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Writing the Software Specification Everyone knew exactly what had to be done until someone wrote it down!