Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 281326

Summary:

Control models and profile management

Product:

[Modeling] MDT.UML2

Reporter:

Thibault Landré <thibault.landre>

Component:

Core

Assignee:

Kenn Hussey <Kenn.Hussey>

Status:

VERIFIED FIXED

QA Contact:

Severity:

enhancement

Priority:

Keywords:

plan

Version:

2.2.0

Flags:

Kenn.Hussey: kepler+

Target Milestone:

Hardware:

OS:

Linux

Whiteboard:

Community Support

Attachments:

Description	Flags
A project containing an example	none

Description Thibault Landré

2009-06-24 05:25:31 EDT

When controlling a part of a model, profiles and stereotypes are not well managed. 

1 - Stereotype appliance, Step to reproduce : 
- Create a new uml model (mainModel.uml).
- Create a package (Package_0) containing a class stereotyped (Class_0)
- Control Package_0 in a new file (controlledModel.uml)
--> The class is no more stereotyped in the new file (controlledModel.uml). This element still has its stereotype on the mainModel (mainModel.uml).

2 - Lose stereotype, step to reproduce : 
- Create a new uml model (mainModel.uml).
- Create a package (Package_0) containing a class stereotyped (Class_0)
- Control Package_0 in a new file (controlledModel.uml)
- In controlledModel.uml, create a new class (Class_1) under Package_0.
- Apply a stereotype on Class_1 and save/quit.
--> Open mainModel.uml, Class_1 have its stereotype applied. 
- Uncontrol Package_0 and save/quit
--> Open mainModel.uml, Class_1 lost its stereotype.

3- Profile application inheritance, step to reproduce : 
- Create a new uml model (mainModel).
- Create a package (Package_0) containing a class (Class_0) under the model. 
- Apply the Standard profile (with profile application) on the model (mainModel)
- Apply the Ecore profile on the package (Package_0)
--> Class_0 may be stereotyped by stereotype from Standard and Ecore profile. 
- Control Package_0 in a new file
--> Class_0 can not be anymore stereotyped with stereotype from Standard profile in the new file. 


For problems 1 and 2, this is due to the fact that stereotype application are stored under the root element. No action seems to be done to manage them with control and uncontrol feature. 
A solution may be to store the stereotype application directly under its element ? 

For problem 3, a solution may be to have a mechanism to get the inherited profile application when controlling an element and to create new profile application in the resulting controlled model. When uncontrolling a model, a mechanism would remove the duplicate profile application.

Comment 1 Thibault Landré

2009-06-24 05:26:56 EDT

Created attachment 139958 [details]
A project containing an example

Comment 2 Kenn Hussey

2012-06-20 15:16:18 EDT

Custom control/uncontrol operation(s) would need to be implemented to override/extend the default behavior from EMF so that profiles and stereotypes are handled properly. This can perhaps be explored in Keppler.

Comment 3 Kenn Hussey

2013-04-03 21:41:02 EDT

I have taken a closer look at this problem and made the following observations:

1. The "MainModel.uml" model that was provided has a corrupt profile application in it; more specifically, its profile application annotation has the following reference:

        <references xmi:type="uml:Profile" href="pathmap://UML_PROFILES/Standard.profile.uml#_0"/>

which should look more like this:

        <references xmi:type="ecore:EPackage" href="pathmap://UML_PROFILES/Standard.profile.uml#_yzU58YinEdqtvbnfB2L_5w"/>

2. Problem 3 deals with a scenario that isn't intended to be directly supported (at least not by UML2). When dealing with model "fragments" (i.e., resources that contain "controlled" objects), it is expected that all manipulation of controlled objects be done in the context of the "main" model - that is, one should not be loading and working with elements in "fragment" models independently of their "main" models. A tool based on UML2 might manage this constraint by identifying "fragment" models with a special file extension (e.g., .fragment.uml) and ensuring that "main" models are automatically loaded when "fragment" models are, possibly leveraging "back-pointers" from the root elements of "fragment" models (perhaps persisted in annotations) and/or a workspace index which keeps track of relationships between resources. In any case, support for such a mechanism is beyond the scope of UML2; certainly, at the very least, it is beyond the scope of the "sample" editor provided by UML2.

3. The solution I propose for problems 1 and 2 would be to customize the control/uncontrol action in the UML2 editor (actually in its action bar contributor) so that stereotype applications are moved to/from "fragment" resources when their base elements are controlled/uncontrolled.

Comment 4 Kenn Hussey

2013-04-10 14:28:15 EDT

The proposed solution for problems 1 and 2, as described in comment #3, has been committed/pushed to the 'master' branch in git.

Comment 5 Kenn Hussey

2013-04-19 16:19:26 EDT

An integration build (for UML2 4.1) containing the changes is now available.