Show dependencies on UML use case diagrams other t

问题:

How can we show simple dependencies between use cases other than "extend" or "include". For example we want to say use case1 depends on use case2 which are done by user1. Can a simple arrow be used for this? For which direction?

回答1:

Yes. There are other dependencies.

The full list of classes directly connected to Use Case is (fig. 18.1 of UML 2.5 standard) :

• Use Case
• Constraint
• Actor
• Include
• Extend
• Extension point

But that doesn't mean you can't use other UML elements in the diagram with Use Cases. UML standard DOESN'T limit any elements to diagrams. You can even use ALL UML elements on one diagram. On the other side, that would be senseless, of course.

A usable practical set can be seen, for example, looking on the elements on the Use Case palette of the VP UML, for example. Except already mentioned, there are:

• System
• Dependency
• Generalization
• Realization
• Collaboration
• Note
• Anchor
• Containment

here you can see a shortened list with explanations.

As you see, dependency is not only allowed by standard (all are), but widely used.

回答2:

You have multiple possibilities to show dependencies between Use-Cases. There are more keywords that you can use than << extend >> and << includes >>.

1. << requires >> - Indicates, that UC2 requires UC1 first to be executed.
2. << follows >> - Says that this use case is executed immediately after another use case.
3. << resembles >> - Means, that this use case is similar in the result and the pre-condition, to another one, but got different actives
4. << equivalent >> - Same Use case but got a different name.

In your case, I would draw an arrow from the actor (user1) to case1 and then case1 << includes >> case2. What you always need to keep in mind, is the purpose of your diagram. If you are using UML as sketch, it's enough to make sure, that the diagram is understandable and within the scope. Over-specification won't support this.

回答3:

You say: "use case1 depends on use case2 which are done by user1".

Can you clarify this? How does UC1 depend on UC2?

UC modelling can be very tricky. It is relatively easy for the modeller to forget what an UC actually is and to mix some other system concerns in the model.

UC model should not express dependencies derived from the underlaying system structure. For example if UC1 is implemented a component that is also used in the implementation of UC2, this situation is not shown on the UC model itself. Is the dependency you are talking about of this mature?

The sequence of the execution between two UC is also normally hidden in the diagram (can be indirectly shown via pre and postconditions, but not using relationships).

My recommendation is to keep UC model as simple as possible, and to limit the relationship to moderate use of include and extend. UC can be seen as an abstraction of an interaction, a dialogue between actor and system. How can a dialogue depend on other dialogue?