CODEWITHSUNDEEP
javaumlassociationsrelationshipclass-diagram
DesirePRG
DesirePRG

Reputation: 6388

understanding UML associations in code

This is the understanding I have about Association, Aggregation and composition as of now.

Association

public class Foo { 
    void Baz(Bar bar) {
    } 
};

Aggregation

public class Foo { 
    private Bar bar; 
    Foo(Bar bar) { 
       this.bar = bar; 
    }
}

Composition

public class Foo {
    private Bar bar = new Bar(); 
}

I think there is no point in understanding what the words mean, unless I can't represent it in actual code. The above code was taken from a SO answer (tell me if the above code is wrong).

My questions are the fllowing.

1) Is aggregation and composition important to be shown in a class diagram

2) I used a tool which can convert the java .class files into a class diagram. Class Visualizer but i was unable to make this tool show aggregation or composition relationships in the class diagram. Is that a problem with the tool or I have not understood how to use composition and aggregation in code? When I used the above code for association the tool gave me a representation of "dependency" relationship. (a dashed line)

Upvotes: 1

Views: 1749

Answers (3)

Gerd Wagner
Gerd Wagner

Reputation: 5673

Yes, your code above is wrong in the sense that it does not show how associations/aggregations/compositions are coded. In fact, your first code example is a case of a mere UML dependency, and not of an association. Associations are always coded/implemented with the help of reference properties, like your property bar, which references an object of type Bar. So, your second and third examples are cases of coding an association between Foo and Bar. Btw, the UML defines compositions to be a special type of aggregations (having exclusive parts), and aggregations to be a special type of association with the intended meaning of part-whole relationships.

Notice that while it is well-known how (the different forms of) associatons are coded/implemented, and this is supported in many app dev frameworks, e.g. in those based on the Active Records paradigm of Ruby on Rails, but also in the object-relational-mapping framework Java Persistency Annotations (JPA), it is not clear how aggregations and compositions are to be coded. In fact, the UML concept of an aggregation is so weak that it does not imply anything in terms of code. But also the UML concept of composition is too weak for being useful/meaningful in coding. Only if we make it stronger by requiring that the parts of a composition cannot be detached from their composite (this requirement is called inseparable parts), as discussed in my SO answer and my (award-winning) CodeProject article, we get two special meanings in terms of code:

  1. In this stronger form of composition we have a life-cycle dependency between the components and their composite, which implies that components should be destroyed whenever their composite is destroyed.
  2. Components can be named/identified relative to their composite.

So the answer to your question "1) Is aggregation and composition important to be shown in a class diagram?" is:

a) no, aggregation is not important/relevant to be shown in a class diagram, just show it as an association

b) composition is important/relevant to be modeled/shown in a class diagram only when it has inseparable parts.

Upvotes: 4

Geert Bellekens
Geert Bellekens

Reputation: 13784

UML is not at the same level as code, so there is no 1-1 translation between code and UML.

There are many ways to reverse engineer code into an UML model, and there are even more ways to implement a UML model in code.

So you'll have to understand the UML concepts itself, and only then think about how you can implement such concept in code.

There are many books about UML and many explanations to be found online, but the only true source is the UML specificiation

Based on this specification I wrote an article trying to figure out the (sometimes subtle) differences between the different types of association: UML Composition vs Aggregation vs Association

Upvotes: 2

qwerty_so
qwerty_so

Reputation: 36333

Whether you show a composition/aggregation depends. You show that the aggregated or composed elements becomes a part and can / can not live without the aggregating/composing element. E.g. in a database you show that children will be deleted in a composition when you delete the parent which is an important statement. On a different level (e.g. when talking about objects derived from database entities) this may become less important. Finally it depends on the targeted reader group. Leaving the aggregate/composition away simply reduces the information you convey to the reader.

I don't know the Class Visualizer, but most UML tools just interpret your examples as dependencies (if at all). It tells: "there is some relation between both - go figure yourself". Or you edit the generated model after import and make it more correct.

Upvotes: 1

Related Questions