inheritanceumluse-caseuse-case-diagram

Generalization, include or extend


In my book OCUP 2 Certification Guide, there is this following example about a use case generalization relationship:
enter image description here

Am I wrong that I do not see this as a generalization-relationship? A pay by cash does not feel like a "kind-of" pay overdue fine, but more like an extend or include? Would you see any objective arguments that would support the choice of the generalisation?


Solution

  • As previously discussed in comments, the whole problem here is bad use case naming. Before elaborating further on choosing between generalization, include and extend, I think book's author's intent is kind of obvious (despite bad naming) but I can see why it can make confusion.

    Something about include. Use case that is included in some other use case (base use case) must be executed when base use case is executed. Main reason behind include's existence is reusability meaning that same use case can be included in multiple other use cases and in that way shrinking use case diagram and making it more clear. In OP's example, it doesn't really make sense that whenever you have to pay overdue fine then you have to pay using cash and pay using check and pay using credit card.

    Something about extend. Use case that extends some other use case (base use case) doesn't have to be executed at all. It's execution is often determined by some condition. In OP's example if we look at Pay overdue fine as the whole process containing for example: giving ticket, signing ticket, paying fine... then we could extend Pay overdue fine with those three other use cases because giving that some condition is met one or more of the three use cases will be executed. Now, is it something that first comes to mind? Probably not.

    Regarding generalization. If we take that Pay overdue fine means simply giving money (in any shape or form) to pay for ticket then generalization works for us (if we disregard bad naming of other three use cases because as they are now, they don't specify that they are used to pay the ticket).

    To sum up. However we interpret Pay overdue fine use case including other three use cases is no good since it's not logical that all three of them have to be executed. Using extend can work if we interpret Pay overdue fine as the whole process of paying fine containing multiple steps. If we interpret that those three use cases are specifically meant to be used in context of paying overdue fine (which is, I believe, book's author's intent) then we can use generalization.

    In my opinion, it would be nice to have use case, for example Pay, that would be generalization of those three use cases and then Pay overdue fine would include Pay. That way with generalization you make that Pay can be used in some other part of system and since you included it in Pay overdue fine it is mandatory that Pay (i.e. some of it's specializations) is executed.

    Example diagram:
    Example UML diagram