1. Modeling the Static Structure: Relationships ©SoftMoore ConsultingSlide 1

2. Class Relationships Association – general relationship Aggregation – whole/part relationship ©SoftMoore ConsultingSlide 2 Class1Class2 Aggregate Part

3. Class Relationships (continued) Inheritance – generalization/specialization relationship Dependency – general dependency between classes ©SoftMoore ConsultingSlide 3 Superclass Subclass Dependent Class Independent Class

4. Reflexive Associations A reflexive association does not imply that an object instance is related to itself. ©SoftMoore ConsultingSlide 4 : Person name = “John” : Person name = “Jane” is-married-to Person is-married-to Class Level Object Level

5. 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 ConsultingSlide 5

6. Displaying Multiplicity ©SoftMoore ConsultingSlide 6 Class 0..1 Optional (zero or one) Class 1 Exactly one Class * Many (zero or more) Class 1..* One or more Class Unspecified Class 1..4, 7 Numerically specified

7. 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 ConsultingSlide 7 Customer c1 : Customer c2 : Customer c3 : Customer Order o1 : Order o2 : Order o3 : Order o4 : Order places 1 * Class Level Object Level

8. One-to-One (1:1) Associations Each elevator has exactly one door, and each door is part of one elevator. ©SoftMoore ConsultingSlide 8 Elevator e1 : Elevator e2 : Elevator e3 : Elevator Door d1 : Door d2 : Door d3 : Door 11 Class Level Object Level

9. 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 ConsultingSlide 9 VendorStock s1 : Stock s2 : Stock s3 : Stock s4 : Stock supplies ** Class Level Object Level v1 : Vendor v2 : Vendor v3 : Vendor v4 : Vendor

10. 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 ConsultingSlide 10

11. Example: Implementing Multiplicity ©SoftMoore ConsultingSlide 11 CustomerOrder 1 * class Customer { Order[] orders;... } class Order { Customer cust;... } custorders could be a list or set of orders instead of an array

12. 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 ConsultingSlide 12 CompanyPerson works-for employeeemployer

13. 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 ConsultingSlide 13 OrderLineItem 1 *

14. 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 ConsultingSlide 14

15. 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 ConsultingSlide 15

16. 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 ConsultingSlide 16 MouseEvent Event

17. 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 ConsultingSlide 17

18. Using Generalization (continued) ©SoftMoore ConsultingSlide 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]

19. 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 ConsultingSlide 19 C1 operation1() operation2() C2 operation1() class C2 overrides the method for operation1()

20. 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 ConsultingSlide 20 Shape

21. 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 ConsultingSlide 21

22. 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 ConsultingSlide 22

23. Example: Abstract Class ©SoftMoore ConsultingSlide 23 Shape origin color lineStyle draw() erase() move() Rectangle corner draw() erase() Circle radius draw() erase()

24. Using Abstract Classes 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 ConsultingSlide 24 “Make non-leaf classes abstract.” – Scott Meyers