Transcript Object Oriented Analysis & Design & UML (Unified Modeling

Part II: Requirements
The requirements workflow
Use case modeling
Advanced use case modeling

17.07.2015
Object Oriented Analysis & Design & UML (Unified Modeling Language)
1
Requirements Workflow

Most of the work is


Discover and reach agreement on





17.07.2015
in Inception and Elaboration phases
requirements: what you are going to build
Express requirements in the language of the
user
Solve the conflicting requirements problem
Build high-level specifications
Prioritize the requirements
Object Oriented Analysis & Design & UML (Unified Modeling Language)
2
Iterations in SW Development
17.07.2015
Object Oriented Analysis & Design & UML (Unified Modeling Language)
3
Requirements and UML

Use Case


is not the only set of requirements
specifies Functional Requirements:


many non-functional requirements in a
system (constraints on the system):





17.07.2015
“what the system will do”
Performance
Reliability
Maintainability
Quality
…
Object Oriented Analysis & Design & UML (Unified Modeling Language)
4
Workflow Model

Contains –




Arrows indicate flow of work
This is not “exact”


it is merely a “normal” workflow
We extend the UP workflow

17.07.2015
Workers (icons)
and Tasks (cogs)
to include non-functional requirements also
Object Oriented Analysis & Design & UML (Unified Modeling Language)
5
Requirements Workflow
17.07.2015
Object Oriented Analysis & Design & UML (Unified Modeling Language)
6
Extending Requirements Workflow
17.07.2015
Object Oriented Analysis & Design & UML (Unified Modeling Language)
7
Importance of Requirements



Discovering what the stakeholders want
the system to do.
Failure here will cause project failure
Lack of user involvement


17.07.2015
is a major cause of project failure
Requirement should drive the rest of
system development
Object Oriented Analysis & Design & UML (Unified Modeling Language)
8
Functionality
t t
ec en
j
o m
Pr ag
an
M
Requirements: The Crossroad
n
ig
es
D
Requirements
Study
Expectations
Coding
M
g
in
st
ity en
ul m
Q ge
a
an
t
Requirements study is the crossroad
All other project practices

17.07.2015
Te

Maintenance

are directed by the requirements
Object Oriented Analysis & Design & UML (Unified Modeling Language)
9
Defining Requirements

Specification of



“what” should be implemented
not “how”
Functional and Non-functional requirements

Functional requirements:


Non-functional requirements :



but it must be mostly “what”
Produce SRS Document

17.07.2015
A specific property of the system
A constraint on the system
It is easier to include some “how”,


What behavior system should offer
the System Requirements Specification
Object Oriented Analysis & Design & UML (Unified Modeling Language)
10
Well-formed Requirements


UML does not have a specific tool
Book suggests the format



Separate Functional from non-functional
requirements
Functional


what the system should do
Non-functional

17.07.2015
<id> the <system> shall do <function>
constraints on the system
Object Oriented Analysis & Design & UML (Unified Modeling Language)
11
Requirement Types

Functional Requirements



A process the system has to perform
Information the system must contain
Nonfunctional Requirements

Behavioral properties the system must
have




17.07.2015
Operational
Performance
Security
Cultural and political
Object Oriented Analysis & Design & UML (Unified Modeling Language)
12
Functional Requirements
Functional
Requirement
17.07.2015
Description
Examples
Object Oriented Analysis & Design & UML (Unified Modeling Language)
13
Nonfunctional Requirements
Nonfunctional
Requirement
17.07.2015
Description
Examples
Object Oriented Analysis & Design & UML (Unified Modeling Language)
14
ATM SW Requirements
Functional requirements

1.
2.
3.
The ATM system shall check the validity of the inserted ATM card
The ATM system shall validate the PIN number entered by the
customer.
The ATM system shall dispense no more than $250 against any
ATM card in 24-hour period.
Non-functional requirements

1.
2.
3.
4.
17.07.2015
The ATM system shall be written in C++.
The ATM system shall communicate with the bank using 256-bit
encryption.
The ATM system shall validate and ATM card in three seconds or
less.
The ATM system shall validate a PIN number in three seconds or
less
Object Oriented Analysis & Design & UML (Unified Modeling Language)
15
Documenting Requirements
17.07.2015
Object Oriented Analysis & Design & UML (Unified Modeling Language)
16
Use Case

UC modeling is


Uses





a form of Requirements Engineering
Actors
Use Cases
Relationships
System Boundary
Activities:



Find the system boundary
Find the actors
Find the use cases


17.07.2015
Specify the use case
Create scenarios
Object Oriented Analysis & Design & UML (Unified Modeling Language)
17
Use case modeling
17.07.2015
Object Oriented Analysis & Design & UML (Unified Modeling Language)
18
System Boundary


Separates the system from its environment
Boundary is defined by


Represented by a box



17.07.2015
who or what uses the system
labeled with the system name
Actors are outside
Use Cases are inside
Object Oriented Analysis & Design & UML (Unified Modeling Language)
19
Actor

The role



Represents a role




some external entity adopts
when interacting with the system
played by a user or another system
Actor is a stereotype of class
Use “stick person” to represent actors
Actors are always external to the system


17.07.2015
System might maintain internal representation of the actors
Example: Customer
Object Oriented Analysis & Design & UML (Unified Modeling Language)
20
Identifying Actors








Who or what uses the system?
What role do they play?
Who installs the system?
What starts and shuts down the system?
Who maintains the system?
What other system interact with ours?
Who provides input?
Things that happen at a given time can be an
Actor
Time
17.07.2015
To find actors ask:
•“Who or what uses or interacts with
the system?”
Object Oriented Analysis & Design & UML (Unified Modeling Language)
21
Use Cases

A specification of sequences or actions





Something the actor wants the system to do
Always started by an actor
Always specified from the user point of view
Naming:



Happens by interacting with outside actors
Verb with an object
e.g. Place Order
Representation:

an Oval with name inside
Place
Order
17.07.2015
GetStatus
OnOrder
To find use cases ask:
•“How does each actor use the
system?” and
•“What does the system do for
each actor?”
Object Oriented Analysis & Design & UML (Unified Modeling Language)
22
Identifying Use Cases



Iterative process
Start with a name
Ask questions


What function will user want form the system?
What triggers system behavior



17.07.2015
store/retrieve information
Are actors notified by the system?
What external events affect the system?
Object Oriented Analysis & Design & UML (Unified Modeling Language)
23
Example: Mail order system
17.07.2015
Object Oriented Analysis & Design & UML (Unified Modeling Language)
24
Use Case Specification


UML has no standard
Template is normally used





UC name
Identifier
Actors
Preconditions/post-conditions
Flow of events (steps in UC)

17.07.2015
<num> the <something> <some action>
Object Oriented Analysis & Design & UML (Unified Modeling Language)
25
Use case example
Use case: ManageBasket
ID: UC10
Actors:
Customer
Preconditions:
1.
The shopping basket contents are visible.
Flow of events:
1.
The use case starts when the Customer selects an item from the basket.
2.
If the Customer selects “delete item”
1.
3.
The system removes the item from the basket
If the Customer types a new quantity
1.
The system updates the quantity on the item in the basket.
Postconditions:
1.
The basket contents have been updated.
17.07.2015
Object Oriented Analysis & Design & UML (Unified Modeling Language)
26
Detail a use case
17.07.2015
Object Oriented Analysis & Design & UML (Unified Modeling Language)
27
Branching etc..

Simple branching


Complex ones



can be specified within a UC
may require a separate UC
Use IF and indented (dot numbered)
actions
when necessary use alternative flows

17.07.2015
and post-conditions for each usecase
Object Oriented Analysis & Design & UML (Unified Modeling Language)
28
17.07.2015
Object Oriented Analysis & Design & UML (Unified Modeling Language)
29
Repetition etc..


Use For <iteration expr> statements
Use dot-numbered indented set of statements
n. For (iteration expression)
n.1 Do something
n.2 Do something else
n.3 …
n+1
Use While <boolean> to represent repetition of
a sequence of actions
n. While (Boolean condition)
n.1 Do something
n.2 Do something else
n.3 …
n+1
17.07.2015
Object Oriented Analysis & Design & UML (Unified Modeling Language)
30
17.07.2015
Object Oriented Analysis & Design & UML (Unified Modeling Language)
31
17.07.2015
Object Oriented Analysis & Design & UML (Unified Modeling Language)
32
Requirements Tracing


17.07.2015
Map (functional) requirements to Use Cases
Requirements Traceability Matrix
Object Oriented Analysis & Design & UML (Unified Modeling Language)
33
Complex Use Cases


UC should be simple
If there are complex branching, iteration etc.:


Scenario:





17.07.2015
One specific path through a UC
Each Main Flow will be a scenario
Scenarios do not branch
Each possible branch is a potential Scenario
Each UC has


use Scenarios
exactly one “primary scenario” (perfect world path)
There are many secondary scenarios
Object Oriented Analysis & Design & UML (Unified Modeling Language)
34
Scenarios



Primary Scenario
Secondary Scenario
How many Secondary scenarios?



17.07.2015
Pick the most important ones
Group similar ones
Use risk factor as a guidance
Object Oriented Analysis & Design & UML (Unified Modeling Language)
35
17.07.2015
Object Oriented Analysis & Design & UML (Unified Modeling Language)
36
17.07.2015
Object Oriented Analysis & Design & UML (Unified Modeling Language)
37
Actor Generalization


Used to simplify diagrams
Customer & SalesAgent


Triggers the same use-cases
Only difference is the
Sales system
ListProducts
Customer
OrderProducts
CalculateCommission


Too many crossed lines
For the common behavior
There should be another role:
SalesAgent


17.07.2015
AcceptPayment
CalcualteCommission
Purchaser
The other roles are derived
Object Oriented Analysis & Design & UML (Unified Modeling Language)
38
Actor Generalization

To express the common actor
behavior



ListProducts
Purchaser
But good style dictates actors to be
abstract
OrderProducts
AcceptPayment
Substitutability principle:




Actors communicate with the same set
of use cases
Sometimes the parent actors are
concrete

Sales system
A descendant actor is replaced
Anywhere the parent is expected
Used to test the correctness
CalcualteCommission
Customer
SalesAgent
Example:


17.07.2015
Replace Purchaser
by Customer or SalesAgent
Object Oriented Analysis & Design & UML (Unified Modeling Language)
39
Use Case Generalization

Used to represent



Use it only


Automatically inherits all features from its parent
The child use case may



17.07.2015
if the diagram is simplified!
The child use case


one or more use cases are
the special type of a more general case
Inherit features from their parent use case
Add new features
Override (change) inherited some of the features
Object Oriented Analysis & Design & UML (Unified Modeling Language)
40
Restrictions to Override
Use case element
Inherit
Add
Override
Relationship
Y
Y
N
Precondition
Y
Y
Y
Postcondition
Y
Y
Y
Step in main flow
Y
Y
Y
Alternative flow
Y
Y
Y
Attribute
Y
Y
N
Operation
Y
Y
Y
The child automatically inherits all features from its parent.
But not every type of use case element may be overridden!
17.07.2015
Object Oriented Analysis & Design & UML (Unified Modeling Language)
41
Use Case Generalization: Example

The parent use case:


FindProduct
Sales system
Two specializations


FindBook
FindCD
FindProduct
Customer
FindBook
17.07.2015
FindCD
Object Oriented Analysis & Design & UML (Unified Modeling Language)
42
Conventions in Documentation

Use normal text



Use italic text


For overridden feature of
parent
Use bold text

17.07.2015
For inherited feature of parent
With no change
to add features to the child
Object Oriented Analysis & Design & UML (Unified Modeling Language)
43
Parent Use Case Specification
Use case: FindProduct
ID: UC12
Actors: Customer
Preconditions:
Flow of events:
1. The Customer selects “find product”.
2. The system asks the Customer for product search criteria.
3. The customer enters the requested criteria.
4. The system searches for products that match the Customer’s criteria.
5. If the system finds some matching products then
5.1.
The system displays a list of the matching products.
6. Else
6.1.
The system tells the Customer that no matching products could be found.
Postconditions:
Alternative flow:
1. At any point the Customer may move to a different page.
Postconditions:
17.07.2015
Object Oriented Analysis & Design & UML (Unified Modeling Language)
44
Child Use Case Specifications
Child use case: FindBook
ID: UC16
Parent use case ID: UC12
Actors: Customer
Preconditions:
Flow of events:
1. The Customer selects “find book”.
2. The system asks the Customer for book search criteria
consisting of author name, title, ISBN, or topic.
3. The customer enters the requested criteria.
4. The system searches for books that match the
Customer’s criteria.
5. If the system finds some matching books then
5.1. The system displays a page showing details of a
maximum of five books.
5.2. For each book on the page the system displays
the title, author, price, and ISBN.
5.3. While there are more books
5.3.1. The system gives the Customer the option
to display the next page of books.
6. Else
6.1. The system redisplays the “find book” search
page.
6.2. The system tells the Customer that no matching
products could be found.
Postconditions:
Alternative flow:
1. At any point the Customer may move to a different page.
Postconditions:
17.07.2015
Child use case: FindCD
ID: UC17
Parent use case ID: UC12
Actors: Customer
Preconditions:
Flow of events:
1. The Customer selects “find CD”.
2. The system asks the Customer for CD search criteria
consisting of artist, title, or genre.
3. The customer enters the requested criteria.
4. The system searches for CDs that match the Customer’s
criteria.
5. If the system finds some matching CDs then
5.1. The system displays a page showing details of a
maximum of ten CDs.
5.2. For each CD on the page the system displays the
title, artist, price, and genre.
5.3. While there are more CDs
5.3.1. The system gives the Customer the option
to display the next page of CDs.
6. Else
6.1. The system redisplays the “find CD” search page.
6.2. The system tells the Customer that no matching
products could be found.
Postconditions:
Alternative flow:
1. At any point the Customer may move to a different page.
Postconditions:
Object Oriented Analysis & Design & UML (Unified Modeling Language)
45
«include»

Used to include



Is a little bit like a function call


the behavior of one use case called supplier
into the flow of another one called client
Prevents repeating the use cases
The client use case

executes until the point of inclusion



then the execution passes to the supplier
when the supplier finishes

17.07.2015
Specify exact point of inclusion!
control returns to the client again
Object Oriented Analysis & Design & UML (Unified Modeling Language)
46
Example to «include»
17.07.2015
Object Oriented Analysis & Design & UML (Unified Modeling Language)
47
Specification for «include»
17.07.2015
Object Oriented Analysis & Design & UML (Unified Modeling Language)
48
«extend»

Adds a new behavior



to an existing use case
at a predefined extension point
Base:


The use case that is extended
Provides extension points







The use case that modifies the behavior of the base use case
Can access and modifies all base attributes and operations
Provides a set of extension segments to insert
extension points are not numbered in specification
«extend» provides a good way

17.07.2015
Does not know anything about the extensions use case
is complete without its extensions
Extension:


used to add new behaviors
To deal with exceptional cases
Object Oriented Analysis & Design & UML (Unified Modeling Language)
49
Example to «extend»
17.07.2015
Object Oriented Analysis & Design & UML (Unified Modeling Language)
50
Specification for «extend»
17.07.2015
Object Oriented Analysis & Design & UML (Unified Modeling Language)
51
The Extension Use Case



Generally are not complete
Might have pre and post conditions
Consists of one or more behavior fragments


Known as insertion segments
Rules:

The «extend» relationship must


The number of insertion points must


specify the extension points in the base use-case
Match the number of insertion segments
Two extension use case might

«extend» the same base use case,


17.07.2015
at the same extension point
the order of execution is indeterminate
Object Oriented Analysis & Design & UML (Unified Modeling Language)
52
Extension use case example
17.07.2015
Object Oriented Analysis & Design & UML (Unified Modeling Language)
53
When to use advanced features?



If they simplify the use case model
The best use cases are the simple ones
The model must be understandable by all
stakeholders





17.07.2015
Actors and use cases are easily understood
Actor generalization is more difficult to grasp
Heavy use of «include» makes the complete
picture harder to visualize
«extend» is very hardly understood
the meaning of «extend» is widely misunderstood
Object Oriented Analysis & Design & UML (Unified Modeling Language)
54
End of Chapter
17.07.2015
Object Oriented Analysis & Design & UML (Unified Modeling Language)
55