1. CSCI 1260 – Lecture 2: Instantiation, Aggregation, and Composition
Class Relationships
November 23, 2018
Class Relationships

2. Learning Objectives
Lecture Objectives: At the end of the lecture you should be able to:
Draw/Produce UML diagrams (instantiation relationship)
Implement and use the instantiation relationship
Produce UML diagrams (aggregate relationship)
Produce UML diagrams (composition relationship)
Implement and use the aggregation relationship
Implement and use the composition relationship
November 23, 2018
Class Relationships

3. Instantiation Relationship
The USES relationship
November 23, 2018
Class Relationships

4. Instantiation Relationship
In the instantiation relationship, one class uses the services provided by another class.
Its objects instantiate and use objects of another class or classes.
An Employee object may use an object of the Name class to represent the person’s name and it may use an object of the Address class to manage the person’s address.
An Automobile object may use objects of the Engine, Transmission, Steering, SoundSystem, and other classes.
The user needs to know about the objects it is using, but the objects being used do not need to know about their user.
A Carpenter needs to know her Hammer but the Hammer doesn’t care who using it.
A Car needs to know about its Engine, but the Engine doesn’t care whether the Car is blue or white.
This promotes enhances separation of concerns, encapsulation, information hiding, and other object-oriented goals.
November 23, 2018
Class Relationships

5. Showing Instantiation in UML
In the diagram, objects of the class Person use the services of objects of the class Hammer
One shows an Instantiation relationship in UML with a dotted arrow pointing from the user to the object in use
November 23, 2018
Class Relationships

6. Implementing the Instantiation Relationship
Typically, this relationship is implemented in Java code with a client method in the user class, say class A, instantiating an object of the other class, say class B, and then calling one or more methods of B on that object.
November 23, 2018
Class Relationships

7. Sample Code Skeleton
A method in class Carpenter instantiates an object of class Hammer and then uses it.
Instantiation/Uses can also be implemented by passing an object of class Hammer to a method of class Carpenter and using it.
November 23, 2018
Class Relationships

8. The “Has-a” Relationship
Composition and Aggregation: the whole-part relationships
November 23, 2018
Class Relationships

9. Aggregation and Composition
The relationship between two classes may be a part-whole relationship
The whole “has-a” part
Consider:
A room has a chair
A house has a roof
Both cases describe a part-whole relationship, where the room or the house is the whole and the chair or the roof is the part
In Java, the whole is a class (or instance thereof) and the part is an attribute of the class
November 23, 2018
Class Relationships

10. Aggregation and Composition
The two examples on the previous slide depict situations in which there is a very subtle difference in the relationships
The room has a chair but the chair is not an essential part of the room
The chair and the room may exist without the other
The chair may be removed from a room and placed in another – and both will continue to exist and function without the other
This relationship is called the aggregate relationship (the chair and the room)
On the other hand:
The house has a roof
The roof is an essential part of the house; the house is incomplete without the roof
Neither the house nor the roof can exist without the other
This relationship is called the composition relationship (the roof is an essential component of the house)
November 23, 2018
Class Relationships

11. Composition and Aggregation
In both relationships, the class representing the whole has an attribute representing the part
In the composition relationship, the part and whole are created together
In Java, the part is instantiated in the constructor of the whole
The part and whole come into existence together and exist together until the whole ceases to exist (the house and its roof have the same lifetime)
In an aggregation relationship, the part is not created with the whole (i.e., in its constructor)
Some other method is provided to instantiate the part
This method may or may not ever be invoked by the driver or some other class
November 23, 2018
Class Relationships

12. Aggregation
November 23, 2018
Class Relationships

13. Aggregation
In the aggregate relationship, one class aggregates objects of the other class
In the diagram, class Room has (or contains) zero or one objects of type Chair
The class Room, acting as the whole, maintains a reference (or references) to an object(s) of the class Chair that act as the part
There are usually one or more methods (that may or may not ever be invoked) that instantiate one or more instances of the part
Reference name
This type arrow indicates the aggregation relationship
Between 0 and 1 instances of a Chair
November 23, 2018
Class Relationships

14. Aggregation in UML
In Jude/Astah*, the aggregation relationship is indicated as shown here:
Use this dropdown …
Select the Aggregation Symbol
Tooltip helps one select the proper symbol
… to get this list
November 23, 2018
Class Relationships

15. Arrow is the result of dragging FROM the Room class TO the Chair class
Aggregation in Jude
Drag the selected arrow FROM the “whole” (Room) TO the “part” (Chair)
The PART
The WHOLE
Arrow is the result of dragging FROM the Room class TO the Chair class
November 23, 2018
Class Relationships

16. Aggregation: code skeleton
The Room has an attribute reference to a Chair object
Room instantiates a reference to an object of type Chair – initially null
Some method in Room associates the Room object with an actual Chair with the reference named chair
Note that the Room object exists (and is initialized by the Room constructor – not shown) and the Chair object that is passed to the setChair method exists separately. The Chair becomes a real part of this Room only when this method is invoked
November 23, 2018
Class Relationships

17. Composition
November 23, 2018
Class Relationships

18. Indicates a House object has exactly one Roof object, named roof
Composition
One class is partially or fully composed of objects of other classes
In the diagram, class House has (or contains) one object roof of type Roof
The class acting as the whole (House) maintains a reference (or references) to an object(s) of the class that is acting as the part (Roof)
The difference between this and aggregation is that the part is instantiated when the whole is instantiated. The house and the roof come into existence together (in the constructor for the House)
Indicates a House object has exactly one Roof object, named roof
This type of arrow indicates that the roof is an integral component of the house
November 23, 2018
Class Relationships

19. Drag it FROM House TO Roof …
Composition in UML
Select the Composition Arrow in Jude/Astah* and Drag FROM the whole (House) TO the part (Roof)
Drag it FROM House TO Roof …
Select this symbol
… to get this
November 23, 2018
Class Relationships

20. Composition
In aggregation, the part is created in a method that may or may not ever be invoked, while here, the part is always created.
Because the Roof/House cannot exist without the other, the House constructor creates its own Roof – and the Roof object exists as long as the House object does
November 23, 2018
Class Relationships

21. Security Issues in Part-Whole Relationships
Can something outside a class access a private member of the class without the class knowing it?
November 23, 2018
Class Relationships

22. Security Issues?
The textbook mentions a number of potential security issues with the aggregation/composition of classes
In the aggregation/composition relationship, you should restrict access to the aggregated/composed object reference by only allowing changes through the object that represents the whole
For example, we should not allow the size of the roof to change unless the entire house is changed (by adding, removing, or changing parts of it)
The House may change its Roof, but we shouldn’t allow the Roof to change itself without the House’s knowledge or its control
The easiest way to do this, is to make sure the House owns the only copy of the Roof (so it can’t be changed elsewhere)
There is a security problem with the aggregation example code given earlier. What is it?
November 23, 2018
Class Relationships

23. Changing the attributes of a reference changes all 3
Security Issues, cont.
Remember that an Object of a Class is a Reference to the actual object in memory
Multiple object references may refer to the same actual object in memory
Changing “one object” through its reference changes the actual object in memory so the others are changed, too
Object 1
Reference 1
Object 2
Reference 2
Object 3
Reference 3
Object in memory
3 instances refer to it
Changing the attributes of a reference changes all 3
November 23, 2018
Class Relationships

24. Example
This technique is called a Shallow Copy because the reference is duplicated, but not the object to which it refers
November 23, 2018
Class Relationships

25. Example, continued
This technique is called a Deep Copy because the object itself is duplicated – not just another reference to the same object
November 23, 2018
Class Relationships

26. Security Problems - resolved
The security problem noted several slides back can be resolved by ALWAYS using Deep Copy operations to assure that the only methods that can change a component object in a Composite class are the members of the Composite class itself
See the example on pages (that starts several pages earlier) of the textbook for the right and wrong ways to handle this issue
November 23, 2018
Class Relationships

27. Correction to Aggregation Example
The correct code for the aggregation example to avoid the security issue is
One should almost always do this to prevent this type of security issue
Room owns the clone of the parameter and only Room can change it. If the object that owns chairIn changes it, there will be no changes to the Room’s chair.
November 23, 2018
Class Relationships

28. Copy Constructor
In a class, it may be desirable to initialize a new object as a duplicate of an existing object (as shown in a previous example)
This is done with a copy constructor
A copy constructor is a constructor that takes one parameter – an existing object of the same class
The copy constructor initializes the attributes of the new object by copying the values of the corresponding attributes of the parameter into them
Example:
Card myCard = new Card (yourCard);
Initializes the new Card name myCard by copying all the attribute values from yourCard into the corresponding attributes in myCard
November 23, 2018
Class Relationships

29. Example of Copy Constructor
Deep copy : copies the entire object – not just copy a reference to it into another reference
November 23, 2018
Class Relationships