Reducing complexity in Use-Case-diagrams

[lemanchot]

Hello,

based on a list of requirements I extracted a Use Case diagram. I read that as a "best practice" it is recommend that ther aren't more than 10 Use Cases in one diagram but in my diagram there are about 40 Use Cases.
Between the Use Cases exist a lot of associations like <include> or <extend> so that it is different for me to describe them separetly.

I have two ideas for a solution:
1.) The first idea is to put the Use-Cases into different packages. The requirements to the system can be described from 3 views, so that I would use one package per view.
But how can I represent the Use-Cases that are used by an <include> from different packages in a good way? There isn't something like an interface where I could offer them.

2.) The second idea seems a little bit better to me. Each view could be represented by an individual Use Case diagram. In these diagrams one could copy references to the Use Cases that are includes from diffenent views. But from where can I include them? :-(

I would be very thankful for every kind of help. Perhaps to my concrete problem but also for a general advice how to reduce the complexity of Use Case diagrams would great.

Thanks a lot and sorry for my bad english skills.

[«Midnight»]

Try this, to see if you can get a fast grip on your problem.

Don't be afraid to divide the use cases between packages. You can simply drag a use case from the Project Browser tree onto a diagram, regardless of where the use case or the diagram reside in the project hierarchy.

Your second idea will also help you, but dividing the views so that the complexity of the overall system does not prevent a reader from understanding what goes on in each component.

Now, create a package (say) for a high-level view of the system. In this package put a single use case for each major functional [See note 1 below] area. This would be along the lines you are thinking of in option 1. Do not use your current use cases; just create one for each area, and use a 'generic' name. You now have a picture of the overall system, divided into function areas.

Make each of the use cases on this diagram into a composite element - see the EA help for how. On each 'child' diagram, drag your highest-level use cases from the appropriate functional area. Now add any «include» and «extend» use cases that related to these. Do not add any use cases that do not belong in this functional area, even if they share the lower-level cases you included.

You should now have a set of simpler diagrams, with a higher level roadmap. Take it from there.

[You could divide this up in other ways, and probably should. Search the forum or current literature for cross-cutting use cases, and other approaches.

My goal above was to get you moving forward as fast as possible, using your work to date.

When you have the luxury, take a close look at other approaches to partitioning complex systems. See if you can raise awareness of these ideas in your organization. Perhaps there is a business case for evolving your paradigm, and perhaps there is sufficient interest and commitment to do so.]

HTH, David

[thomas.kilian]

If your Use Case diagrams resemble spider webs consider a re-design of you UCs. It's most likely a wrong design. Read the standards about UC design.

[lemanchot]

Hey,

your advice is helping me a lot, thank you.  "Cross-cutting use cases" seems to be a good keyword for further research.

I created use cases on a high abstraction level in a package. But I'm still not sure how to model in a manner that avoids redundancy.

For example there is a use case "XY" that has to be included in the composite diagrams of the Use Cases A,B and C. If one want to avoid redundancy, there must be a link to Use Case XY from within two of A,B and C. If XY was first created as original in A, the link could be copied to to B and C but I don't see a reason why the "original" XY should be declared in A while B and C refer to it. It could also be declared in one of the two other use cases.

You wrote: "You can simply drag a use case from the Project Browser tree onto a diagram, regardless of where the use case or the diagram reside in the project hierarchy."
So, I don't care where I declared XY at first and just copy the link when and where I need it?

Thanks,
Tim

[lemanchot]

If your Use Case diagrams resemble spider webs consider a re-design of you UCs. It's most likely a wrong design. Read the standards about UC design.

It isn't realy a spider web. I think that it's recommanded as a design pattern to extract functionality that is shared by different use cases in a single use case that can be included instead of declaring the functionality at serveral places.

But I always think about solutions for a better design.

[jeshaw2]

What about making the use cases that need to include 'xy',  specalizations of a more general use case "G" that has the <<include>> relationship?  Then, "A", "B" and "C" would inherit the relationship to "xy".  8-)  Much less "redundancy" I suggest.

Jim

[BioformLivesAgain]

Ummmm (voice of experience here) you have WAY too many use cases...

I am currently working on a financial membership application for the NY.. and NA.. system that has 28 use cases total and only have 3 includes and 1 extend relationship.

It really sounds like your UCs are too small in their scope. Remember a system use case's scope should describe an interaction with the system that accomplishes something that has value to the business.

A good test is to ask yourself if after I completed the use case, would I be able to get up and go to lunch feeling that I accomplished something of value to the business...

Example: Manage Task Assignments. Define the Task Game Plan, etc. (actual UCs that use the system to accomplish the business process of managing member applications)

Hope that helps...

I would recommend any of the 3 Amigo series of books on Use Cases.

David