CODEWITHSUNDEEP
uml
Urban
Urban

Reputation: 585

UML to extend or not between two use cases

I have an actor called X. This actor is connected to the Use Case: View inventories. There is also a Use Case called View items. While viewing inventories the actor can choose to view the items belonging to a inventory.

In this case: Should the View items Use Case extend the View inventories? Because it's optional for the actor to view the items while seeing all the inventories? Or should both use cases simply get connected to the actor and not each other?

In UML 2 and the unified process it's stated that Extension use cases generally at note complete use cases and therefore can't be instantiated. I'm really confused in my situation.

Here a simpeler view:

Use case: View inventories

extend----> View items

You can't view items without first choosing a specific inventory from the view inventories use case. This is optional.

use case: View items

extend----> Add item extend----> remove item

You have to view the items from a specific inventory before you can add or remove items. This is optional. enter image description here

Upvotes: 0

Views: 183

Answers (1)

qwerty_so
qwerty_so

Reputation: 36305

You better forget those extend/include relations. You are tempted to apply functional decomposition on UCs and that's simply the opposite of what you are trying to achieve here. A UC shall be a unique added value the system under consideration (SUC) delivers to one of its actors. So UCs are best shown as simple bubble inside a boundary representing the SUC and the actor standing outside. It's common to place the primary actor to the left and (if present) secondary actors to the right border of the boundary.

  • Simply don't use extend/include. (I never really had a need for those relations. IMHO they are a design fault in UML.)
  • If your UC diagrams start resembling a spider web your design is likely broken.
  • UC are not about order of functions. If a UC can only be performed after another one has been executed, add a constraint { can only be executed after UC x has been completed once } or the like.

Upvotes: 1

Related Questions