CHAPTER 12

A picture is worth
1024 words
 Objectives

• After finish this chapter, student should understand the

purpose of every type of diagrams, when and how to
build them.
• Student could choice the plan to model requirements.
 Contents

1. A useful of picture in requirements representation

2. Modeling the requirements
3. From voice of the customer to analysis models
4. Selecting the right representations
5. Data flow diagram
6. Swimlane diagram
7. State-transition diagram and state table
8. Decision tables and decision trees
9. Modeling on agile projects
 A useful of picture in requirements
representation

• Diagrams communicate certain types of information more

efficiently than text can.
• Pictures help bridge language and vocabulary barriers
among team members
 Modeling the requirements

• Visual requirements models can help you identify missing,

extraneous, and inconsistent requirements.
• Given the limitations of human short-term memory,
analyzing a list of one thousand requirements for
inconsistencies, duplication, and extraneous requirements
is nearly impossible.
 From voice of the customer to analysis
models

• By listening carefully to how customers present their

requirements, the BA can pick out keywords that translate
into specific model elements.
Selecting the right
representations
Selecting the right
representations
Selecting the right
representations
 Data flow diagram – context diagram

• Purpose
– DFDs provide a big-picture view of how data moves through a
system, which other models don’t show well
– A gives context to the functional requirements regarding how
the user performs specific tasks.
– DFDs can be used as a technique to identify missing data
requirements
Dataflow diagram: example
 Swimlane diagram

• Purpose:
– Provide a way to represent the steps involved in a business
process or the operations of a proposed software system.
– They are a variation of flowcharts, subdivided into visual
subcomponents called lanes. The lanes can represent different
systems or actors that execute the steps in the process.
– Swimlane diagrams are most commonly used to show business
processes, workflows, or system and user interactions.
– They are similar to UML activity diagrams. Swimlane diagrams
are sometimes called cross-functional diagrams.
Swimlane example
 State-transition diagram
and state table

• Purpose: Software systems involve a combination of

functional behavior, data manipulation, and state changes.
Real-time systems and process control applications can exist
in one of a limited number of states at any given time.
• A state change can take place only when well-defined criteria
are satisfied, such as receiving a specific input stimulus under
certain conditions
• State transition diagram contains three type of elements:
– Possible system states, shown as rectangles
– Allowed state changes or transitions, shown as arrows connecting
pairs of rectangles
– Events or conditions that cause each transition to take place, shown
as text labels on each transition arrow
 What is a State Machine?

• A directed graph of states (nodes) connected by

transitions (directed arcs)
• Describes the life history of a reactive object
Guard Condition
Event Activity
State1 State2
Event(args)[guard condition]/activity

Transition
State State
 Pseudo States
Initial State
• Initial state
– The state entered when an
State1
object is created
– Mandatory, can only have one
initial state
• Choice Choice
– Dynamic evaluation of
subsequent guard conditions
– Only first segment has a trigger
Final State
• Final state
– Indicates the object’s end State2
of life
– Optional, may have more than
one
 Identify and Define the
States
• Significant, dynamic attributes
The maximum number of students per course offering is 10
numStudents < 10 numStudents > = 10

Open Closed

• Existence and non-existence of certain links

Professor Link to Professor Link to Professor
exists doesn’t exist

0..1
Assigned Unassigned
0..*

CourseOffering
 Identify the Events

• Look at the class interface operations

CourseOffering 0..*
Professor
+ addProfessor() 0..1
+ removeProfessor()

Events: addProfessor,
removeProfessor
 Identify the Transitions
• For each state, determine what events cause
transitions to what states, including guard
conditions, when needed
• Transitions describe what happens in response to
the receipt of an event
CourseOffering 0..*
0..1 Professor
+ addProfessor()
+ removeProfessor()

Unassigned

removeProfessor addProfessor

Assigned
 Add Activities

• Entry StateA

– Executed when the state is Entry/anAction

entered

• Do
– Ongoing execution
StateB StateC
Do/anActivity Exit/someAction
• Exit
– Executed when the state is
exited
ate Machine
Example: State machine
addStudent / numStudents = numStudents + 1
/ numStudents = 0 removeStudent [numStudents >0]/ numStudents = numStudents - 1

Unassigned

closeRegistration

cancel Canceled
addProfessor
do/ Send cancellation notices
close

removeProfessor cancel
[ numStudents = 10 ]
cancel
Full

close[ numStudents < 3 ] close

addStudent / closeRegistration [ has Professor assigned ]

numStudents = numStudents + 1 [ numStudents = 10 ]

Assigned closeRegistration[ numStudents >= 3 ] Committed

do/ Generate class roster
close[ numStudents >= 3 ]

removeStudent[ numStudents > 0] / numStudents = numStudents - 1

 Example: State Machine
superstate with Nested States and
/ numStudents = 0 Open
History closeRegistration Closed

close Canceled
Unassigned do/ Send cancellation notices

cancel
cancel
substate
Full
close[ numStudents < 3 ]
remove a professor
[ numStudents = 10 ] close
add a professor
closeRegistration [ has Professor assigned ]

closeRegistration[ numStudents >= 3 ] Committed

Assigned
do/ Generate class roster
addStudent /
numStudents = numStudents + 1

H close[ numStudents >= 3 ]

removeStudent[ numStudents > 0] / numStudents = numStudents - 1

 Which Objects Have
Significant State?
• Objects whose role is clarified by state transitions
• Complex use cases that are state-controlled
• It is not necessary to model objects such as:
– Objects with straightforward mapping to implementation
– Objects that are not state-controlled
– Objects with only one computational state
 How Do State Machines Map
to the Rest of the Model?
• Events may map to operations
• Methods should be updated with state-specific
information
• States are often represented using attributes
– This serves as input into the “Define Attributes” step

CourseOffering
- numStudents
+ addStudent()

addStudent / numStudents = numStudents + 1

Open Closed

[numStudents<10] [numStudents>=10]
State table example
 Several diagrams
for self-studying
• Dialog map
• Decision tables and decision trees
• Event-response tables
 A few words about UML diagrams

• UML diagrams: representation requirements

– Why ?
– When?
– What ?
 Use case example

Student Register for Courses Course Catalog

 Example: Sequence Diagram

: RegisterForCoursesForm : RegistrationController : CourseCatalogSystem : Course Catalog

: Student

1: // create schedule( )
2: // get course offerings( )
Create a new 3: // get course offerings(forSemester)
schedule
4: // get course offerings( )

A list of the available 5: // display course offerings( )

course offerings for this
semester are displayed

A blank schedule
is displayed for the 6: // display blank schedule( )
students to select
offerings

ref Select Offerings

ref Submit Schedule

 <<interface>>
RegistrationController ICourseCatalogSystem

+ // submit schedule () + getCourseOfferings ( [in] forSemester : Semester) : CourseOfferingList

+ // save schedule ()
+ // create schedule with offerings ()
+ // get course offerings ()
Global visibility
0..1 Schedule
0..1
- semester : Semester
0..1
+ submit ()
+ currentSchedule + //save ()
Field visibility # any conflicts? () Field
0..*
+ //create with offerings() visibility
0..* 0..*
0..1 + registrant 1
alternateCourses
0..2 0..4 + primaryCourses
Student
CourseOffering
- name
- address
- StudentID : int - number : String = "100"
- startTime : Time
+ addSchedule ( [in] aSchedule : Schedule ) - endTime : Time
+ getSchedule ( [in] forSemester : Semester ) : Schedule - day : String
+ hasPrerequisites ( [in] forCourseOffering : CourseOffering ) : boolean
# passed ( [in] aCourseOffering : CourseOffering ) : boolean + addStudent ( [in] aStudentSchedule : Schedule)
+ removeStudent ( [in] aStudentSchedule : Schedule)
+ new ()
Parameter visibility + setData ()
 <<control>>
<<boundary>> <<boundary>>
Actor 1 Actor 2

<<entity>> <<entity>>

Model interaction between the system and its environment.

 Example: Candidate
Entity Classes

Student Register for Courses Course Catalog

Student Schedule CourseOffering

 Example: Finding
Boundary Classes

Student Register for Courses Course Catalog

RegisterForCoursesForm CourseCatalogSystem
 Example: Finding Control
•
Classes
In general, identify one control class per use case.
– As analysis continues, a complex use case’s control class may evolve
into more than one class

Student Register for Courses Course Catalog

System

RegistrationController
 Modeling on agile projects

• The difference in how traditional and agile projects

perform modeling is related to when the models are
created and the level of detail in them
• The key point in using analysis models on agile projects—
or really, on any project—is to focus on creating only the
models you need, only when you need them, and only to
the level of detail you need to make sure project
stakeholders adequately understand the requirements.