Isn’t it that drawing an aggregation relationship means to have a class attribute of type “pointer to instance of other class” later after code generation? I expected that automatically such an attribute member is put in class A if I draw an aggregation relationship to class B. But it seems it’s completely unrelated in UML. Doesn’t that sound like an unfinished feature of the UML language?
Actually, it should be enough to give aggregation or composition arrows the attribute name. And the multiplicity defines if it’s a simple pointer or array of pointers or similar. And if done this way, it’s not necessary anymore to insert those attributes into the class box.
To me, that interpretation is too implementation-specific. The way I think of aggregation is a grouping of items. Compared to its stronger form, composition, in which I think of it as a grouping that makes a whole.
Attributes and relationships are modelled separately. If you’re thinking of implementation code, then yes, you may have a member in your code to fulfill the relationship but in terms of software/domain modelling, such detail is not important.
My guess is that you are not satisfied with what code generation produced? To me, code generation is great for setting up structure. However, constraints, such as relationships, will need to be hand-coded afterward or the code generation tool needs to be instructed in how to interpret certain constraints.
Not necessarily. To me, it means that you are looking for something more specific to complete your model and for you, UML alone doesn’t suffice. That is why constraint languages, such as OCL, exists outside of UML. In your case, you can choose to model the attribute to explicitly describe your pointers, which is still in the realm of UML.
However, keep in mind that that doesn’t necessarily mean that you can expect the implementation to include the relationship’s name/label as an attribute. If you want to be explicitly clear that you’re expecting a member in a class, you’ll need to mention it. You can also use brackets (“”) to specify an array of the same type. For example, “+ Numbers : int[]”
