uml-include or extend

Question

I am trying to make a use case diagram for library management system. I have two actors admin and user.

Now, the admin has three functions manageCategories (of books like history, geography etc.) manageUser and manageBooks..

What I am doing is considering these 3 functions in a single function manage i.e manage is a single use case.

How should I consider the three functions managerUser, manageBooks, manageCategories in the diagrams?

Should I use include or extend the three functions in a single use case manage, or use anything else?

Answer 1

Edited after the corrects comments of @vainolo about the included use case confusion in my answer:

If the manage use case needs the callable use cases (managerUser, manageBooks, manageCategories) in order to make sense (produce value) for the main actor, then you should use the include relationship.

If the actor can complete the manage use case executing zero or all three of the callable use cases (managerUser, manageBooks, manageCategories) then you should use the extend relationship and you may specify the extension point conditional statements for them.

If the manage use case is a container used to organize the three callable use cases which can be executed independently, then I'd modelize manage as a Use Case Package containing the three use cases rather than a use case per se.

---

Please find the following excerpt from that post about the NOT mandatory execution of an included use case (as correctly pointed out by @vainolo):

Point 5: Inclusion use cases may be optional

A UML superstructurestatement Section 16.3.5 of 2 states:

“Note that the [inclusion] use case is not optional, and is always required for the [base] use case to execute correctly.”

Cause for confusion

Some seem to interpret this to mean that an inclusion use case must be performed during each and every execution of a base use case.

Nothing is further from the truth and the truth is simple.

The simple truth

Whether an inclusion use case is mandatory or optional to a base use case depends on where in the base use case the fragment was defined that is now replaced with an include statement for the inclusion use case.

If that fragment was part of the base use case’s unconditional flow (steps that always get executed), the inclusion use case is mandatory. If that fragment was part of a conditional flow (steps that get executed optionally), the inclusion use case is optional.

So what does the UML statement mean?

The purpose of the UML statement seems to be to contrast the include relationship with the extend relationship, as follows.

At an extension point (not for the entire base use case), the extension use case’s execution is optional.

When the execution of a base use case reaches an extension point, an extension use case may or may not be inserted, because there may be a condition attached to the extend relationship. However, at an “inclusion point” (not for the entire base use case), the inclusion use case’s execution is mandatory.

When the execution of a base use case reaches an inclusion point (i.e., an include statement in the base use case), the inclusion use case will always be performed, because there is no provision for attaching a condition to the include relationship.

Answer 2

I disagree with @TonyRad.

Including a use case in another use case is like saying "this use case needs the other use case to execute". It doesn't mean that the other use case will actually be called. For example, when a user does manageBooks he doesn't always executes editUser, but on the other hand, the manageBooks use case is not complete if there is no implementation of the editUser use case.

Extending use cases should be used when the extended use case does not require the extending use case to exist. For example, a browser exhibits extension points where plugins can be added. The browser will work if there are no plugins, but it there are, the browser will execute them when the extension point comes.

In your case, the question is how these use cases are show to the user. If the user first has to enter a "management" screen and from them he can access "add user", "remove user" and "edit user", then it is logical to model them as inclusions. If on the other hand the manager can directly operate this three use cases, I would do inheritance from "management" to "add user", "remove user" and "edit user".