Use-Cases for Two Inherited Actors

Question

We have been developing a requirements model for a travel agency system. There are two kinds of member users: premium and free. Both users are able to cancel their previous reservations. Unlike premium users, free users have to pay a cancellation fee as a result of cancellation.

In the use case diagram for the previous functions we have the following struggle: Shall we distinguish the cancel use case for different user types? That is, when a free user makes a cancellation, it should include the fee payment use case. But, we also know that reservation cancellation is a function that is same for both kinds of users (Although it may result in some other use case if it is a free user). So we are not sure whether a single use case is enough to show system capability. Moreover, we should use extends relation to show that sometimes it may include the fee payment. But if two different cancel use cases are used, we can show explicitly the includes relation of a free user. We will appreciate any suggestions. Thanks in advance.

Answer 1

Although this question is asking about use cases, the problem is that the underlying data model is inadequate.

The "user is a free user" and "user is a premium user" suggest that there is an inheritance relationship, but this only applies at an instant of time. Being a travel agency, users may well change their account status over time, with some interesting results. (I assume there is a database backing the system)

• A change in status means they become a different user. Customers may become a tad tetchy if their reservations disappear when they change their account status. You can work around this with a lot of unnecessary code.
• OO languages simply don't like an entity changing its type in the middle of the program. Good luck with that.
• It is not the responsibility of the user to calculate cancellation fees. Long term the calculation may need to access international exchange rates, sales tax rates and goodness knows what else. This data is generally not user related.

So what should we do?

• Create a new "UserType" entity, with just two records - premium and free.
• Move the calculation logic into this entity, or possibly out to a calculation class that is referenced by this entity.
• Add a linking entity (say "UserStatus") that holds the user key, the userType key and the date range that it applies to. (One record will have null end date - that is the current record). What you are doing is stating that "a user has a role (account status) for a period"

I would recommend looking at https://en.wikipedia.org/wiki/Object_Modeling_in_Color. This concept completely changed my approach to inheritance.

Hopefully once you get the data model right, your use cases will fall into line. Good Luck.