Modeling the Static Structure: Relationships ©SoftMoore Consulting Slide 1
Modeling the Static Structure:Relationships
©SoftMoore Consulting Slide 1
Class Relationships
• Association – general relationship
• Aggregation – whole/part relationship
©SoftMoore Consulting Slide 2
Class1 Class2
Aggregate
Part
Class Relationships(continued)
• Inheritance – generalization/specialization relationship
• Dependency – general dependency between classes
©SoftMoore Consulting Slide 3
Superclass
Subclass
DependentClass
IndependentClass
Reflexive Associations
A reflexive association does not imply that an object instance is related to itself.
©SoftMoore Consulting Slide 4
: Personname = “John”
: Personname = “Jane”
is-married-to
Person
is-married-to
Class Level
Object Level
Multiplicity of Associations
• Multiplicity is a constraint on an association that specifies how many instances of one class may relate to a single instance of another class.
• Examples:– a workstation has 1 or more windows– a car has 2 or 4 doors– a person works for 0 or more companies
• Multiplicity is indicated by text expressions at each end of the association.
©SoftMoore Consulting Slide 5
Displaying Multiplicity
©SoftMoore Consulting Slide 6
Class0..1
Optional (zero or one)
Class1
Exactly one
Class*
Many (zero or more)
Class1..*
One or more
Class
Unspecified
Class1..4, 7
Numerically specified
One-to-Many (1:N) Associations
A customer can place many (zero or more) orders, but each order is associated with only one customer.
©SoftMoore Consulting Slide 7
Customer
c1 : Customer
c2 : Customer
c3 : Customer
Order
o1 : Order
o2 : Order
o3 : Order
o4 : Order
places1 *Class Level
Object Level
One-to-One (1:1) Associations
Each elevator has exactly one door, and each door is part of one elevator.
©SoftMoore Consulting Slide 8
Elevator
e1 : Elevator
e2 : Elevator
e3 : Elevator
Door
d1 : Door
d2 : Door
d3 : Door
1 1Class Level
Object Level
Many-to-Many (M:N) Associations
A number of stock items in inventory are supplied by more than one vendor, and vendors often supply more than one stock item.
©SoftMoore Consulting Slide 9
Vendor Stock
s1 : Stock
s2 : Stock
s3 : Stock
s4 : Stock
supplies* *Class Level
Object Level v1 : Vendor
v2 : Vendor
v3 : Vendor
v4 : Vendor
Implementing Multiplicity
• Multiplicity of one is usually implemented using– a reference or pointer in a programming language– a foreign key in a relational database– a combination of the above
• Multiplicity of many is usually implemented using an array or a container class (e.g., list or vector).
©SoftMoore Consulting Slide 10
Example: Implementing Multiplicity
©SoftMoore Consulting Slide 11
Customer Order1 *
class Customer { Order[] orders; ... }
class Order { Customer cust; ... }
cust orders
could be a list or set oforders instead of an array
Role Names
• Each end of an association is a role. A role name may be used to identify how a class at one end of an association participates in the association.
• Roles provide a way of viewing a binary association as a traversal from one object to a set of associated objects.
©SoftMoore Consulting Slide 12
CompanyPersonworks-for
employee employer
Aggregation
• Aggregation is a special kind of association used to represent a “whole/part” or “has-a” relationship among classes.
• Aggregation is specified by adorning an association with a small open diamond at the whole (aggregate) end of the relationship.
©SoftMoore Consulting Slide 13
Order LineItem1 *
Using Aggregation
• Aggregation is a special kind of association– asymmetric relationship– transitive relationship– stronger coupling– additional semantics
• Behavior (copy, delete, etc.) is often propagated across an aggregation but not across an ordinary association.
• The decision to use aggregation is a matter of judgment. When in doubt, use ordinary association.
©SoftMoore Consulting Slide 14
Generalization
• Generalization is a relationship between a more general class (the superclass) and a more specialized class (the subclass), in which objects of the subclass are substitutable in any context that requires an object of the superclass.
• Generalization expresses the “is-a-kind-of” relationship.
• A subclass inherits the attributes, operations, methods, and relationships of its superclass.
©SoftMoore Consulting Slide 15
Notation for Generalization
Graphically, generalization is rendered as a directed line from the subclass to its superclass with a large, open arrowhead pointing toward the superclass.
©SoftMoore Consulting Slide 16
MouseEvent
Event
Using Generalization
• The ability to define superclass/subclass relationships is a fundamental concept in using an object-oriented approach to software development.
• Generalizations can be defined at multiple levels, giving rise to an inheritance hierarchy. They are transitive across multiple levels.
• Inheritance hierarchies with “too many” levels of subclassing can be difficult to understand. Six or more levels would probably be excessive for most applications.
©SoftMoore Consulting Slide 17
Using Generalization(continued)
©SoftMoore Consulting Slide 18
“It is true that an object-oriented language or notation needs the concept of inheritance to be fully object-oriented. But that doesn’t mean that you have to use inheritance on every problem. The real essence of object-oriented analysis is not inheritance but thinking in terms of objects.
– James Rumbaugh [JOOP, Nov/Dec 1991]
Overriding Methods
An operation in a subclass that has the same signature as an operation in a superclass overrides (rather than inherits) the method from the superclass. In effect, the subclass has the same operation but supplies its own method.
©SoftMoore Consulting Slide 19
C1
operation1()operation2()
C2
operation1()
class C2 overridesthe method foroperation1()
Abstract Class
• An abstract class is a class for which object instances may not be created.
• An abstract class is defined only for the purpose of deriving subclasses; it encapsulates commonality for all descendant classes but may not be used for declaring objects.
• An abstract class is specified by writing its name in italics.
©SoftMoore Consulting Slide 20
Shape
Abstract Operation
• An abstract operation defines the signature of an operation whose corresponding method does not exist or is incomplete.
• An abstract operation may have a “default” method that implements common functionality.
• A class with one or more abstract operations is an abstract class; no object instances are permitted.
• As with classes, an abstract operation is specified by writing its signature in italics.
©SoftMoore Consulting Slide 21
Concrete Class
• A concrete class is a class for which it is possible to declare object instances.
• A concrete class derived from an abstract class must provide an implementation (method) for each abstract operation. The abstract operation imposes an obligation on concrete subclasses to provide the corresponding method.
©SoftMoore Consulting Slide 22
Example: Abstract Class
©SoftMoore Consulting Slide 23
Shape
origincolorlineStyle
draw()erase()move()
Rectangle
corner
draw()erase()
Circle
radius
draw()erase()
Using AbstractClasses and Operations
• Minimize the overriding of non-abstract methods. In general, either an operation should be declared as abstract, or else its method should be inherited without overriding.
• Minimize inheritance from classes that are not abstract.
©SoftMoore Consulting Slide 24
“Make non-leaf classes abstract.” – Scott Meyers