Author Topic: Hierarchical Decomposition of Use Cases  (Read 4880 times)

bern

  • EA Novice
  • *
  • Posts: 1
  • Karma: +0/-0
    • View Profile
Re: Hierarchical Decomposition of Use Cases
« Reply #15 on: June 25, 2003, 08:15:11 pm »
Take care when reviewing the UML Use Case diagram, which only reflects an abstracted view of the important actions that a user expected of a system.  The true UC itself is, as Nicholas notes above,  a documented set of steps.  
Be careful to not chase UC "heirarchy" as though it nicely fits into an "is-a" relationship--it doesn't--it isn't a classification-based organizational system, it's merely an associative grouping convenience.  "lower level" use cases merely peel back one level of abstraction to the actions that are globbed as the superior "course-grain-action", and do not belong on that superior's diagram {save extending use cases-which are not lower level at all, but variations of}.   Each of the more-granular "lower level" UCs is usually not "a child of" the superior, it's just a sub-step that was too detailed for the higher level discussion.  This is different than the "extends" use cases; they represent unique variation to the extended / referenced use case, and in that they are the only UCs that resemble the "is a" type of heirarchical classification based grouping.  They are not children though, they are peers with a "wrinkle" on the base UC scenario.  
Keep UC names "Action-verb Plural-noun" form; that helps to keep your focus on the actions and objects being acted upon... when something pops up not related, it hints at other use cases... for example,
"Create Ledgers" not "Ledger Creation"--the latter can remind you of ancillary actions that only slightly relate to a ledger, and non-centric actions start to creep into the Use Case documented-steps, starting a difficult to trace initiation of awkwardly or incorrectly associated objects and actions.  Pluralizing the object noun helps to remind yourself that this action isn't a "one-off" it repeats often in the business process--that's why you're writing the use case!  And THEN drawing it's abstracted diagram. ;)

jdbaker

  • EA Novice
  • *
  • Posts: 4
  • Karma: +0/-0
  • I love YaBB 1 Gold!
    • View Profile
Re: Hierarchical Decomposition of Use Cases
« Reply #16 on: July 21, 2003, 01:11:28 pm »
A long and very interesting thread.

For questions and concerns related to use case hierarchy, I recommend Alistair C o c kburn's book, Writing Effective Use Cases.  He has a webiste with a lot of information at http://alistair.c o c k burn.us/.
(remove the spaces which have been inserted to prevent Alitair's name from becoming "thingy burn")

Alistair lays out a hierarchy of use cases much the same as Constantines.  That is the top level are summary use cases where each step in the summary use case may well be a separate user goal use case.  User goals may have sub-goals, like login.  I use this technique in EA by creating a package structure in my Use Case View.  I can provide a sample model for anyone interested in that approach.
« Last Edit: July 21, 2003, 01:13:38 pm by jdbaker@computer.o »

J.D. Baker
BAE SYSTEMS

fwoolz

  • EA User
  • **
  • Posts: 435
  • Karma: +0/-0
  • We have met the enemy, and he is us.<Pogo, 1970>
    • View Profile
Re: Hierarchical Decomposition of Use Cases
« Reply #17 on: July 23, 2003, 08:21:17 am »
My tuppence (or, yet another branch in the flow of this discussion),

I'm wondering how many folks have used UML diagrams to represent use case flows rather than (or in addition to) "plain" text.  Activity diagrams, in particular, seem well-suited to such an application, although sequence diagrams and state charts would (IMHO) also be appropriate.  BTW, the activity diagram approach is presented as a way to represent complex flows in "Advanced Use Case Modeling" by Frank Armour and Granville Miller (Addison Wesley).

Cheers,
Fred Woolsey
Fred Woolsey
Interfleet Technology Inc.

Always be ready to laugh at yourself; that way, you beat everyone else to the punch.