Best practice for Use Case groups

[ebeb]

Hi,

I'm currently thinking about how to realize use case groups. Let explain, what I mean: Imagine you have two use cases "Update Software over-the-air" and "Update Software via cable link", you can summarize this in a use case group called "Update Software".

Graphically using EA, I have several options: I could draw all three use cases using generalize relationship. Or I could use a package called "Update Software" including the two specialized use cases.

But I'd like to have a use case element "Update Softawe" instead of a package that will open a new use case diagram after doublicking that will only software update use cases.

Is this possible to do this using EA or do you recommend another practice? I want to remain a clear design in the main use-case diagram by not getting too deep into and providing more details in other sub-use-case diagrams.

Thanks,

Jan

[ebeb]

Oops, maybe this should be moved to the UML forum...

[ebeb]

Third post

OK, I found the perfect answer to my question:

Just right click on the Use Case (or other Element) and choose "Advanced" adn then "Make Composite". After this, a new Use case Diagram will be created as a child. After this, you can double click on the User Case to open the child diagram.

Jan

[«Midnight»]

Hi Jan,

Note that you can have multiple child diagrams, of various types. Only one will open when you double click the element though, that being the one you create when you set up the element as composite.

Right-click the element and from the context menu choose Add. The sub-menu will (sometimes, depending on the parent element type) suggest some possible child diagram types. There is also an option (even if no suggestions are given) to choose a diagram type.

Note that the child diagram feature does not make the element composite, nor does it prevent you from doing so (before or after). These are separate and compatible features of EA.

You can search the forum - go way back - for some other details on this if you run into trouble (that is unlikely though).

HTH, David

PS: Oh yeah, I almost forgot. Look into hyperlinks in the EA help. That's another way to navigate around a diagram group.

[Luis J. Lobo]

Ok, but have in mind that a Use Case diagram isn't a DFD. A Use Case shouldn't be process-oriented or sub-composed.

The best solution is Generalization.

[«Midnight»]

What I am talking about should work for many different element types, and many different child diagram types for each. It is similar to composite elements, but much more general.

PS: I strongly suggest you do not use composite elements as a substitution for generalization of use cases (ala UML 2.0). The purposes of these two concepts are distinct.

[ebeb]

Hmmm... interesting...  

The funny thing is, before working with EA, I used another tool to create use cases where I actually only used generalization. Now that I changed to EA, I had to migrate all use cases and I decided that it was too messy.

I have 8 primary use case which have lots of sub use cases that can be modeled by using generalization. But that would require putting all in one diagram.

The way I do it now has several advantages:
- You can easily have an overview
- you can easily navigate into the sub use cases by double clicking
- When it comes to documentation, every primary use case has some subsections with additional diagram and explanations.

I don't see any of these advantages when using generalization except it is more UML conform.

Please correct me if I'm wrong, maybe there other ways to have both.

Jan

[Luis J. Lobo]

Yes, but you could have the same beneficts using packages instead of "father" use cases. The package is a container element without functionality, and it's navigable too by double-clicking (without need to make it composite), could contain diagrams...

It's only an appointment, but in this way your model should be more "elegant".

Under a use case there should be only activity and interaction (sequence/communication) diagrams, little more.

Though I have to admit that we all have had at some time the temptation of nesting use cases!!

[ebeb]

For Requirement, I use packages to create a hierarchy. But for use cases, I see the problem of the graphical representation of packages.

If I have a top level use case diagram, I don't want any package elemtent to appear because this is a use case diagram which we want to share with the customer. So messing up use cases and packages element within the use case diagram can lead to incomprehension.

And I can still have activity diagrams at the lowest level.