1. Chapter 8 Analysis Modeling Adapted by Dan Fleck from: - Roger Pressman’s Slides Jochen Rick’s slides from GA Institute of Technology Extra_Examples/DFD_Example_1/ - System Analysis and Design slides edited by Yale Braunstein
Coming up: Requirements Analysis

2. 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.
Coming up: Analysis Phase: What is it?

3. Analysis Phase: What is it?
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

4. Analysis Modeling Approaches
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
Entity Relationship Model - ERD
Flow = Data Flow Diagram
But don’t be to dogmatic!
Coming up: Elements of the Analysis Model

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

6. 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
Coming up: Class-Based Modeling

7. 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: Grammatical Parsing

8. Grammatical Parsing
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
Nouns are your classes
Verbs are your methods
Got here 2/27/2008
Coming up: Grammatical Parsing

9. Grammatical Parsing
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
Nouns are your classes
Verbs are your methods
Coming up: Grammatical Parsing

10. Grammatical Parsing
University Bank will be opening in Oxford, Mississippi, in January, 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
Nouns are your classes
Verbs are your methods
Coming up: Typical Classes (a reminder)

11. 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)
But, how do we select classes?
Coming up: Selecting Classes—Criteria

12. Selecting Classes—Criteria
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!)
select a noun as a class if it fits all (or most) of these criteria (in the analysis phase)
Coming up: Selecting Classes—Example

13. Selecting Classes—Example
ATMUser
Yes
PinNum
Yes No
Maybe
retained information
needed services
multiple attributes
common attributes
common operations
essential requirements
Coming up: Elements of the Analysis Model

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

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

16. 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
Data Object is similar to a class, but with no methods
themselves data items
What are some typical data objects?
Coming up: Typical Data Objects

17. Typical Data 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)
External - produces or consumes information
Anything that consolidates multiple pieces of data (attributes)
Coming up: Data Objects and Attributes

18. Data Objects and Attributes
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?

19. 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
Coming up: Crow’s Foot Style ERD

20. Crow’s Foot Style ERD
The ERD: Other style’s exist. There are a few, but most are more confusing and less common than Crow’s foot. Depending on who you ask this was invented by Dr. Gordon Everest of Clive Finkelstein.
Teacher teaches 0 to many classes
Classes have 1 and only 1 teacher
Students have 1 to many addresses
An address is for zero to one student (addresses may not be associated with multiple students)
Teacher
Class
Student
Address
First “thing” denotes optional or mandatory.
Second “thing” denotes cardinality (one or many)
Coming up: The ERD: An Example

21. The ERD: An Example request Customer for service standard work
places
request
for service
Customer
standard
task table
generates
work
order
(1,1)
selected
from
work
tasks
consists of
materials
lists
Coming up: Elements of the Analysis Model

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

23. Flow-Oriented Modeling
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, flow-oriented modeling continues to provide a view of the system that is unique—it should be used to supplement other analysis model elements
Coming up: The Flow Model

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

25. Flow Modeling Notation
external entity
process
data flow
data store
Coming up: External Entity

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

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

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

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

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

31. Constructing a DFD—I
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
Coming up: Level 0 DFD Examples

32. Level 0 DFD Examples user digital video processor monitor video source
processing
request
user
requested
video
signal
digital
video
processor
monitor
video
source
NTSC
video signal
Coming up: Constructing a DFD—II

33. 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
Coming up: The Data Flow Hierarchy

34. The Data Flow Hierarchyb x P y
level 0 c a p2 f p1 b p4 d 5 g p3 e
level 1
Coming up: Example DFD: Level 1

35. Example DFD: Level 1
Coming up: DFD: A practical example

36. DFD: A practical example
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.
Coming up: Lets Try It

37. Lets Try It Lets create a DFD for A carpet cleaning business
A web-based order processing system for a computer store
An address book for an iPhone
Coming up: Flow Modeling Notes

38. 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)
Got here 10/16/2008
Coming up: Elements of the Analysis Model

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

40. Behavioral Modeling
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 diagram for each use-case.
Build a state diagram for the system.
Review the behavioral model to verify accuracy and consistency.
Coming up: State Representations

41. 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
Coming up: State Diagram for the ControlPanel Class

42. State Diagram for the ControlPanel Class
Coming up: State Diagram Details

43. State Diagram Details State Name (verb in current tense)
(Optional) actions happening during state
[age <= 20]
[age > 20]
[age <= 20]/setFlag(false)
Guards: Use to describe event that causes a state transition happens (ALL transitions should have guards)
Name Examples:
sorting
validating
updating status …
Action: If something happens while transitioning to another state. (Optional)
Coming up: The States of a System

44. 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
Coming up: Behavioral Modeling

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

46. State Diagram - Lets Try It!
You are designing a traffic light system for this intersection.
Draw a state diagram showing the different states and how they transition.
North
West
Got here on class 10/2/2008
East
South
Coming up: Elements of the Analysis Model

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

48. Object Oriented Analysis (OOA)
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
Coming up: Object-Oriented Concepts

49. Object-Oriented Concepts
What are the basic object oriented concepts?
Coming up: Object-Oriented Concepts

50. Object-Oriented Concepts
What are the basic object oriented concepts?
Classes and objects
Attributes and operations
Encapsulation and instantiation
Inheritance
The analysis model is designed to help you make “good” choices
Coming up: Object-Oriented Concepts

51. Object-Oriented Concepts
What helps you determine if something should be a class or an attribute?
What helps you determine needed operations?
How does the analysis model make sure your requirements are correct?
Coming up: Elements of the Analysis Model

52. 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
Coming up: Analysis Model Rules of Thumb

53. Analysis Model Rules of Thumb
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 non-functional 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.
Coming up: Analysis Phase: What is it?

54. Analysis Phase: What is it?
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: Writing the Software Specification

55. Writing the Software Specification
Everyone knew exactly what had to be done until someone wrote it down!
Read the last three slides on your own
Coming up: Specification Guidelines

56. Specification Guidelines
Coming up: Specification Guidelines

57. Specification Guidelines
Coming up: Specification Guidelines

58. Specification Guidelines
End of presentation