(responding to Minimole Liz Thomas)

> Let me explain my doubt with an example.
>
> For an ATM system, I have 3 use cases         
> Withdraw Cash,
> Deposit Cash,
> Transfer Funds
>
> The Customer Identification becomes a  first step for each
> of the above mentioned use cases. So the Identify
> Customer is yet another use case which can be included
> in the base use cases.
>
> Should this include use case be referred to as the first
> step of each of the base use cases or referred to in the
> Pre-Condition of each of the base Use Cases. Which is
> the most appropriate way of representing/including this
> abstract use case in the Use Case Specification of the
> base use cases?

To some large extent, the answer will depend on other
requirements not stated, and whether or not you want
to be 'pure' in eliminating Design Decisions from your
Use Cases.

Suppose, for example, there's a requirement that the
ATM user should confirm his identification prior to
each operation.  This may be a valid security
requirement, to prevent the next customer from 
usurping the identity of the previous customer.

In this case, it would be reasonable to have the steps
for Customer Identification included at the start of
each use case.  It would also be reasonable to
factor out these steps into a separate Use Case that gets 
'included', to avoid repetition and cut down on the
opportunities for inconsistency.

OTOH, if there is no such requirement that Customer
Identity need be re-verified for each Use Case, then
we don't want to make the Customer go through the
process for each ATM operation.

One approach that would express the requirement
adequately would be to take the advice given by
Gilles Mantel, and state the requirement for prior
verification explicitly in the preconditions for each
Use Case.

I favour a different approach.  I favour using the Actor
rather than the Precondition.  If we have an Actor
'Identified Customer' that initiates the three Use Cases
in question, then we can keep separate the information
on what it takes to become an Identified Customer
from being an Unidentified ATM User.

The advantage of taking this approach is that it is
very clear in the Use Case diagrams that the Actor
needs to be an Identified Customer, rather than
being comparatively hidden away in the preconditions.

I guess it's a matter of choice, though.

Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Post or Reply to: [EMAIL PROTECTED]
* Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
*    http://www.rational.com/support/usergroups/rose/rose_forum.jsp
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*    To: [EMAIL PROTECTED]
*    Subject: <BLANK>
*    Body: unsubscribe rose_forum
*************************************************************************

Reply via email to