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.
