Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - bern

Pages: [1]
Uml Process / Re: Hierarchical Decomposition of Use Cases
« 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. ;)

Pages: [1]