Han,
There's a
lot of ways to go about this. Depending on who you're listening to, each way has the advantage of being better than all the others.
Let's see if I can start you off in a useful direction.
Take some time to look through this forum (all sections) for some really good advice on this. There are quite a few members who've got some really good approaches. They have spent the time and effort to either leverage EA to support use cases or adapt to EA tp their approaches (or both).
Chime if folks!
That said, as a starting point remember that you an associate quite a lot of different diagrams (for example) with a use case. Once you've drilled the use cases down to a comfortable level, consider making (some of) the lowest level cases composite elements. To do this right-click the use case in question and from the context menu select Advanced | Composite Element.
This will create a new use case diagram and diagram 'below' and owned by the composite. Go to the 'inner' diagram and from the EA main menu choose Diagram | Change Diagram Type. You can now make this a sequence or activity (or whatever) diagram. This gives you a powerful paradigm for description of the inner workings of a component. It also allows you to impose considerable semantic rigor, if that is your intent.
The advantage (and occasionally the curse) of this method is that there is a visual cue on the composite element, and double clicking will take you to the inner diagram.
You can also associate additional inner diagrams with a use case (and several other elements) by right-clicking the element and choosing Add from the context menu. Depending on the element type there may be one or more diagram types that you can add (there are five for use cases). These diagrams will not be visually cued or linked by double clicking, but they are still associated with the owning element. [You can probably use the trick above to include diagrams other than the types offered. Think twice about this though, since the set offered usually makes good sense.]
This whole approach is very good for (for example) providing a model of some scenarios. Depending on the type and level of use case an appropriately named activity or sequence diagram (or both) could help explain a scenario; this can be a
real help when you run into a scenario that starts getting too wordy.
HTH, David
