CHAPTER
UCP 5 UUCP TCF EF For the running example we obtain
6.6 Organization of the conceptual model
The relation ofFigure 6.33states that a book may have one or more genres and a genre has a set of books associated with it. As a book may have more than one genre, then the qualifier should be necessarily external.
6.6.1 Generalization, specialization, and inheritance
For years, inheritance was considered the most important feature of object-oriented languages.
Languages such as Smalltalk, for example, were built over a single hierarchy of classes based on inheritance.
As time went by, this emphasis lost strength, because it was perceived that inheritance is not always the best idea for solving modeling problems. Today, inheritance is considered just one of the techniques that help to factorize information that otherwise would be repeated in classes.
Inheritance, in object-oriented systems, occurs when two classes relate through a special associ- ation called ageneralization(or aspecialization, depending on the direction you look). A class that generalizes another class is itssuperclass, and the specialized one is thesubclass.
Generalization should be used every time there is a set of classes X1,. . .,Xnthat have specific differences and common similarities, so that the similarities can be grouped in a superclassX(gen- eralization ofX1,. . .,Xn) and the differences maintained inX1,. . .,Xn.
The generalization has a semantic much different from the other associations of the conceptual model. It exists only between classes, not between instances as normal associations do. For exam- ple, if a classCustomeris associated to the classOrder by a normal association, then instances of Customermay be linked to instances ofOrder: the normal association allows the links to exist. On the other hand if a classBankAccount is a generalization ofCheckAccount, then every instance of CheckAccountisalsoan instance ofBankAccount(Figure 6.34). There are not two instances to be linked, just one instance with the properties defined in both class. In the example, every instance of CheckAccounthas three attributes:number, overdraftLimit, and overdraftFee. However, not every instance ofBankAccountis an instance of CheckAccount: the generalization is anti-symmetric. An instance ofBankAccounthas only one attribute:number.
Thus, one of the reasons to use inheritance is when there are some similar properties (attributes, associations, or methods) in different classes, which may be factorized in an abstract construct such as a superclass.
If the superclass may have its own instances, then it is a normal class. However, most of the time superclasses are defined not to allow direct instances: only their subclasses may have instances. In this case they are known asabstractsuperclasses. Abstract superclasses are represented in UML by a class with its name written in italic, or, more visibly, with the constraint {abstract} (Figure 6.35).
BankAccount
CheckAccount +overDraftLimit : Money +overDraftFee : Percentage
<<unique>> +number : AccountNumber
FIGURE 6.34
An example of generalization with inheritance.
139 6.6 Organization of the conceptual model
In Figure 6.35, the BankAccount class is abstract, and therefore cannot have direct instances;
only its subclasses may have instances. Instances of CheckAccount have number, overdraftLimit, andoverdraftFeeas attributes; instances of SavingsAccounthave numberandinterestRateas attri- butes. Both subclasses also inherit the association to the classCustomer, and all instances of both classes must, therefore, be linked to an instance ofCustomer.
Generalization in not advisable when the superclass has no properties, that is, no attributes, associations, or methods of its own (Figure 6.36).
Generalization should also not be used when subclasses do not have properties (attributes, asso- ciations, or methods12) that differentiate them from each other as inFigure 6.37.
In these cases, the ideal solution is to use a single attribute, possibly typed with an enumeration, to differentiate instance groups of objects that have the same properties (Figure 6.38).
Besides these rules, before deciding on the use of inheritance, it is advisable to verify if the gen- eralization really represents a structural classification of the elements, and not an associative or temporal organization, as seen in the following sections.
Thing
AVOID
Customer Book
<<unique>> +id : IdNumber +name : String
+address : String
<<unique>> +isbn : ISBN +title : String
+authorsName : String +year : Integer +pageCount : Natural FIGURE 6.36
Situation where generalization is not recommended, because there are no generalized properties.
{abstract} BankAccount Customer
1
*
SavingsAccount +interestRate : Percentage CheckAccount
+overDraftLimit : Money +overDraftFee : Percentage
<<unique>> +number : AccountNumber
FIGURE 6.35
Two classes being generalized by an abstract class.
12Methods are only considered when design classes are being modeled. Remember that conceptual classes do not have methods.
140 CHAPTER 6 Conceptual Modeling: Fundamentals
6.6.2 Association classes
One issue frequently misunderstood in conceptual modeling is related to the definition of generaliza- tion among classes that are not really structural subtypes, butroles. For example, a bookstore may have two “types” of people: customers and workers. After discovering that both have a name, address, phone, etc., an analyst could assume that they are two concepts that should be generalized asPerson.
But that apparently simple solution (Figure 6.39) generates a complicated problem, because they are not different types of people, but different roles that people could play when relating to a company.
Person
Man Woman
AVOID +address : String
+name : String
<<unique>> +id : IdNumber
FIGURE 6.37
Situation where specialization is not recommended because there are no properties being specialized in subclasses.
Person +address : String +name : String
<<unique>> +id : IdNumber +gender : HumanGender
<<enumeration>>
HumanGender
<<Constant>> +male
<<Constant>> +female
FIGURE 6.38
A more adequate model for the situation ofFigure 6.37.
Person
AVOID
1
* Order
Customer Worker
+wage : Money +creditLimit : Money
<<unique>> +id : IdNumber +name : String
+address : String +phone : PhoneNumber
FIGURE 6.39
Unsuitable way to represent roles with generalization.
141 6.6 Organization of the conceptual model
Why is this a problem? Imagine that a bookstore worker decides to buy books at her workplace.
In this case the worker will be behaving like a customer. An unsuitable although very frequent solution to this is to create a second record for the worker as a customer, as if she was a different person. As a consequence, the same person would have two records in the system: one as a worker and another as a customer. This produces data redundancy and it is a source of data inconsistency, because, for example, if the worker has registered a change in address, the customer may still keep the old address. As they are the same person, this information is inconsistent.
A more suitable solution is to consider that there exists aPersonthat may relate to aCompany in at least two ways: as a customer and as a worker. The specific properties of a customer (credit limit, for instance), and of a worker (salary, for instance), would be properties of the associations, and not of the person. To represent these association properties, an association class should be defined for each one, as shown inFigure 6.40.
Therefore, when the same object may play different roles related to other objects, these roles should not be represented as subclasses, but asassociation classes.
In order to decide which situation demands inheritance and which situation demands association classes, it may be verified if the “subtypes” depend on the existence of a third class to make sense.
If the “subtype” depends on a third class, then the solution consists of using an association class.
For example, nobody may be simply a student; if someone is a student, then she must be associated to a school or at least to a teacher.
Thus, it is unsuitable to create classes that represent kinds of people that in reality are not sub- classes, but roles. Workers, teachers, students, principals, customers, etc., should not be subclasses of Person. Concepts like these only make sense if related to other concepts such as Company, School,Department, etc. A person may be workerata company, studentata school, etc.
The difference between using an association class and an intermediary concept is subtle.
Figure 6.41 shows an example of a reservation being modeled as an intermediary concept, and Figure 6.42is a version of that reservation modeled as an association class.
In the case of Figure 6.41, a reservation associates a customer to a book. In the case of Figure 6.42the customer and the book are directly associated, and the reservation, as an association
Person
Customer Order
Company workingPlace
shop worker
customer
1
*
*
*
*
*
Worker +wage : Money
+creditLimit : Money
<<unique>> +id : IdNumber +name : String
+address : String +phone : PhoneNumber
FIGURE 6.40
More suitable representation of roles as class associations.
142 CHAPTER 6 Conceptual Modeling: Fundamentals