Aggregation in class diagram and class properties - oop

Question

In a lecture about Class diagrams the following slide appeared which describes the relationship in an Elevator system:
The lecture called the black headed arrows a "composite aggregation" relationship which means that the child cannot exist independently of the parent.
In this elevator system example, the Motor object is irrelevant outside of the Elevator object.
What I don't understand though is how the composite aggregation appears in the code itself. I'd expect there to be a "myMotor" property in the Elevator but there isn't.
Is it because by drawing this relationship we tell the programmer that he needs to implement it but the implementation details are his to choose?
As opposed to the father object's proprties which are stated explicitly (like the elevator's isActive boolean property)?

Answer 1

U.M.L. can be used, in several ways,as very conceptual design tool, or a more specific programming design tool.
So, when representing a composite aggregation, it can be represented in several ways.
Sometimes, you may want to display all members of a class. Bad, when there are too much members.
+--------------------------+
| ElevatorClass |
+--------------------------+
| [+] boolean: isActive |
| [+] boolean: isInOrder |
| [+] Floor: Location |
| [+] MotorClass: Motor |
| [+] DoorClass: Door |
+--------------------------+
| [+] startOperation() |
| [+] stopOperation() |
| [+] gooUp() |
| [+] gooDown() |
| [+] openDoor() |
| [+] closeDoor() |
+--------------------------+
Sometimes, you may want to hide all members of a class. Good, when you want to focus in the class, not the members. Note: This may be the case you are looking right now.
+--------------------------+1 1+--------------------------+
| ElevatorClass |------<*>| RescueButtonClass |
+--------------------------+ +--------------------------+
Sometimes, you may want to show some members of a class, and hide another.
+--------------------------+ 1 1 +--------------------------+
| ElevatorClass |------<*>| MotorButtonClass |
+--------------------------+ +--------------------------+
| [+] boolean: isActive |
| [+] boolean: isInOrder |
| [+] Floor: Location |
| [+] MotorClass: Motor |
| [+] DoorClass: Door |
+--------------------------+
To make things a little complicated, the motor, as well as the other elements, doesn't necesarilly have to be referenced by a reference member in the elevator class.
Example (c style):
class ElevatorClass {
public:
List<ComponentClass*> Components;
...
void AddComponent(ComponentClass* ThisComponent);
} // class ElevatorClass
...
MyElevator.AddComponent(MyMotor);
In the previous code example, the member is not referenced directly.
Personally I agree with you that this its very clear:
class ElevatorClass {
public:
MotorClass* Motor;
MotorClass* Motor;
} // class ElevatorClass
Cheers.

Answer 2

For a Composite Aggregation (also called Composition), USUALLY this indicates a parent-child relationship. In your example, an Elevator object in your code would contain a reference to only one Motor object. Here is a link to a blog post that may explain it better. Look for the Composition section:
http://aviadezra.blogspot.com/2009/05/uml-association-aggregation-composition.html
I think this representation makes sense for all the objects pictured except maybe StopRequest. Personally I would not have pictured that as a Composition to the Elevator object, but remember that UML is not an exact science.

Answer 3

Your assumption is correct - UML relations doesn't specify the implementation details. In case of composition the requirement is that Motor object lifetime is bounded to the containing Elevator object lifetime. This can be achieved in several ways (and dependens on the language you use as well). It can be a property inside the Elevator and in this case it will be automatically destroyed along with the the containing Elevator. On the other hand, it can be an external object which is instantiated and freed manually during the lifetime of the containing Elevator object. The implementation depends on the specific case and additional design considerations, such as simplicity, flexibility, modularity etc.
There are many details that can be added to the diagram. The creator of the diagram needs to consider what to include and what to omit. For example, private properties are usually related to implementation details and aren't interesting for the class diagram thus they won't be mentioned. Properties mentioned explicitly imply a composition relation between the containing object and the property. Such notion is usually used for primitive properties, such as boolean, int etc. For a more complex properties an explicit UML relation is usually used to depict the relation between the objects (like between Elevator and Motor).