Drilling Down on Use Cases

[Facer]

I am very new to UML and Enterprise Architect. I want to be able to limit the number of Use Cases on a diagram. This will invariably mean that one or more Use Cases on a diagram will have to be broken down into two or more uses cases on another diagram. I do not want to use packages. How is this achieved?

Laurie

[Bruno.Cossi]

Hi Laurie,

technically, this certainly can be done. You can create a child diagram underneath the Use Case - just right-click the Use Case in the Project View, select New Child Diagram. Use Case diagram does not appear as an option, just select any of the five presented options and change it to "Use Case" in the window that opens afterwards. Now you have a Use Case with another Use Case diagram underneath where you can place more Use Cases.
Now, as I have said, technically this can be done. However it is a really bad practice.  You say you are new to UML. I suggest you start by reading a definition of what Use Case is - as each use case ultimately represents an interaction between the user and the system, believing that you can create multi-level hierarchy of use cases is fundamentally wrong.

By the way, even if you do decide to limit number of Use Cases on a diagram, why would it invariably mean that one or more UC will have to be broken down? You could just create separate UC diagrams for groups of related Use Cases - you would limit the size of each of the diagrams while preserving the Use Cases.

Hope this helps.
Bruno

[sargasso]

Laurie,
Bruno is right.  If you need to show some heirarchy in terms of use cases,  the package structure is the way to go.  In fact I was reading something either by Scott Ambler on this today.

Heres a couple of hints I find successful.

1. The first step is just to make a list of all the use cases, but ... dont bother trying to make sure the list is totally complete, just fairly comprehensive and dont analyse each one as you go just give it a name.

2. (mentally) Group the obvious together.

3. Pick a significant group and
a) pick the main use case in the group
b) describe its outcomes...

by way of example of this, an online travel booking system may have main "groups" like "book travel", "cancel travel", "frequent flyer registration" containing use cases like "Book Domestic Flight", "Book International Flight", .... "Register FF Profile", "Update FF Profile" etc etc.

Lets pick a target - in "book travel" pick "Book Domestic Flight".

The outcomes are :
CRS booking entry made
CRS inventory updated
CRS financial record created
CRS ticketting record created
(easy so far, but what about)
ticket email sent to user
user nominated credit card account debitted
(or even...)
Frequent Flyer pro-forma profile created
booking miles creditted to FF miles on proforma.


Now look at the other use cases in the group, are the outcomes the same or similar enough to cast doubt as to whether they are real use cases... N.B. EXCEPTION CASES ARE NOT USE CASES...  perhaps they are scenarios, duplicates or just plain mistakes.

Kill those ones off now. get them out of the model, they will only confuse things later (or at least add unnecessary effort all the way through the project).

Even after 4 or so years of using UML I still find that the inital list of use cases suspected for a project can be culled  to a significant fraction by this approach. Alright, I'll admit that a couple of times I've had to add one or two culls back in at a later stage but this was trivial compared to attempting to create massive, detailed, heirarchies of use cases that had little value at the end of the day.

The UML cognoscienti (can't call 'em gurus any more or TK may take offense   ) "say" only put a dozen or more use cases on  diagram.  What they "mean" is that humans can't  cope with more than about that level of complexity in a visual model.  This is like the old Powerpoint maxim of only putting 3-5-or-7 dot points on a slide.  If there are more than 12 significant use cases in a system then there are more than 12 significant use cases in a system.  Communication of those use cases is easier if we split the diagrams up.

Now here's something to consider.  Sometimes I'll split them up by a perfectly logical and valid structural concept - say user group for example.  Other times I'll split them by some obscure, technocrafty, arcane, weird pseudo concept (I cant give you an example or I would have to kill you).  

Why?  Purely because of the reason I drew the diagram - to communicate with a specific audience about a specific aspect of the system anaylsis or design.   Each audience requires a different view of the use cases, and often a different grouping.  

If you try and create complex formal heirarchical arrangements of  your use case models you will constrain yourself in creating these communication-level diagrams on the fly and you will cripple effective use of UML.

HTH
Bruce


p.s. Sorry guys - I've inadvertently let the inner circle secret that UML is a communication tool out again...  

[Steve99]

Hi Bruno/Sargasso,

Consider the situation that an Actors interaction with the system is to Produce 6 different Reports on Sales and 6 other reports relating to Administration.

At the highest/only level of Use Case Diagram you could simply say the User Produces Reports or you could create 2 Use Cases to say say that the User Produces Sales Reports and another Use Case to show that the user produces Admin Reports.

I might then want to show that the user interacts with the system to produce each of the 12 Reports. Visually it makes sense to see another diagram in which the user interacts with each of the 6 Sales Reports, which become individual Use Cases in their own right. It would then make sense to link the main Use Case "Produce Sales Reports" into the child Use Case diagram listing the Sales Reports and showing the user's interaction with them.

It appears from what you are saying that technically this is this too much detail to show in the Use Case Model.

I would be interested in hearing where you would then detail the 6 Sales Reports and 6 Admin Reports.

[sargasso]

I know this is sacrilege but...

Just think about this specific use case from the POV of the system.  Does the "user" do anything widely different to produce report x rather than report Y?  (Ignore the fact that there may be different report selection parameters entered.)   What is the real interaction that happens?
a) User selects "reports" function - system displays report menu
b) User selects report - system displays report paramter entry screen
c) [alt] User enters parameters - system validates parameters and if correct generates report else system display error message.
d) [alt] User selects exit - system returns to prevuious state.

OK, the details in your case may be different but isn't the overall flow the same?  What about the outcomes - either a report is generated or it isn't.  

I would tend to put each of the 10^n reports the user's require as requirements under the single use case.  

hth
bruce

p.s. dont forget that use cases are behaviorial models - reports and there layouts are structural.

[thomaskilian]

Me too  

[TrtnJohn]

Bruce,

If you are modeling an existing system,  I might agree.   But, if you are creating a new system your approach could be dangerous.  The problem I see is that it will seperate the reports from their actual real use from the users point of view.    

Let me give an example:  Let's say you design a new home banking system that allowed you to generate reports for your Deposits, Withdrawals, and Transfers for your accounts.  If I understand what you are saying, the Use Cases would show that you can give them the basic capability to specify a timeframe and out comes the report.  The problem with specifying it this way is that the user really wants the use "Balance my Checkbook" but you have provided only "Account Transaction Reports".    To me the better way to focus on the problem is not to generalize reports.  But instead, to try and understand all of the reasons WHY reports are even necessary and document those uses.

[thomaskilian]

I think it depends So behind the report generation there (should be) always a use case that tells WHAT is being done with the report (except for "put in folder and stow away"). In that case I would opt for (still) a single Create Report use case that extends/is included by the use case describing the overall semantic.

[sargasso]

Everyone above is right.

I took Steve99's description at face value, that the user perception is of an atomic function supplying the answer to "I want to produce my xyz report". Thus my response was for a generic reporting use case.

TrtnJohn's view of specific reports being included as an artifact necessary to provide for a business level use case "I want to use the system to balance my chequebook" (or in my case "I want to try and understand why my chequebook doesn't balance").

In support of the first case I would argue that there are many systems where analysis of the reason why a specific report is needed is beyond the pragmatic scope of a particular project - just accept that there is a need for this report, no matter how irrational it seems.  Rationale for the second case is obvious.

This thread just goes to show the power available to designers through use case analysis - and dont forget that  power tools need special safety rules!

rgrds
bruce

... and of course TK is always right!

[thomaskilian]

... and of course TK is always right!

just because I stay vague enough in my answers

[TrtnJohn]

Reporting is definately something that get abused  when defining requirements.  I constantly battle managers that think we need X or Y report.  Notice I said managers and not customers.  All too often reporting is something that developers tend to take the "carpet bombing" approach.  We have no idea what the customer wants so let's build in every possible instance of data reporting imaginable.  Most systems I see built with this attitude end up with reports that are too complicated for the user to use and therefore only get about 10% utilization.  Of course, I've seen it go the other way too.  In these cases there are too few specialized reports and therefore isn't very uselful to the customer.  The only way to really make sure is to understand the customers' needs and how they relate to the reporting requirements.  But, being pragmatic too, I do realize this information isn't always available.  In these cases I tend to error on the side of minimum definition as opposed to making a bunch of unused reports.  Which, of course, usually backfires too when you deliver and the customer is shocked you couldn't read his mind all along.