Why Did We Remove Single <> in Given Diagram

Question

While I am following an object oriented course, I am faced with a statement that is kinda strange. I couldn't understand why we would remove UC4 from the given image.

And if it is wrong, then similar UC which is below (Download Docs) also must be wrong?

Please tell me what's wrong with this <<include>>?

Answer 1

You do not have to remove UC4 to be UML compliant (it is not wrong), but it is good to remove it for a different reason (best practice). Let me explain.

Eventually, every use case must be further specified, using plain text and/or using diagrams, in order to specify the flows of events (the steps in the user-system communication).

Several use cases may have partially the same flows of events. Without using «include» relationships, you would have to specify these flows in each of these use cases. To avoid duplication of specification (and thus the danger of inconsistencies), you may factor out the duplicate specification in separate "use cases" and use «include» relationships to indicate which use cases share which flows.

By the way, the "use cases" representing the shared parts of other use cases, may not be complete use cases in themselves, therefore I write "use cases" in quotes. Such an incomplete "use case" is not directly associated with an actor in the use case diagram. Personally, I think this should be allowed, but this is debatable.

In your example, the «include» from UC3 to UC2 is fine, because it avoids duplication of the UC2 flows in the specification of UC3.

However, the «include» from UC3 to UC4 makes no sense, because you could include the UC4 flows in UC3 and then remove UC4. This «include» relationship does not avoid any duplication of texts or diagrams.

Yes, the same applies to the «include»-relationship from "Search docs - full text" to "Download doccs".

For more information, see "Master the Use Case Include Relationship"

Answer 2

The first diagram tries to recommend good practices:

1. Avoid useless specialization

Admin seems to have no relevance in the diagram, since it only inherits the association to use-cases of Member and has no other association. So it seems to add no meaning to the diagram:

• Pros: the temptation of adding unnecessary knowledge might lead to diagrams difficult to read, whereas additional actors are not in anything different when interacting with the system.

• Cons: the diagram is not all; sometimes Admin can be used in constraints, or in the use-case description , e.g. "a Member can only see own ratings, except for Admin who can view the ratings of everybody". So in some rare cases, the additional specialization can make sense.

2. Avoid use cases with no actor

Use-cases represents a set of behaviors that help some actors to achieve some goals. Absence of actors then suggest that this UC corresponds to no real need, or that the intellectual effort to identify the actor was not done:

• Pros: isolated use-cases often represent something that is not really a use-case, e.g. Modern user interface, Fast response time, Date-picker. Sometimes, the actor was just not identified. In the last 25 years, I have never encountered an isolated use-case that was really justified.
• Cons: it is not forbidden to have a use case without actor. According to UML 2.5.1, a use-case "specifies a set of behaviors (...), which yields an observable result that is of value for Actors or other stakeholders". So, the goal of use-case can be a goal of some-one who doesn't use the system. Moreover, "Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors" - it's a possibility, but not an obligation as implied by section 5.1. that explains how the word "can" shall be understood.

However, an other stakeholder can only benefit of the system's observable results if someone or some other system brings it to his/her attention. So there should be an actor that was not identified, and hence the pros really dominate here.

3. Avoid including use cases with no actor

This recommendation is an stronger extension of the rule 2: no actor, no real purpose.

• Pros: this rule may prevent use-cases that are not driven by the value for an actor.
• Cons: this rule is very theoretical, since many modelers understand that the actor of the including use-case is implicitly also actor of the included use-case. This is why you'll often see diagrams, like diagram 2.

So this recommendation is not really justified. I'd be more provocative and say to avoid includes and extends at all, since it makes diagram more complex, and often leads to undesirable functional decomposition.