I think you are closer to an <<extend>> for each Use-Case.

Multiple things may have to be undertaked in the user identification, i.e.
this bank, another bank in the network, invalid card, invalid pin etc. etc.
so having this as an abstract use-case seems a good idea.

If multiple transactions are required the system should not have to
recheck, so an include, which has to be performed, is overkill.


Mark Hampshire


|---------+----------------------------->
|         |           "Burk, Susan"     |
|         |           <SBurk@MassMutual.|
|         |           com>              |
|         |           Sent by:          |
|         |           owner-rose_forum@r|
|         |           ational.com       |
|         |                             |
|         |                             |
|         |           07/15/2002 10:10  |
|         |           AM                |
|         |           Please respond to |
|         |           "Burk, Susan"     |
|         |                             |
|---------+----------------------------->
  
>------------------------------------------------------------------------------------------------------------------------|
  |                                                                                    
                                    |
  |       To:       "'Minimole Liz Thomas (Systems)'" 
<[EMAIL PROTECTED]>, [EMAIL PROTECTED],          |
  |        [EMAIL PROTECTED], [EMAIL PROTECTED]                             
                                    |
  |       cc:                                                                          
                                    |
  |       Subject:  (ROSE) RE: (RUP) Doubt on the Include relation in the Use Case 
Specifica tion                          |
  
>------------------------------------------------------------------------------------------------------------------------|





There are many styles of documentation which will work here.  As long are
you are consistent in your approach, you will be fine.  ::~)

With respect to the style which I use, here are some answers to your
question:

If "Identify Customer" has a number of steps and business rules, it could
be
an <<include>. in each of the use cases.

If <<Identify Customer>> is a simple "find" by ATM card number, it is
simply
a responsibility of either the Account or Customer class.  The
responsibility is named "Find Customer by account number"; we can save the
discussion of whether the message goes to the Account or the Customer class
"for another day" ::~).   For a one step responsibility with minimal
business logic,  I think there is no harm showing it simply as a step in
each of the use cases without calling it an <<include>>.  Although the same
step occurs in three use cases, it is only one step, and it will be
accomplished by invoking the services of the same class (the Account or the
Customer).  The sequence diagram for each of the use cases will show the
same message "Identify Customer" being sent to the same class (Account or
Customer).

As far as pre-conditions are concerned, if the business folks said "Don't
even try to let some withdraw cash or deposit cash or transfer funds unless
we already know the customer", then Customer Exists is a pre-condition.  On
the other hand, if the ATM serves many banks and the first step of the use
case must be to Identify the Customer (in the correct bank), Customer
Exists
should ***not*** be a pre-condition.  Also, even in an ATM which belongs to
one bank, if the business wants to allow for someone to put in the wrong
ATM
card by mistake and handle the exception by asking the customer to try the
correct ATM card, then identification of the customer is a first step
rather
than a pre-condition.

So identification of the customer is either a first step or a
pre-condition,
but not both.  And if it is a first step, it is an <<include>> if it
contains a lot of business logic and simply a step in each use case if
"just" a read.

hth

Sue

-----Original Message-----
From: Minimole Liz Thomas (Systems)
[mailto:[EMAIL PROTECTED]]
Sent: Monday, July 15, 2002 8:19 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: (RUP) Doubt on the Include relation in the Use Case
Specification



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?

Please give me a feedback on this.

Thanking you in advance,
Minimole Liz Thomas
Project Manager.
****************************************************************************

*****
* RUP Forum is a public venue for discussions about the
* Rational Unified Process (RUP).
*
* For RUP support materials, process Plug-Ins, tutorials, whitepapers,
* a biweekly column, Rational University training courses, and more,
* please visit the Rational Developer Network (available to Rational
* customers) at:  http://www.rational.net.
*
* For technical support of RUP, RPW, Rose or any other Rational
* product, please visit: http://www.rational.com/support
*
* For other discussion groups, such as Rose and UML, please
* sign up at: http://www.rational.com/support/usergroups/index.jsp
*
* To reply to a posting, please "Reply to all" or send
* To: [EMAIL PROTECTED]
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
*
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send an email:
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rup_forum
*
****************************************************************************


------------------------------------------------------------------------------

This e-mail transmission may contain information that is proprietary,
privileged and/or confidential and is intended exclusively for the
person(s) to whom it is addressed. Any use, copying, retention or
disclosure by any person other than the intended recipient or the intended
recipient's designees is strictly prohibited. If you have received this
message in error, please notify the sender immediately by return e-mail and
delete all copies.


==============================================================================


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






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