Topic # 04 Software Analysis Model. Requirements Modeling

1

Topic # 04Topic # 04Software Analysis Model.Software Analysis Model.Requirements Modeling: Requirements Modeling:

Data Flow Diagramming and Behavior DiagrammingData Flow Diagramming and Behavior Diagramming

(Ch. 7)(Ch. 7)

2

Analysis Model as a BridgeAnalysis Model as a Bridge

system

description

analysis

model

design

model

System Description

(by a customer)

Lists of System Requirements

(that customer still understands)

List of SW System Specifications

(that SW engineer understands)

System Development by SW technologists and technicians

analysis model

3

Main Components of the SW Analysis ModelMain Components of the SW Analysis Model

1. Scenario-based models:- use-cases – textual;- use-cases – diagrams;- activity diagrams;- swim lane diagrams;(were covered in previous class)

Analysis Model

2. Class models:- class diagrams;- analysis packages;- collaboration diagrams(were covered in previous class)

3. Behavioral models:- state transition diagrams;- sequence diagrams.

4. Data-flow models:- data-flow diagrams;- ERD diagrams;- control-flow diagrams;- processing narratives;

4

Maps intoMaps into

Power of Power of DFDsDFDs

Analysis modelAnalysis model

Design modelDesign model

Software modulesSoftware modules

Class objects and processing unitsClass objects and processing units

5

1.1.Data FlowData Flow--Oriented Modeling:Oriented Modeling:(Data Flow Diagrams (Data Flow Diagrams –– DFDsDFDs))

Data Flow Diagrams (DFDs) enable system engineers and system analysts as well as customers

- to outline the steps of a process, and

- to highlight goals.

Because DFDs rely on specific symbols that indicate the meaning or significance of a step, there are straightforward rules a person should follow when creating a flow chart.

This enables experts/users/readers to understand the chart and can help make the design and development process more efficient.

6

DFDsDFDs: Main Symbols: Main Symbols

Source: Modern Systems Analysis and Design, 4th Edition Jeffrey Hoffer, Joey George, & Joseph Valacich

7

Data Flow Diagramming Rules

1) Processes cannot have only outputs, cannot have only inputs, and must have a verb phrase label.

2) Data can only move to a data store from a process, not from another

data store or an outside source.

3) Similarly, data can only be moved to an outside sink or to another data store by a process.

4) Data to and from external sources and sinks can only be moved by

processes.

5) Data flows move in one direction only.

6) Both branches of a forked or a joined data flow must represent the same type of data.

7) A data flow cannot return to the process from which it originated.

8

No process can have only outputs or only inputs…processes must have both outputs and inputs.

Process labels should be verb phrases.


9

Data store labels should be noun phrases.

All flows to or from a data store must move through a process.


10

Source and sink labels should be noun phrases.

No data moves directly between external entities without going through a process.

Interactions between external entities without intervening processes are outside the system and therefore not represented in the DFD.


11

Bidirectional flow between process and data store is represented by two separate arrows.

Forked data flow must refer to exact same data item (not different data items) from a common location to multiple destinations.


Bidirectional flow. Forked Data.

12

Joined data flow must refer to exact same data item (not different data items) from multiple sources to a common location.

Data flow cannot go directly from a process to itself, must go through intervening processes.


Joined Data Flow.

13

(a) Improperly Drawn DFD


14

(b) Proper Use of a Process


15

Data Flow Diagramming:Data Flow Diagramming:GuidelinesGuidelines

1) always begin with a 1) always begin with a context level diagram (also called level 0) with context level diagram (also called level 0) with information of highest levelinformation of highest level

2) always show 2) always show external entities (external users) at level 0external entities (external users) at level 0

3) the DFD evolves through a 3) the DFD evolves through a number of levels of detailsnumber of levels of details

4) all 4) all icons must be labeledicons must be labeled with meaningful nameswith meaningful names

5) always 5) always label data flow arrowslabel data flow arrows

6) do not represent procedural logic6) do not represent procedural logic

16

Context Diagram (An example)Context Diagram (An example)

useruser

processing processing requestrequest

videovideosourcesource NTSCNTSC

video signalvideo signal

digitaldigitalvideovideo

processingprocessing

requestedrequestedvideovideosignalsignal

monitormonitor

Important notes:• A single processing unit• No data storage units• Multiple data sources (providers of data, receivers of data)

17

Context Diagram: An example of the University of Missouri Context Diagram: An example of the University of Missouri –– St. St. Louis Student Registration SystemLouis Student Registration System

http://www.umsl.edu/~sauterv/analysis/dfd/dfd_homework.html

• A single processing unit

• No data storage units

• Multiple data sources (providers of data, receivers of data)

18

The Data Flow Hierarchy: from context diagram towards levelThe Data Flow Hierarchy: from context diagram towards level--0 0 diagramdiagram

PrPraa bb

xx yy

P1.0P1.0

P2.0P2.0

P3.0P3.0P4.0P4.0 P5.0P5.0

aa

bb

cc

ddee

ff

gg

Context D.Context D.

Level 0 D.Level 0 D.

Main processing unit Pr (main function) can be divided into up to 9 sub-units (sub functions), labeled as P1.0, P2.0, P3.0, P4.0, etc.

19

Level 0 Diagram: An example of the University of Missouri Level 0 Diagram: An example of the University of Missouri –– St. St. Louis Student Registration SystemLouis Student Registration System

http://www.umsl.edu/~sauterv/analysis/dfd/dfd_homework.html

• Main (single) processing unit is divided into sub-units (level-0 processing units)

• Use of data storage units

• Still multiple data sources (providers of data, receivers of data) –they are the same as at Context DFD

20

Maps intoMaps into

Power of Power of DFDsDFDs

Analysis modelAnalysis model

Design modelDesign model

Software modulesSoftware modules

Class objects and processing unitsClass objects and processing units

21

Topic # 04Topic # 04Software Analysis Model.Software Analysis Model.

Requirements Modeling: Data Flow DiagrammingRequirements Modeling: Data Flow Diagramming

In-Classroom Exercise

22

2. 2. Behavioral ModelingBehavioral Modeling

(State Transition Diagrams (State Transition Diagrams –– STDs)STDs)

23

System’s Behavioral ModelingSystem’s Behavioral Modeling

Outsideworld

Software system

events behavior

• State transition diagrams (STD) - one means of representing a software behavioral model.

• The behavioral model indicates The behavioral model indicates how software will respond to external events.how software will respond to external events.

•• To create the model, the analyst must perform the following steTo create the model, the analyst must perform the following steps:ps:1) Identify events1) Identify events that drive the interaction sequence and understand how these evthat drive the interaction sequence and understand how these events ents

relate to specific objects.relate to specific objects.2) Create a sequence of events2) Create a sequence of events for each usefor each use--case.case.3) Build a state diagram3) Build a state diagram for the system.for the system.4) Review the behavioral model4) Review the behavioral model to verify accuracy and consistency.to verify accuracy and consistency.

24

The States of SW SystemThe States of SW System

StateState -- a set of observable circumstances that a set of observable circumstances that characterizes the behavior of a system atcharacterizes the behavior of a system ata given timea given time

State transitionState transition -- the movement from one state tothe movement from one state toanotheranother

Event Event -- an occurrence that causes the system toan occurrence that causes the system toexhibit some predictable form ofexhibit some predictable form ofbehaviorbehavior

Action Action -- process that occurs as a consequence ofprocess that occurs as a consequence ofmaking a transitionmaking a transition

statestate

new statenew state

event(s) causing transitionevent(s) causing transition

action(s)action(s)

state transitionstate transition

25

Creating Behavior Models: TOCreating Behavior Models: TO--DO listDO list

Evaluate all useEvaluate all use--casescases to understand the sequence of interaction within to understand the sequence of interaction within the systemthe system

Identify eventsIdentify events that drive the interaction sequence and how these events that drive the interaction sequence and how these events

relate to specific objectsrelate to specific objects

Create a sequence of events and list of corresponding statesCreate a sequence of events and list of corresponding states or eventor event--trace for each usetrace for each use--casecase

Build a state transition diagramBuild a state transition diagram for the entire systemfor the entire system

Review the behavior modelReview the behavior model to verify accuracy and consistencyto verify accuracy and consistency

26

An Example: Research Seminar Registration STD (1/2)An Example: Research Seminar Registration STD (1/2)

Top-level STD in UML format

An STD with details for the “Enrollment” state in UML format

Source: http://www.agilemodeling.com/artifacts/stateMachineDiagram.htm

27

An Example: Research Seminar Registration STD (2/2)An Example: Research Seminar Registration STD (2/2)

Final STD with multiple details (events, actions, etc.) in UML format

Source: http://www.agilemodeling.com/artifacts/stateMachineDiagram.htm

28

State Diagrams of various levels: other examplesState Diagrams of various levels: other examples

Source: http://www.math-cs.gordon.edu/courses/cs211/ATMExample/CRCCards.html

29

Topic # 04Topic # 04

Software Analysis Model.Software Analysis Model.

Requirements Modeling: Behavior DiagrammingRequirements Modeling: Behavior Diagramming

In-Classroom Exercise

30


Software Analysis Model.Software Analysis Model.Requirements Modeling: Requirements Modeling:


Homework AssignmentHomework Assignment

31


Software Analysis Model.Software Analysis Model.Requirements Modeling: Requirements Modeling:


An Example of HW Solutions (by format students)An Example of HW Solutions (by format students)

32

OPTIONALOPTIONAL

Other Types of ModelingOther Types of Modeling(a review)(a review)

33

1. Patterns for Requirements Modeling1. Patterns for Requirements Modeling(a review)(a review)

Discovered (not created)Discovered (not created) during requirements engineering workduring requirements engineering work

Should be documentedShould be documented by describing the general problem pattern is by describing the general problem pattern is applicable to, the prescribed solution, assumptions, constraintsapplicable to, the prescribed solution, assumptions, constraints, , advantages, disadvantages, and references to known examplesadvantages, disadvantages, and references to known examples

Documented analysis patterns are stored in an indexed repositoryDocumented analysis patterns are stored in an indexed repositoryfacilitate its facilitate its reuse reuse by other team membersby other team members

34

Patterns for Requirements’ Language Patterns for Requirements’ Language (a fragment) (a fragment) -- optionaloptional

Source: http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER04/Alicia_Martinez.pdf

35

2. WebApp Requirements Modeling2. WebApp Requirements Modeling(a review)(a review)

Models:Models:

Content ModelContent Model –– content (text, graphics, images, audio, video) provided by content (text, graphics, images, audio, video) provided by WebApp WebApp

Interaction ModelInteraction Model –– describes user interaction with WebAppdescribes user interaction with WebApp

Functional ModelFunctional Model –– defines operations applied to the WebApp content and defines operations applied to the WebApp content and other content independent processing functionsother content independent processing functions

Navigation ModelNavigation Model –– defines overall navigation strategy for the WebAppdefines overall navigation strategy for the WebApp

Configuration ModelConfiguration Model –– describes WebApp environmental infrastructure in describes WebApp environmental infrastructure in detaildetail

Documents

Topic # 04 Software Analysis Model. Requirements Modeling