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?

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

• directionality
• multiplicity
• labels

Association

Association

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

Dependency

Dependency

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

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
• Represented in UML by a solid line with a hollow arrowhead

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 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}

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