Hierarchical Decomposition of Use Cases

[Paul D]

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

PD.

[PhilR]

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,

PhilR

[Tjerk]

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.

Greetings,
Tjerk

[Paul D]

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.

[Paul D]

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

Anyways.

[PhilR]

Hi Guys,

Interesting debate this.  Here's my perspective.

When I was an electrical engineer   (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 ).

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.

PhilR

[Tjerk]

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.

Greetings,
Tjerk

[PhilR]

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.

PhilR

[Tjerk]

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:

• System / subsystem specifications (SSS): functional & non-functional system / subsystem requirements. Non-functional requirements range from packaging, design / implementation and hardware / software context requirements (e.g. OS, PC).
  
• System / subsystem design description (SSDD): design decisions, resulting in "design" requirements for software units contained in the (sub)system.
  
• Interface requirements specifications (IRS): interface related requirements (content, bandwidth, sequence, etc.).
  
• Software Requirements Specifications (SRS): functional & non-functional component (or other software unit) requirements.
  

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.

Greetings,
Tjerk

[Nicholas Blumhardt]

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

Nick

[PhilR]

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:

• Add new product
  
• Add new customer
  
• Add new inventory location
  

etc...

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

PhilR

[Fintan]

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.

Regards,

Fintan

[brettonwoods]

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:

2.11.2.5
“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.”

2.11.4.2
“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

[fwoolz]

TB,

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

Cheers,
Fred Woolsey

[Tjerk]

Hi Tom,

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

Greetings,
Tjerk