Object-Oriented Programming

UML Class Relationships

Michael L. Collard, Ph.D.

Department of Computer Science, The University of Akron

UMLasSketch

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 exactly 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
Generalization is a
Association has a
Aggregation (Association) has a
Composition (Association) has a

Relationship

  • directionality

  • multiplicity

  • labels

Association

  • One class has a(n) element of another class

Dependency

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

Dependency Discussion

  • 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

  • Show the strongest relationship only

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]

Generalization

  • 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

Inheritance

  • 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 Composition 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 one that is declared, but not defined, and a derived class must provide a definition.
  • Displayed (both classes and methods) as Event or with a label {abstract}, or abbreviated label {A}

Interfaces

  • 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