01.11.2015 Object Oriented Analysis & Design & UML (Unified Modeling Language) 1 Part II:...

20.04.23Object Oriented Analysis & Design & UML (Unified Modeling

Language) 1

Part II: Requirements

The requirements workflowUse case modelingAdvanced use case modeling

20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 2

Requirements Workflow Most of the work is

in Inception and Elaboration phases Discover and reach agreement on

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


Iterations in SW Development


Requirements and UML Use Case

is not the only set of requirements specifies Functional Requirements:

“what the system will do” many non-functional requirements in

a system (constraints on the system): Performance Reliability Maintainability Quality …


Workflow Model Contains –

Workers (icons) and Tasks (cogs)

Arrows indicate flow of work This is not “exact”

it is merely a “normal” workflow We extend the UP workflow

to include non-functional requirements also


Requirements Workflow


Extending Requirements Workflow


Importance of Requirements Discovering what the stakeholders

want the system to do. Failure here will cause project

failure Lack of user involvement

is a major cause of project failure Requirement should drive the rest

of system development


Requirements: The Crossroad

Requirements study is the crossroad All other project practices

are directed by the requirements

CodingExpectations

Fu

nct

ion

alit

yM

ainten

ance

RequirementsStudy

Desig

n

TestingPro

ject

Man

agm

ent

Qulity

Managem

ent


Defining Requirements Specification of

“what” should be implemented not “how”

Functional and Non-functional requirements Functional requirements:

What behavior system should offer Non-functional requirements :

A specific property of the system A constraint on the system

It is easier to include some “how”, but it must be mostly “what”

Produce SRS Document the System Requirements Specification


Well-formed Requirements UML does not have a specific tool Book suggests the format

<id> the <system> shall do <function> Separate Functional from non-functional

requirements Functional

what the system should do Non-functional

constraints on the system


Requirement Types

Functional Requirements A process the system has to perform Information the system must contain

Nonfunctional Requirements Behavioral properties the system

must have Operational Performance Security Cultural and political


Functional RequirementsFunctional Requirement

Description Examples


Nonfunctional Requirements

Nonfunctional Requirement

Description Examples


ATM SW Requirements Functional requirements

1. The ATM system shall check the validity of the inserted ATM card

2. The ATM system shall validate the PIN number entered by the customer.

3. The ATM system shall dispense no more than $250 against any ATM card in 24-hour period.

Non-functional requirements1. The ATM system shall be written in C++.2. The ATM system shall communicate with the bank using

256-bit encryption.3. The ATM system shall validate and ATM card in three

seconds or less.4. The ATM system shall validate a PIN number in three

seconds or less


Documenting Requirements


Use Case UC modeling is

a form of Requirements Engineering Uses

Actors Use Cases Relationships System Boundary

Activities: Find the system boundary Find the actors Find the use cases

Specify the use case Create scenarios


Use case modeling


System Boundary Separates the system from its

environment Boundary is defined by

who or what uses the system Represented by a box

labeled with the system name Actors are outside Use Cases are inside


Actor The role

some external entity adopts when interacting with the system

Represents a role 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

System might maintain internal representation of the actors

Example: Customer


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

To find actors ask:•“Who or what uses or interacts with the system?”


Use Cases A specification of sequences or actions

Happens by interacting with outside actors Something the actor wants the system to do Always started by an actor Always specified from the user point of view Naming:

Verb with an object e.g. Place Order

Representation: an Oval with name inside

Place Order

GetStatus

OnOrder

To find use cases ask:•“How does each actor use the system?” and•“What does the system do for each actor?”


Identifying Use Cases Iterative process Start with a name Ask questions

What function will user want form the system?

What triggers system behavior store/retrieve information

Are actors notified by the system? What external events affect the system?


Example: Mail order system


Use Case Specification UML has no standard Template is normally used

UC name Identifier Actors Preconditions/post-conditions Flow of events (steps in UC)

<num> the <something> <some action>


Use case exampleUse 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. The system removes the item from the basket

3. If the Customer types a new quantity1. The system updates the quantity on the item in the basket.

Postconditions:1. The basket contents have been updated.


Detail a use case


Branching etc.. Simple branching

can be specified within a UC Complex ones

may require a separate UC Use IF and indented (dot numbered)

actions when necessary use alternative flows

and post-conditions for each usecase


Repetition etc.. Use For <iteration expr> statements Use dot-numbered indented set of

statementsn. For (iteration expression)

n.1 Do somethingn.2 Do something elsen.3 …

n+1

Use While <boolean> to represent repetition of a sequence of actions

n. While (Boolean condition)n.1 Do somethingn.2 Do something elsen.3 …

n+1


Requirements Tracing Map (functional) requirements to Use Cases Requirements Traceability Matrix


Complex Use Cases UC should be simple If there are complex branching, iteration etc.:

use Scenarios Scenario:

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

exactly one “primary scenario” (perfect world path) There are many secondary scenarios


Scenarios

Primary Scenario Secondary Scenario How many Secondary scenarios?

Pick the most important ones Group similar ones Use risk factor as a guidance


Actor Generalization

Used to simplify diagrams Customer & SalesAgent

Triggers the same use-cases Only difference is the

CalculateCommission Too many crossed lines For the common behavior

There should be another role: Purchaser

The other roles are derived

Lis tP ro ducts

S ales system

O rderP ro ducts

A cceptP aym ent

C alcualteC o m m iss io n

C usto m er

S alesA gent


Actor Generalization To express the common actor

behavior Actors communicate with the same

set of use cases Sometimes the parent actors

are concrete But good style dictates actors to be

abstract Substitutability principle:

A descendant actor is replaced Anywhere the parent is expected Used to test the correctness

Example: Replace Purchaser by Customer or SalesAgent

ListP ro ducts

S ales system

O rderP ro ducts

A cceptP aym ent

C alcualteC o m m issio n

C usto m er S alesA gent

P urchaser


Use Case Generalization Used to represent

one or more use cases are the special type of a more general case

Use it only if the diagram is simplified!

The child use case Automatically inherits all features from its

parent The child use case may

Inherit features from their parent use case Add new features Override (change) inherited some of the

features


Restrictions to Override

The child automatically inherits all features from its parent.But not every type of use case element may be overridden!

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


Use Case Generalization: Example

The parent use case: FindProduct

Two specializations FindBook FindCD

C usto m er

S ales system

FindP ro duct

F indB o o k FindC D


Conventions in Documentation Use normal text

For inherited feature of parent

With no change Use italic text

For overridden feature of parent

Use bold text to add features to the child


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:


Child Use Case SpecificationsChild 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:

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:


«include» Used to include

the behavior of one use case called supplier into the flow of another one called client

Is a little bit like a function call Prevents repeating the use cases

The client use case executes until the point of inclusion

Specify exact point of inclusion! then the execution passes to the supplier when the supplier finishes

control returns to the client again


Example to «include»


Specification for «include»


«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

used to add new behaviors Does not know anything about the extensions use case is complete without its extensions

Extension: 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

To deal with exceptional cases


Example to «extend»


Specification for «extend»


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

specify the extension points in the base use-case The number of insertion points must

Match the number of insertion segments Two extension use case might

«extend» the same base use case, at the same extension point

the order of execution is indeterminate


Extension use case example


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 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

20.04.23Object Oriented Analysis & Design & UML (Unified Modeling

Language) 55

End of Chapter

01.11.2015 Object Oriented Analysis & Design & UML (Unified Modeling Language) 1 Part II:...

Documents

Transcript of 01.11.2015 Object Oriented Analysis & Design & UML (Unified Modeling Language) 1 Part II:...