Linking use case scenario objects on a diagram?

[dmf]

I want to represent on a single diagram a set of scenarios pertaining to a single use case.  Firstly, I assume the correct way to represent each scenario is as an object element, instantiated from the use case (and indicated on the diagram with an <<instantiate>> dependency to the use case element).

My question is how can I associate the scenario objects with each other?  For example, I want to illustrate the connection between the main success scenario and an alternate scenario that departs from the main one part way through.  I am guessing this is a dependency relationship (the alternate scenario depends on the main one), but what is an appropriate stereotype?  I want to illustrate all scenarios as elements on the one diagram, giving some indication of their closeness to each other (ie. in terms of number of steps in common).  Am I on the right track?

On further thought, I guess <<extend>> is appropriate?  Is it correct for a scenario to <<extend>> another that shares a common classifier?

[BioformLivesAgain]

I use an activity diagram to describe the flow of the use case with each pathway through the activity diagram representing a possible scenario...

I further use color coding to represent the basic path (leading to the successful outcome), alternate paths (additional paths outside of the basic path that also lead to a successful outcome), and exception paths (ones that do NOT lead to a successful outcome.)

[dmf]

Thanks for your response!  However, my question does not relate to how the detail of each scenario should be displayed.  My goal is to represent each scenario as a single element (a <<scenario>> object with a Use Case classifier) and to show (via dependency relationships) how these scenarios relate to each other.

[Paolo F Cantoni]

In UML, an activity diagram IS an activity object.  Taking bioform's suggestions, you can create a single object that this the activity diagram representing both the main, alternate and exception flows.  This represents the consolidated view of the Use Case.

You can make this the instantiated object.

Then you can create separate activity diagram underneath the consolidated activity and designate them scenarios.  You can copy and paste the diagram from the consolidated views and remove the elements not required for the specific scenario.  If you then Lock these scenario diagrams, you can make them "views" of the consolidated one.  You can then make changes in the consolidated diagram - with all the relevant information to hand.  The scenario views will be updated.

The scenario view diagrams are implicit instantiations of (part of) the use case.

If you REALLY aren't interested in the activity details, leave them diagrams empty.  The structure above still works.

Does that help?
Paolo

[dmf]

Thanks Paolo, interesting notion of using activity diagrams themselves as instantiations of the use case.  However, my key questions still remains of how these scenarios relate to each other.  You mention creating a separate activity diagram "underneath" the consolidated activity, but what UML link would you use to connect these diagrams.

[«Midnight»]

None, at least not a UML connector.

Right-click the use case and from the context menu select either the diagram type you want or the final entry - I don't have EA open, so I don't have the exact entry name - that brings up the diagram type dialog. A diagram of the type you specify (either from the context menu or the dialog) will be created as a child of the use case. [Check the project browser.]

HTH, David

If you want to do this from the API, use the ElementID (I think) property of the diagram.

[Paolo F Cantoni]

None, at least not a UML connector.

dmf,

David is right...  Once you start trying to model other than code using UML, you come across its limitation at present. However, since it's extensible, you can create your own nomenclature.

So long as you're consistent (THAT word again), should UML expand into these areas, you should be able to transform what you've done into more formal UML when it catches up.

HTH,
Paolo