October 5, 2010 OOP, UML 2 comments
Composition vs. Aggregation – Best way to distinguish
Shame on me, but I have to admit that yesterday I had doubts about what is aggregation and composition. As everyone of us would do I started googling and found some of very useful and helpful explanations.
Two examples to start with
For example, we have table in room, we say that room aggregates table. Table can live without parent object (room).
Example of composition would be college composing faculties. Faculty cannot live without college.
Challenge
When I talked about this two examples with my friend he challenged following verification:
“If child cannot live without parent we have composition and when child can live without parent we have aggregation.” He gave me example of queue build upon list, he stated that this always was an example of composition to him. In this case queue has field _innerList (or something like that), but indeed being child list can be moved out of queue and conceptually we can operate with different lists in our system. So the rule of child-parent doesn’t apply. Even more it is applicable vise verse – queue (parent) cannot live without list (child).
So I found following to be the best way to distinguish:
If during lifetime of parent its child element(s) should exist to have consistent system, then this is COMPOSITION.
If above statement is not satisfied, but at the same time parent can contain child element(s), then this is AGGREGATION.
Relational/UML point of view
If you would read this wiki page. You will also find that aggregation is more general term then composition. They explain this from a bit another point, point of relations.
Above relation on the picture shows composition and is marked as filled diamond, below relation shows aggregation as more generalization of composition, without restriction to have child elements (Monday our pound is full of ducks and Tuesday there is no ducks at all).
I would love to hear from you thoughts on how we can help others distinguish this more quicker.
KE – Day Third – Modelling: UML
August 10, 2010 Career, UML 5 comments
Today is my third day preparing to the Knowledge Evaluation. For today I had DB Design and Modeling. Modeling is about UML diagrams as it is mentioned in sheet I’m using for preparing. In this post I explained each of the diagrams with one simple sentence. Also I drew few of them, have no enough power at this point of time at night to continue and draw all of them. Hope you will like my drawing tries :)
UML: Structure Diagrams
Class Diagram – show classes and their interaction in details.
Component Diagram – represent components of the system, their relationships and contracts they use to interact.
Composite Structures Diagram – show collaboration of instances in run-time and communication links used.
Package Diagram – organizes other model elements into groups for easy understanding of the system.
Deployment Diagram – represent static state of the working system, including hardware and software located on it.
Object Diagram – shows snapshot of the instances of the system to represent how system can look at run-time.
UML: Behavior Diagrams
Activitiy Diagram – represent workflow of the activities in the system, basing on decisions made.
Use Case Diagram – show usage patterns of the system, so they can ideally describe requirements.
State Diagram – shows all of the possible states of the object in the system and conditions when it can change its state.
UML: Interaction Diagrams
Sequence Diagram – show the lifetime of the components/classes and their interaction in time.
Communication Diagram – shows flow of the messages in the system and illustrates basic relationships between classes.
