CSEB233
Fundamentals of Software
Engineering
Module 3: Requirements
Engineering
(Part 2)
Badariah Solemon 2010
Objectives
1. Identify guidelines of creating requirements
analysis models.
2. Explain structured and object-oriented analysis
approaches to requirements modelling.
3. Identify three classifications of modelling
elements based on object-oriented approach.
4. Introduce use case diagram, activity diagram, class
diagram, state diagram, and sequence diagram.
Badariah Solemon 2010
Overview
Activity
Action
Communication
Task
Inception
Requirements Engineering
Req. Elicitation
Req. Analysis & Negotiation
Req. Specification
Req. Verification and Validation
Req. Management
Requirements Modeling
Design Modeling
Context Modeling
Technical Modeling
Planning
Modeling
Construction
Deployment
Badariah Solemon 2010
Requirements/Analysis Model
• A graphical representations of business processes, the
problems to be solved, and the new proposed product
(software).
• Objectives:
1.
2.
3.
•
To describe software requirements.
To establish a basis for the creation of a software design.
To define a set of requirements that can be
Software
specification
validated once the software is built.
Bridges the gap between a software
specification and a software design.
Analysis
Model
Design
Model
Badariah Solemon 2010
Rules of Thumb
• Suggested by Arlow and Neustadt in Pressman (2009):
– 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 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
Badariah Solemon 2010
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.
• 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 task should move from essential
information toward implementation detail.
Badariah Solemon 2010
*Recap from chapter 4
Domain Analysis
• According to Donald Firesmith in Pressman (2009):
“ 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 . . .”
Badariah Solemon 2010
What is Domain Analysis?
• An on-going SE activity that is not connected
to any software project (by domain analyst)
• Involves:
1. Defining the domain to be investigated.
2. Collecting a representative sample of
applications in the domain.
3. Analyzing each application in the sample.
4. Developing an analysis model for the objects.
Badariah Solemon 2010
Requirements Analysis Modeling
• Categorized into two main levels of details:
1. Context (conceptual-level) modeling*
•
•
High-level conceptual descriptions of a product and its
environment. Must be supplemented with detailedlevel models. E.g.: Architectural model
Usually usable to non-technical people and decisionmakers
2. Technical (detailed-level) modeling
* Module 4
Badariah Solemon 2010
Approaches for Technical
Modeling
1. 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
2. Object-oriented Analysis
–
–
–
model objects, classes, and the relationships and
behavior associated with them.
The industry standard for the OO modeling is known as
Unified Modelling Language (UML) specification and 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, and etc.
* Relate with generic modeling elements in Part 1.
Badariah Solemon 2010
Flow-oriented Modeling
• According to Pressman (2009):
– 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
Badariah Solemon 2010
OO Analysis Approach
• Need to first understand OO concepts, which
include objects, classes, attributes, methods,
sub-class, super-class, and etc.
• Classifications of OO modeling elements
(Pressman, 2005):
1. Scenario-based
•
•
to show how end-users interact with the system
e.g.: use-case diagram, activity diagram, swim-lane
diagram
Badariah Solemon 2010
OO Analysis Approach (cont’d)
2. Class-based
•
•
to specify classes and objects, attributes, operations,
and associations and dependencies.
e.g.: class diagram, class responsibility collaborator
(CRC) model, collaboration diagram.
3. Behavioral
•
•
to model how the system reacts to external event .
e.g.: event-driven use case, state diagram, sequence
diagram.
Badariah Solemon 2010
Scenario-based Modelling:
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 (usecases).”
• Elements:
1. 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.
Badariah Solemon 2010
Scenario-based Modeling:
Use Case (cnt’d)
2. 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 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.
Badariah Solemon 2010
Use Case: Example #1
University Library System
Badariah Solemon 2010
Use Case: Example #2
• Airline Reservation System
Airline Reservation System
Check In Passenger
Ticket Clerk
Add New Reservation
Cancel Reservation
Badariah Solemon 2010
Relationships of Use Cases
1. 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.
For example, in the Airline Reservation System, the ‘Add New
Reservation’ use case uses ‘Check Space Availability’ and ‘Record
Passenger Information’ use cases.
2. 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.
For example, in the Airline Reservation System, there are two ways to
assign a seat either by assigning a window seat or by assigning an
Badariah Solemon 2010
aisle seat.
Relationships of Use Cases:
Example #1
Airline Reservation System
«uses»
A
B
Weigh Luggage «extends»
«uses»
Check In Passenger
B
«uses»
B
«uses»
Ticket Clerk
Add New
Reservation
Assign Window
Seat
«extends»
Assign Seat
A
A
A
Assign Aisle
Seat
Check Seat Availability
B
Cancel Reservation
Record Passenger
Information
Badariah Solemon 2010
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 the how those activities depend on
one another.
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.
Badariah Solemon 2010
Activity Diagram: Example #1
ent er password
and user ID
• Pressman (2009),
pp 162
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
Badariah Solemon 2010
Scenario-based Modeling:
Swimlane Diagram
•
•
A variation of activity diagram.
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.
Badariah Solemon 2010
Swimlane: Example #1
homeowner
• Pressman (2009),
pp 163
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
select ed
prom pt f or reent ry
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
Badariah Solemon 2010
(http://edn.embarcadero.com/article/31863
Swimlane: Example #2
Badariah Solemon 2010
Class-based Modeling:
Class Diagram
1. Depicts a collection of system’s classes, their
attributes, and the relationships between the
classes.
2. 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).
Badariah Solemon 2010
Class Diagram: Example #1
• To model a class, use a rectangle with three sections:
1.
2.
3.
•
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
Badariah Solemon 2010
Class Diagram: with Several Classes
• Need to show how they are related to each other.
• Two basic types of relationships between classes:
1. Associations
•
•
•
•
This relationship exists when two classes are related to each
other in any way
You may need to analyse further this relationship by identifying
multiplicity of the association because there is possibility that a
students might register for none, one, or several courses.
Among the potential multiplicity indicators: (next page)
There exist other types of associations such as association class,
aggregation (basic and composition), reflexive associations, and
realisation. For further explanation, refer to OMG (2009).
Badariah Solemon 2010
Class Diagram: with Several Classes
(cnt’d)
Indicator Meaning
0..1
1
0..*
1..*
N
0..n
1..n
•
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)
Example:
Student
StudentID
Firstname
Lastname
Email
ContactNumber
Registered
0..*
0..*
attended by
Course
CourseCode
CourseName
CreditHours
Fees
RegisterCourse()
DropCourse()
PrintTranscript()
Badariah Solemon 2010
Class Diagram: with Several Classes
(cnt’d)
2. 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.
Badariah Solemon 2010
Postgraduate
ProjectTitle
ThesisSubmitDate
Class Diagram: with Several Classes
(cnt’d)
•
Example:
Student
0..*
Registered
attended by
0..*
StudentID
Firstname
Lastname
Email
ContactNumber
Course
CourseCode
CourseName
CreditHours
Fees
RegisterCourse()
DropCourse()
PrintTranscript()
Undergraduate
CreditLimit
* ATM Case Study
Postgraduate
ProjectTitle
ThesisSubmitDate
Badariah Solemon 2010
Postgraduate
ProjectTitle
ThesisSubmitDate
Class Diagram: Example
–
Models a customer order from a retail catalog
(http://edn.embarcadero.com/article/31863)
Badariah Solemon 2010
Class-based Modeling: CRC
•
•
Wir (1990): CRC modeling provides a simple
means for identifying and organizing the
classes that are relevant to system or product
requirements.
Ambler (1995): “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.”
Badariah Solemon 2010
Postgraduate
ProjectTitle
ThesisSubmitDate
CRC: Example
• Pressman (2009)
Class:
Class:
Descript
ion:
Class:
Descript
ion: FloorPlan
Class:
Descript ion:
Responsibility:
Descript ion:
Responsibility:
Responsibility:
Responsibility:
Collaborator:
Collaborator:
Collaborator:
Collaborator:
def ines f loor plan name/ ty pe
manages f loor plan posit ioning
scales f loor plan f or display
scales f loor plan f or display
incorporat es walls, doors and windows
Wall
shows posit ion of v ideo cameras
Camera
Badariah Solemon 2010
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
Badariah Solemon 2010
The States of a System
•
•
•
•
State —a set of observable circum-stances 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
Badariah Solemon 2010
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
Badariah Solemon 2010
State Representations (cnt’d)
• The state of a class takes on both passive and active
characteristics (de Champeaux et. al. in Pressman (2009)).
– 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.
Badariah Solemon 2010
State Diagram
•
Notations:
1.
2.
3.
4.
5.
6.
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
Badariah Solemon 2010
State Diagram: Example #1
•
http://edn.embarcadero.com/article/31863
Badariah Solemon 2010
Statechart Diagram: Example #2
• State Diagram for the ControlPanel Class (Pressman,
2009)
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
Badariah Solemon 2010
Behavioral Modeling:
Sequence Diagram
• An interaction diagram that details how
operations are carried out -- what
messages are sent and when.
• Are organized according to time. The
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.
Badariah Solemon 2010
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 dogeared rectangle
Badariah Solemon 2010
Sequence Diagram: Example #1
• Pressman (2009)
cont rol panel
homeowner
syst em
ready
A
sensors
sensors
syst em
reading
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
Badariah Solemon 2010
Sequence Diagram: Example #2
•
•
A sequence diagram for making a hotel reservation
http://edn.embarcadero.com/article/31863
Badariah Solemon 2010
Summary
You have been introduced to:
1.
2.
3.
4.
Guidelines of creating requirements analysis models.
Two approaches to requirements modelling: structured
and object-oriented analysis approaches.
Three classifications of modelling elements based on
object-oriented approach.
Overview of several OO modeling elements such as use
case diagram, activity diagram, class diagram, state
diagram, and sequence diagram.
Badariah Solemon 2010