Object-Oriented Programming

UML Class Relationships

Michael L. Collard, Ph.D.

Department of Computer Science, The University of Akron

Properties: Attributes & Association

  • Another notation for property (alternative to attribute)
  • Use attributes for properties that are data types, e.g., primitive types, or whatever is considered a data type in your design
  • Use associations for class types, especially if the methods are of interest at the design level
  • Is String a class or a datatype?


DataType Class
Primitives Objects
Methods are familiar Methods are not familiar
Operators do not change Operators can change
New developers know precisely what you mean New developers have only a vague idea
Tend to be scalar (single value) Tend to be complex types
Equivalent values ⇨ same identity Two distinct objects can have the same value
Probably not a base for generalization (inheritance) Maybe a base for generalization (inheritance)

Class Relationships

  • Object-Oriented Design: What classes make up this system?
  • Multiple classes ⇨ relationships between classes
  • Existence and kinds of relationships between classes are the central part of a UML Class Design

UML Class Relationships

Relationship Description
Dependency uses a
Association has a
Aggregation (Association) has a
Composition (Association) has a
Generalization is a


  • directionality
  • multiplicity
  • labels



  • One class has a(n) element of another class
  • Represented in UML by a solid line with an arrow



  • Class used as a parameter or local variable only (not a field/data member) results in a dependency

Dependency Discussion

  • Represented in UML by a dashed line with an arrow
  • Changes to the definition of the supplier/source (e.g., Tokenizer) may cause changes to the client/target (e.g., Student)
  • Dependencies are weaker than Associations and therefore preferred

Dependency & Association

Dependency & Association

  • Show the strongest relationship only

Strong Relationships

  • Can rank the strength of relationships
  • Association is a stronger relationship than dependency
  • Strong relationships are not good
  • Any relationship implies coupling, overly strong coupling is not good design
  • The stronger the relationship the more constrained and rigid the design is
  • Prefer dependency over association

Scenario: Original Design

Scenario: Name removed

Substitutability: Liskov Substitution Principle

Subtype Requirement: Let ϕ(x) be a property provable about objects x of type T. Then, ϕ(y) should be true for objects y of type S where S is a subtype of T.

  • We can substitute type S objects for type T objects
  • Not just interface (syntax), but behavior (semantics)
  • Typically referred to as an "is a" relationship
  • [Liskov,Wing'94]


  • Expression of is a relationship: Substitutability
  • Maps directly to inheritance in most OOP languages
  • Subclass/subtype/derived class is a generalization of superclass/supertype/base class
  • Highest semantically defined relationship
  • Represented in UML by a solid line with a hollow arrowhead


  • In C++, Generalization is public inheritance

Problems with Generalization

The purpose of generalization is to solve design problems. If you don't have a design problem, don't use generalization.

  • Inheritance and inheritance hierarchies are more challenging to get right than realized
  • Developer needs to create classes with inheritance in mind. Most classes are not designed for this, e.g., C++ standard library
  • Often overused. In general, prefer association over generalization

Substitutability Violation #1

Violation Solution #1

Substitutability Violation #2

Violation Solution #2

Abstract Classes/Methods

  • Abstract classes do not support direct instantiation, e.g., you can create a DateEvent object, but not an Event object
  • An abstract class typically has one or more abstract methods. An abstract method is a method that is declared but not defined in the class, and a derived class must provide a definition.
  • Displayed (both classes and methods) as Event or with a label {abstract}, or abbreviated label {A}


  • All operations are public, and no operation has a method body
  • Cleanly models interfaces in Java, COM, CORBA
  • Indicated as keyword «interface», or with a label {interface}, or abbreviated label {I}
  • In this case, inheritance means implementation
  • We can also have a dependency relationship with an interface