Roger Pressman’s Slides
http://www.informatics.sussex.ac.uk/users/lb203/se/SE04.pdf
Jochen Rick’s slides from GA Institute of Technology
http://webfuse.cqu.edu.au/Courses/aut2001/95169/
Extra_Examples/DFD_Example_1/
- System Analysis and Design slides edited by Yale Braunstein
Coming up: Requirements Analysis
1



Requirements analysis
 specifies software’s operational characteristics
 indicates software's interface with other system elements
 establishes constraints that software must meet
Requirements analysis allows the software engineer
(called an analyst or modeler in this role) to:
 elaborate on basic requirements established during earlier requirement engineering tasks
 build models that depict user scenarios, functional activities, problem classes and their relationships, system and class behavior, and the flow of data as it is transformed.
2
Coming up: Analysis Phase: What is it?

system description analysis model design model
Three objectives:
• To describe what the customer requires
• To establish a basis for the creation of a software design
• To define a set of requirements that can be validated once the software is built
Coming up: Analysis Modeling Approaches
3

 Structural analysis:
 The data : The model defines their attributes and relationships .
 The processes that transform the data: The model shows how they transform the data objects as they flow through the system.
 Object-oriented analysis:
 Focus: Classes and their inter-relationships
 UML is predominantly object-oriented
But don’t be to dogmatic!
4
Coming up: Elements of the Analysis Model

Elements of the Analysis Model
Scenario-based elements
Use-case diagrams
Use cases - text
Activity Diagrams
Swim lane diagrams
Analysis
Model
Flow-oriented elements
Data-flow diagrams
Control flow diagrams
Processing narratives
Class-based elements
Class diagrams
Analysis Packages
CRC Models
Collaboration Diagrams
Behavioral elements
State diagrams
Sequence diagrams
Coming up: Elements of the Analysis Model
5

Elements of the Analysis Model
Scenario-based elements High level idea of the system from user’s or a functional perspective
Flow-oriented elements
How information flows throughout the system (data and control flow)
Behavioral elements
How the system responds to external stimuli
Class-based elements Static view of the system and how the different parts are related. Tries to show standard ideas of object oriented development
6
Coming up: 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
Coming up: What is a Data Object?
7

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
Coming up: Typical Data Objects
What are some typical data objects?
8

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)
Coming up: Data Objects and Attributes
9

A data object contains a set of attributes that act as an aspect, quality, characteristic, or descriptor of the object object: automobile attributes: make model body type price options code
How do data objects differ from OO classes or do they?
Coming up: What is a Relationship?
10

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
Coming up: ERD Notation
11

One common form: object
1
(0, m) relationship
(1, 1) object
2 attribute
Another common form: object
1
(0, m) relationship
(1, 1) object
2
See http://www.smartdraw.com/tutorials/software/erd/tutorial_01.htm
for a tutorial on how to draw entity relationship diagrams.
Coming up: The ERD: An Example
12

Customer
(1,1) places standard task table
(1,1) selected from
(1,w) work tasks
(1,w) materials
(1,i)
(1,m) request for service
(1,1) generates
(1,n)
(1,1) work order
(1,1) consists of lists
Coming up: Elements of the Analysis Model
13

Elements of the Analysis Model
Scenario-based elements
Use-case diagrams
Use cases - text
Activity Diagrams
Swim lane diagrams
Onward to data flow diagrams!
Flow-oriented elements
Data-flow diagrams
Control flow diagrams
Processing narratives
Analysis
Model
Class-based elements
Class diagrams
Analysis Packages
CRC Models
Collaboration Diagrams
Behavioral elements
State diagrams
Sequence diagrams
Coming up: Flow-Oriented Modeling
14

Coming up: The Flow Model
Represents how data objects are transformed at they move through the system
A data flow diagram (DFD) is the diagrammatic form that is used
Considered by many to be an ‘old school’ approach, floworiented modeling continues to provide a view of the system that is unique —it should be used to supplement other analysis model elements
15

Every computer-based system is an information transform ....
input computer based system output
Coming up: Flow Modeling Notation
16

Coming up: External Entity
external entity process data flow data store
17

Coming up: Process
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
18

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
Coming up: Data Flow
19

Coming up: Data Stores
Data flows through a system, beginning as input and be transformed into output.
base height compute triangle area area
20

Data is often stored for later use.
sensor # report required look-up sensor data sensor #, type, location, age type, location, age sensor number sensor data
Coming up: Data Flow Diagramming:
Guidelines
21






 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
Coming up: Constructing a DFD —I
22



 review 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
23
Coming up: Level 0 DFD Examples

processing request user digital video processor requested video signal monitor video source
NTSC video signal
Coming up: Constructing a DFD —II
24

 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
Coming up: The Data Flow Hierarchy
25

x a
P b y level 0 a p1 level 1 d c p3 p2 e f p4 g
5 b
Coming up: Example DFD: Level 1
26

Coming up: DFD: A practical example
27

Launched Dec. 11, 1998, the Climate Orbiter plunged too steeply into the Martian atmosphere Sept. 23, 1999, and either burned up or crashed. In an initial failure report released Oct. 15, 2000 the review board blamed the navigation error on a communications foul-up between NASA's Jet Propulsion Laboratory and prime contractor Lockheed Martin.
Transfer of Flight Control Data
Who was responsible for this task?
This process was missing
JPL-1
Collect, analyze, generate flight control data
?
Transfer data
?
Convert data from Metric to
English
LM-1
Control spaceflight
Metric data
JPL store
English data
LM1
LM store
28




 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)
Coming up: Elements of the Analysis Model
29

Elements of the Analysis Model
Scenario-based elements
Use-case diagrams
Use cases - text
Activity Diagrams
Swim lane diagrams
Analysis
Model
Flow-oriented elements
Data-flow diagrams
Control flow diagrams
Processing narratives
Class-based elements
Class diagrams
Analysis Packages
CRC Models
Collaboration Diagrams
Behavioral elements
State diagrams
Sequence diagrams
Coming up: Activity Diagram
30

Supplements the use-case by providing a diagrammatic representation of procedural flow ent er password and user ID
How might we make this better?
valid passwor ds/ ID invalid passwor ds/ ID selec t major f unc t ion ot her f unct ions m ay also be select ed selec t surv eillanc e prompt f or reent ry no input t r ies r em ain input t r ies r em ain t hum bnail views select a specif ic cam er a selec t spec if ic c amera - t humbnails selec t c amera ic on v iew c amera out put in labelled window prompt f or anot her v iew exit t his f unct ion see anot her cam er a
Coming up: Swimlane Diagrams
31

Allows the modeler to represent the flow of activities described by the use-case and at the same time indicate which actor
(if there are multiple actors involved in a specific use-case) or analysis class has responsibility for the action described by an activity rectangle h o m e o w n e r ent er pas s word and us er ID c a m e r a i n t e r f a c e s elec t m ajor f unc t ion o t h er f u n ct io n s m ay also b e select ed s elec t s urv eillanc e t h u m b n ail views select a sp ecif ic cam er a s elec t s pec if ic c am era - t hum bnails s elec t c am era ic on valid p asswo r d s/ ID in valid p asswo r d s/ ID prom pt f or reent ry in p u t t r ies r em ain n o in p u t t r ies r em ain generat e v ideo out put v iew c am era out put in labelled window prom pt f or anot her v iew exit t h is f u n ct io n see an o t h er cam er a
32
Coming up: Activity Diagram Example

-
To show concurrent activity, activity diagrams allow branches and joins.
-
You can also reference or include other activity diagrams
Coming up: Lets Try It
33

 Lets create a swimlane activity diagram for opening a Lemonade stand.
Coming up: Elements of the Analysis Model
34

Elements of the Analysis Model
Scenario-based elements
Use-case diagrams
Use cases - text
Activity Diagrams
Swim lane diagrams
Analysis
Model
Flow-oriented elements
Data-flow diagrams
Control flow diagrams
Processing narratives
Oh behave!
Class-based elements
Class diagrams
Analysis Packages
CRC Models
Collaboration Diagrams
Behavioral elements
State diagrams
Sequence diagrams
Coming up: Behavioral Modeling
35

 The behavioral model indicates how software will respond to external events or stimuli. 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.
36
Coming up: State Representations



In the context of behavioral modeling, two different characterizations of states must be considered:

 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 [CHA93].


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.
37
Coming up: State Diagram for the ControlPanel Class

State Diagram for the
ControlPanel Class
Coming up: The States of a System t imer < lockedTime key hit t imer > lockedTime locked reading password = incorrect
& numberOf Tries < maxTries comparing numberOf Tries > maxTries password ent ered do: validat ePassw or d password = correct select ing act iv at ion successf ul
38




 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
Coming up: Behavioral Modeling
39

 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 diagram or a sequence diagram
Coming up: State Diagram - Lets Try It!
40

You are designing a traffic light system for this intersection.
West
North
Draw a state diagram showing the different states and how they transition.
East
Coming up: Elements of the Analysis Model
South
41

Elements of the Analysis Model
Scenario-based elements
Use-case diagrams
Use cases - text
Activity Diagrams
Swim lane diagrams
Analysis
Model
Flow-oriented elements
Data-flow diagrams
Control flow diagrams
Processing narratives
Class-based elements
Class diagrams
Analysis Packages
CRC Models
Collaboration Diagrams
Behavioral elements
State diagrams
Sequence diagrams
Onward to Class-based elements!
Coming up: Object Oriented Analysis (OOA)
42

Object Oriented Analysis (OOA)

1.
2.
3.
4.
5.
The intent of OOA is to define all classes (and the relationships and behavior associated with them) that are relevant to the problem to be solved. For that, a number of tasks must occur:
Classes must be identified (i.e., attributes and methods)
A class hierarchy is defined
Object-to-object relationships should be represented
Object behavior must be modeled
Tasks 1 through 4 are reapplied iteratively
43
Coming up: Object-Oriented Concepts

 What are the basic object oriented concepts?
Coming up: Object-Oriented Concepts
44

 What are the basic object oriented concepts?


Classes and objects
Attributes and operations


Encapsulation and instantiation
Inheritance
Coming up: Encapsulation/Hiding
45

The object encapsulates both data and the logical procedures required to manipulate the data method
# 1 data method
# 2 method
# 6 method
# 3 method
# 5
Achieves “information hiding” method
# 4
Coming up: Scenario Based Modeling:
Use-Cases
46


“[Use-cases] are simply an aid to defining what exists outside the system (actors) and what should be performed by the system (usecases).” Ivar Jacobson a scenario that describes a “thread of usage” for a system
 actors represent roles people or devices play as the system functions
 users can play a number of different roles for a given scenario
47
Coming up: Class-Based Modeling



Identify analysis classes by examining the problem statement
Use a “grammatical parse” to isolate potential classes
 Identify the attributes of each class
 Identify operations that manipulate the attributes
Coming up: Domain Analysis
48

Coming up: Domain Analysis
Software domain analysis is the identification, analysis, and specification of common requirements from a specific application domain, typically for reuse on multiple projects within that application domain . . .
What is object oriented domain analysis then?
49

Software domain analysis is the identification, analysis, and specification of common requirements from a specific application domain, typically for reuse on multiple projects within that application domain . . .
Object-oriented domain analysis is the identification, analysis, and specification of common, reusable capabilities within a specific application domain, in terms of common objects , classes, subassemblies, and frameworks . . .
Coming up: Grammatical Parsing Donald Firesmith
50

 Write an informal description of the problem. The customer requirements document is one such description.
 Underline all nouns in the description
 Decide which of these are really objects which the project requires and organize them in related clusters
51
Coming up: Grammatical Parsing

University Bank will be opening in Oxford, Mississippi , in January ,
ATM ) system.The ATM system will interact with the customer through a display screen, numeric and special input keys , a bankcard reader, a deposit slot , and a receipt printer .Customers may make deposits , withdrawals, and balance inquires using the ATM machine, but the update to accounts will be handled through an interface to the
Accounts system .Customers will be assigned a Personal Identification
Number ( PIN ) and clearance level by the Security system . The PIN can be verified prior to any transaction.In the future, we would also like to support routine operations such as a change of address or phone number using the ATM
Coming up: Grammatical Parsing
52

 University Bank will be opening in Oxford, Mississippi, in
January, 2000. We plan to use a full service automated teller machine (ATM) system.The ATM system will interact with the customer through a display screen , numeric and special input keys , a bankcard reader , a deposit slot, and a receipt printer .
Customers may make deposits , withdrawals , and balance inquires using the ATM machine, but the update to accounts will be handled through an interface to the
Accounts system .Customers will be assigned a Personal
Identification Number (PIN) and clearance level by the
Security system . The PIN can be verified prior to any transaction.In the future, we would also like to support routine operations such as a change of address or phone number using the ATM
53
Coming up: Typical Classes (a reminder)








External entities - printer, user, sensor
Things - 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 or loading dock)
Structures (e.g., sensors, four-wheeled vehicles, or computers)
Coming up: Selecting Classes —Criteria
But, how do we select classes?
54

retained information – information about it must be remembered needed services – operations that change the attributes multiple attributes – if it is only one attribute, probably should be part of another class common attributes – common things for all instances of a class common operations – for all instances of the class essential requirements – appear in the PROBLEM space
(remember we’re doing analysis modeling!)
Coming up: Selecting Classes —Example
55

retained information needed services multiple attributes common attributes common operations essential requirements
ATMUser
Yes
Yes
Yes
Yes
Yes
Yes
PinNum
Yes
No
No
Yes
Maybe
Yes
Coming up: CRC Modeling
56

 See specific CRC slides
Coming up: Rules of Thumb
57







The model should focus on requirements that are visible within the problem or business domain. The level of abstraction should be relatively high.
Each element of the analysis model should add to an overall understanding of software requirements and provide insight into the information domain, function and behavior of the system.
Delay consideration of infrastructure and other nonfunctional models until design.
Minimize coupling throughout the system.
Be certain that the analysis model provides value to all stakeholders.
Keep the model as simple as it can be.
58
Coming up: Elements of the Analysis Model

Elements of the Analysis Model
Scenario-based elements High level idea of the system from user’s or a functional perspective
Flow-oriented elements
How information flows throughout the system (data and control flow)
Behavioral elements
How the system responds to external stimuli
Class-based elements Static view of the system and how the different parts are related. Tries to show standard ideas of object oriented development
59
Coming up: Writing the Software Specification

Everyone knew exactly what had to be done until someone wrote it down!
60
Coming up: Specification Guidelines

use a layered format that provides increasing detail as the "layers" deepen use consistent graphical notation and apply textual terms consistently (stay away from aliases) be sure to define all acronyms be sure to include a table of contents; ideally, include an index and/or a glossary write in a simple, unambiguous style (see "editing suggestions" on the following pages) always put yourself in the reader's position, "Would
I be able to understand this if I wasn't intimately familiar with the system?"
Coming up: Specification Guidelines
61

Be on the lookout for persuasive connectors, ask why?
keys: certainly, therefore, clearly, obviously, it follows that ...
Watch out for vague terms
keys: some, sometimes, often, usually,ordinarily, most, mostly ...
When lists are given, but not completed, be sure all items are understood
keys: etc., and so forth, and so on, such as
Be sure stated ranges don't contain unstated assumptions
e.g., Valid codes range from 10 to 100.
Integer? Real? Hex?
Beware of vague verbs such as handled, rejected, processed, ...
Beware "passive voice" statements
e.g., The parameters are initialized.
By what?
Beware "dangling" pronouns
e.g., The I/O module communicated with the data validation module and its contol flag is set.
Whose control flag?
Coming up: Specification Guidelines
62

End of presentation
When a term is explicitly defined in one place, try substituting the definition forother occurrences of the term
When a structure is described in words, draw a picture
When a structure is described with a picture, try to redraw the picture to emphasize different elements of the structure
When symbolic equations are used, try expressing their meaning in words
When a calculation is specified, work at least two examples
Look for statements that imply certainty, then ask for proof
keys; always, every, all, none, never
Search behind certainty statements—be sure restrictions or limitations are realistic
63