3

in the book UML @ Classroom An Introduction to Object-Oriented Modeling is written "Use cases—even included or extending use cases—can always be executed independently. If they can only be executed within the scope of another use case and not independently, they are not use cases and must not be depicted as such. Their functionality must then be covered in the description of the use case that uses them.", however all examples of extends relationships my Professor gave to me and I found in internet the extending use cases can only be triggered within the scope of the base use case. I'm lost, which one is correct ?

I have a mini-project, I ignored the extending use cases that can't be triggered by any actor, should I draw these extending use cases ?

Ahmed
  • 31
  • 3
  • Does this answer your question? [What's is the difference between include and extend in use case diagram?](https://stackoverflow.com/questions/1696927/whats-is-the-difference-between-include-and-extend-in-use-case-diagram) – Geert Bellekens Jul 10 '23 at 10:39
  • I'm afraid the statement, although well intended to warn about functional decomposition, is wrong. – Geert Bellekens Jul 10 '23 at 10:41
  • Thank you for you reply, you mean that ignoring these extending use cases is wrong ? take a look on this question https://stackoverflow.com/questions/44245773/actors-and-extending-use-cases-in-uml?rq=2 to understand more what I mean – Ahmed Jul 10 '23 at 11:21
  • @GeertBellekens The answer you linked contains a lot of bad/wrong explanations. I would remove it all along if possible. – qwerty_so Jul 10 '23 at 13:44
  • @Ahmed Teaching UC is broken. Your professor should be right but reality shows that teachers did not get the point either. It's a pity: even you know it's wrong your prof wants to see what HE thinks is right. – qwerty_so Jul 10 '23 at 13:47
  • 1
    You better show your own context rather than linking an old question. – qwerty_so Jul 10 '23 at 13:49
  • @qwerty_so I know, but it is basically the same question, hence the duplicate. Some of the answers are OK. – Geert Bellekens Jul 10 '23 at 13:55
  • @GeertBellekens The problem for the ignorant: which of those answers are good and which bad? The "bad UC syndrome" is everywhere, and SO's voting does not cure it :-( – qwerty_so Jul 10 '23 at 16:27

2 Answers2

2

The specification says:

the extending UseCase typically defines behavior that may not necessarily be meaningful by itself.

and

The extension takes place at one or more specific extension points defined in the extended UseCase.

So, uml@classroom is wrong and your professor is right. Extending use cases are not meaningful by itself and cannot exist without an extension point in the extended case.

However, there are good reasons for avoiding the extend relationship.

First of all, the specification contradicts its own definition:

A UseCase specifies a set of actions performed by its subjects, which yields an observable result that is of value for one or more Actors or other stakeholders of each subject.

How can a behavior that "may not necessarily be meaningful" be "of value"?

So, maybe the UML should have introduced «secondary» "use cases" for this purpose. Actually, this is how it is done in my company. That is, if the client insists on using «extend» or «include».

In my opinion secondary "use cases" are only needed, if they are your only means to describe common or extending behavior. However, usually you will use other elements to describe the use case, such as activity diagrams or interaction overview diagrams. They can easily and accurately describe such behavior. Extending use cases will simply duplicate the effort without any benefit.

So, even when uml@classroom is formally incorrect, the advice is sound! A use case that is worth the effort is independent!

PS: Much confusion stems from the sloppy use of language: A use case is not executed. A use case happens, when I use a system by invoking some its functions, which will then get executed. The specification never uses this wording. Rather it talks about initiating a use case.

Axel Scheithauer
  • 2,758
  • 5
  • 13
  • Seems I could repeat my comment to Christope's answer here. Honestly I learned UC from Bittner/Spence and not from digesting the specs. Max Liebermann: "Man kann nicht so viel fressen, wie man kotzen möchte" – qwerty_so Jul 10 '23 at 23:27
  • 1
    @querty_so I agree, the specification is not meant to give methodological advice. For this you should read other books. You have to concede this to the specification: It allows good modeling of use cases according to Bittner/Spence. – Axel Scheithauer Jul 11 '23 at 08:25
1

The independence is a practical way to avoid functional decomposition. Considering that functional decomposition is not a bad use-case practice (even if UML specs explicitly allow it), it is a good idea to look for independent use-cases.

Extensions should also follow this rule, but not for the reason you think. By definition, the extension is an additional behavior that makes sense only in the context of the extended use-case:

UML 2.5.1 - Section 18.1.3.2: An Extend is a relationship from an extending UseCase (the extension) to an extended UseCase (the extendedCase) that specifies how and when the behavior defined in the extending UseCase can be inserted into the behavior defined in the extended UseCase. The extension takes place at one or more specific extension points defined in the extended UseCase. Extend is intended to be used when there is some additional behavior that should be added, possibly conditionally, to the behavior defined in one or more UseCases.

It is therefore very difficult to have an independent extensiin. Nevertheless, still you shoukd apply the rule of your book: avoid dependent use-cases. Therefore avoid extensions at all. And this is good, because most often extznsions present something very detailed that could as well be explained in the narrative of the extended use-case ;-)

Christophe
  • 68,716
  • 7
  • 72
  • 138
  • Me still thinks that the evil comes from the meta-model authors being techies and thinking themselves in functional decompositon paths. Neither include not extend should exist since it only leads to functional decompostion. Just reading the definition verifies that. Well, wishful thinking. Until UML 5.0 we will probably have to juggle. Failure for sure. – qwerty_so Jul 10 '23 at 21:43