Personally I have to go with the latest OMG UML Spec:
(Version 1.3, page 2-127)
"A pragmatic rule of use when defining use cases is that each use case
should yield some kind of
observable result of value to (at least) one of its actors. This ensures
that the use cases are
complete specifications and not just fragments."
Even the examples in the spec show 'Place Order' not pieces of it. So...
Position A.
However, do whatever works for you, yes? If you're using RUP however, you
almost have to go with the OMG Spec or Position A or Quantrani (or, for that
matter, Schneider "Applying Use Cases" or Jabcobson "The Unified Software
Development Process" or Rumbaugh "The UML Reference Manual" or Booch "The
UML User Guide" or Booch "Object Solutions" and I could go on... -- these
all support position A). Chop up use cases into incomplete bits and they
fall apart in RUP. They won't support iteration planning well, or realize
the test model, or work for estimating man-hours (see Schneider), or do well
in the use-case realization to analysis classes transition. For smaller
projects you can get by but in larger projects break out the Band-Aids or
give it up, it just fly without tons of effort.
Rusty
------------------------------------------------------------
Rusty Williamson
> Sr. Systems Architect
GERS Retail Systems
http://www.gers.com/
The Object Workshop
http://home.san.rr.com/williamson/
Home Page
http://www.znet.com/~rusty/
------------------------------------------------------------
-----Original Message-----
From: Eric D. Tarkington [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 27, 2000 9:04 PM
To: ROSE_FORUM
Subject: (ROSE) Bar Bet #1
There is a collegial dispute between some of the instructors here at
Seneca. I won't tell you which side I'm on, but your comments would be
welcome. You can rest assured that I will pass them on -- if they
support me, of course.
Position A: One instructor says that you can't split a use case into
scenarios that cover less than a *complete* path through the FOE. This
agrees with Quatrani (start of chapter 5, VISUAL MODELLING), but may
produce long, awkward scenarios, and long, wide sequence diagrams.
Position B: The other says that's not good software practice, and
scenarios need to capture a small, natural unit of work in the FOE.
This contradicts Quatrani, but produces shorter scenarios with easier
sequence diagrams. One argument against is that the decomposition into
smaller scenarios may be confusing.
So, whadaya say? Do you favor position A or position B? Why?
-Eric
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* 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
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************
