1. B. Computer Science (SE) (Hons.)
CSEB233: Fundamentals of
Software Engineering
Requirements
Engineering: Modeling
2. Objectives
Identify guidelines of creating requirements
analysis models
Explain structured and object-oriented analysis
approaches to requirements modeling
Identify three classifications of modeling elements
based on object-oriented approach
Apply use case diagram, activity diagram, class diagram, state diagram, and sequence diagram
5. Requirements/Analysis Model
A graphical representation of
business processes,
the problems to be solved, and
the new proposed product (software)
Objectives
To describe software requirements
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
Bridges the gap between a software
specification and a software design
Software
specification
Analysis
Model
Design
Model
6. Rules of Thumb
Suggested by Arlow and Neustadt:
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
7. Rules of Thumb
Suggested by Arlow and Neustadt:
Minimize coupling throughout the system
Be sure that the analysis model provides value to all
stakeholders
Keep the model as simple as possible especially if
extra diagrams do not provide new information
8. Requirements Modeling Principles
Principle #1:
The information domain of a problem must be
represented and understood
Principle #2:
The functions that the software performs must be
defined
Principle #3:
The behavior of the software, as a consequence of
external events, must be represented
9. Requirements Modeling Principles
Principle #4:
The models that depict information, function, and
behavior must be partitioned in a manner that
uncovers detail in a layered (or hierarchical) fashion.
Principle #5:
The analysis of task should move from essential
information toward implementation detail
11. What is Domain Analysis?
According to Donald Firesmith:
“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 . . .”
12. What is Domain Analysis?
An on-going SE activity that is not connected to
any software project (by domain analyst)
Involves:
Defining the domain to be investigated
Collecting a representative sample of applications in
the domain
Analyzing each application in the sample
Developing an analysis model for the objects
13. Requirements Analysis Modeling
Categorized into two main levels of details:
Context (conceptual-level) modeling*
High-level conceptual descriptions of a product and its
environment.
Must be supplemented with detailed-level models, e.g.:
architectural model
Usually usable to non-technical people and decisionmakers
Technical (detailed-level) modeling
14. Technical Modeling Approaches
Structured Analysis
Considers data and the processes that transform the
data as separate entities.
Includes data models, data flow models and
behavioral models
e.g., ERD, DFD, state machine model
15. Technical Modeling Approaches
Object-oriented Analysis
model objects, classes, and the relationships and
behavior associated with them
The industry standard for OO modeling is the Unified
Modeling Language (UML) specification
The current available version is 2.2 (OMG, 2009).
e.g., use-case diagrams, activity diagrams (swim-lane
diagram), sequence diagram, class diagram, state
diagram, etc.
17. Flow-oriented Modeling
Represents how data objects are transformed as
they move through the system
Data flow diagram (DFD) is the diagrammatic
form that is used
Considered by many to be an “old school”
approach, but continues to provide a view of the
system that is unique
It should be used to supplement other analysis
model elements
18. OO Analysis Approach
Need to first understand OO concepts, which
include objects, classes, attributes, methods, subclass, super-class, etc.
Classifications of OO modeling elements:
Scenario-based
to show how end-users interact with the system
e.g., use-case diagram, activity diagram, swimlane diagram
19. OO Analysis Approach
Class-based
to specify classes and objects, attributes, operations, and
associations and dependencies
e.g., class diagram, class responsibility collaborator (CRC)
model, collaboration diagram
Behavioral
to model how the system reacts to external event
e.g., event-driven use-case, state diagram, sequence
diagram
20. 1. Scenario-based Modeling
Use Case
Ivar Jacobson:
“[Use-cases] are simply an aid to defining what exists
outside the system (actors) and what should be
performed by the system (use-cases)”
Elements:
Actor
a „stick figure‟ that represent roles of people, other system
(database, servers, and legacy systems) or equipment that
interact with use cases in the system.
21. 1. Scenario-based Modeling
Use Case
Use case
an oval shape labeled with the use case name (inside or
outside the oval) that represent a complete unit of system
functionality
A use case may be made up of a set of scenario
Each scenario describes the steps that consist of an
interaction between the actors and the system
Just like DFDs, you can continue to add detail by
breaking the uses cases into more use cases
22. Use Case
Example 1
Use case diagram for SafeHome System
Saf eHome
Access camera
surveillance via t he
Int ernet
Conf igure Saf eHome
syst em paramet ers
homeowner
Set alarm
cameras
23. Use Case
Example 2
Airline Reservation System
Airline Reservation System
Check In Passenger
Ticket Clerk
Add New Reservation
Cancel Reservation
24. Relationships of Use Cases
Uses
An arrow drawn from use case A to use case B to
indicate that in the process of completing functionality
A, functionality B will be performed too
e.g.,, in the Airline Reservation System, the „Add New
Reservation‟ use case uses „Check Space Availability‟
and „Record Passenger Information‟ use cases
25. Relationships of Use Cases
Extends
An arrow drawn from use case A to use case B to
indicate that the use case A is a special way of doing
use case B and must be done to complete use case B
e.g., in the Airline Reservation System, there are two
ways to assign a seat either by assigning a window
seat or by assigning an aisle seat
26. Relationships of Use Cases
Example 1
Airline Reservation System
«uses»
Weigh Luggage «extends»
«uses»
Assign Window
Seat
«extends»
Check In Passenger
Assign Seat
«uses»
Assign Aisle
Seat
«uses»
Ticket Clerk
Add New
Reservation
Cancel Reservation
Check Seat Availability
Record Passenger
Information
27. 1. Scenario-based Modeling
Activity Diagram
Supplements the use case by providing a graphical
representation of the flow of interaction within a
specific scenario
Activity diagrams and statechart diagrams are related
While a statechart diagram focuses attention on an object
undergoing a process (or on a process as an object), an
activity diagram focuses on the flow of activities involved
in a single process
The activity diagram shows how those activities depend
on one another
28. 1. Scenario-based Modeling
Activity Diagram
UML‟s basic symbols:
Symbol
Purpose
To represent an activity
To represent a flow
To represent branching decisions
To indicate all parallel activities within the system.
29. Activity Diagram
Example 1
ent er password
and user ID
valid passwor ds/ ID
invalid passwor ds/ ID
selec t major f unc t ion
prompt f or reent ry
ot her f unct ions
m ay also be
select ed
input t r ies r em ain
selec t surv eillanc e
no 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
30. 1. Scenario-based Modeling
Swimlane Diagram
A variation of activity diagram
Represents the flow of activities described by the usecase, 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
31. Swimlane
Example 1
homeowner
c a m e ra
i n t e rf a c e
ent er password
and user ID
valid p asswo r d s/ ID
in valid
p asswo r d s/ ID
select m ajor f unct ion
o t h er f u n ct io n s
m ay also b e
prom pt f or reent ry
select ed
in p u t t r ies
select surveillance
r em ain
n o in p u t
t r ies r em ain
t h u m b n ail views
select a sp ecif ic cam er a
select specif ic
cam era - t hum bnails
select cam era icon
generat e video
out put
view cam era out put
in labelled window
prom pt f or
anot her view
exit t h is
f u n ct io n
see
an o t h er
cam er a
33. 2. Class-based Modeling
Class Diagram
Depicts a collection of system‟s classes, their
attributes, and the relationships between the
classes
A class is an object applicable to a system
You can think of an object as any person, thing, place,
concept, event, and etc.
Objects have attributes (information stored about and
object or variables for OO programming) and methods
or operations (things an object perform)
34. Class Diagram
Example 1
To model a class, use a rectangle
with three sections:
name of the class (top)
list of attributes (middle)
methods (bottom).
Example:
a Student class which has attributes
StudentID,
Firstname, Lastname,
Email, and ContactNumber.
Student perform operations such as
RegisterCourse, DropCourse, and
PrintTranscript.
Student
StudentID
Firstname
Lastname
Email
ContactNumber
RegisterCourse()
DropCourse()
PrintTranscript()
Name of
class
List of
attributes
List of
methods
35. Class Diagram
With Several Classes
Need to show how they are related to each other
Two basic types of relationships between classes:
Associations
This relationship exists when two classes are related to each
other
Analyze this relationship further by identifying multiplicity of the
association because there is possibility that a student might
register for none, one, or several courses
Some potential multiplicity indicators: (see next slide)
There are other types of associations such as association class,
aggregation (basic and composition), reflexive associations, and
realization.
For further explanation, refer to OMG (2009).
36. Class Diagram
With Several Classes
Example:
Student
StudentID
Firstname
Lastname
Email
ContactNumber
RegisterCourse()
DropCourse()
PrintTranscript()
Indicator
0..1
1
0..*
1..*
N
0..n
1..n
Meaning
Zero or one
One only
Zero or more
One or more
Only n (where n > 1)
Zero to n (where n > 1)
One to n (where n > 1)
0..*
attended by
Registered
0..*
Course
CourseCode
CourseName
CreditHours
Fees
37. Class Diagram
With Several Classes
Inheritance/Generalisation
Different classes usually share the same attributes and/or
methods
To avoid repeating the same attributes and/or methods,
you need to take advantage of the inheritance (also known
as generalisation) mechanism
When class X inherits from class Y, you may say that X is
the subclass of Y and Y is the superclass of X
UML‟s notation for inheritance is a line with upward
arrowhead pointing from the subclass to the superclass
38. Class Diagram
With Several Classes
Example
Student
StudentID
Firstname
Lastname
Email
ContactNumber
RegisterCourse()
DropCourse()
PrintTranscript()
Undergraduate
CreditLimit
0..*
Registered
Course
attended by
0..* CourseCode
CourseName
CreditHours
Fees
Postgraduate
ProjectTitle
ThesisSubmitDate
39. Class Diagram: Example
Models a customer order from a retail catalog
(http://edn.embarcadero.com/article/31863)
40. 2. Class-based
Modeling
CRC
CRC modeling provides a simple means for
identifying and organizing the classes that are
relevant to system or product requirements
(Wir, 1990)
A CRC model is really a collection of standard index
cards that represent classes
The cards are divided into three sections
Along the top of the card you write the name of the class
In the body of the card you list the class responsibilities on
the left and the collaborators on the right
(Ambler, 1995)
41. CRC: Example
Class:
Class:
Descrip tion:
Class:
Descrip tion: FloorPlan
Class:
Descrip tion:
Responsibility:
Descrip tion:
Responsibility:
Responsibility:
Responsibility:
Collaborator:
Collaborator:
Collaborator:
Collaborator:
defines floor plan name/type
manages floor plan positio ning
scales f lo or plan for display
scales f lo or plan for display
incorporates w alls , doors and w indow s
Wall
show s position of video cameras
Camera
42. 3. 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, also known as statechart
diagram or a sequence diagram
43. 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
44. 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
45. State Representations
The state of a class takes on both passive and
active characteristics
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
46. State Diagram
Notations:
States are rounded rectangles
Transitions are arrows from one state to another
Events or conditions that trigger transitions are written
beside the arrows
The initial state (black circle) is a dummy to start the
action
Final states (2 circles with inner black circle) are also
dummy states that terminate the action
The action that occurs as a result of an event or condition
is expressed in the form/action
e.g., Cancel/Quit
48. Statechart Diagram
Example 1
State Diagram for the ControlPanel Class
t imer < lockedTime
t imer > lockedTime
locked
password = incorrect
& numberOfTries < maxTries
comparing
reading
numberOfTries > maxTries
key hit
password
ent ered
do: validat ePassw ord
password = correct
select ing
act iv at ion successful
49. 3. Behavioral Modeling
Sequence Diagram
An interaction diagram that show how operations
are carried out - what messages are sent and
when
Are organized according to time
Time progresses as you go down the page
The objects involved in the operation are listed
from left to right according to when they take part
in the message sequence
50. Sequence Diagram
Each vertical dotted line is a lifeline, representing
the time that an object exists
Each arrow is a message call
An arrow goes from the sender to the top of the
activation bar of the message on the receiver's lifeline
The activation bar represents the duration of
execution of the message
The diagram has a clarifying note, which is text
inside a dog-eared rectangle
51. Sequence Diagram
Example 1
co nt rol panel
homeowner
syst em
ready
A
sensors
sensors
syst em
readin g
password ent ered
request lookup
comparing
result
password = correct
request act ivat ion
num berOf Tries > m axTries
locked
A
t imer > lockedTime
select ing
act ivat ion successful
act ivat ion successful
Figure 8 .2 7 Sequence diagram (part ial) f or Saf eHome securit y f unct ion
52. Sequence Diagram
Example 2
A sequence diagram for making a hotel reservation
http://edn.embarcadero.com/article/31863
53. Summary
You have been introduced to:
Guidelines of creating requirements analysis models.
Two approaches to requirements modeling
structured
object-oriented analysis
Three classifications of modeling elements based on
object-oriented approach
Several OO modeling elements such as use case
diagram, activity diagram, class diagram, state
diagram, and sequence diagram
