Setting the association end ownership in UML: What does it mean with respect to generated code in visual paradigm (or in other UML tools)?

Question

What is the effect of setting the association end ownership from "association" to "classifier" on the code that gets generated?

In other words,

0) I start with an empty diagram

1) I create class A and class B

2) I connect A and B with an association A-B

3) the association end at A is named as a

4) the association end at B is named as b

5) the association end ownership for a is set to class B (by default it is set to the association A-B itself)

6) I generate Java code for this diagram

How and why does (should) the generated code now differ if I omit step 5 ? I.e. if I use the default value ?

What is the meaning of setting the association end ownership of a to class B ? What difference does it make ?

In visual paradigm the diagrams differ as follows (second diagram shows if step 5 is omitted) :

EDIT:

In VP-UML, the generated code in both cases is the same :

public class A {

    B b;

}

public class B {

    A a;

}

So in this sense the ownership does not matter ? This is a little confusing.

Answer 1

I could give you a general approach about how a general UML 2 source code generator might work (UML spec doesn't specify how to generate code from UML models)

From my point of view, if the association ends (property) belongs to the UML class, then a field should be generated in the source code class, whereas if it belongs to the association no field is generated (allows you to model unidirectional or bidirectional associations between classes). Have a look to the example I've recently posted

Answer 2

Ownership means that class or its instance has not only reachable way to instance of another class, but has it as an attribute (direct reference or simply contains it). Ownership does NOT belong to strict features of UML.

• Before other things you should understand what the association A to B is.
  • Basically it is a solid line between A and B. It can represent one structure that connects class/instanc(es) of A with the class/instances of B. The structure can be of any sort and belong anywhere. All information, written about the line, describes this structure.
  • If there are two structures, one structure, that connects one instance of A with instance(s) of B and another structure that connects instance of B with instance(s) of A, you can show them both in ONE association. Then, information written about its B end describes the first structure (b->a) and info about the other end describes the other structure.
  • If you'll have more than one structure guiding from A to B, you have to draw two different associations.
  • If a joining structure is complex, you could represent it as an Association Class. There you can define more details.
  • A joining structure can connect more than two classes, then it will be shown as a large diamond with solid branches to these classes. It is still association! Attention: these two more complex associations are very badly supported by existing tools. You can easily create something absolutely senseless with them. And they are difficult. Use carefully.

---

---

In C++ instance A can have the B instance not by pointer, but directly. There is NO special UML sign for it, it should be shown in the same way as normal, pointer attribute.

Answer 3

I think the convention you are trying to deal with is now deprecated.

Navigability notation was often used in the past according to an informal convention, whereby non-navigable ends were assumed to be owned by the association whereas navigable ends were assumed to be owned by the classifier at the opposite end. This convention is now deprecated.

Source: www.site.uottawa.ca

Answer 4

You are expecting to see impact of ownership on navigability while ownership and navigability are orthogonal concepts.

Setting the association end ownership specifies that the association end is a feature of the class on the opposite side, which will have three impacts:

1. in term of semantic, the definition of the owner Class will refer to the owned end and its classifier. Inversely, the definition of the Class on owned end side should not refer to the owner Class. In your example, the definition of B should refer the role a of A while the definition of A should not talk about B at all.

2. in term of implementation, a modification of the association will only impact the object of the Owner class. In your example, let's suppose B_1 is an instance of B, and A_1 is an instance of A. Let's also suppose the cardinality of you {a,b} relationship is 1-1 and navigability is bi-directional so that we have a property B.a:A but also a property A.b:B to navigate easily from B to A and from A to B. In this case, a modification of B_1.a will be considered an update of object B_1 (an B_Updated event can be emitted to listeners) while a modification of A_1.b will NOT be considered an update of object A_1. Conceptually, no features of A_1 was updated. When changing A_1.b it is actually the associated B object that is updated.

Note: Of course, this example is a bit fictive as normally A_1.b should be read-only and derived from instances of B. A_1.b should return the instance B_i of B where B_i.a == A_1. This bring me to the third impact of ownership:

3. when the two Classes of an association are part of two different DB schemas, it is the DB schema of the Owner Class that is the master source of the association. In your example, if A is in schema_A and B in schema_B, the relationship is mastered in schema_B. If the {a,b} relationship is a many-to-one relationship, i.e. B.b is a collection of A, we will therefore not store the FK of B in schema_A (as it would be done naturally in DB design) but we will create a specific table in schema_B to store all {a,b} relationships. Doing so will ensure that integrity of B, including the B.a feature, will be managed centrally in schema_B.

Hope it clarifies a bit the idea.