Confusion in making use case diagram from class diagram

Question

I am trying to make a use case diagram with the help of my class diagram but the problem is i am here confused that what should i take as actors and what will come and what attributes shall i take and where to use <<extend>> ? Kindly help. Thank you in advance.

Answer 1

As Thomas pointed out, there is no algorithmic way to go from a class design to a use case. In fact, for a given class diagram, it's not even granted that there is a use case at all (for example, if the classes represent only the relation between business objects and no actors).

However, by analyzing your specific diagram from a human point of view, you can very well infer a class diagram:

1) Identify candidate actors

An actor specifies a role played by a user or any other system that interacts with the subject. Candidates in your diagram are: visitor, admin, and registered user

The classes Movie, Book tickets, Make payment are obviously not representing roles of a user.

2) Identify candidate use cases

A use case defines the interactions of a system and an actor in order to achieve some goal. So let's brainstorm a little bit to find everything that looks like an interaction:

• Very explicit candidate use cases: Book tickets (class and method of Registered user), Make payment (class and method of Registered user)

• Less explicit candidate use cases or interactions: View movie (relation and method of Registered user), update movie (relation), Add movie record (method of admin), Update movie record (method of admin), delete movie record (method of admin), Confirm registration of visitor (inferred from relation), 'Get registered(method of a user),cancel ticket(and method ofRegistered user),Login(method ofRegistered user),Logout(method ofRegistered user),Update Seats available(method ofBook tickets), confirm transaction (method), refund money of cancelled ticket (method)

• Implicit/inferred use cases or interactions : create and maintain admin , create a visitor, register and maintain a registered user account, anything else ?

3) Sort out the use cases

Among all the potential use cases and interaction identified, not all should get the use case status. You have then to find which are use cases and which are just interactions part of the same use case. For example:

• update movie catalog would be composed of update movie, Add movie record, Update movie record, delete movie record.
• Get registered and Confirm registration of visitor are obviously part of the same use case, because the goal is the same: registering a user.
• ... I let you as an execise sort out the rest.

4) Review the actors

After having identified meaningful use cases you may want to review your candidate actors:

• Some candidate actors might appear to be in fact only objects that are unrelated to users (it's not the case here, but it could be, for example, if you'd have a Movie producer, which is just an info related to a movie but not a user of the system).

• Identify obviously missing actors for important use case that you have identified. Here for example, I first thought it was an internet movie business. But the method Update Seats makes obvious that we are talking of a real theater. So who would get the payment from the user, hand out the ticket, reimburse money in relation with the system ? If it's just the online booking system, we are fine. If the cahs desk operator shall use the system as well, then we should add this actor.

• Find out relationship between candidate actors. A registered user was first a visitor. Shall we represent both of them in the diagram or not ?

5) Draw your use case diagram

Now you have all the elements, you can make your use case diagram. But you still have to decide on the level of detail you want to represent. Here a proposal: