Home » Modeling » UML2 Tools » Association Owner Package
| Association Owner Package [message #471228] |
Thu, 05 July 2007 13:31  |
 Philippe
Messages: 100
Registered: July 2009 |
Senior Member |
|
|
Hi,
I'm stuck with an issue about the package that will own the association.
When editing a class diagram and creating an association between a class
and a shortcuted class from another package, the association will always
go in the package of the "target" class.
I's very troublesome for several reasons:
-the first is that the association will simply disappear from the
diagram on refresh.
-2nd is when defining a shared or composite associations, and
furthermore a navigable association, it's best to store the association
with the "source" class. UML2 does it for the methode
createAssociation() of Class,
but I found in AssociationCreateCommand doDefaultElementCreation()
Type sourceType = (Type) getSource();
Type targetType = (Type) getTarget();
//due to association end conventiontions (see AssociationEndConvention)
//we need to have member end of type SourceType to be the first one created
//thus, we are calling UML2 createAssociation() in opposite order
boolean setNavigability =
getCreateRequest().getParameter(AssociationEditHelper.PARAME TER_SET_TARGET_NAVIGABILITY)
!= null;
Association result = targetType.createAssociation(false,
AggregationKind.NONE_LITERAL, "src", 1, 1, sourceType, setNavigability,
AggregationKind.NONE_LITERAL, "dst", 1, 1);
I think that this workaround didn't take the owner package of the
association into account.
In addition making this like this is equivalent to pollute the package
or the model from which the shortcut comes with associations that won't
have any semantic value in it.
Regards
Philippe
|
|
|
| Re: Association Owner Package [message #471234 is a reply to message #471228] |
Thu, 05 July 2007 18:05  |
Dave Carlson
Messages: 402
Registered: July 2009 |
Senior Member |
|
|
I completely agree with Philippe's comment. Another related use case that
is very important is to divide a large model into separate domain and
datatype libraries, where each is stored in a separate .uml file. Some of
the common classes and datatypes are shared by a team of developers, and the
shared model files must be read-only for most users. So if you create an
association to a shared library class (where that class is a short-cut on a
diagram), the target package/resource is read-only and cannot be modified,
thus the association must be saved in the source package.
Regards,
Dave Carlson
"Philippe" <philippeweber57@yahoo.fr> wrote in message
news:f6is0d$rfg$1@build.eclipse.org...
> Hi,
>
> I'm stuck with an issue about the package that will own the association.
> When editing a class diagram and creating an association between a class
> and a shortcuted class from another package, the association will always
> go in the package of the "target" class.
>
> I's very troublesome for several reasons:
>
> -the first is that the association will simply disappear from the diagram
> on refresh.
>
> -2nd is when defining a shared or composite associations, and furthermore
> a navigable association, it's best to store the association with the
> "source" class. UML2 does it for the methode createAssociation() of Class,
> but I found in AssociationCreateCommand doDefaultElementCreation()
>
> Type sourceType = (Type) getSource();
> Type targetType = (Type) getTarget();
> //due to association end conventiontions (see AssociationEndConvention)
> //we need to have member end of type SourceType to be the first one
> created
> //thus, we are calling UML2 createAssociation() in opposite order
> boolean setNavigability =
> getCreateRequest().getParameter(AssociationEditHelper.PARAME TER_SET_TARGET_NAVIGABILITY)
> != null;
> Association result = targetType.createAssociation(false,
> AggregationKind.NONE_LITERAL, "src", 1, 1, sourceType, setNavigability,
> AggregationKind.NONE_LITERAL, "dst", 1, 1);
>
>
> I think that this workaround didn't take the owner package of the
> association into account.
> In addition making this like this is equivalent to pollute the package or
> the model from which the shortcut comes with associations that won't have
> any semantic value in it.
>
> Regards
> Philippe
|
|
|
| Re: Association Owner Package [message #602221 is a reply to message #471228] |
Thu, 05 July 2007 18:05 |
Dave Carlson
Messages: 402
Registered: July 2009 |
Senior Member |
|
|
I completely agree with Philippe's comment. Another related use case that
is very important is to divide a large model into separate domain and
datatype libraries, where each is stored in a separate .uml file. Some of
the common classes and datatypes are shared by a team of developers, and the
shared model files must be read-only for most users. So if you create an
association to a shared library class (where that class is a short-cut on a
diagram), the target package/resource is read-only and cannot be modified,
thus the association must be saved in the source package.
Regards,
Dave Carlson
"Philippe" <philippeweber57@yahoo.fr> wrote in message
news:f6is0d$rfg$1@build.eclipse.org...
> Hi,
>
> I'm stuck with an issue about the package that will own the association.
> When editing a class diagram and creating an association between a class
> and a shortcuted class from another package, the association will always
> go in the package of the "target" class.
>
> I's very troublesome for several reasons:
>
> -the first is that the association will simply disappear from the diagram
> on refresh.
>
> -2nd is when defining a shared or composite associations, and furthermore
> a navigable association, it's best to store the association with the
> "source" class. UML2 does it for the methode createAssociation() of Class,
> but I found in AssociationCreateCommand doDefaultElementCreation()
>
> Type sourceType = (Type) getSource();
> Type targetType = (Type) getTarget();
> //due to association end conventiontions (see AssociationEndConvention)
> //we need to have member end of type SourceType to be the first one
> created
> //thus, we are calling UML2 createAssociation() in opposite order
> boolean setNavigability =
> getCreateRequest().getParameter(AssociationEditHelper.PARAME TER_SET_TARGET_NAVIGABILITY)
> != null;
> Association result = targetType.createAssociation(false,
> AggregationKind.NONE_LITERAL, "src", 1, 1, sourceType, setNavigability,
> AggregationKind.NONE_LITERAL, "dst", 1, 1);
>
>
> I think that this workaround didn't take the owner package of the
> association into account.
> In addition making this like this is equivalent to pollute the package or
> the model from which the shortcut comes with associations that won't have
> any semantic value in it.
>
> Regards
> Philippe
|
|
|
Goto Forum:
Current Time: Fri Apr 26 08:52:50 GMT 2024
Powered by FUDForum. Page generated in 0.03167 seconds |
] 
Search
Help
Register
Login
Home
