intro to systems requirements comp1007 © copyright de montfort university 2002 all rights reserved...

Intro to Systems Requirements COMP1007

© Copyright De Montfort University 2002 All Rights Reserved

COMP1007 Introduction to Systems Requirements

Use-Cases II



Learning Objectives

Consider how to structure the Use Case Model using– include – extend– generalisation



Structuring the Use Case Model Objectives:

“To extract behaviour in use cases that need to be considered as abstract use cases. Examples of such behaviour are common behaviour, optional behaviour, exceptional behaviour, and behaviour that is to be developed in later iterations.

To find new abstract actors that define roles that are shared by several actors. “

RUP 2000



Structuring the Use Case Model Essentially

– simplify the use cases by identifying common behaviour (include and generalisation) or exceptional/optional behaviour (extend)

common behaviour need only be specified once

exceptional/optional behaviour is specified separately



UML Definitions

Abstract Use Case– a use case that cannot be directly

instantiated Concrete Use Case

– a use case that can be directly instantiated

– initiated by an actor and comprises a complete flow of events



Placing an order

PlaceOrderSalePerson

Concrete Use Case

Probably quite complicated



Stereotypes Stereotype

– meta-classification of a modelling element – based on existing modelling elements – may extend semantics but not structure

of existing types and classes. – some are predefined, others may be user

defined– uses matched guillemets around

stereotype name eg «include»



Stereotypes

Generally represents a usage distinction

Include and Extend are stereotype relationships.

UML suggests using dashed arrows but Rational Rose use solid association arrows stereotyped as include or extend



Include Relationship

Used when– separating complex details to improve

clarity– separating behaviour used by several

base use cases A use case instance following the

base use case must also follow (include) the inclusion use in order to be complete



Placing an order - structured

SalePerson

RecordCustomerInformationDetermineOrderRequirements

SetPaymentMethod

PlaceOrder

<<include>>

<<include>>

<<include>>

New Inclusion Use Cases

Base Use Case now has simplified specification

Include relationship



Include Relationships

RecordCustomerInformation (and the the other inclusions use cases) is included as a contiguous series of events at one location in the base use case PlaceOrder.



Extend Relationship

Used when– optional or exceptional behaviour are

specified separately in an extension use case thus simplifying the specification of the base use case

The flow of events in the base use case is complete and does not reference the extension use case



SalePerson

RecordCustomerInformation

DetermineOrderRequirements

SetPaymentMethod

RequestProductCatalogue

PlaceOrder

<<include>>

<<include>>

<<include>>

<<extend>>

Extension use case containing optional behaviour

Extends relationship



Extension Points

An extension use case is inserted into the base use case at one or more extension points which have to be explicitly named.

A base use case with events ‘mnopqr’ might be extended by the

use case ‘abcde’ to be instantiated as ‘mabnopcdqre’



Generalisations

Used when behaviour common to two or more use cases is factored into a parent use case

Means that a use case instance following the child use case also follows the parent use case to be complete



Generalisation

CheckPassword

CheckRetinalScan

CustomerValidateCustomer

Parent Use CaseChild Use Case

Generalisation Relationship



Generalisation

In this case ValidateCustomer is abstract. Frequently the generalisation use case is abstract but in general neither the parent or child use case need be abstract.



Generalisation

Child use case may– add behaviour segments or modify

behaviour segments inherited from the parent

– the structure of the parent is preserved– multiple child use cases are independent

of each other eg an instance of ValidateCustomer is either completed by CheckPassword or CheckRetinaScan



Other approaches

Larry Constantine– distinguishes between essential

(business) use cases and conventional or concrete use cases

Alistair Cockburn– builds “(business) goal-driven” use

cases



Other approaches

Craig Larman– influenced by Constantine

distinguishes between High-Level use cases and Real use cases, and also between Initiating Actors and Participating Actors



Summary

Considered use structuring to identify commonality using– include, extend, generalisation relationships

between use cases– and generalisation between actors

Note that this is not a form of functional decomposition



References

Cockburn, Alistair, Writing Effective Use Cases, Addison-Wesley, 2000

Bennett, S., McRobb, S. & Farmer, R. Object-Oriented Systems Analysis and Design using UML McGraw-Hill 1999, Ch 5

Jacobson, I., Booch, G. and Rumbaugh, J. (1999), The Unified Software Development Process, Addison-Wesley, Reading Mass. (Ch 7)

Rational Unified Process 2000

intro to systems requirements comp1007 © copyright de montfort university 2002 all rights reserved...

Documents