- SuperClass
- Fuente. KULeuvenX: UMLx UML Class Diagrams for Software Engineering (Copia Textual – Literature Review).
Superclass
In this presentation we’ll explain the concept of generalization and specialization. This concept is actually a UML association construct. It relates to inheritance, fundamental concept of object oriented programming. This concept states that a class can inherit attributes and operations from a parent class.
In this example We have the general concept of account and two more specific concepts of checking account and saving account that inherit the characteristics of the more general concept of account. The more general concept is called generalization, superclass or supertype and the more specific concept is called the specialization, subclass or subtype. Graphically, the generalization/specialization association is drawn as a line connecting the super type to the subtype, and which is adorned with a triangle pointing towards the super type.
The principle of inheritance states that a subtype inherits the features of the super type. So, in this case, the superclass ‘account’, has defined two attributes: ‘IBAN number’ and ‘balance’. Those attributes will be inherited by checking account. So, also checking account will have an IBAN number and a balance. In addition, the checking account can extend what it inherited from account with its own attributes. And, in this case, checking account defines an additional attribute: ‘credit card’. Likewise, the savings account inherits from account that it has an IBAN number and a balance. But, it extends this with four attributes relating to a savings plan…Here, we graphically represent how a generalization/specialization is similar to a superset/subset relation.
Generalization sets.
Sometimes it is difficult to decide how to define the specialisations of a super type because different partitionings are possible. Take the example of vehicles. If you look at the transportation medium, you would have a partition like this:
This examples illustrates how in certain cases a single concept can be partitioned in two different ways. In UML, the concept of generalization set provides a way to group Specializations into orthogonal dimensions. Each group is represented by a generalization set. There are three different notations to represent generalisation sets.
First, by putting a name next to the Generalization relationship lines, that name designates a GeneralizationSet to which the Specialization belongs.
Second, two or more lines can be drawn to the same arrowhead and labelled by a single
generalization set name. This is called the “shared target” style.
With either of these two notations, if there are no labels on the Generalization arrows it cannot be determined from the diagram whether there are any generalization sets in the model.
Finally, a generalization set may be designated by drawing a dashed line across those lines with separate arrowheads that are meant to be part of the same set. Here, the generalization set is labelled with a single name, instead of each line labelled.
Constraints on Generalization/Specialization.
The concept of generalization/specialization comes with constraints and there are two types of constraints to consider. The first is whether the specialization is complete or incomplete. The question to ask is whether the subclasses cover all the elements of the superclass. Let’s consider an example where the superclass are the pet animals. That is the general concept. And you have three subtypes or specialized concepts namely cats, dogs and horses. The question to ask is: are there other pet animals than cats, dogs and horses? If yes, then the specialization of the subclasses is an incomplete specialization of the general concept. If there are no other pet animals than cats, dogs and horses, then the specialization is complete.
The other constraint to consider is whether or not subclasses are disjoint or overlapping. The question to ask here is: are there overlapping subclasses? For our example: Are there animals that can be dog and cat at the same time? Or cat and horse at the same time? Or dog and horse at the same time? If that’s not the case, then your classes are disjoint. If it is possible that an animal is a cat and a dog at the same time or a cat and a horse or a dog and a horse at the same time, then you have overlapping subclasses. If you don’t specify anything then by default it is assumed that your subclasses are disjoint.
The way to write these constraints down is simply by including the words that indicate the correct constraint between brackets next to the triangle.
Reading a diagram with inheritance (Inherited associations).
The general rule is that you have to read inheritance as an OR. So if you read the association between customer and account in this direction, the way to read the diagram is as follows.
A customer can have zero to many accounts and these accounts are either checking accounts or savings account because the specialization is complete and disjoint.
In the other direction, from account to customer, the way to read the diagram is that each account, be it the checking account or savings account, must have exactly one customer as an owner. In other words, checking account and savings account inherit from account that they belong to exactly one owner.
And here’s another example. Reading from student to course means that a student can follow zero to many courses and that these courses are advanced or intermediate or both, or just courses. Because inheritance is overlapping and incomplete.
In the other direction, reading from course to student we can see that each course is followed by zero to many students. And, because of the inheritance relationship, the advanced course and intermediate course inherit from course the fact that they are followed by zero to many students. So each course, advanced or intermediate, or just course is followed by zero to many students.
In the case of multiple inheritance trees in a single diagram, extra care is required. Consider this example. The association between Flight and Airplane seems to read as a general rule “Each flight has to be done with an airplane, and each Airplane can serve for zero to many flights.” While this seems a logical interpretation, the actual meaning is different.
The blue part of the model should be read as “A Flight, which could be either a cargo flight or a passenger flight” Similarly, the orange part of the model should be read as “An airplane, which could either be a passenger airplane or a cargo airplane.” In combination with the association, the true meaning of the model is: A flight of any kind, be it cargo or passenger flight, is always done with one airplane of any kind, be it a passenger or a cargo plane. So if you want to capture that passenger flights can only be done with passenger planes, and that cargo flights can only be done with cargo planes, then you need to model this at the level of the specialisations. And obviously, the association at the level of the super type then needs to be removed.
And what if cargo flights can be done with any kind of planes? Then the association connects “Cargo Flight” to the superclass “Airplane” rather than to the subclass. And the model looks like this.
AssociationClass
Let’s take a look again at the example of projects, products and suppliers. Suppose that prior to buying a product for a project, you need to be able to look up the different prices different suppliers ask for a product. So, next to keeping track of which product has been sourced from which supplier for a project, you also want to know which supplier offers which product.
So, where would you keep the price attribute? Would you model this as an attribute of supplier? Definitively not. Is it an attribute of product? Since each supplier has its own price for a given product, you can’t model it as an attribute of product either.
The price is rather an attribute of the combination of supplier and product. It’s therefore an attribute of the association between supplier and product. As a result, the association exhibits the characteristics of a class. In UML this is capture by the concept of associationclass.
An association class is both an association and a class at the same time. The association class is therefore named like a Class, and it can have attributes and operations. In this example, a good name for the association class is “ProductOffer”. And next to the price, this association class could also contain other attributes such as shipping conditions, average shipping time, etcetera.
In the example of the projects, products and suppliers, also the other associations may be converted to association classes, depending on required attributes. For example, the association that models which products are required by which projects, may be turned into an association class ProductRequirement capturing the required quantity, the maximum price that should be paid and the deadline by which products should be available.
The use of the concept of association class adds complexity to a model, in the sense that it is an extra symbol one needs to understand. To a large extent, a model using only classes and associations can express the same thing. For example, the product offer can also be modelled as a conventional class, related to a single supplier and a single product.
Larry Francis Obando – Technical Specialist
Escuela de Ingeniería Electrónica de la Universidad Simón Bolívar, Valle de Sartenejas.
Escuela de Ingeniería Eléctrica de la Universidad Central de Venezuela, CCs.
Escuela de Turismo de la Universidad Simón Bolívar, Núcleo Litoral.
Contact: Caracas, Quito, Guayaquil, Jaén – tlf. +34 633129287
WhatsApp: +34 633129287
email: dademuchconnection@gmail.com
Copywriting, Content Marketing, Tesis, Monografías, Paper Académicos, White Papers (Español – Inglés)
1 pensamiento sobre “UML Advanced”