Sparx Systems Forum

Enterprise Architect => Uml Process => Topic started by: Paul D on March 25, 2003, 02:43:55 pm

Title: Hierarchical Decomposition of Use Cases
Post by: Paul D on March 25, 2003, 02:43:55 pm
Hi All,

I've scoured all postings regarding use cases but can't find any explicit discussion of this...

Basically, I'm at the stage of use case modelling for a reasonably large website, and I'm trying to come up with the "best" / "correct" way to hierarchically decompose high level use cases in to sub-use cases. My only reference unfortunately is the excellent, though sometimes cryptic 'UML in a Nutshell' by O'Reilly [...looking at chapter 8 here].

I'm trying to find the right association/stereotype to define the relation between a superordinate use case and its immediate subordinate use cases. Working from the above text, my best guesses so far are: [Assuming that a use case 'X' is superordinate to use cases 'a', 'b', and 'c'...]

(a) There exist generalisation associations from a,b,c to x with the <<realise>> stereotype

(b) There exist dependency associations from a,b,c to x with the <<refine>> stereotype

(c) a,b,c are contained (directly) in a package, p, and there exists a dependency from p to x with a <<refine>> stereotype

(d) avoid using any form of superordinate use cases at all. All use cases are 'bottom level', and the hierarchy is imposed by using packages nested appropriately.

I don't like (d) for the simple reason that I would like to be able to describe 'general' high level tasks in use case form so that the client (and I!) can see the wood for the trees. Plus the O'Reilly text does suggest that there is a proper, UML compliant, way to do this.

I *know* I should buy a more prosaic text (and I will), but I'm in a bind at the moment, so if anyone has thoughts or ideas, I'd greatly appreciate them...

Title: Re: Hierarchical Decomposition of Use Cases
Post by: PhilR on March 25, 2003, 06:28:43 pm
Simple answer - don't decompose use cases.  Use cases are NOT functions.  They are represent a sequence of interactions between an Actor and a System.  The sequence of interactions provide some value to the Actor.  Each individual action is a use case step.

This means that option d) is the only valid option.  However, there is nothing wrong with giving your packages functional sounding names such as "Customer Maintenance", "Transaction Posting" etc etc.

Packages are the correct UML mechanism for "seeing the wood from trees".  Note that you can create a diagram showing a hierarchy of packages by dragging a package on to a diagram canvas.

Hope this helps,

Title: Re: Hierarchical Decomposition of Use Cases
Post by: Tjerk on March 26, 2003, 12:43:32 am
Hi Phil,

I tend to disagree with you. When I talk to my client(s), they first come up with a rough outline of interactions they want with the system. These are not strict and worked out Use Cases, but they are a first start. Then each Use Case is worked out with scenario's and it could also be that the suggested Use Case is actually a group of interactions. I now use the first Use Cases in a global diagram "summarising" the system interactions and then work out each Use Case, optionally with another diagram providing the details of that Use Case (showing the Use Cases that realise the global Use Case).

E.g.: I have a client that first tells me he wants to maintain a GIS dataset. That Use Case could roughly indicate that he wants to have a GUI where he sees the data and is able to change and save the data.
In the next sessions with the client, the client tells me that the above Use Case is true but not accurate, so he tells me that that Use Case must be realised by Use Cases "Editing on a map", "Editing using a table", etc, which include details on verification, way of entering data, etc. So I do use the <<realise>> between a rough first Use Case and its worked out Use Cases.

This might not be strictly UML and / or UP, but this seems to help capturing the specs of the client without missing the strict details needed in specs.

I have to say, I'm not really fond of Use Cases, I tend to work with requirements. The Use Cases are to me more like a means to get to my requirements.

Title: Re: Hierarchical Decomposition of Use Cases
Post by: Paul D on March 26, 2003, 01:53:37 am
Phil, Tjerk, Thanks for the responses.

However, Phil, though I do realise that use case are semantically quite different from functions, I'm pretty sure that there is a UML compliant way of arranging them hierarchically. Looking at the UML in a Nutshell book, the terms 'superordinate use case' and 'subordinate use case' are used repeatedly, and there is even a diagram showing a tree of use cases, but the associations are not described....

... anyways. I may go straight to the horses mouth and scour the UML specification (I'm just like that!). Cheers for the feedback.
Title: Re: Hierarchical Decomposition of Use Cases
Post by: Paul D on March 26, 2003, 06:16:13 am
Just a quick addendum to what I wrote there....

The main attraction for me (and I think this is what Tjerk was getting accross) of having use cases organised in a proper hierarchy, is that the broad view of actors (as human users) roles' that it communicates.

For example, suppose I have an actor 'Site Administrator' and another 'Content Manager'. There might be a top level use case called 'Administer Site' which the site administrator uses, and another called 'Manage Content' which the content manager uses. At this level, these actors are not associated with any other use cases.

Then the 'Administer Site' use case may be decomposed into 'Manage Users', 'Manage Workflow Settings' etc.. etc.., and there may be various  uses, includes, and extends relations between them as appropriate. These may be further decomposed in to subusecases until the appropriate level is reached. A similar tree would be developed for the 'Content Manager'.

Okay, this might sound like overkill. But the advantage that I can perceive is that the top level use case, along with its notes, requirements etc., immediately communicates to anyone looking at the model for the first time (client, developer etc.) exactly what the actor's role is "in general". This is especially useful for clients who are not UML/technically literate.

The example I gave is not the best -- it is fairly obvious that a Content Manager's role is to manage content!! .. but it isn't difficult to imagine problem domains where the actors names don't convey this information. Without having a hierarchy (however shallow) of use cases, the only real way to glean the sum total of an actors role is to survey all the use cases it iteracts with, and for systems with a large number of use cases this can be time consuming..

Title: Re: Hierarchical Decomposition of Use Cases
Post by: PhilR on March 26, 2003, 06:57:49 pm
Hi Guys,

Interesting debate this.  Here's my perspective.

When I was an electrical engineer  8) (many, many eons ago) I used a standard notation for circuit diagrams.  There were (still are) standard symbols for resistors, capacitors etc etc.  The semantic meaning of the symbol was defined by the physical behaviour of the component being represented.

If I had suggested to my fellow engineers that I wanted to use different symbols or change the meaning of an exisiting symbol they would have looked at me as if I were mad  ??? and probabaly would have thrown me out of the profession (I left of my own accord as it happens :o ).

My point?  The UML is a standard notation.  The meaning of a use case is defined in the UML.  If people assign a different meaning to a use case they muddy the water and confuse people.  If you don't like use cases then use functional decomposition but please don't call the end result use cases.

One of the problems with our industry is the 'fashion police'.  Functional decomposition is 'out' use cases are 'in'.  This means that we shouldn't refer to functional decomposition even if need to do it.  Call it a use case hierarchy instead.

The reason that functional decomposition gets such a bad review is that it is a poor paradigm for internal software design (OO is a much better paradigm).  However that should not stop people using it for organising requirements becasue requirements are totally independent of design aren't they?

Finally, if you want to classify actors, you can use generalise (inherit) relationships between them.  This is really useful for documenting the situation you describe Paul.

Title: Re: Hierarchical Decomposition of Use Cases
Post by: Tjerk on March 27, 2003, 01:50:35 am
Hi Phil,

I do agree on the fact that Use Cases should always conform UML specs, using the same technique (symbols, naming) for other purposes is out of the question! I've studied electrical engineering myself  ;) (university, 4 years ago) and like discussions like these myself.

But I do think that the Use Case specifications leave room for different abstraction levels (I'm not a guru, so please correct me if I'm wrong). I use that room, just as Paul wants to, to include different levels of abstraction.

This also leads to testcases, coming from the usecases, that use different levels of abstraction (e.g. managment, financial department, the guy working with some GUI of the system,etc.) so that every actor / stakeholder has its share in testing.

If I'm wrong, I guess that an abstract / top-level Use Case (as I use it now) should be modelled as a package with a text fitting toplevel descriptions. This should be worked out untill there are enough details to write Use Cases in the strict sense. In this case I must make my first system decompositions (to subsystems, components) based on the package contents, instead on Use Cases, am I right?

By the way, my experience with Use Cases, is that they can contain overlapping functionality, so I try to come up with a non-overlapping and complete set of requirements. Those requirements are then, in my point of view, the takeoff point for designers and coders.

In general I think that Use Cases are readable for clients, but not a conveniant starting point for developers. And requirements are hard to read for clients and more practical to start development from. Depending on the client, I work out Use Cases, work with Use Cases resulting in requirements or even work directly with requirements. In the first case, I translate the Use Cases to requirements without the client.

Title: Re: Hierarchical Decomposition of Use Cases
Post by: PhilR on March 27, 2003, 06:08:44 pm
Hi Tjerk,

Yes you are correct that the top-level grouping of use cases should be done with packages.  You can even stereotype the package and import a .wmf graphic for it if you want to make it different to plain old boring packages.

I am of the growing opinion that use cases need to be suplemented with written requirements in some areas for exactly the reasons you mention.  In fact, there is a need to associate some or all of the following with use cases depending on the type of project and approach followed:

functional and non-functional requirements
business rules
data elements included in the interface
project issues and requirements
attributes of persistent classes that are updated by the use case

Use cases are great but the whole technique was originally spawned from about three pages of a book by Ivar Jacobsen.  All sorts of 'ideas' have been sucked in to fill the vacum.

To sum up I think we need to stay agile but abide by the rules which strengthen communication.  I don't care how you arrive at your use cases but I do care that we both understand exactly what they mean.

Title: Re: Hierarchical Decomposition of Use Cases
Post by: Tjerk on March 28, 2003, 12:25:46 am
Hi Phil,

Great, discussion and agreement! By the way, are you known with the J-Std-016 / Mil-Std-498 standard? That standard helps you in ordering and packaging requirements. It has toplevel documentation:

The mentioned standard is very keen on traceability from toplevel requirements (and as we discussed, Use Cases) all the way down to actual implementation and testing. Working with a tool (e.g. EA) makes this easier, but still needs discipline along the complete line of development.

I also agree on being agile. Standards keep faces in the same direction and improve communication, but selection of the proper elements to be used from a standard (UML, J-Std-016, or whatever) is still an issue to be agreed on when starting a project.

And Paul, I hope you have found an answer to your question  :)! Otherwise, please join in again.

Title: Re: Hierarchical Decomposition of Use Cases
Post by: Nicholas Blumhardt on March 30, 2003, 06:42:05 pm
Hi All, guess there has been a lot said already in this thread that pretty much covers this ground. There is a simple way to get an answer to the original question though:

A use case is text. It is a sequential textual representation of a user's interaction with a system. Use cases on UML diagrams are just a way of organising those pieces of use case text- each use case on the diagram must still correspond to a (potential) piece of use case text. Hence 'Add a new product' is a use case, but the 'superordinate' use case 'Manage products' is not.

Thus the decomposition by package only will maintain the necessary semantics.

Hope this is of some help. Greetings to everyone :)

Title: Re: Hierarchical Decomposition of Use Cases
Post by: PhilR on March 30, 2003, 07:57:56 pm
By the way, are you known with the J-Std-016 / Mil-Std-498 standard?

No I am not but I will check it out.  Sounds interesting.

Nick, you make the point very well.  I must be able to write some (sensible) text for my use case.  In fact Alistair Cockburn jokes that his entire book on use cases describes what to put between the two braces of a use case UML tag.  In other words the use case description.

I tend to regard use case diagrams as not much more than a bullet list of use cases such as:


Appart from the actors invloved a use case diagram does not convey much more information.

Title: Re: Hierarchical Decomposition of Use Cases
Post by: Fintan on April 17, 2003, 02:51:43 am
Just to add my 2.54 c (Euro cents that is),

Paul :  What I think people are saying is that your "top level use cases" should in fact be packages.  E.g. you will have an association between the Site Administrator actor and a package called 'Administer Site'.  Within this package are all the use cases that the Site Administrator is associated with.  Ditto for Content editor & 'Manage Content' package.

Where I would use relationships between use cases is in the case that TJerk mentions - overlapping functionality, although I would use it rather for overlapping requirements.  Where there is a requirement which is used in more than one use case, I would extract that requirement into its own use case and create an <<include>> relationship between them.


Title: Re: Hierarchical Decomposition of Use Cases
Post by: brettonwoods on June 03, 2003, 04:51:20 pm
Hi All,

No one seemed to look at the UML in this discussion – although Paul did make the threat. My reading of the tea leaves in V1.5, is that it is perfectly OK to create hierarchies of Use Cases.

In the UML metamodel, a Use Case is first off a Classifier. Classifiers implement GeneralizableElement which provides the semantics for creating element hierarchies. See Figures 2-5  and 2-21 in UML V1.5. The text in the UML also makes note of this in several sections. Including but are not limited to:
“Generalization between Use Cases means that the child is a more specific form of the parent. The child inherits all Features and Associations of the parent, and may add new Features and Associations.”
“A generalization relationship between use cases implies that the child use case contains all the attributes, sequences of behavior, and extension points defined in the parent use case, and participates in all relationships of the parent use case. The child use case may also define new behavior sequences, as well as add additional behavior into and specialize existing behavior of the inherited ones. One use case may have several parent use cases and one use case may be a parent to several other use cases.”

Yea! We can legally have Use Case hierarchies. This is all well and good but as others have pointed out Use Cases by themselves are not well equipped to specify all the requirements in a software system. So how do we bring those other requirements into the UML so we can visually model them?

The UML has defined standard elements of ‘requirement’ and ‘responsibilities’ which should help. They are stereotypes that apply to the base element ‘Comment’. A requirement “Specifies a desired feature, property, or behavior of an element” while a responsibility “Specifies a contract or an obligation of an element in its relationship to other elements.”

So what can we do with a 'Comment'? Not much. A Comment, unlike our Use Case that inherits from Classifier, comes from ModelElement. It’s one step away from Element, the UML equivalent of primordial slime. See 1.5 Figure 2-9. Comments have … “no semantic force but may contain information useful to the modeler.” That’s it – they can’t be organized into hierarchies or have semantically meaningful relationships, like dependencies, with other elements.

EA, to it’s credit, takes a practical way out and ignores the limitations of the Comment. It goes ahead and involves it in realizations with Use Cases and associations with other Comments. This provides a mechanism for organizing all those untidy requirements. From a purist standpoint, as far as I can tell, this is politically incorrect.  It’s a real improvement though over using something like Rational's Requisite Pro which completely divorces requirements management form the UML tool.

I don’t know why the UML does not have a model element for requirements that is the equilivant of a Use Case. Such an element could provide the semantics that would give requirements textual clarity and organization within the context of a visual model. It could be extended with stereotypes like ‘business rule’, ‘legal requirement’ or ‘architectural requirement’ and organized into hierarchies as suggested by the J-Std-016 / Mil-Std-498 standards mentioned in a previous response.

The UML provides many mechanisms for rule enforcement, for example constraints and associations limit what the developer can do. The problem as I see it is that these restrictions are scattered across the UML landscape and do not easily trace back to the stakeholders critical needs. This makes them hard to present in a coherent format that is understandable to the business.

I think we are all stuck with this fundamental shortcoming in the UML. It leads to problems with half baked workarounds in the real world and tools that solve the problem in an inconsistent manner.

I know this note is a long winded and late to the show, but I would like to here some further discussion on the issue if anyone is interested.

Thanks if you got this far.
Tom Burns
Title: Re: Hierarchical Decomposition of Use Cases
Post by: fwoolz on June 03, 2003, 05:38:54 pm

I agree that the UML has given short shrift to requirements... I am working on a method that uses requirements and issues to create "Requirements Diagrams" and "Issue Diagrams" that cover written requirements (where they exist), requirements elicited through an interview process, and questions/requests for clarification regarding requirements.  Kudos to Sparx and the EA team for cooking up a clever (albeit not, strictly speaking, UML compliant) way of bringing them into the UML model.  I LIKE IT!!!

Fred Woolsey
Title: Re: Hierarchical Decomposition of Use Cases
Post by: Tjerk on June 04, 2003, 12:17:32 am
Hi Tom,

Thanks for the elaboration on the subject! It is always good to have the proper backgrounds when having a discussion  ;).

Title: Re: Hierarchical Decomposition of Use Cases
Post by: bern 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. ;)
Title: Re: Hierarchical Decomposition of Use Cases
Post by: jdbaker 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
(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.
Title: Re: Hierarchical Decomposition of Use Cases
Post by: fwoolz 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).

Fred Woolsey