4

Extension Diagram

Hi, I would like to have the receptionist and the manager to be able to view work type and rates and subsequently update it. However, tech personnel can only view but not update. Is the diagram valid?

I read that extended use-case are initiated by actors that initiated the base case. How should I differentiate that tech personnel can only initiate the base case and not the extended case? Should I not place the extension association? What about included use-case?

Sorry if this question has been asked before.

aydinugur
  • 1,208
  • 2
  • 14
  • 21
Soggeh
  • 101
  • 1
  • 8

3 Answers3

3

You should neither «include» nor «extend»

View work type and rates and Edit work type and rates are perfectly valid independent use cases.

In general it is a bad idea to chain use cases together just because you usually do one after the other. You should not try to model the sequence of activities with use cases. Use your business process analysis for that.

You can use the post- and preconditions to constrain the execution of use case. In fact your Edit use case doesn't really require the View use case in particular to be executed does it?. It probably only needs a work type to be selected. So it can be executed right after any use case that has a postcondition stating that work type is selected.

Which use case does that is irrelevant to the Edit use case, as long as a work type is selected before the use case starts. There might be 10 different use cases that result in a work type being selected.

The «extend» I consider to be simply wrong. Extending use cases are usually incomplete use cases that insert their behavior into a complete use case are a particular extension point defined in the extended use case. The extended use case in does not have any knowledge about the extending use case and does not need or use the results of this behavior.

The few cases I which I found «extend» use cases to be applicable were things like monitoring use case. For example a use case that monitors the number of open tickets in the system and sends an alert to an admin in case a certain threshold is surpassed.

If you still insist on linking the use cases together, for example in case you really mean that you can only edit rates after executing the use case View work type and rates I would do it the other way around. Include the use case View work type and rates from the use case Edit work type and rates, probably as the first step.

Both solutions (separate use cases, or include from Edit to View) solve your issue regarding the rights of different users as it is now clear beyond any doubt who can do what.

Geert Bellekens
  • 12,788
  • 2
  • 23
  • 50
  • 2
    Yes, incl/excl is mistaken for chaining, which is not their intention. So it's better left away if one is not absolutely sure about its use. I might add the comment in my answer to the answer to clarify this. – qwerty_so Nov 10 '17 at 08:17
  • Though I think you are not right about completeness. Read on P. 638. – qwerty_so Nov 10 '17 at 08:35
  • 1
    @ThomasKilian I did, and it states: *the extending UseCase typically defines behavior that may not necessarily be meaningful by itself* Which I translated into "not complete". Use cases that are extended have to be "complete" on their own as they have no knowledge of the extending use cases. – Geert Bellekens Nov 10 '17 at 08:39
  • Especially about include: _As the primary use of the Include relationship is for reuse of common parts, what is left in a base UseCase is usually not complete in itself but dependent on the included parts to be meaningful._ This, in contrast to what you said. So `include` makes the main UC incomplete! – qwerty_so Nov 10 '17 at 08:39
  • _may not_ is the crucial part. – qwerty_so Nov 10 '17 at 08:42
  • @ThomasKilian I don't think your quote contradicts my statement. It says that usecases that include other use cases are usually incomplete. Use cases that are extended are always complete. Extending use cases are usually *not* complete. I'll edit my response to reflect the "may" – Geert Bellekens Nov 10 '17 at 08:46
  • Thinking a bit more over this got me the question: what is an incomplete use case? A fish without bike? I think that whole section in the specs is rubbish. A use case shall only show a single added value. No extend/include. Period. (Well, we could make this a lengthy discussion, but we should not...) – qwerty_so Nov 10 '17 at 11:05
2

I'd model it this way:

enter image description here

Manager and Receptionist have the same roles in this context which is why I used a generalization. Without knowing the domain this seems okay, but it's just a proposal.

The <<extend>> is constrained by {not allowed for actor Tech} which clearly excludes this actor from entering this (optional) use case.

There is no need to also associate Receptionist with Update... since it's an extension of View..., except you want to be able to Update without Viewing first.

N.B. about <<include>>/<<extend>>: They are not meant as chaining use cases. The UML spec states (pp. 638):

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.

and

The Include relationship is intended to be used when there are common parts of the behavior of two or more UseCases. This common part is then extracted to a separate UseCase, to be included by all the base UseCases having this part in common.

Now that <<include>> just looks like a bastard. A use case is about a unique added value. And this uniqueness can be questioned if there were behavioral recurrence in more than one use case. In any case these relations are often just taken as functional decomposition. And that would be plain wrong. From my POV the UML spec would be better without these relations.

In context of the above diagram it represent a pattern where you view something and only then can make it editable. It would well be perfect to have two individual bubbles without <<extend>> where you place a constraint in Update telling { can only be reached after View... }.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
  • but if you set an include and associate receptionist to view and update, you do not need the constraint ... – granier Nov 09 '17 at 14:45
  • @granier An `<>` is **always** performed, which in this context does not seem to make sense - it's optional. – qwerty_so Nov 09 '17 at 14:47
  • an update without viewing what you update hum I have to figure what it could be – granier Nov 09 '17 at 14:49
  • @granier Simple: the View form and the Edit form are different. Though the Edit shows the values, they are editable. The View does not allow editing. They are clearly different use cases. – qwerty_so Nov 09 '17 at 14:54
  • Can it be a precondition instead? i.e. {actor must be Receptionist or Manager} – Soggeh Nov 09 '17 at 17:09
  • 1
    Yes, a precondition is just enough My human logic tells me that there would be no semantic difference in this :-) – qwerty_so Nov 09 '17 at 21:02
  • @ThomasKilian The idea that an include is always executed an dan extend is option is a common misunderstanding of the UML specs. I've seen numerous wrong usages of especially the extend relationship because of this. – Geert Bellekens Nov 10 '17 at 07:18
  • @GeertBellekens You're trying to baptize the saint ;-) I know that and almost never get sick of sermonizing that. However, in this context I think it's a valid application for `<>` (one of the few). It's not directly about order UCs. But this implies "you need to view in order to update" which is a common pattern. I'd put aside `<>` if there were a requirement for direct editing. Read on p. 638: _Extend is intended to be used when there is some additional behavior ..._ So that could be the pattern: view with locked fields, then optionally unlock for editing. – qwerty_so Nov 10 '17 at 08:14
0

I would change extend by include. To update the work, you have to view it. It is mandatory to view it.

In your diagram, Manager and Receptionnist are equivalent, with this schema only, you can define one actor only. Or model that Manager inherits from Receptionnist.

And to avoid mistake, if you do that, you have to be sure that Receptionist and Manager can also activate the view use case without the update. Otherwise some associations have to be remove.

granier
  • 1,739
  • 13
  • 25
  • 1
    if you change extend by include yes. – granier Nov 09 '17 at 13:50
  • Haha, the diagram is just the snapshot of the actual schema so as to illustrate my question. The receptionist and manager have different roles in other use-cases. However, does the diagram sufficiently/legally illustrate that only manager and receptionist can update? (although they too have to view first). And yes, they can view without updating. – Soggeh Nov 09 '17 at 13:51
  • Nonetheless, is it better if i just remove the association between the two use-cases? – Soggeh Nov 09 '17 at 13:56
  • You can but if you remove the include (assuming you change extend by include) to update it will not be mandatory to view. If you want that to update you have to do the actions done to view, you have to keep the include. And thinks to inheritance between the manager and receptionist: your schema will be easier to read. – granier Nov 09 '17 at 13:59
  • @granier Maybe you should clarify whether you mean an include from the edit use case to the view use case or the other way around. – Geert Bellekens Nov 10 '17 at 07:09
  • in fact, we can discuss a lot's about such topic and how it is logic to model the view/update. I feel that @killian suggestion is closed to the question but It can be argue about the logic behind. But I am not sure that's will be a positive debat ... – granier Nov 10 '17 at 08:51