KK24503 REQUREMENTS

ENGINEERING
SEMESTER 1 2023/2024
- MODEL BASED REQUIREMENTS SPECIFICATION-
  Gain an overview of a set of requirements

 Understand relationships and inter- connections between

requirements

 Focus on some aspect of a system, abstracting from the

MOTIVATION rest
why do we
model Primarily for
requirements? functional
requirements
Quality requirements
and constraints are
mostly specified in
natural language
 DEFINITION. Model – an abstract representation of an
existing part of reality or a part of reality to be created.
The notion of reality includes any conceivable set of
elements, phenomena or concepts, including other
MODELS IN models.
RE With respect to a model, the modeled part of reality
is called the original.
 Requirements models are problem-oriented
models of the system to be built
 Architecture and design information is omitted
 O Specifying requirements (as a means of
replacing textually represented requirements)
O Paraphrasing textually represented
requirements to improve
Requirement understanding of complex structures
s models and dependencies
can be used
O Testing textually represented
for
requirements to uncover omissions,
ambiguities and inconsistencies
O Decomposing a complex reality into
comprehensible parts
 m Structure and Data
l Structural properties of a system, particularly of
the static data
l Structure of a system’s domain
m Function and Flow
Sequence of actions and control / data flow for
l producing a required result

Which l describing a (business) process

m State and Behavior
aspects Behavior of a system or a domain component

can be l State-dependent reactions to events

l Dynamics of component interaction
modeled? m Context and boundary
l Structural embedding of system in its environment
l Interaction between system and actors in the
context
m Goals
Understanding the goals for a system
l Goal decomposition
l Goal-agent networks
Methods for
Requirements
Engineering
 1. To explain the role of methods and
techniques in requirements
engineering
2. To introduce data-flow modelling
3. To introduce semantic data
Objectives modelling
4. To introduce
object-oriented methods
5. To explain the role of formal
methods in requirements
engineering
7
  Process of requirements engineering (RE)
Role of is usually guided by a requirements
methods in RE method
 Requirement methods are systematic
ways of producing system models
 System models important bridges
between the analysis and the design
process

8
 1. Suitability for agreement with the end-user
 Indicates the extent to which the notation is understandable by
someone without formal training
 Solution integrate both formal and informal description of the
system requirements

2. The precision of definition of its notation

Necessary 

Check for consistencies and correctness using the notation
Imprecise notation  errors and misunderstanding
properties 3. Assistance with formulating requirements
for a RE  Processes involves capture, structuring, analysis and resolution of many
ideas, perspectives and relationships at varying level of detail
method  Solution  must use proper technique to handle all these tasks

4. Definition of the world outside

 Requirements model is complete once all the components which it
interacts with is modelled.
 Solution  understand the real problem that will reflect the actual
needs of the users.

9
 5. Scope for malleability
 Accommodate changes to the requirements without the need to re-
work the entire set of requirements.

6. Scope for integrating other approaches

 No COMPLETE approach or technique that adequately represents all
the system requirements
 DFD  may not represent the control requirements
Necessary  Formal language  may not express non-functional requirements
sufficiently.
properties for  Solution  support incorporation of other modeling technique
when applicable and needed
a RE
7. Scope for communication
method  RE processes involve human process
 Solution  support the need to communicate ideas and problems

8. Tool support
 Manage complexity on large projects, too many information to
manage and analyzed.
 Solution  find the most effective and affordable CASE tool

10
  There is no ideal requirement method
No ideal RE
 A number of methods use a variety of
method
modelling techniques to formulate
system requirements
 System models can be enriched by
modelling different aspects of using
modelling techniques

11
 1. Data-flow models
 Show processes at different stages.

2. Compositional models
 ERDs are used to show entities and its relationships.

:: Modelling 3. Classification models

 Class/Object/inheritance diagrams may be used to represent
techniques :: common attributes among entities.

4. Stimulus-response models
 State Transition Diagrams are used to show how the system
reacts to events

5. Process models
 Used to model the principal activities and deliverables involved.

12
  Based on the notion that systems can be modelled as a
set of interacting functions
 Uses data-flow diagrams (DFDs) to graphically
represent the external entities, processes, data-flow,
and data stores

1. Data flow
modelling Transform

Input Output Terminator

Data dictionary

13
  There is little uniformity in industry concerning
the DFD notation
 The notation shown was advanced by DeMarco
 Gane and Sarson (1979) use :
 Squares representing external entities, which are
sources or destinations of data.
Notation  Rounded rectangles representing processes, which
variability take data as input, do something to it, and output
it.
 Arrows representing the data flows, which can
either be electronic data or physical items.
 Open-ended rectangles representing data stores,
including electronic stores such as databases or
XML files and physical stores such as or filing
cabinets or stacks of paper.

14
  Orr uses rectangles for bubbles, ellipses for
sources and destinations, and ellipses for
data stores
 Tips :
 All processes must have at least one data flow in
and one data flow out.
Notation  All processes should modify the incoming data,
variability producing new forms of outgoing data.
 Each data store must be involved with at least
one data flow.
 Each external entity must be involved with at
least one data flow.
 A data flow must be attached to at least one
process.

15
 These diagrams show a group of related
sets:
1. Context Diagram: This is the highest
level and represents the overall system
and its interaction with its environment
DFD : How it 2. Level 0 Diagram: This shows the major
looks like? subsystems and their interactions
3. Level x Diagram: Shows the processes
that make up each of the major
subsystems
4. Level x.y Diagram: Shows detail of the
above diagrams

16
  Consider a simple library system
intended to automate the issuing of
library items
 The first DFD derived by the analyst
represents the ‘target’ system at its
DFD example context level
 The next level (level 1) of the data-flow
diagram is constructed by decomposing
the library system bubble into sub-
functions

17
 Library card
Return date Library
Requested item Issue library
Library item assistant
user
Issued item

Context Diagram for Issue Library Item System

18
MSS
Context
DFD

9-19
 User database

user details
update details
Library
card update
Check
user

Library
user
details

UserID What is missing?

example - Library
user
User status

Level 1 data
requested
ItemID
item Check
Item

flow diagram
item
status
issued return date
Issue Library
item
item assistant

item details
Update details

Item database
Common
Process Errors
on DFDs

9-21
Data Flows to
and from Data
Stores

9-22
  A data flow
should never go
unnamed.
 In logical
Rules for modeling, data
flow names
Data should describe
the data flow
Flows without
describing the
implementation
 All data flows
must begin
and/or end at a
process.

9-23
Structured
Analysis
Diagram
Progression
(1 of 3)

9-24
Structured
Analysis
Diagram
Progression
(2 of 3)

9-25
Structured Analysis Diagram Progression (3 of 3)

9-26
 Balancing - a concept that requires that
data flow diagrams at different levels of
detail reflect consistency and
completeness
Balancing  Quality assurance technique
 Requires that if you explode a process to
another DFD to reveal more detail, you
must include the same data flows and data
stores

9-27
  The data-flow approach is typified
by the Structured Analysis method
(SA)
Structured  Two major strategies dominate
analysis structured analysis
1. ‘Old’ method popularised by
DeMarco
2. ‘Modern’ approach by Yourdon-
read article in the internet

28
  A top-down approach
 The analyst maps the current physical
system onto the current logical data-flow
model
 The approach can be summarised in four
1. DeMarco steps:
 Analysis of current physical system
 Derivation of logical model
 Derivation of proposed logical model
 Implementation of new physical system

29
Distinguishes between user’s real needs and
those requirements that represent the
external behaviour satisfying those needs

2. Modern
Includes real-time extensions structured
analysis
Structured Analysis and
Other structured Design Technique (SADT)
analysis approaches Structured Systems
Analysis and Design
include: Methodology (SSADM)

30
Data may also be Specifies data as a set
of tables, with some
modelled using the columns being used as
relational model common keys

Disadvantages of Implicit data typing 2. Relational

Inadequate modelling
relational model of relations model

Data model should include information

about the semantics of the data

31
  Approaches to semantic data modelling include:
 Entity-relationship model (Chen, 1976)
 Relational Model/Tasmania (RM/ T) (Codd, 1979)
 Semantic Database Model (SDM) (Hammer and
Semantic McLeod, 1981)
model
 Models identify the entities in a database, their
attributes and their relationships
 Uses graphical notations

32
 <Name>
<Name>
An Entity An Entity

Notation for <Input cardinality>

semantic data
modelling <Name>

<Output cardinality>

A relation between entities An inheritance relation

33
  The basic ERM has been extended to
include sub and super-types to the
basic entity and relation primitives
Extensions to  Types may have sub-types
entity  Types may inherit the attributes of
relationship their super-types
model (ERM)  In addition, sub-types may have
private attributes

34
Identifier Source Description Type Priority

Requirement Specification
1

has
(0,N)
1,N
N
Identifier Changes result in Version

description author

rationale

35
  Closest originator is entity relationship model
 Requirements methods based on object orientation:
 Shlaer and Mellor (1988)
 Colbert (1989)
3. Object-  Coad and Yourdon (1989)
 Wirf-Brock (1990)
oriented
 Rumbaugh (1991)
approaches  Jacobson (1992)
 Martin-Odell (1992)
 Notations for the various methods are semantically
similar

36
  Are major actors, agents, and servers in the
problem space of the system
 Identified by analysing the domain
 Objects include:
Object  Devices that the system interacts with
 Systems that interface with the system under study
 Organisational units
 Things that must be remembered over time
 Physical locations or sites
 Specific roles played by humans

37
  Object and Class
 Encapsulation
Basic concepts  Inheritance
 Operations or Services

38
  Something real or abstract about
which we store data and those
operations that manipulate the data
Object  Examples include:
definition An account, a sensor, a software design,
a car, an organisation
 May be composite - composed of
other objects

39
  An implementation of an object type
 The object type Bank Customer refers to a
class of bank customers
 Objects that share common attributes and
Class operations
definition  An object is an instance of a class
 For example, if “John Smith” is a bank
customer, then bank customer is the class
and “John Smith” is an instance of the bank
customer

40
  Used to read and manipulate the data of an
object
 Reference only the data structures of that object
type
Operations  To access the data structures of another object,
and methods objects must send messages to that object
 Methods specify the way in which operations
are encoded in software

41
  Packaging together of data and operations
that manipulate the data
 Details of how the operation is performed
Encapsulation hidden from user
 Prevents the unauthorised access of an
object’s data

42
  Objects at a lower level in class hierarchy
inherit the operations and attributes of
their parent(s)
Inheritance  Objects are able to incorporate data
and/or operations specific to themselves
 Inherits data from more than one parent
is called multiple inheritance.

43
 Class definition Class:
Library item

Attributes classmark
title

catalogue
Operations Object inherits attributes
Illustration of acquire
loan and methods of parent class
object Generalisation

concepts Book

author Encapsulation of
publisher data and operations
year into a single object

operation1
operation 2
44
  Objects communicate by sending messages
 Message comprises:
 Name of receiver object
 Operation to be invoked
Messages  Optional set of parameters
 When an object receives a message it causes an
operation to be invoked
 The operation performs the appropriate method

45
 Message 1:
Object: to:ObjectY
ObjectX operation: 12
parameters: a,b
attribute 1
attribute 2
attribute 3 Object:

Message operation 1
operation 2
ObjectY

passing operation 3 attribute 12

attribute 13
attribute 14
operation 12
operation 13
operation 14

46
  A library system is intended to provide its users with
the ability to automate the process of:
 Acquiring library items
 Cataloguing library items
 Browsing library items
Object  Loaning library items

modelling -  Library items comprise published and recorded

Library material
example  The system will be administered by a member of the
library staff
 Users must register with the system administrator
before they can borrow library items

47
  Library users are drawn from three primary
groups:
Students, Members of staff and External users
 All library users have as part of their
Library registration:
example Name, Library number, Address, Account
(contd.)  In addition, the following information also
required for registration:
Students - Degree programme and admission number.
Staff - Staff number
External users - Employer details

48
  Most methods based on the object-oriented
model share certain common analysis steps:
 Identify core objects
Steps in  Construct the object structures defining the
object- associations between object classes
 Define the attributes associated with each object
oriented  Determine the relevant operations for each object
method  Define the messages that may be passed between
objects

49
 <Class name>
Object-
oriented <Attributes>

notation used <Operations>

(i) Class (ii) Generalisation (iii) Aggregation

50
Step 1 - Initial Account
classes Library user Library item Library staff

identified

51
  We can identify the following relationships from
the partial requirements:
(i) A library user borrows a library item
(ii) A library item is recorded or published
Step 2 - (iii) The system administrator registers the
Relationships library user
between (iv)
users
Library users are students, staff and external

classes (v) The system administrator catalogues the

library items
(vi) The library assistant issues the library items

52
  Try to find how many classes are involved
in this scenario.
Step 2 - Basic
object model  Draw relationship among the classes.
showing  Put the cardinalities for each
attributes and relationship.
relationships  Review the class diagram and make
corrections if needed.

53
  Attributes can be revealed by the analysis of the
system requirements
 For example, it is a requirement that all library users
must be registered before they can use the library
Step 3 -  This means that we need to keep registration data about library users

Identifying the  Library users may also be provided with an account to keep track of the
items loaned to them
attributes  Library item has the attributes; title, description and
classmark
 The library user class has the attributes; name,
address and library id

57
  This step is intended to describe operations to be
performed on the objects
 Certain operations are implicit from the object
structure
Step 4 - Object  These include operations for accessing and
modifying the attribute values. These operations are
operations assumed and we need not show them explicitly in
the model
 One way of identifying operations is by
modelling the messages that may be passed
between the objects

58
 1. issue
2. return
3. browse
Library user Library item

Step 4 -
Messages 1. acquire
1. register
between objects 2. query
2. catalogue
3. dispose
Library staff

59
 Library user

Name Account
Address
Step 4 - Library id
loaned item id
due date
Operations for register
query
compute fine

library user
and library
staff Student Staff External

Degree programme Employer name

Admission number Staff number
Employer address

60
 Library item

Title
Classmark

acquire
issue
return
dispose
catalogue

Step 4 -
Operations for Published item Recorded item

library item Publisher

Year
Format
Length of play
Contents

Book Journal
Author Volume
ISBN number Issue

61
 Polymorphism – the concept
that different objects can
respond to the same message in
different ways.

Polymorphism Override – a technique whereby

a subclass (subtype) uses an
attribute or behavior of its own
instead of an attribute or
behavior inherited from the
class (supertype).

10-62
  There are three classifications of UML diagrams:
1. Behavior diagrams. A type of diagram that depicts
behavioral features of a system or business process. This
includes activity, state machine, and use case diagrams as
well as the four interaction diagrams.
2. Interaction diagrams. A subset of behavior diagrams
UML 2.0 which emphasize object interactions. This includes
communication, interaction overview, sequence, and
timing diagrams.
3. Structure diagrams. A type of diagram that depicts the
elements of a specification that are irrespective of
time. This includes class, composite structure,
component, deployment, object, and package diagrams.

63
UML 2.0|
Structural,
Behavioral Static or Structural
Diagrams
Behavioral
Modelling Diagrams
Interaction Diagram
• Sequence Diagram,
and • Class Diagram,
• Object Diagram,
• Use Case Diagram (used
by some methodologies
• Communication
Diagram,
Interaction • Component Diagram,
• Composite Structure
during requirements
gathering);
• Timing Diagram, and
• Interaction Overview

Diagrams Diagram,
• Package Diagram, and
• Activity Diagram, and
• State Machine Diagram.
Diagram.

• Deployment Diagram.

64
 Diagram Description
Class Depicts the system's object structure. It shows
object classes that the system is composed of as
well as the relationships between those object
UML 2.0 classes.
Diagrams | Object Similar to a class diagram, but instead of depicting
object classes, it models actual object instances
Static or with current attribute values. The object diagram
provides the developer with a "snapshot" of the
Structural system's object at one point in time.
Diagrams
Component Depicts the organization of programming code
divided into components and how the components
interact.

10-65
 Diagram Description
Composite Decomposes internal structure of class,
Structure component, or use case.
UML 2.0 Deployment Depicts the configuration of software
components within the physical
Diagrams | architecture of the system's hardware
"nodes."
Static or
Structural Package Depicts how classes or other UML
constructs are organized into packages
Diagrams (corresponding to Java packages or C++
and .NET namespaces) and the
dependencies of those packages.

10-66
 Diagram Description
Use Case Depicts interactions between the system and external
systems and users. In other words it graphically
describes who will use the system and in what ways
UML 2.0 the user expects to interact with the system. The use-
case narrative is used in addition to textually describe
the sequence of steps of each interaction.
Diagrams |
Behavioral Activity Depicts sequential flow of activities of a use case or
Modelling business process. It can also be used to model logic
with the system.
Diagrams State Models how events can change the state of an object
Machine over its lifetime, showing both the various states that
an object can assume and the transitions between
those states.

10-67
 Diagram Description
Sequence Graphically depicts how objects
interact with each other via messages
in the execution of a use case or
UML 2.0 operation. It illustrates how messages
are sent and received between objects
Diagrams | and in what sequence.
Interaction Communication (Collaboration diagram in UML 1.X)
Depicts interaction of objects via
Diagram messages. While a sequence diagram
focuses on the timing or sequence of
messages, a communication diagram
focuses on the structural organization
of objects in a network format.

10-68
 Diagram Description
Interaction Combines features of sequence
Overview and activity diagrams to show
UML 2.0 how objects interact within each
Diagrams | activity of a use case.
Interaction Timing Another interaction diagram
that focuses on timing
Diagram constraints in the changing state
of a single object or group of
objects. Especially useful when
designing embedded software
for devices.

10-69
 Object operations may also be identified by
modelling event scenarios for the different
functions provided by the system
Use case and
event • Events are then traced to objects that react to them
scenarios
Typically scenarios model the interactions
between the users and the system

70
 <<uses>>
access services user permissions

Typical use- Library user

<<uses>>
search criteria
case scenario browse item

for library register user

system
Library staff <<extends>>

Use Case set permissions

71
 Library User (LU) System Library staff
Requests library item (1) Scans in LU registration (2)

accepts registration (3)

Event scenario rejects registration (3)
for borrowing verifies item loan to LU (4)

item loans item (5)

denies loan (5)

72
 Requirements specification techniques can be
categorised on a “formality” spectrum

Semi-formal and informal methods

Formal • Use natural language, diagrams, tables and simple notation
methods • Include structured analysis and object-oriented analysis

Formal methods include:

• Based on mathematically formal syntax and semantics
• Include Z, B, VDM, LOTOS

74
Formal
1 2 3
methods Provide a means for
achieving a high degree
Do not absolute
guarantee of
Have little directly to
offer to the problems of
(contd.) of confidence that a
system will conform to
correctness managing software
projects
its specification • However, benefits can be gained
from gaining a clear
understanding of the task at an
early stage

75
 Syntax that defines the specific notation
with which the specification is
represented
Components
Semantics that help to define a “universe
of formal of objects” that will be used to describe
specification the system
language
Relations which define the rules that
indicate which objects properly satisfy the
specification

76
 Formal methods are not widely used
amongst software developers

Formal Factors contributing to slow

methods not acceptance of formal methods:
widespread
• Difficulty in understanding the notations
• Difficulty in formalising certain aspects of
requirements
• Payoff is not obvious.

77
 The number of formal specification languages in use
today can be broadly divided into two categories.

Formal Model-based notations

specification • Z and Vienna Development Method (VDM)
languages
Process algebras -based notations
• Communicating Sequential Processes (CSP), CCS and LOTOS

78
 Removes ambiguity

Advantages of Encourages greater rigor in the early

formal stages of software engineering
methods
Possible to verify the correctness,
incompleteness and inconsistency
checking of the specification

79
 Difficult to represent behavioural aspects of
problem

Some requirements can only be determined

Disadvantages through empirical evaluation and prototyping
of formal
methods Do not address the problem of how the
requirements are constructed

Lack of adequate tool support

80
 A Z specification is presented as a collection of
schemas

A Schema comprises three main parts:

Z - A model
based formal • Name, Declarations and Predicates

method Schema declarations set out the names and types

of entities introduced in the schema

Schema predicate sets out the relationships

between the entities in the declaration

81
 Variable declarations are of the form identifier:type

Predicates give properties of, and relationships between

the variables

A schema may be used to describe either a state or an

Using Z operation
• To describe a state, the declared variables form the components of the
state and the predicates give the invariant properties of the state
• For an operation, the declarations consist of the initial state
components, the final components, the inputs and the outputs of the
operation
• For an operation, the predicate part describes the relation between the
inputs, outputs, and initial and final states

82
 Schema Name
Declarations
Z Schema
Predicates

83
  The state space of the lending library can be defined
using the following schema:

Library
Library stock: P Book
example onLoan: Book Borrower

dom onLoan  stock

84
 B
orro
w
Schema for Library
book
?:B o
ok
borrow re
ader?:Borro
w e
r
operation book?stock
book?dom onL
oan
onLoan
'=onLoan{(b
ook
?,re
ade
r?)}
sto
ck'=sto
ck

85
 N
ew
L
ibra
ry
b
ook
?:B
ook

s
toc
k'=sto
ck{b
ook
?}

Schema for o
nLoan
'=onLo
an

‘New’ and
R
etu
rn
‘Return’ L
ibra
ry

operations
b
ook
?:B
ook

b
ook?domonLo
an
d
om o
nLo
an'=do
m on
Lonb
a ook
?
s
toc
k'=s
tock

Requirements Engineerng 2012 86

  No ideal requirements method
 System models can be considerably enriched by
combining different techniques
 Data-flow model is based on the notion that systems
can be modelled as a set of interacting functions
Key points  The object-oriented approach is based on the notion
that systems can be modelled as a set of interacting
objects
 Formal methods are based on mathematical
principles and are intended to achieve a high degree
of confidence that a system will conform to its
specifications

Requirements Engineering 2012 87

  Create a set of detail use case descriptions for the following
system.
A video store(vs) provides services for video rental. Before a video
can be put on the shelf, it must be catalogued and entered its
information into the video database. Every customer must have a
valid customer card in order to rent a video. Customers rent
videos for three days at a time with the charge of RM5.00 each.
Every time a customer rents a video, the system must ensure
there’s no overdue videos. If so, the overdue videos must be
:: Use Case returned first and an overdue fee must be paid before the
Diagram customer can rent new videos. The overdue fee is RM1.00 per-day.
If the customer has returned the overdue videos, but has not paid
Exercises :: the overdue fee, the fee must be made before new videos can be
rented. Every morning the store manager prints a report that lists
overdue videos. If the video is two or more days overdue, the
manager calls the customer as a reminder to return the video. If a
video is returned in damage condition, the manager removes it
from the database and charge the customer for RM 20.00 for
each damage videos. The manager can at any time update all the
charges for the system.
 Draw a use case diagram. Identify the normal flow of events,
alternatives and exceptions flow within the use cases.

88
  Create a set of detail descriptions for a health club membership system.
 When members join the members club, they pay a fee for certain amount
of period. Most memberships are for one year, but memberships as short
as two months are available. Throughout the year, the health club offers a
variety of discounts on its regular membership prices (eg: two membership
for the price of one for valentine’s day). It is common for members to pay
different amounts for the same period of membership. The club wants to
mail out reminder letters to member asking them to renew their
memberships one month before the membership expires. Some members
:: Use Case have become angry when they are asked to renew their membership at a
much higher rate than their original contract, so the club wants to keep
Diagram track the price paid so that the manager can override the regular prices
with special prices when members are asked to renew. The system must
Exercises :: track these new prices so that the renewals can be processed accurately.
One of the problems in the health club industry is the high turnover rate of
members. While some members remain active for many years, about half
of the members do not renew their memberships. This is a major problem
since the club spends a lot in advertising to attract each new member. The
manager wants the system to keep track each time the member comes to
the club. The system will then identify the regular users and generate a
report so that the manager can ask them to renew the membership early,
perhaps offering them special rate for early renewal. And the system will
identify members who have not visited the club, so that the manager can
call them and invite them to join activities held in the club.

90
USE CASE
DIAGRAM
UML 2.0

92
 Use case – subset of the overall system functionality
 Represented by a horizontal ellipse with name
of use case above, below, or inside the ellipse.

Basic Use-Case Actor – anyone or anything that needs to interact with

the system to exchange information.
Symbols  human, organization, another information system,
external device, even time.

Temporal event – a system event triggered by time.

 The actor is time.

7-93
 1. Primary business actor
 The stakeholder that primarily benefits from the execution of
the use case.
 e.g. the employee receiving the paycheck
2. Primary system actor
 The stakeholder that directly interfaces with the system to
initiate or trigger the business or system event.
Four Types of  e.g. the bank teller entering deposit information
Actors 3. External server actor
 The stakeholder that responds to a request from the use case.
 e.g. the credit bureau authorizing a credit card charge
4. External receiver actor
 The stakeholder that is not the primary actor but receives
something of value from the use case.
 e.g. the warehouse receiving a packing slip

7-94
 1. Between Actors
1. generalization or inheritance
2. Actor to use case or Use Case to Actor
Actor & Use 1. association

Case 3. Between use cases

1. Association
Relationship 2. Extends
3. Uses
4. Depends

95
 Association – a relationship between an actor and a use case in
which an interaction occurs between them.
 Association modeled as a solid line connecting the actor and the use
case.
 Association with an arrowhead touching the use case indicates that
the use case was initiated by the actor. (1)
Use Case  Association lacking arrowhead indicates a receiver actor. (2)

Association  Associations may be bidirectional or unidirectional.

Relationship

7-96
 Extension use case –use case consisting of steps extracted from
another use case to simplify the original.
 Extends the functionality of the original use case.
 Extension is a way of capturing a variant to a use case.
 Extends relationship represented as arrow beginning at the
Use Case extension use case and pointing to use case it is extending.
 Labeled <<extends>>.
Extends
Relationship

7-97
Use Case
Extends
Relationship

7-98
<<extend>>

99
 Abstract use case – use case that reduces redundancy
in two or more other use cases by combining common
steps found in both.
 Available by any other use case that requires its functionality.
 Generally not identified
in requirements phase
 Relationship between
Use Case Uses abstract use case
and use case that
Relationship uses it is called a
uses (or includes)
relationship.
 Depicted as arrow
beginning at
original use case
and pointing to
use case it is using.
 Labeled <<uses>> or <<include>>.

7-100
Uses and
extends

101
 Depends On – use case relationship that specifies
which other use cases must be performed before the
current use case.
 Can help determine
sequence in which
Use Case use cases need to
Depends On be developed.
 Depicted as arrow
Relationship beginning at one
use case and
pointing to use case
it depends on.
 Labeled
<<depends on>>.

7-102
 Inheritance – a use case relationship
in which the common behavior of two
actors initiating the same use case is
extrapolated and assigned to a new
Use Case abstract actor to reduce redundancy.
Inheritance  Other actors can inherit the interactions
Relationship of the abstract actor.
 Depicted as an arrow beginning at one
actor and pointing to the abstract actor
whose
interactions the first actor inherits.

7-103
Use Case
Inheritance
Relationship

7-104
  A car rental company wants to develop an automated system that
can handle car reservations, customer billing and car auctions.
Usually, a customer reserves a car; picks it up and then returns it
after a certain period of time. At the time of pickup, the customer
has an option to buy or waive collision insurance on the car. When
the car is returned, the customer receives a bill and pays the
specified amount. The company also has corporate customers
where they are not billed directly. For corporate customers, the
Exercise | Use organizations they work for will be billed and payments are made
Case Diagram later. In addition to renting cars, every six months, the car rental
company auctions the cards that have accumulated over 20,000
miles.
 Draw a use case diagram for capturing the requirements of the
system.
 TIPS: Include an abstract use case to capture common behavior
among any two use-cases. Use the relevant relationships to
capture the requirements.

105
 Group UML Model
VORD Class Diagram,
Object Diagram,
Component Diagram,

GORE Composite Structure Diagram,

Package Diagram

A4-UML UNIFIED Activity Diagram

Interaction Overview Diagram.
MODEL
AGILE Deployment Diagram.
State Machine Diagram.
VOLERE Sequence Diagram,
Communication Diagram,

USE-CASE DRIVEN Timing Diagram

106