How to use correctly use case <<generalization>> in use case diagrams?

Question

I'm starting to learn UML and I'm a little confused. I have the following use case diagram:

I'm asking this because I want to draw my diagrams correctly in order to anybody with correct knowledge of UML can understand and not just draw the diagrams in a way that just I understand.

Now for the reason I used Use Case Generalization here is why;

After reading the section 5.3 of the book UML 2 and the unified Process, I think that what I'm trying to do is use case generalization, specially after looking at the example in page 100. This example shows a use case called FindProduct that as stated in the page 101 is an abstract use case.

We read that

the FindBook use case is much more concrete. It specializes the more abstract parent to deal with specific type of product, books. If the parent use case has no flow of events or a flow of events that is incomplete, it is an abstract use case. Abstract use cases are quite common because you can use them for capturing behavior at the highest levels of abstraction. Because abstract use cases have a missing or incomplete flow of events, they can never be executed by the system

And that's what I'm trying to represent in my diagram. I have an abstract use case Turn ON and this use case is never going to be executed as it is. It needs child, or in this case, children to specialize it because the system is going to turn on by IR or by KNOB and never just turn ON, that's abstract.

So the thing here is that I'm not sure about the multiple generalization and If doing this is correct. Or shall I change for example the Turn with IR and Turn with KNOB use cases for Turn ON with IR and Turn ON with KNOW use cases and make these the children of Turn ON and add Turn OFF with IR and Turn OFF with KNOB use cases and make these the children of Turn OFF, and so on?

Thanks!!

Answer 1

About you question: the most common approach I have seen, is to have one activity diagram per use case.

A few points about your use case diagram:

1- I have never seen multiple specialization in use case diagrams. you may want to reconsider that. When use case A (child) specializes use case B (parent) it inherits all the preconditions, post-conditions, main flow and alternative flow steps. I can guess that this features are not the same for your parent use cases (for example turn volume up and turn on); therefore multiple specialization does not makes sense here, to say the least.

2- Use case generalization should be avoided unless it adds real value to your model. It is not very intuitive and makes your diagrams vague.

3- This use case diagram seems to have the tendency to view use cases as classes and generalization as inheritance; which is not correct.

4- You may want to reconsider the level of granularity of your use cases as well; turn on with IR/Knob and turn off with IR/Knob may all be integrated in one reasonable sized use case with some alternative flows. But this is a choice you make as a requirements engineer, anyone may do it differently.

I recommend you take a look at section 5.3 of UML 2 and the Unified Process book which is about use case generalization.

Suggestion:

Let's assume you want to keep separate use cases for turning on and off and focus on one use case (turning on):

1- If the steps for turning on with IR are totally different from turning on with knob, make the turn on use case abstract and do not write any spec (text) or draw any activity diagram for it. Then specialize two use cases called turn on with knob and turn on with IR which are concrete with separate specs and/or activity diagrams.

2- If the steps for turning on with IR are almost the same as turning on with knob except for one step where the user chooses IR or Knob; you could use alternative flows. In this case you can have only one use case with one spec and/or one activity diagram.

Do the same for other three use cases.