When should I use generalization in case of use?

Question

• What is the purpose of generalization in the case of use?
• When should I generalize?
• If I have 2 actors, one student and the other teacher, they are respectively users, then enter the generalization part?

Source: Wikipedia

Answer 1

Generalization in use cases is analogous to generalization in databases or object orientation (which we call inheritance).

When speaking of actors, several actors can play the same role in a specific use case. Generalization is how this is represented, one actor can "inherit" characteristics from another.

If I have 2 actors, one student and the other teacher, they are respectively users, then enter the generalization part?

No, necessarily. This will depend on the rules of the application. For all purposes, all primary actors will be system users (who will interact through some kind of graphical interface). Generalization has the most with sharing features.

Think of actors as being specific roles that access certain actions and a system user can play different roles.

To illustrate what I mean, here is a small example. Imagine we’re creating the use case diagram for a school library and we have the following rules:

• Students and Teachers can book books
• Students and Teachers can search the book catalog
• Teachers can request new books

Note that, everything students can do, teachers can do. That way, we could use generalization and make the actor Professor inherit the characteristics of Pupil.

Answer 2

There’s some controversy about that. There is a "school" that thinks in one way and it is the most academic possible, in fact it is used in practically every example of book, blog, course or other way that sees around how to generalize. And there is the pragmatic "school" that tries to think about how things really are and so can give you a better chance of not having problems in the future. Even these people understand that inheritance, and therefore generalization is almost a anti-Pattern nowadays and that some people already realize that if one has to generalize it should be with an abstract class or interface (or trait where this exists), that is, a concrete class cannot be generalization.

Then his example follows the academic "school" (no pun intended with the mastery of the example). She believes that the same real object can exist in several instances of the system, either in the same line of specialization or in the more general, and more so, it can exist in different lines, so she uses an inheritance of a concrete object in another object. My experience is already corroborated with many people I know who are not followers of cake recipe who believe that what is in the books serves for something real is that this does not exist and causes problems in modeling.

Who is pragmatic knows that student, teacher and user are different things, and in general are papers which persons exercise in the system (or organisation). A person is composed, among other things, by their roles, or else a role is composed, among other things, by a person. In composition there is no generalization. Eventually a role could be a generalization of these specific roles, but I don’t usually see it that way because I don’t see what one role has in common with another, but it’s possible. If the generalization is made in some specific fact it can be through interfaces. Giving an actor a general ability is something that happens more than the more general generalization.

So the use case needs to consider what that object can do, and if there are other objects that do exactly the same thing, even if specific to it, then there is some form of generalization, but completely, just in this specific characteristic. So student and teacher can have something that they do in common equally and that allows for a partial generalization, but they are not specifics of an actor but rather of an action.

A generalization that I always see is a person being a generalization of physical person and juridical person, where the first would be abstract and the other concrete, maintaining that idea that the most general object can not be concrete.

In academic "school" it is enough to have something in common that should already make the generalization. This group of people think that, at least in some cases, if you have a name in two objects you can already generalize because it has something in common, even if that name has nothing to do with the other name. They ignore the liskov principle.

What I see is that it takes a lot of experience to know how to generalize, and therefore object-oriented programming, because it’s not easy to see when you should do it or not without knowing what’s wrong. It takes a lot of experience with taxonomy and even ontology and dialectics. You can study these things, but only experience gives you good conditions to deal with it. More and more I believe that OOP should only be introduced to programmers after a certain time, who knows when it is making the transition from junior to full and the exercise of this discipline actually happen only when the person is senior (really, not only that it has the title)who don’t make these mistakes of academicism so easily.

One thing I say a lot is that you need to be very clear about what you’re doing. I’ll give you an example: you put the word respectively, but there’s nothing respective there, so even though you’re unconsciously already seeing the problem in a way that it’s not. Of course you can review this, but if no one more experienced talk will probably make some mistake in modeling with it. So some have difficulty evolving to learn, they don’t want to hear who is more experienced, who can give a parameter and show where it is going wrong. Of course the person should not trust blindly everything they say to her too, because everyone can make a mistake, has to create their own consciousness, it takes time.

Then you first have to choose what "school" you will follow. Pragmatics makes learning faster, but it is not well seen in certain circles that still buys the idea of academia and tends to classify as wrong if it does not follow what is in the books.