Supplementary Slides for Software Engineering A Practitioners Approach

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. 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 1

Chapter 12 Analysis Modeling 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 2

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 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 3

Structured Analysis (De. Marco) 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 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 4

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 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 5

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) 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 6

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 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 7

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 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 8

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 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 9

Data Modeling and Entity Relationship (E-R) Diagramming 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 10

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 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 11

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) each instance 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 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 12

Typical Objects external entities (printer, user, sensor) things (e. g, reports, displays, signals) occurrences or events (e. g. , interrupt, alarm) roles (e. g. , manager, engineer, salesperson) organizational units (e. g. , division, team) places (e. g. , manufacturing floor) structures (e. g. , employee record) 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 13

Data Objects and Attributes A data object contains a set of attributes that act as an aspect, quality, characteristic, or descriptor of the object: automobile attributes: make model body type price options code 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 14

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 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 15

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 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 16

ERD Notation One common form: object 1 (0, m) relationship (1, 1) object 2 attribute Another common form: object 1 relationship (0, m) (1, 1) object 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 17

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 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 18

The ERD: An Example Customer (1, 1) places (1, m) request for service (1, 1) standard task table (1, 1) work selected from (1, w) tasks materials generates (1, n) (1, w) (1, i) work order (1, 1) consists of lists 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 19

Creating a Flow Model 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 20

The Flow Model Every computer-based system is an information transform. . input computer based system output 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 21

Flow Modeling Notation external entity process data flow data store 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 22

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 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 23

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 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 24

Data Flow Data flows through a system, beginning as input and be transformed into output. base height compute triangle area 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 25

Data Stores Data is often stored for later use. sensor # report required sensor #, type, location, age look-up sensor data sensor number type, location, age sensor data 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 26

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 timecontinuous basis Control information is passed throughout the system and associated control processing 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 27

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 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 28

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 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 29

Level 0 DFD Example user video source processing request digital video processor requested video signal monitor NTSC video signal 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 30

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 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 31

The Data Flow Hierarchy x a p 1 a c d level 1 b P p 2 level 0 f p 4 p 3 y e g 5 b 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 32

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) 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 33

DFDs: A Look Ahead analysis model Maps into design model 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 34

Behavioral Modeling and Process Specification 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 35

Behavioral Modeling events Outside world behavior Application 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 36

The States of a System 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 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 37

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 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 38

State Transition Diagram Notation state event causing transition action that occurs new state 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 39

State Transition Diagram full and start invoke manage-copying reading operator commands full invoke read-op-input copies done invoke read-op-input making copies reloading paper empty invoke reload paper jammed invoke problem-diagnosis problem state not jammed invoke read-op-input 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 40

Control Specification (CSPEC) The CSPEC can be: state transition diagram (sequential spec) state transition table combinatorial spec decision tables activation tables 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 41

Process Specification (PSPEC) bubble PSPEC narrative pseudocode (PDL) equations tables diagrams and/or charts 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 42

A Design Note PSPEC one or more ”components" in the software design 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 43

Creating Mini-Specs Software Specification 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 44

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 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 45

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 CFD 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 46

The Data Dictionary 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 47

Building a Data Dictionary 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 48

Data Dictionary Notation 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 49

Data Dictionary Example 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 50

Writing the Software Specification Everyone knew exactly what had to be done until someone wrote it down! 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 51