Correct usage of includes and extends in use case diagram

Question

I am creating a use case diagram for a barber shop system. I am not sure if the Add Product Inventory use case should include the Purchase Product use case.

The actors which will interact with the barber shop system are:

1. Customers
2. System users (ie. Barber)
3. System Administrator (ie. Manager)

All users will need to be able to login in, customers will need to register if they are a first time user.

The customer will interact with the system to make a booking or purchase a product i.e gel, shampoo, wax. A booking can extend to cancelling the appointment, it is unlikely for the customer to be able to reschedule the appointment but rather cancel the appointment and book again at a different time.

The system user, the barbers, need to be able to view the timetable of appointments, view customer contact details and login to the system.

The system admin, who is likely a manager and head barber, should also be able to view the timetable of appointments, view customer contact details and add a product inventory to the store. The product inventory will also include setting product specification, the colour or size of product, and setting the price.

Answer 1

I am not sure if the Add Product Inventory use case should include the Purchase Product use case.

This is not the case, else that means each time a product is added in the inventory it is also purchased during that add. Note also the actors are not the same for these two use cases, but having the include that means the purchase is also done by the admin.

There is no extend too.

The fact a product was added in the inventory before to be purchased is a precondition you put in the description of the UC Purchase.

---

There are other problems in your diagram :

• all your extends are drawn in the wrong direction, except may be between Login and Register depending on what you wanted to say

• it is common to put the secondary actors on the right, so Customer seems to be a secondary actor but this is not the case.

• Admin and Barber cannot Login (but they can logout), to have one of these roles a real person needed to successfully login before and that is done with an actor Guest or something like that.

• in the same way a Customer cannot Register (nor Login)

• But in fact Login and Register (and logout) are very common and simple features and probably do not have enough plus value to be use cases.

• A Customer can cancel an appointment only during its creation, this is not what you want.

  • you need to allow Customer to activate Cancel Appointment in an other way (directly or as an extension of the probable View Own Appointments, see after)
  • for me while an appointment is under construction it does not exist and then the Customer cannot cancel the appointment, but the customer can abort the construction. So for me there is no extend between these use cases. Of course in the description of Make Appointment you can say an abort is possible, but I think this is the case in all the UC.

• Very probably a Customer can view his/her appointments so an UC (let say View Own appointments) must be added. Note this is not like the UC View Appointmenst a Barber can activate, so these UCs must not have the same name. To have Cancel Appointment as an extend of this new UC seems a good way and in that case Cancel Appointment cannot be directly activated by Customer.

• Some UCs an Admin can activate are missing, to modify the price of a product, to remove a product, to modify a barber details, to remove a barber, ...

Answer 2

I'm not familiar with the business rules in your scenario, so this is a little bit of guess-work and a few assumptions which you can verify.

I assume the 'Add Product Inventory' Use Case is about adding products to an inventory of all products. For our purposes to answer your question, I don't think it matters whether this Use Case relates to adding one product, multiple products, managing products (e.g. editing or removing them), whether the inventory already exists or not, or if the Inventory is a separate thing to the Products on it, but answers to those questions are not 100% clear from your model and you may consider clarifying those points.

I also assume that a Product needs to be on the Inventory in order that it can be Purchased. If that is the case, then I think what you are asking is about this very point -- how do I represent the fact that the Product needs to be Added to the Inventory before it can be Purchased? If that is what you're asking, then you can represent that using a simple 'dependency' relationship which would run from the Purchase Product Use Case to the Add Product Inventory Use Case as per below. This states that the Product Purchase is somehow dependent on Add Product, but does not go further in explaining that relationship. Alternatively, you could use a preceedes relationship running instead from the Add to the Purchase. I don't think extend is the correct relationship -- the steps of Add Product don't need to be factored in every time you Purchase Product, the dependency is on the objective of Add Product having first been achieved, not the steps.