topic # 04 software analysis model. requirements modeling
Post on 29-May-2022
1 Views
Preview:
TRANSCRIPT
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.
Source: Modern Systems Analysis and Design, 4th Edition Jeffrey Hoffer, Joey George, & Joseph Valacich
9
Data store labels should be noun phrases.
All flows to or from a data store must move through a process.
Source: Modern Systems Analysis and Design, 4th Edition Jeffrey Hoffer, Joey George, & Joseph Valacich
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.
Source: Modern Systems Analysis and Design, 4th Edition Jeffrey Hoffer, Joey George, & Joseph Valacich
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.
Source: Modern Systems Analysis and Design, 4th Edition Jeffrey Hoffer, Joey George, & Joseph Valacich
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.
Source: Modern Systems Analysis and Design, 4th Edition Jeffrey Hoffer, Joey George, & Joseph Valacich
Joined Data Flow.
13
(a) Improperly Drawn DFD
Source: Modern Systems Analysis and Design, 4th Edition Jeffrey Hoffer, Joey George, & Joseph Valacich
14
(b) Proper Use of a Process
Source: Modern Systems Analysis and Design, 4th Edition Jeffrey Hoffer, Joey George, & Joseph Valacich
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
Topic # 04Topic # 04
Software Analysis Model.Software Analysis Model.Requirements Modeling: Requirements Modeling:
Data Flow Diagramming and Behavior DiagrammingData Flow Diagramming and Behavior Diagramming
Homework AssignmentHomework Assignment
31
Topic # 04Topic # 04
Software Analysis Model.Software Analysis Model.Requirements Modeling: Requirements Modeling:
Data Flow Diagramming and Behavior DiagrammingData Flow Diagramming and Behavior Diagramming
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
top related