Inheritance Trees

I l @ ve RuBoard

The basis for specialization (i.e., why subclasses were created) in an inheritance relationship is called the discriminator. The discriminator typically has a finite set of values and subclasses that may be created for each value. For example, one basis for discrimination for a Course class is the location of the courseOnCampusCourse and OffSiteCourse could be two subclasses of the Course class based on this discriminator. The inheritance relationship may be shown as a tree for all subclasses created from one discriminator. Another subclass of Course could be MandatoryCourse. This subclass would not be part of the inheritance tree because it belongs to a different discriminatorcourse type. Care must be taken when you discover multiple discriminators for a classfor example, what happens when a mandatory course is held on campus. Do you have a multiple inheritance situation? Should aggregation be used? As analysis and design progresses, the answers to these questions will lead to the structure of the model.


  1. Open the class diagram that will display the inheritance hierarchy.

  2. Click to select the Class icon from the toolbar and click on the open class diagram to draw the class.

  3. With the class still selected, enter the name of the class.


    The class could also be created in the browser and added to the open class diagram.

  4. Click to select the Generalization icon on the toolbar.

  5. Click on one subclass and drag the generalization line to the superclass.

  6. For each subclass that is part of the inheritance tree, select the Generalization icon from the toolbar, click on the subclass, and drag the generalization line to the inheritance triangle.


An inheritance tree may be created from two separate generalization arrows by selecting one arrow and dragging it onto the other arrow.

An inheritance tree relationship is shown in Figure 8-2.

Figure 8-2. Inheritance Tree


I also like to show stereotypes as labels in this type of diagram since the inheritance triangle may obscure the class name if an icon is used.

Attributes, operations, and relationships are relocated to the highest applicable level in the hierarchy once a superclass is created. What features should be relocated ? Let's look at the RegistrationUser hierarchy. The attributes, operations, and relationships for the subclasses are shown in Figure 8-3. As long as name and IDNumber have the same format they may safely be moved to the superclass (RegistrationUser). Both classes have a relationship to the CourseOffering class. There are two options that may be chosen for this relationship:

  • Keep the relationships at the subclass level.

  • Have one relationship at the superclass level with a multiplicity that includes the professor and the student objects (i.e., one CourseOffering object would be related to 411 RegistrationUser objects). Here a constraint stating that one RegistrationUser object must be a Professor object should be added to the model.

Figure 8-3. RegistrationUser Inheritance Hierarchy


Which way is correct? They both are. Which way is the best to use? It depends. If you have a need for a CourseOffering object to know all the students and the professor, then having one list containing this information might be handy. This would imply that the second option is the way to go. If, on the other hand, you need to know only students or professors but not both at the same time, then the first option is probably best. It all comes down to what the system needs to do! This will be discovered by carefully examining the use cases and scenarios to discover the needed behavior.


  1. Click the + sign next to one subclass in the browser to expand the class.

  2. Select the attribute or operation to be relocated.

  3. Drag the attribute or operation to the superclass.

  4. Delete the attribute or operation from all other subclasses.

  5. Repeat steps 2 through 4 for each additional attribute or operation to be relocated.

Relocated attributes are shown in Figure 8-4.

Figure 8-4. Relocated Attributes and Operations


I l @ ve RuBoard

Visual Modeling with Rational Rose 2002 and UML
Visual Modeling with Rational Rose 2002 and UML (3rd Edition)
ISBN: 0201729326
EAN: 2147483647
Year: 2002
Pages: 134

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: