Class-owned end

[Jean Fex]

Hello, I need to represent an Association end that is owned par the Class at the opposite end. I only need that End to be displayed with the dot in the diagram. I expected a property of the End to indicate it and possibly by a check box. The only thing I found is the ownerAttribute search property to link the End to an existing Attribute of the owner Class. (I did not find the term ownerAttribute in the OMG Specification.) To use it, I must create the Attribute in the owning Class whose Type is the Class of the Class-owned End. This is considered redundant and might generate the inconsistency of having the Attribute in the owner Class of a Type different then the Class at the owned End.

If there is a way with StarUML to just indicate that an End is Class-owned, I'd like to know it otherwise I'd like to request such a change in an upcoming version.

Kindest regards, Jean

[Jean Fex]

I realised that I didn't find "ownerAttribute" in the OMG Specification because the term is: "ownedAttribute" for some meta-association-ends.

[StarUML]

Hi Jean,

Thank you for your feedback. 

This is not an easy matter. For us, it becomes a situation where there are duplicate properties to express Class-owned.

An inconsistency may occur where the owerAttribute is assigned, but the classOwned property is not set. I think it is good to provide a single way to express class-owned.

Thanks,

2022년 7월 20일 수요일 오후 10시 49분 27초 UTC+9에 jean...@yahoo.fr님이 작성:

[Jean Fex]

Hi StarUML,

I understand the difficulty. With the way StarUML implements the Class-owned Association-end, there is always duplicate Properties since this End (a Property) has to be linked to an Attribute (also a Property). Therefore, StarUML would have to verify that the End is linked to an Attribute of the Class at the other End and that this Attribute has the same properties and so on.

What do you mean by "the classOwned property is not set"? I don't understand it.

I still need and request that StarUML provides a way to represent an Association-end as Class-owned only, and illustrate it only by the "dot" at that End i.e. without having nor needing the ownedAttribute. Notice that it is exactly the Update request considered covered by version 5.02. It is a feature that can easily be implemented by a check box for Association Ends labeled "Class owned". Consequently, the ownedAttribute feature could automatically set the check box and if the box is uncheked with the owned Attribute linked, issue an error message. I consider that having only the dot is sufficient and used in most circumstances, and additionally avoids inconsistencies.

Again, it's not "ownerAttribute" but 'ownedAttribute": OMG Spec section 9.5. It sould be corrected.

Best regards, Jean

[StarUML]

Hi Jean,

First of all, this issue has been added as feature request in the our main issue tracking system.

We're still concerned that adding the "classOwned" attribute would be a redundant way to mark the End with a dot. If "ownedAttribute" is assigned, but "classOwned"=false , then there will be a semantic conflict. The user must consider all combinations of the two attributes (
"ownedAttribute" and "classOwned") (assigned/false, assigned/true, not-assigned/true) and decide which combination to use.

Of course we understand that you need a way to display a dot at the End without adding an attribute in the class. But, is there any reason why it shouldn't necessarily appear as an attribute of a class when assigned with "ownedAttribute"? (I have not yet found any diagram with a dot at the End without appearing as an attribute in the class.)

We'll see if there's a better way, review it internally, and discuss whether to add it to the next version.

Thanks,

2022년 7월 23일 토요일 오전 1시 2분 3초 UTC+9에 jean...@yahoo.fr님이 작성:

[Jean Fex]

Hi StarUML,

I thank you and apreciate your consideration for my need and concern.

I never put the attribute in the owner class that correspond the association end owned by that class. I always make sure my audiences know it and when they don't, I inform them clearly. My main reason is to have my diagrams as simple as possible while having them complete. To me, it's a best practice. I can't provide actual exemples of diagrams that used the dots only but the diagrams of the OMG Specification are like that.

It is obviously a tool design decision for you. With the current version, a verification should block the possibility to select an attribute from a class other than the one at the other end. With the class-owned selection property of the association end the only problem is "assigned/false". In this case, a verification should alert the user or it could automatically set the property to True (checked).

Kindest regards, Jean