Software Engineering Methodologies

UML Relationships

Michael L. Collard, Ph.D.

Department of Computer Science, The University of Akron

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 results in a dependency
  • Not a field/data member

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. [Liskov,Wing'94]

  • 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

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
  • The 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

Aggregation

  • part of relationship
  • Special kind of association
  • Roles and multiplicities often used
  • Targets may be shared, i.e., source (e.g., Club) doesn't control the lifetime of the target (e.g., Person)
  • Code: Fields (data members) are pointers/references to this type, and the objects are created externally
  • So how does this differ from association?

Composition

  • Often confused with aggregation
  • Target belongs only to the source
  • No sharing, i.e., source (e.g., Company) controls the lifetime of the target (e.g., Location)
  • Code: These objects are fields/data members or pointers/references to objects created (and destroyed) internally
  • Often preferred to aggregation

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