Working with members of my development team realized that the programmers had difficulty interpreting the Class Diagrams that the analyst was doing. Or were ambiguous interpretations of what he accomplishes, losing the primary functionality of the UML language. Especially with regard to the relations that existed between classes. So I set out to make this short document, which I will try to explain the meaning of each relationship, in my words, and how does this translate into code.
Association:
is usually a structural relationship between classes, ie in the example, there is a class attribute of the transport medium, which is of type conductor. The Navégalo shows us where is located the attribute. That is what is the class that is contained attribute if it did not.
Aggregation:
is a relationship that was derived from the association, also be structural, ie it contains an attribute that in all cases be a collection, ie an array , vector, etc, and on top of that the class containing the collection must have a method that adds items to the collection. Can also be read as a means of transport has several wheels.
We are saying that the wheel objects are part of the object transportation. But their life cycle is not tied object to transport half. Ie if the car is destroyed, the wheels can continue to exist independently.
Composition
Like aggregation, is a structural relationship but adds, that has a method of destruction of objects. And unlike the association, the object lifecycle area is related to the object's path. That is, if the travel route rises, the areas that arose from it disappear. Can also be read as a route has several areas of coverage.
Much has been discussed about the aggregations and compositions, the debate is almost as hot as the include and extends to the use cases. Because some argue that object-oriented languages \u200b\u200bhave garbage collector, so no need methods of destruction of objects (related to the cycles of life in the compocición). And the schedule is the same for the compositions and aggregations, and the difference is merely conceptual from one to another. There is but one interpretation, but is exposed which I adhere.
Class Association
is a class that arises from a multiplicity many to many, and was incorporated in UML to support this case. Attributes are taken out of the classes involved and incorporated into a class apart. As the above refers to a structural relationship. In the example are the objects and road trip
Making
is a contractual relationship with another class. It is used to implement an interface. In languages \u200b\u200blike java or php use the keyword "implements"
Travel public class implements {...} InterfaceA
Usually when we're not sure if "something" is an interface or an abstract class, that drew the tag to make references to interfaces, we see the relationship to know.
Generalization
is an inheritance relationship. You can say it is a relationship "is a type." In our example: "a car is a type of means of transport." Is between a child class and parent class. In the encoding we can find the word "extends" which refers to this relationship. We can also find keywords such as "this" and "super" or "self" and "parent." To realize that there is a relationship of this type involved.
public class Auto extends MedioDeTransporte {...}
Unit
usage is a relationship, meaning that a class uses another. And if the latter is altered, the former may be affected.
in code often translate mainly as classes which makes the instantiation of an object. In our example the class trip he created the "new" of different objects. At this point you may wonder how you can make a new abstract class, hehe. Do not make new abstract class, if not their daughters. would be something like half MedioDeTransporte
= new Auto ();
also argues that this type of relationship makes references to the parameters passed in a method, under this concept, in Java, could be something like as: public void
crearViaje (MedioDeTransporte middle) {}
Finally also argues that we can encode this relationship by performing a "return" of the type of data in some form.
Well I hope I have cleared some doubts, there is much to discuss the matter.
Greetings team.
Here I give another example, a bit more complex and the methods of each class to be more specific.
Anl. Ariel Diaz Molina.
More information about UML on the label design.
