Home » Modeling » UML2 » Memory leak in uml2 ?
| | | |
Re: Memory leak in uml2 ? [message #478055 is a reply to message #478054] |
Tue, 09 December 2008 13:38 |
Alexander Weickmann Messages: 33 Registered: July 2009 |
Member |
|
|
I call unload on every resource I loaded now. It didn't get better but
simpler it seems.
I collected actual data with JProbe and now I have 2339 of Element in the
heap.
They all have only 1 referrer:
org.eclipse.emf.ecore.util.EObjectResolvingEList
I have also an allocation trace for that, it seems the problem starts with
the applyStereotype method:
Method,Source,
java.lang.reflect.Array.newArray(Class, int),Array.java:Not Available,
java.lang.reflect.Array.newInstance(Class, int),Array.java:52,
org.eclipse.emf.ecore.util.EcoreEList.newData(int),EcoreELis t.java:63,
org.eclipse.emf.common.util.BasicEList.grow(int),BasicEList. java:1099,
org.eclipse.emf.common.util.BasicEList.addUnique(int,
Object),BasicEList.java:686,
org.eclipse.emf.common.notify.impl.NotifyingListImpl.doAddUn ique(int,
Object),NotifyingListImpl.java:393,
org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUniq ue(int,
Object),NotifyingListImpl.java:351,
org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.setValue(EObjec t,
EStructuralFeature, Object, int),XMLHelperImpl.java:1183,
org.eclipse.emf.ecore.xmi.impl.XMLHandler.setFeatureValue(EO bject,
EStructuralFeature, Object, int),XMLHandler.java:2643,
org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleForwardRefer ences(boolean),XMLHandler.java:1135,
org.eclipse.emf.ecore.xmi.impl.XMLHandler.endDocument(),XMLH andler.java:1214,
org.eclipse.uml2.uml.internal.resource.UMLHandler.endDocumen t(),UMLHandler.java:55,
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .endDocument(Augmentations),AbstractSAXParser.java:737,
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl.scanDocument(boolean),XMLDocumentFragmentScannerI mpl.java:515,
com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(boolean),XML11Configuration.java:807,
com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(XMLInputSource),XML11Configuration.java:737,
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(X MLInputSource),XMLParser.java:107,
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .parse(InputSource),AbstractSAXParser.java:1205,
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSA XParser.parse(InputSource),SAXParserImpl.java:522,
javax.xml.parsers.SAXParser.parse(InputSource,
DefaultHandler),SAXParser.java:395,
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLResource, InputStream,
Map),XMLLoadImpl.java:181,
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(InputS tream,
Map),XMLResourceImpl.java:180,
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(InputS tream,
Map),ResourceImpl.java:1445,
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Map),R esourceImpl.java:1241,
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(Resource),ResourceSetImpl.java:255,
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo adHelper(Resource),ResourceSetImpl.java:270,
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(URI,
boolean),ResourceSetImpl.java:397,
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getEObje ct(URI,
boolean),ResourceSetImpl.java:216,
org.eclipse.emf.ecore.util.EcoreUtil.resolve(EObject,
ResourceSet),EcoreUtil.java:202,
org.eclipse.emf.ecore.util.EcoreUtil.resolve(EObject,
EObject),EcoreUtil.java:262,
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eResolveProxy(In ternalEObject),BasicEObjectImpl.java:1470,
org.eclipse.uml2.uml.internal.impl.StructuralFeatureImpl.get Type(),StructuralFeatureImpl.java:216,
org.eclipse.uml2.uml.internal.operations.ElementOperations.g etExtension(Element,
Stereotype),ElementOperations.java:1168,
org.eclipse.uml2.uml.internal.operations.ElementOperations.a pplyStereotype(Element,
Stereotype),ElementOperations.java:1407,
org.eclipse.uml2.uml.internal.impl.ElementImpl.applyStereoty pe(Stereotype),ElementImpl.java:501,
org.faktorips.uml.core.internal.ClassDelta.applyToUmlModel(M ap),ClassDelta.java:1055,
org.faktorips.uml.core.internal.PackageDelta.applyClassDelta sToUmlModel(Map),PackageDelta.java:837,
org.faktorips.uml.core.internal.ModelDelta.applyPackageDelta sToUmlModel(),ModelDelta.java:493,
org.faktorips.uml.core.internal.ModelDelta.applyToUmlModel() ,ModelDelta.java:464,
org.faktorips.uml.core.ModelSynchronizer.synchronizeUmlModel (),ModelSynchronizer.java:168,
org.faktorips.uml.ui.actions.UpdateUmlModelAction.updateUmlM odel(),UpdateUmlModelAction.java:135,
org.faktorips.uml.ui.actions.UpdateUmlModelAction.run(IProgr essMonitor),UpdateUmlModelAction.java:70,
org.eclipse.jface.operation.ModalContext$ModalContextThread. run(),ModalContext.java:121,
|
|
|
Re: Memory leak in uml2 ? [message #478056 is a reply to message #478055] |
Tue, 09 December 2008 14:59 |
james bruck Messages: 1724 Registered: July 2009 |
Senior Member |
|
|
Hi Alex,
I don't believe this is a result of the uml cache adapter ( which I was also
thinking to be the cause - and Ed mentioned ).
You mentioned in your original posting that you are doing an "export", do
you see the same problem just opening and closing the model?
Stereotypes use Dynamic EMF, do you just see the issue with just stereotypes
or other types?
Can you post a small model with exact steps to reproduce. I would like to
observe this with the memory profile tools we use.
Cheers,
- James.
"Alex " <eistoeter@gmx.de> wrote in message
news:b7264e17e716ce5ed533604cd9d6ba52$1@www.eclipse.org...
>I call unload on every resource I loaded now. It didn't get better but
>simpler it seems.
>
> I collected actual data with JProbe and now I have 2339 of Element in the
> heap.
> They all have only 1 referrer:
> org.eclipse.emf.ecore.util.EObjectResolvingEList
>
> I have also an allocation trace for that, it seems the problem starts with
> the applyStereotype method:
>
> Method,Source,
> java.lang.reflect.Array.newArray(Class, int),Array.java:Not Available,
> java.lang.reflect.Array.newInstance(Class, int),Array.java:52,
> org.eclipse.emf.ecore.util.EcoreEList.newData(int),EcoreELis t.java:63,
> org.eclipse.emf.common.util.BasicEList.grow(int),BasicEList. java:1099,
> org.eclipse.emf.common.util.BasicEList.addUnique(int,
> Object),BasicEList.java:686,
> org.eclipse.emf.common.notify.impl.NotifyingListImpl.doAddUn ique(int,
> Object),NotifyingListImpl.java:393,
> org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUniq ue(int,
> Object),NotifyingListImpl.java:351,
> org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.setValue(EObjec t,
> EStructuralFeature, Object, int),XMLHelperImpl.java:1183,
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.setFeatureValue(EO bject,
> EStructuralFeature, Object, int),XMLHandler.java:2643,
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleForwardRefer ences(boolean),XMLHandler.java:1135,
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.endDocument(),XMLH andler.java:1214,
> org.eclipse.uml2.uml.internal.resource.UMLHandler.endDocumen t(),UMLHandler.java:55,
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .endDocument(Augmentations),AbstractSAXParser.java:737,
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl.scanDocument(boolean),XMLDocumentFragmentScannerI mpl.java:515,
> com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(boolean),XML11Configuration.java:807,
> com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(XMLInputSource),XML11Configuration.java:737,
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(X MLInputSource),XMLParser.java:107,
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .parse(InputSource),AbstractSAXParser.java:1205,
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSA XParser.parse(InputSource),SAXParserImpl.java:522,
> javax.xml.parsers.SAXParser.parse(InputSource,
> DefaultHandler),SAXParser.java:395,
> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLResource, InputStream,
> Map),XMLLoadImpl.java:181,
> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(InputS tream,
> Map),XMLResourceImpl.java:180,
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(InputS tream,
> Map),ResourceImpl.java:1445,
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Map),R esourceImpl.java:1241,
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(Resource),ResourceSetImpl.java:255,
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo adHelper(Resource),ResourceSetImpl.java:270,
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(URI,
> boolean),ResourceSetImpl.java:397,
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getEObje ct(URI,
> boolean),ResourceSetImpl.java:216,
> org.eclipse.emf.ecore.util.EcoreUtil.resolve(EObject,
> ResourceSet),EcoreUtil.java:202,
> org.eclipse.emf.ecore.util.EcoreUtil.resolve(EObject,
> EObject),EcoreUtil.java:262,
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eResolveProxy(In ternalEObject),BasicEObjectImpl.java:1470,
> org.eclipse.uml2.uml.internal.impl.StructuralFeatureImpl.get Type(),StructuralFeatureImpl.java:216,
> org.eclipse.uml2.uml.internal.operations.ElementOperations.g etExtension(Element,
> Stereotype),ElementOperations.java:1168,
> org.eclipse.uml2.uml.internal.operations.ElementOperations.a pplyStereotype(Element,
> Stereotype),ElementOperations.java:1407,
> org.eclipse.uml2.uml.internal.impl.ElementImpl.applyStereoty pe(Stereotype),ElementImpl.java:501,
> org.faktorips.uml.core.internal.ClassDelta.applyToUmlModel(M ap),ClassDelta.java:1055,
> org.faktorips.uml.core.internal.PackageDelta.applyClassDelta sToUmlModel(Map),PackageDelta.java:837,
> org.faktorips.uml.core.internal.ModelDelta.applyPackageDelta sToUmlModel(),ModelDelta.java:493,
> org.faktorips.uml.core.internal.ModelDelta.applyToUmlModel() ,ModelDelta.java:464,
> org.faktorips.uml.core.ModelSynchronizer.synchronizeUmlModel (),ModelSynchronizer.java:168,
> org.faktorips.uml.ui.actions.UpdateUmlModelAction.updateUmlM odel(),UpdateUmlModelAction.java:135,
> org.faktorips.uml.ui.actions.UpdateUmlModelAction.run(IProgr essMonitor),UpdateUmlModelAction.java:70,
> org.eclipse.jface.operation.ModalContext$ModalContextThread. run(),ModalContext.java:121,
>
>
|
|
|
Re: Memory leak in uml2 ? [message #478057 is a reply to message #478056] |
Tue, 09 December 2008 17:35 |
james bruck Messages: 1724 Registered: July 2009 |
Senior Member |
|
|
Hi Alex,
Another idea would be to provide a trace from YourKit - I believe they have
a 10 day free license.
Narrowing this problem to straight opensource UML2 or EMF with a
reproduceable scenario would be the key.
Cheers,
- James.
"James Bruck" <jbruck@ca.ibm.com> wrote in message
news:ghm117$67v$1@build.eclipse.org...
> Hi Alex,
>
> I don't believe this is a result of the uml cache adapter ( which I was
> also thinking to be the cause - and Ed mentioned ).
> You mentioned in your original posting that you are doing an "export", do
> you see the same problem just opening and closing the model?
> Stereotypes use Dynamic EMF, do you just see the issue with just
> stereotypes or other types?
> Can you post a small model with exact steps to reproduce. I would like to
> observe this with the memory profile tools we use.
>
> Cheers,
> - James.
>
> "Alex " <eistoeter@gmx.de> wrote in message
> news:b7264e17e716ce5ed533604cd9d6ba52$1@www.eclipse.org...
>>I call unload on every resource I loaded now. It didn't get better but
>>simpler it seems.
>>
>> I collected actual data with JProbe and now I have 2339 of Element in the
>> heap.
>> They all have only 1 referrer:
>> org.eclipse.emf.ecore.util.EObjectResolvingEList
>>
>> I have also an allocation trace for that, it seems the problem starts
>> with the applyStereotype method:
>>
>> Method,Source,
>> java.lang.reflect.Array.newArray(Class, int),Array.java:Not Available,
>> java.lang.reflect.Array.newInstance(Class, int),Array.java:52,
>> org.eclipse.emf.ecore.util.EcoreEList.newData(int),EcoreELis t.java:63,
>> org.eclipse.emf.common.util.BasicEList.grow(int),BasicEList. java:1099,
>> org.eclipse.emf.common.util.BasicEList.addUnique(int,
>> Object),BasicEList.java:686,
>> org.eclipse.emf.common.notify.impl.NotifyingListImpl.doAddUn ique(int,
>> Object),NotifyingListImpl.java:393,
>> org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUniq ue(int,
>> Object),NotifyingListImpl.java:351,
>> org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.setValue(EObjec t,
>> EStructuralFeature, Object, int),XMLHelperImpl.java:1183,
>> org.eclipse.emf.ecore.xmi.impl.XMLHandler.setFeatureValue(EO bject,
>> EStructuralFeature, Object, int),XMLHandler.java:2643,
>> org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleForwardRefer ences(boolean),XMLHandler.java:1135,
>> org.eclipse.emf.ecore.xmi.impl.XMLHandler.endDocument(),XMLH andler.java:1214,
>> org.eclipse.uml2.uml.internal.resource.UMLHandler.endDocumen t(),UMLHandler.java:55,
>> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .endDocument(Augmentations),AbstractSAXParser.java:737,
>> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl.scanDocument(boolean),XMLDocumentFragmentScannerI mpl.java:515,
>> com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(boolean),XML11Configuration.java:807,
>> com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(XMLInputSource),XML11Configuration.java:737,
>> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(X MLInputSource),XMLParser.java:107,
>> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .parse(InputSource),AbstractSAXParser.java:1205,
>> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSA XParser.parse(InputSource),SAXParserImpl.java:522,
>> javax.xml.parsers.SAXParser.parse(InputSource,
>> DefaultHandler),SAXParser.java:395,
>> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLResource, InputStream,
>> Map),XMLLoadImpl.java:181,
>> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(InputS tream,
>> Map),XMLResourceImpl.java:180,
>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(InputS tream,
>> Map),ResourceImpl.java:1445,
>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Map),R esourceImpl.java:1241,
>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(Resource),ResourceSetImpl.java:255,
>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo adHelper(Resource),ResourceSetImpl.java:270,
>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(URI,
>> boolean),ResourceSetImpl.java:397,
>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getEObje ct(URI,
>> boolean),ResourceSetImpl.java:216,
>> org.eclipse.emf.ecore.util.EcoreUtil.resolve(EObject,
>> ResourceSet),EcoreUtil.java:202,
>> org.eclipse.emf.ecore.util.EcoreUtil.resolve(EObject,
>> EObject),EcoreUtil.java:262,
>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eResolveProxy(In ternalEObject),BasicEObjectImpl.java:1470,
>> org.eclipse.uml2.uml.internal.impl.StructuralFeatureImpl.get Type(),StructuralFeatureImpl.java:216,
>> org.eclipse.uml2.uml.internal.operations.ElementOperations.g etExtension(Element,
>> Stereotype),ElementOperations.java:1168,
>> org.eclipse.uml2.uml.internal.operations.ElementOperations.a pplyStereotype(Element,
>> Stereotype),ElementOperations.java:1407,
>> org.eclipse.uml2.uml.internal.impl.ElementImpl.applyStereoty pe(Stereotype),ElementImpl.java:501,
>> org.faktorips.uml.core.internal.ClassDelta.applyToUmlModel(M ap),ClassDelta.java:1055,
>> org.faktorips.uml.core.internal.PackageDelta.applyClassDelta sToUmlModel(Map),PackageDelta.java:837,
>> org.faktorips.uml.core.internal.ModelDelta.applyPackageDelta sToUmlModel(),ModelDelta.java:493,
>> org.faktorips.uml.core.internal.ModelDelta.applyToUmlModel() ,ModelDelta.java:464,
>> org.faktorips.uml.core.ModelSynchronizer.synchronizeUmlModel (),ModelSynchronizer.java:168,
>> org.faktorips.uml.ui.actions.UpdateUmlModelAction.updateUmlM odel(),UpdateUmlModelAction.java:135,
>> org.faktorips.uml.ui.actions.UpdateUmlModelAction.run(IProgr essMonitor),UpdateUmlModelAction.java:70,
>> org.eclipse.jface.operation.ModalContext$ModalContextThread. run(),ModalContext.java:121,
>>
>>
>
>
|
|
| |
Re: Memory leak in uml2 ? [message #478059 is a reply to message #478058] |
Wed, 10 December 2008 16:11 |
Rafael Chaves Messages: 362 Registered: July 2009 |
Senior Member |
|
|
Alex, are you sure you are unloading all the resources in the resource
set? See this thread from the old eclipse.tools.uml2 newsgroup:
http://dev.eclipse.org/newslists/news.eclipse.tools.uml2/msg 04014.html
In a follow-up post to that one, I fixed my test case to unload all
resources in the resource set:
for (Iterator i = resourceSet.getResources().iterator(); i.hasNext();) {
Resource current = (Resource) i.next();
current.unload();
i.remove();
}
That would include resources loaded explicitly and implicitly.
Do you still see a leak in that case?
Also: instead of a 12 test cases, it would be better if you could run
your test case a thousand times. If there is a leak, it will probably
cause the test suite to fail at some point.
Cheers,
Rafael
http://abstratt.com/blog/
Alex wrote:
> Hi James
>
> The problem seems to be only with my JUnit tests. I have tried my
> application ... the memory consumption increases every time I start my
> export but that is just because GC is not running. If I export often
> enough the GC gives free everything again or when I start GC manual over
> the Eclipse gui.
>
> But with test cases more and more memory is needed with every test that
> is not given free. When the memory of the VM is full no Exception occurs
> but it takes longer and longer for a test to complete (6, 15, 16, 80,
> 180 seconds and so on). It seems the GC has fewer and fewer stuff to
> collect and needs to run longer and longer trying to find anything to free.
>
> I isolated the problem from my plugin and created an eclipse plugin
> project with a Junit Test Case and my profile and primitive library.
>
> In this Test Case I just create a platform project, a uml model, load my
> profile and my primitive types library, create some classes with
> attributes and applying stereotypes. In tearDown I unload my resources
> and close delete the platform project.
>
> I've uploaded to my server, you can import it as eclipse plugin project
> and run yourself. If you take a look into your system resource
> consumption panel you see that after each test method some megabytes are
> lost that are not being freed until the complete test run ends.
>
> Here is the project: http://www.starspring.de/uml2test.zip
>
|
|
|
control command and stereotypes [message #478060 is a reply to message #478059] |
Wed, 10 December 2008 22:13 |
|
Hi all,
when applying the "control" command on a package (or a component)
containing elements with applyed stereotypes the new sub-model does not
show those applied stereotypes.
When I open it as text file I can see that neither profile application
nor applied stereotypes are embedded int this file. In fact the applied
stereotypes are not lost but are simply stored (and visible) in the
parent file.
I think it can lead to confusion as the end user expects to see applied
stereotypes in the controlled resource in the same way he sees them in
the parent resource.
This was the first point but there is another one: how to apply
stereotypes in the controlled resource as profile data are not present?
If it is a package, then you can load the profile as an additional
resource and then apply it to the package. But what about a component?
As it is not possible to apply profiles on components, you will never be
able to apply stereotypes in a controlled UML component.
And this is for me a strong restriction...
So, I have a suggestion : when applying the "control" command on a model
element, perhaps we could have an option to ask the end user if he (she)
would like to keep a reference on the parent model in the controlled
resource.
If yes, the controlled resource would then access to the applied
profiles and to the applied stereotypes and would allow the user to both
see and apply stereotypes.
regards
raphaël
|
|
|
Re: control command and stereotypes [message #478061 is a reply to message #478060] |
Thu, 11 December 2008 01:31 |
Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, raphaël,
I agree with you that it would be more intuitive if the UML editor
customized the "Control" action to move stereotype instances to the new
resource, that are applied to elements that are move to that resource.
However, I don't think that you can expect an element (component or
otherwise) in a controlled resource to "work" without its containment
chain (in the parent resources) also being loaded. Composition in UML
is very strong dependency of a contained object on its parent, and one
aspect of this is profile applications, as you have observed.
Every element that is not a package must be contained, ultimately, in a
package because only packages may be root elements of the tree. Thus, a
component is not valid if it is not in a containing package, and when
that package is present, then naturally it could have profiles applied.
Cheers,
Christian
raphaël Faudou wrote:
> Hi all,
>
> when applying the "control" command on a package (or a component)
> containing elements with applyed stereotypes the new sub-model does not
> show those applied stereotypes.
> When I open it as text file I can see that neither profile application
> nor applied stereotypes are embedded int this file. In fact the applied
> stereotypes are not lost but are simply stored (and visible) in the
> parent file.
> I think it can lead to confusion as the end user expects to see applied
> stereotypes in the controlled resource in the same way he sees them in
> the parent resource.
>
> This was the first point but there is another one: how to apply
> stereotypes in the controlled resource as profile data are not present?
> If it is a package, then you can load the profile as an additional
> resource and then apply it to the package. But what about a component?
> As it is not possible to apply profiles on components, you will never be
> able to apply stereotypes in a controlled UML component.
> And this is for me a strong restriction...
>
> So, I have a suggestion : when applying the "control" command on a model
> element, perhaps we could have an option to ask the end user if he (she)
> would like to keep a reference on the parent model in the controlled
> resource.
> If yes, the controlled resource would then access to the applied
> profiles and to the applied stereotypes and would allow the user to both
> see and apply stereotypes.
>
> regards
> raphaël
>
>
>
>
|
|
|
Re: control command and stereotypes [message #478062 is a reply to message #478061] |
Thu, 11 December 2008 08:32 |
|
Hi Christian,
thanks for those tips.
Now my question is rather about methodology. What I like with components
is that you can build the product tree and it is probably from this
tree that you would like to split your model and dispatch pieces to
several subcontractors.
Until recently I wwas used to build this tree with packages and it there
were no problems except that I had to create one UML component for each
package to get the whole picture with component diagrams.
Would you have a suggestion or recommendation to avoid such a
duplication of semantics while dealing with profiles in a distributed model?
Cheers
raphaël
Christian W. Damus a écrit :
> Hi, raphaël,
>
> I agree with you that it would be more intuitive if the UML editor
> customized the "Control" action to move stereotype instances to the new
> resource, that are applied to elements that are move to that resource.
>
> However, I don't think that you can expect an element (component or
> otherwise) in a controlled resource to "work" without its containment
> chain (in the parent resources) also being loaded. Composition in UML
> is very strong dependency of a contained object on its parent, and one
> aspect of this is profile applications, as you have observed.
>
> Every element that is not a package must be contained, ultimately, in a
> package because only packages may be root elements of the tree. Thus, a
> component is not valid if it is not in a containing package, and when
> that package is present, then naturally it could have profiles applied.
>
> Cheers,
>
> Christian
>
> raphaël Faudou wrote:
>> Hi all,
>>
>> when applying the "control" command on a package (or a component)
>> containing elements with applyed stereotypes the new sub-model does not
>> show those applied stereotypes.
>> When I open it as text file I can see that neither profile application
>> nor applied stereotypes are embedded int this file. In fact the
>> applied stereotypes are not lost but are simply stored (and visible)
>> in the parent file.
>> I think it can lead to confusion as the end user expects to see
>> applied stereotypes in the controlled resource in the same way he sees
>> them in the parent resource.
>>
>> This was the first point but there is another one: how to apply
>> stereotypes in the controlled resource as profile data are not present?
>> If it is a package, then you can load the profile as an additional
>> resource and then apply it to the package. But what about a component?
>> As it is not possible to apply profiles on components, you will never
>> be able to apply stereotypes in a controlled UML component.
>> And this is for me a strong restriction...
>>
>> So, I have a suggestion : when applying the "control" command on a
>> model element, perhaps we could have an option to ask the end user if
>> he (she) would like to keep a reference on the parent model in the
>> controlled resource.
>> If yes, the controlled resource would then access to the applied
>> profiles and to the applied stereotypes and would allow the user to
>> both see and apply stereotypes.
>>
>> regards
>> raphaël
>>
>>
>>
>>
|
|
| | |
Re: control command and stereotypes - component hierarchy [message #478103 is a reply to message #478087] |
Mon, 05 January 2009 10:44 |
|
Hi all,
Happy new year !
Well, probably my prvious message was not very clear.
I try to explain my needs through a simple example.
Let us consider we have a system with 3 subsystems that communicate each
other.
I would like to show this communication : my idea is to use the
component diagram with subystems modelled as UML components with
"subsystem" stereotype.
Then,I would like to distribute those 3 subsystems to 3 different teams.
The most natural idea that comes to my mind is to control each UML
component and to give those new resources to the teams. Isn't it? Then I
loose the visibility of steretoype application...
As alternative I can create 3 packages (one for each subsystem) and then
control those packages but I find it redundant with the existing UML
components.
Recursively the same thing happens at a lower level. Let us suppose that
my first subsystem is decomposed into 4 components. I would like to
outsource two of those components.
Should I model those components as packages because package is the
element used to split resources?
I would prefer using UML components as they are the main natural
elements for product decomposition (Work Breadkwon Structure)...
Any piece of advice?
thanks
raphaël
Kenn Hussey a écrit :
> Raphaël,
>
> While components, like packages, do have packaging behavior, the semantics
> of components are are quite different from those of packages, so I'm not
> sure that there is much duplication of semantics here. If what you're
> looking to do it partition a package hierarchy across several resources, I'd
> recommend ensuring that the (root) package to which the profile is applied
> is loaded when working with a (nested) resource in which the component
> exists, as Christian has suggested...
>
> Kenn
>
> "raphaël Faudou" <raphael.faudou@atosorigin.com> wrote in message
> news:ghqj6t$qna$1@build.eclipse.org...
> Hi Christian,
>
> thanks for those tips.
> Now my question is rather about methodology. What I like with components
> is that you can build the product tree and it is probably from this
> tree that you would like to split your model and dispatch pieces to
> several subcontractors.
> Until recently I wwas used to build this tree with packages and it there
> were no problems except that I had to create one UML component for each
> package to get the whole picture with component diagrams.
> Would you have a suggestion or recommendation to avoid such a
> duplication of semantics while dealing with profiles in a distributed model?
>
> Cheers
> raphaël
>
> Christian W. Damus a écrit :
>> Hi, raphaël,
>>
>> I agree with you that it would be more intuitive if the UML editor
>> customized the "Control" action to move stereotype instances to the new
>> resource, that are applied to elements that are move to that resource.
>>
>> However, I don't think that you can expect an element (component or
>> otherwise) in a controlled resource to "work" without its containment
>> chain (in the parent resources) also being loaded. Composition in UML is
>> very strong dependency of a contained object on its parent, and one aspect
>> of this is profile applications, as you have observed.
>>
>> Every element that is not a package must be contained, ultimately, in a
>> package because only packages may be root elements of the tree. Thus, a
>> component is not valid if it is not in a containing package, and when that
>> package is present, then naturally it could have profiles applied.
>>
>> Cheers,
>>
>> Christian
>>
>> raphaël Faudou wrote:
>>> Hi all,
>>>
>>> when applying the "control" command on a package (or a component)
>>> containing elements with applyed stereotypes the new sub-model does not
>>> show those applied stereotypes.
>>> When I open it as text file I can see that neither profile application
>>> nor applied stereotypes are embedded int this file. In fact the applied
>>> stereotypes are not lost but are simply stored (and visible) in the
>>> parent file.
>>> I think it can lead to confusion as the end user expects to see applied
>>> stereotypes in the controlled resource in the same way he sees them in
>>> the parent resource.
>>>
>>> This was the first point but there is another one: how to apply
>>> stereotypes in the controlled resource as profile data are not present?
>>> If it is a package, then you can load the profile as an additional
>>> resource and then apply it to the package. But what about a component?
>>> As it is not possible to apply profiles on components, you will never be
>>> able to apply stereotypes in a controlled UML component.
>>> And this is for me a strong restriction...
>>>
>>> So, I have a suggestion : when applying the "control" command on a model
>>> element, perhaps we could have an option to ask the end user if he (she)
>>> would like to keep a reference on the parent model in the controlled
>>> resource.
>>> If yes, the controlled resource would then access to the applied profiles
>>> and to the applied stereotypes and would allow the user to both see and
>>> apply stereotypes.
>>>
>>> regards
>>> raphaël
>>>
>>>
>>>
>>>
>
>
|
|
|
Re: control command and stereotypes - component hierarchy [message #478104 is a reply to message #478103] |
Mon, 05 January 2009 13:32 |
Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Raphaël,
One consideration when sharing partial models in this way is the impact
that it has on the effective qualified names of elements. If you do not
make the containing chain of namespaces available to your consumers,
then the qualified names will be missing some segments.
This could be an issue for expression languages like OCL. Portability
of expressions from the partial model to the full model context (and,
esp., vice-versa) could be a problem.
It would probably be a good idea to ensure that, when re-distributing
only one of the components, that its containing package(s) be included,
as well, to ensure the integrity of names. This would mean, I suppose,
that these packages should only contain elements by proxy and that users
of the partial models will see several unresolved proxies in the content
tree. A robust UML application should be able to handle that.
Of course, it isn't necessarily the case that names are important to
your application ... I'm just waving my hands. :-)
Also, your example indicates that these subsystems communicate with each
other. If that implies some kind of dependencies between them, then
they don't stand on their own as complete models, anyway. OTOH, this
communication might be defined at a higher level of abstraction, in
protocols that these components implement without any such coupling
between them. Now my hands are waving frantically. :-D
Cheers,
Christian
raphaël Faudou wrote:
> Hi all,
> Happy new year !
>
> Well, probably my prvious message was not very clear.
> I try to explain my needs through a simple example.
>
> Let us consider we have a system with 3 subsystems that communicate each
> other.
> I would like to show this communication : my idea is to use the
> component diagram with subystems modelled as UML components with
> "subsystem" stereotype.
> Then,I would like to distribute those 3 subsystems to 3 different teams.
>
> The most natural idea that comes to my mind is to control each UML
> component and to give those new resources to the teams. Isn't it? Then I
> loose the visibility of steretoype application...
>
> As alternative I can create 3 packages (one for each subsystem) and then
> control those packages but I find it redundant with the existing UML
> components.
>
> Recursively the same thing happens at a lower level. Let us suppose that
> my first subsystem is decomposed into 4 components. I would like to
> outsource two of those components.
> Should I model those components as packages because package is the
> element used to split resources?
> I would prefer using UML components as they are the main natural
> elements for product decomposition (Work Breadkwon Structure)...
> Any piece of advice?
> thanks
> raphaël
>
-----8<-----
|
|
|
Re: control command and stereotypes - component hierarchy [message #478108 is a reply to message #478104] |
Tue, 06 January 2009 10:44 |
|
Christian W. Damus a écrit :
> Hi, Raphaël,
>
> One consideration when sharing partial models in this way is the impact
> that it has on the effective qualified names of elements. If you do not
> make the containing chain of namespaces available to your consumers,
> then the qualified names will be missing some segments.
>
> This could be an issue for expression languages like OCL. Portability
> of expressions from the partial model to the full model context (and,
> esp., vice-versa) could be a problem.
>
> It would probably be a good idea to ensure that, when re-distributing
> only one of the components, that its containing package(s) be included,
> as well, to ensure the integrity of names. This would mean, I suppose,
> that these packages should only contain elements by proxy and that users
> of the partial models will see several unresolved proxies in the content
> tree. A robust UML application should be able to handle that.
>
> Of course, it isn't necessarily the case that names are important to
> your application ... I'm just waving my hands. :-)
>
> Also, your example indicates that these subsystems communicate with each
> other. If that implies some kind of dependencies between them, then
> they don't stand on their own as complete models, anyway. OTOH, this
> communication might be defined at a higher level of abstraction, in
> protocols that these components implement without any such coupling
> between them. Now my hands are waving frantically. :-D
FWIW, Topcased 2.0 introduced new operations to better support these
kinds of use cases (splitting a model in sub-models which will be worked
on independently, and merging the new versions back).
It introduces Export/Import operations, which can be seen as extended
versions of Control/Uncontrol. The main difference is that an exported
sub-model will stand alone: everything it depends on (including
stereotypes) is copied in a new "cache" resource, so that the exported
sub-model and its cache are totally self-contained.
It is not perfect: there are some issues with ProfileApplications, and
as you mentionned we lose information on the qualified name of elements.
Basically, the exported model (+ its cache) is technically standalone,
but the semantics can never be exactly the same because as you said the
semantics of UML elements depdend on the context they are used in (e.g.
the name of their parent, the profiles applied 5 levels above, etc.).
Pierre-Charles David - Obeo
Need training or professional services for Sirius?
http://www.obeodesigner.com/sirius
|
|
| |
Re: control command and stereotypes - component hierarchy [message #478112 is a reply to message #478111] |
Wed, 07 January 2009 16:25 |
|
Hi Kenn, hi Christian,
Thank you very much for the attention you paid to my question and for
those answers.
I'm going to have a look at the API as you suggest and I will try to
enforce the loading of the parent model when controlling one component.
Cheers
raphaël
Kenn Hussey a écrit :
> Raphaël,
>
> I would suggest having the three components directly or indirectly owned by
> the same package/model and apply the profile to that package/model. When the
> components are separated into separate resources ("controlled"), their
> corresponding stereotype applications should be separated with them (I know
> the sample UML editor does not do this currently, but the APIs are there).
> Then, when a given team wants to work with their component, they need only
> load/open the root resource (containing the owning package/model) and the
> resource containing their component.
>
> As Christian has pointed out, it's possible that the components might have
> references between them, which might mean that one or more of the other
> resources (containing the other components) would need to be loadded/opened,
> but if a source control system were being used, only the resource containing
> the team's particular component need be checked out (committed),
> dependening, of course, on the nature of the changes and the potential
> impact on the other components.
>
> Kenn
>
> "raphaël Faudou" <raphael.faudou@atosorigin.com> wrote in message
> news:4961E49A.5060006@atosorigin.com...
> Hi all,
> Happy new year !
>
> Well, probably my prvious message was not very clear.
> I try to explain my needs through a simple example.
>
> Let us consider we have a system with 3 subsystems that communicate each
> other.
> I would like to show this communication : my idea is to use the
> component diagram with subystems modelled as UML components with
> "subsystem" stereotype.
> Then,I would like to distribute those 3 subsystems to 3 different teams.
>
> The most natural idea that comes to my mind is to control each UML
> component and to give those new resources to the teams. Isn't it? Then I
> loose the visibility of steretoype application...
>
> As alternative I can create 3 packages (one for each subsystem) and then
> control those packages but I find it redundant with the existing UML
> components.
>
> Recursively the same thing happens at a lower level. Let us suppose that
> my first subsystem is decomposed into 4 components. I would like to
> outsource two of those components.
> Should I model those components as packages because package is the
> element used to split resources?
> I would prefer using UML components as they are the main natural
> elements for product decomposition (Work Breadkwon Structure)...
> Any piece of advice?
> thanks
> raphaël
>
>
> Kenn Hussey a écrit :
>> Raphaël,
>>
>> While components, like packages, do have packaging behavior, the semantics
>> of components are are quite different from those of packages, so I'm not
>> sure that there is much duplication of semantics here. If what you're
>> looking to do it partition a package hierarchy across several resources,
>> I'd recommend ensuring that the (root) package to which the profile is
>> applied is loaded when working with a (nested) resource in which the
>> component exists, as Christian has suggested...
>>
>> Kenn
>>
>> "raphaël Faudou" <raphael.faudou@atosorigin.com> wrote in message
>> news:ghqj6t$qna$1@build.eclipse.org...
>> Hi Christian,
>>
>> thanks for those tips.
>> Now my question is rather about methodology. What I like with components
>> is that you can build the product tree and it is probably from this
>> tree that you would like to split your model and dispatch pieces to
>> several subcontractors.
>> Until recently I wwas used to build this tree with packages and it there
>> were no problems except that I had to create one UML component for each
>> package to get the whole picture with component diagrams.
>> Would you have a suggestion or recommendation to avoid such a
>> duplication of semantics while dealing with profiles in a distributed
>> model?
>>
>> Cheers
>> raphaël
>>
>> Christian W. Damus a écrit :
>>> Hi, raphaël,
>>>
>>> I agree with you that it would be more intuitive if the UML editor
>>> customized the "Control" action to move stereotype instances to the new
>>> resource, that are applied to elements that are move to that resource.
>>>
>>> However, I don't think that you can expect an element (component or
>>> otherwise) in a controlled resource to "work" without its containment
>>> chain (in the parent resources) also being loaded. Composition in UML is
>>> very strong dependency of a contained object on its parent, and one
>>> aspect of this is profile applications, as you have observed.
>>>
>>> Every element that is not a package must be contained, ultimately, in a
>>> package because only packages may be root elements of the tree. Thus, a
>>> component is not valid if it is not in a containing package, and when
>>> that package is present, then naturally it could have profiles applied.
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>> raphaël Faudou wrote:
>>>> Hi all,
>>>>
>>>> when applying the "control" command on a package (or a component)
>>>> containing elements with applyed stereotypes the new sub-model does not
>>>> show those applied stereotypes.
>>>> When I open it as text file I can see that neither profile application
>>>> nor applied stereotypes are embedded int this file. In fact the applied
>>>> stereotypes are not lost but are simply stored (and visible) in the
>>>> parent file.
>>>> I think it can lead to confusion as the end user expects to see applied
>>>> stereotypes in the controlled resource in the same way he sees them in
>>>> the parent resource.
>>>>
>>>> This was the first point but there is another one: how to apply
>>>> stereotypes in the controlled resource as profile data are not present?
>>>> If it is a package, then you can load the profile as an additional
>>>> resource and then apply it to the package. But what about a component?
>>>> As it is not possible to apply profiles on components, you will never be
>>>> able to apply stereotypes in a controlled UML component.
>>>> And this is for me a strong restriction...
>>>>
>>>> So, I have a suggestion : when applying the "control" command on a model
>>>> element, perhaps we could have an option to ask the end user if he (she)
>>>> would like to keep a reference on the parent model in the controlled
>>>> resource.
>>>> If yes, the controlled resource would then access to the applied
>>>> profiles and to the applied stereotypes and would allow the user to both
>>>> see and apply stereotypes.
>>>>
>>>> regards
>>>> raphaël
>>>>
>>>>
>>>>
>>>>
>>
>
>
|
|
| | |
Re: Memory leak in uml2 ? [message #627271 is a reply to message #478053] |
Tue, 09 December 2008 11:11 |
Ed Merks Messages: 33218 Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------030809070907090906040609
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Alex,
You mentioned:
None of my classes is there, but for example
org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList
still refers to StereotypeImpls
A StereotypeImpl isn't an adapter though. Can you provide a bit more
detail about what specific adapter is still referring to your Stereotype
object?
It seems to me that UML's cache adapter could potentially be a problem.
You could always try calling Resource.unload on each resource you've
loaded and see it that helps...
Alex wrote:
> No I don't. Is it maybe required to close uml resources in some way?
>
--------------030809070907090906040609
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Alex,<br>
<br>
You mentioned:<br>
<blockquote>None of my classes is there, but for example
org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList still
refers to StereotypeImpls
<br>
</blockquote>
A StereotypeImpl isn't an adapter though.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: Memory leak in uml2 ? [message #627272 is a reply to message #478054] |
Tue, 09 December 2008 13:38 |
Alexander Weickmann Messages: 33 Registered: July 2009 |
Member |
|
|
I call unload on every resource I loaded now. It didn't get better but
simpler it seems.
I collected actual data with JProbe and now I have 2339 of Element in the
heap.
They all have only 1 referrer:
org.eclipse.emf.ecore.util.EObjectResolvingEList
I have also an allocation trace for that, it seems the problem starts with
the applyStereotype method:
Method,Source,
java.lang.reflect.Array.newArray(Class, int),Array.java:Not Available,
java.lang.reflect.Array.newInstance(Class, int),Array.java:52,
org.eclipse.emf.ecore.util.EcoreEList.newData(int),EcoreELis t.java:63,
org.eclipse.emf.common.util.BasicEList.grow(int),BasicEList. java:1099,
org.eclipse.emf.common.util.BasicEList.addUnique(int,
Object),BasicEList.java:686,
org.eclipse.emf.common.notify.impl.NotifyingListImpl.doAddUn ique(int,
Object),NotifyingListImpl.java:393,
org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUniq ue(int,
Object),NotifyingListImpl.java:351,
org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.setValue(EObjec t,
EStructuralFeature, Object, int),XMLHelperImpl.java:1183,
org.eclipse.emf.ecore.xmi.impl.XMLHandler.setFeatureValue(EO bject,
EStructuralFeature, Object, int),XMLHandler.java:2643,
org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleForwardRefer ences(boolean),XMLHandler.java:1135,
org.eclipse.emf.ecore.xmi.impl.XMLHandler.endDocument(),XMLH andler.java:1214,
org.eclipse.uml2.uml.internal.resource.UMLHandler.endDocumen t(),UMLHandler.java:55,
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .endDocument(Augmentations),AbstractSAXParser.java:737,
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl.scanDocument(boolean),XMLDocumentFragmentScannerI mpl.java:515,
com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(boolean),XML11Configuration.java:807,
com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(XMLInputSource),XML11Configuration.java:737,
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(X MLInputSource),XMLParser.java:107,
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .parse(InputSource),AbstractSAXParser.java:1205,
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSA XParser.parse(InputSource),SAXParserImpl.java:522,
javax.xml.parsers.SAXParser.parse(InputSource,
DefaultHandler),SAXParser.java:395,
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLResource, InputStream,
Map),XMLLoadImpl.java:181,
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(InputS tream,
Map),XMLResourceImpl.java:180,
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(InputS tream,
Map),ResourceImpl.java:1445,
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Map),R esourceImpl.java:1241,
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(Resource),ResourceSetImpl.java:255,
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo adHelper(Resource),ResourceSetImpl.java:270,
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(URI,
boolean),ResourceSetImpl.java:397,
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getEObje ct(URI,
boolean),ResourceSetImpl.java:216,
org.eclipse.emf.ecore.util.EcoreUtil.resolve(EObject,
ResourceSet),EcoreUtil.java:202,
org.eclipse.emf.ecore.util.EcoreUtil.resolve(EObject,
EObject),EcoreUtil.java:262,
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eResolveProxy(In ternalEObject),BasicEObjectImpl.java:1470,
org.eclipse.uml2.uml.internal.impl.StructuralFeatureImpl.get Type(),StructuralFeatureImpl.java:216,
org.eclipse.uml2.uml.internal.operations.ElementOperations.g etExtension(Element,
Stereotype),ElementOperations.java:1168,
org.eclipse.uml2.uml.internal.operations.ElementOperations.a pplyStereotype(Element,
Stereotype),ElementOperations.java:1407,
org.eclipse.uml2.uml.internal.impl.ElementImpl.applyStereoty pe(Stereotype),ElementImpl.java:501,
org.faktorips.uml.core.internal.ClassDelta.applyToUmlModel(M ap),ClassDelta.java:1055,
org.faktorips.uml.core.internal.PackageDelta.applyClassDelta sToUmlModel(Map),PackageDelta.java:837,
org.faktorips.uml.core.internal.ModelDelta.applyPackageDelta sToUmlModel(),ModelDelta.java:493,
org.faktorips.uml.core.internal.ModelDelta.applyToUmlModel() ,ModelDelta.java:464,
org.faktorips.uml.core.ModelSynchronizer.synchronizeUmlModel (),ModelSynchronizer.java:168,
org.faktorips.uml.ui.actions.UpdateUmlModelAction.updateUmlM odel(),UpdateUmlModelAction.java:135,
org.faktorips.uml.ui.actions.UpdateUmlModelAction.run(IProgr essMonitor),UpdateUmlModelAction.java:70,
org.eclipse.jface.operation.ModalContext$ModalContextThread. run(),ModalContext.java:121,
|
|
|
Re: Memory leak in uml2 ? [message #627273 is a reply to message #478055] |
Tue, 09 December 2008 14:59 |
james bruck Messages: 1724 Registered: July 2009 |
Senior Member |
|
|
Hi Alex,
I don't believe this is a result of the uml cache adapter ( which I was also
thinking to be the cause - and Ed mentioned ).
You mentioned in your original posting that you are doing an "export", do
you see the same problem just opening and closing the model?
Stereotypes use Dynamic EMF, do you just see the issue with just stereotypes
or other types?
Can you post a small model with exact steps to reproduce. I would like to
observe this with the memory profile tools we use.
Cheers,
- James.
"Alex " <eistoeter@gmx.de> wrote in message
news:b7264e17e716ce5ed533604cd9d6ba52$1@www.eclipse.org...
>I call unload on every resource I loaded now. It didn't get better but
>simpler it seems.
>
> I collected actual data with JProbe and now I have 2339 of Element in the
> heap.
> They all have only 1 referrer:
> org.eclipse.emf.ecore.util.EObjectResolvingEList
>
> I have also an allocation trace for that, it seems the problem starts with
> the applyStereotype method:
>
> Method,Source,
> java.lang.reflect.Array.newArray(Class, int),Array.java:Not Available,
> java.lang.reflect.Array.newInstance(Class, int),Array.java:52,
> org.eclipse.emf.ecore.util.EcoreEList.newData(int),EcoreELis t.java:63,
> org.eclipse.emf.common.util.BasicEList.grow(int),BasicEList. java:1099,
> org.eclipse.emf.common.util.BasicEList.addUnique(int,
> Object),BasicEList.java:686,
> org.eclipse.emf.common.notify.impl.NotifyingListImpl.doAddUn ique(int,
> Object),NotifyingListImpl.java:393,
> org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUniq ue(int,
> Object),NotifyingListImpl.java:351,
> org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.setValue(EObjec t,
> EStructuralFeature, Object, int),XMLHelperImpl.java:1183,
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.setFeatureValue(EO bject,
> EStructuralFeature, Object, int),XMLHandler.java:2643,
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleForwardRefer ences(boolean),XMLHandler.java:1135,
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.endDocument(),XMLH andler.java:1214,
> org.eclipse.uml2.uml.internal.resource.UMLHandler.endDocumen t(),UMLHandler.java:55,
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .endDocument(Augmentations),AbstractSAXParser.java:737,
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl.scanDocument(boolean),XMLDocumentFragmentScannerI mpl.java:515,
> com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(boolean),XML11Configuration.java:807,
> com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(XMLInputSource),XML11Configuration.java:737,
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(X MLInputSource),XMLParser.java:107,
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .parse(InputSource),AbstractSAXParser.java:1205,
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSA XParser.parse(InputSource),SAXParserImpl.java:522,
> javax.xml.parsers.SAXParser.parse(InputSource,
> DefaultHandler),SAXParser.java:395,
> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLResource, InputStream,
> Map),XMLLoadImpl.java:181,
> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(InputS tream,
> Map),XMLResourceImpl.java:180,
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(InputS tream,
> Map),ResourceImpl.java:1445,
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Map),R esourceImpl.java:1241,
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(Resource),ResourceSetImpl.java:255,
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo adHelper(Resource),ResourceSetImpl.java:270,
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(URI,
> boolean),ResourceSetImpl.java:397,
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getEObje ct(URI,
> boolean),ResourceSetImpl.java:216,
> org.eclipse.emf.ecore.util.EcoreUtil.resolve(EObject,
> ResourceSet),EcoreUtil.java:202,
> org.eclipse.emf.ecore.util.EcoreUtil.resolve(EObject,
> EObject),EcoreUtil.java:262,
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eResolveProxy(In ternalEObject),BasicEObjectImpl.java:1470,
> org.eclipse.uml2.uml.internal.impl.StructuralFeatureImpl.get Type(),StructuralFeatureImpl.java:216,
> org.eclipse.uml2.uml.internal.operations.ElementOperations.g etExtension(Element,
> Stereotype),ElementOperations.java:1168,
> org.eclipse.uml2.uml.internal.operations.ElementOperations.a pplyStereotype(Element,
> Stereotype),ElementOperations.java:1407,
> org.eclipse.uml2.uml.internal.impl.ElementImpl.applyStereoty pe(Stereotype),ElementImpl.java:501,
> org.faktorips.uml.core.internal.ClassDelta.applyToUmlModel(M ap),ClassDelta.java:1055,
> org.faktorips.uml.core.internal.PackageDelta.applyClassDelta sToUmlModel(Map),PackageDelta.java:837,
> org.faktorips.uml.core.internal.ModelDelta.applyPackageDelta sToUmlModel(),ModelDelta.java:493,
> org.faktorips.uml.core.internal.ModelDelta.applyToUmlModel() ,ModelDelta.java:464,
> org.faktorips.uml.core.ModelSynchronizer.synchronizeUmlModel (),ModelSynchronizer.java:168,
> org.faktorips.uml.ui.actions.UpdateUmlModelAction.updateUmlM odel(),UpdateUmlModelAction.java:135,
> org.faktorips.uml.ui.actions.UpdateUmlModelAction.run(IProgr essMonitor),UpdateUmlModelAction.java:70,
> org.eclipse.jface.operation.ModalContext$ModalContextThread. run(),ModalContext.java:121,
>
>
|
|
|
Re: Memory leak in uml2 ? [message #627274 is a reply to message #478056] |
Tue, 09 December 2008 17:35 |
james bruck Messages: 1724 Registered: July 2009 |
Senior Member |
|
|
Hi Alex,
Another idea would be to provide a trace from YourKit - I believe they have
a 10 day free license.
Narrowing this problem to straight opensource UML2 or EMF with a
reproduceable scenario would be the key.
Cheers,
- James.
"James Bruck" <jbruck@ca.ibm.com> wrote in message
news:ghm117$67v$1@build.eclipse.org...
> Hi Alex,
>
> I don't believe this is a result of the uml cache adapter ( which I was
> also thinking to be the cause - and Ed mentioned ).
> You mentioned in your original posting that you are doing an "export", do
> you see the same problem just opening and closing the model?
> Stereotypes use Dynamic EMF, do you just see the issue with just
> stereotypes or other types?
> Can you post a small model with exact steps to reproduce. I would like to
> observe this with the memory profile tools we use.
>
> Cheers,
> - James.
>
> "Alex " <eistoeter@gmx.de> wrote in message
> news:b7264e17e716ce5ed533604cd9d6ba52$1@www.eclipse.org...
>>I call unload on every resource I loaded now. It didn't get better but
>>simpler it seems.
>>
>> I collected actual data with JProbe and now I have 2339 of Element in the
>> heap.
>> They all have only 1 referrer:
>> org.eclipse.emf.ecore.util.EObjectResolvingEList
>>
>> I have also an allocation trace for that, it seems the problem starts
>> with the applyStereotype method:
>>
>> Method,Source,
>> java.lang.reflect.Array.newArray(Class, int),Array.java:Not Available,
>> java.lang.reflect.Array.newInstance(Class, int),Array.java:52,
>> org.eclipse.emf.ecore.util.EcoreEList.newData(int),EcoreELis t.java:63,
>> org.eclipse.emf.common.util.BasicEList.grow(int),BasicEList. java:1099,
>> org.eclipse.emf.common.util.BasicEList.addUnique(int,
>> Object),BasicEList.java:686,
>> org.eclipse.emf.common.notify.impl.NotifyingListImpl.doAddUn ique(int,
>> Object),NotifyingListImpl.java:393,
>> org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUniq ue(int,
>> Object),NotifyingListImpl.java:351,
>> org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.setValue(EObjec t,
>> EStructuralFeature, Object, int),XMLHelperImpl.java:1183,
>> org.eclipse.emf.ecore.xmi.impl.XMLHandler.setFeatureValue(EO bject,
>> EStructuralFeature, Object, int),XMLHandler.java:2643,
>> org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleForwardRefer ences(boolean),XMLHandler.java:1135,
>> org.eclipse.emf.ecore.xmi.impl.XMLHandler.endDocument(),XMLH andler.java:1214,
>> org.eclipse.uml2.uml.internal.resource.UMLHandler.endDocumen t(),UMLHandler.java:55,
>> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .endDocument(Augmentations),AbstractSAXParser.java:737,
>> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl.scanDocument(boolean),XMLDocumentFragmentScannerI mpl.java:515,
>> com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(boolean),XML11Configuration.java:807,
>> com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(XMLInputSource),XML11Configuration.java:737,
>> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(X MLInputSource),XMLParser.java:107,
>> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .parse(InputSource),AbstractSAXParser.java:1205,
>> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSA XParser.parse(InputSource),SAXParserImpl.java:522,
>> javax.xml.parsers.SAXParser.parse(InputSource,
>> DefaultHandler),SAXParser.java:395,
>> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLResource, InputStream,
>> Map),XMLLoadImpl.java:181,
>> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(InputS tream,
>> Map),XMLResourceImpl.java:180,
>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(InputS tream,
>> Map),ResourceImpl.java:1445,
>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Map),R esourceImpl.java:1241,
>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(Resource),ResourceSetImpl.java:255,
>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo adHelper(Resource),ResourceSetImpl.java:270,
>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(URI,
>> boolean),ResourceSetImpl.java:397,
>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getEObje ct(URI,
>> boolean),ResourceSetImpl.java:216,
>> org.eclipse.emf.ecore.util.EcoreUtil.resolve(EObject,
>> ResourceSet),EcoreUtil.java:202,
>> org.eclipse.emf.ecore.util.EcoreUtil.resolve(EObject,
>> EObject),EcoreUtil.java:262,
>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eResolveProxy(In ternalEObject),BasicEObjectImpl.java:1470,
>> org.eclipse.uml2.uml.internal.impl.StructuralFeatureImpl.get Type(),StructuralFeatureImpl.java:216,
>> org.eclipse.uml2.uml.internal.operations.ElementOperations.g etExtension(Element,
>> Stereotype),ElementOperations.java:1168,
>> org.eclipse.uml2.uml.internal.operations.ElementOperations.a pplyStereotype(Element,
>> Stereotype),ElementOperations.java:1407,
>> org.eclipse.uml2.uml.internal.impl.ElementImpl.applyStereoty pe(Stereotype),ElementImpl.java:501,
>> org.faktorips.uml.core.internal.ClassDelta.applyToUmlModel(M ap),ClassDelta.java:1055,
>> org.faktorips.uml.core.internal.PackageDelta.applyClassDelta sToUmlModel(Map),PackageDelta.java:837,
>> org.faktorips.uml.core.internal.ModelDelta.applyPackageDelta sToUmlModel(),ModelDelta.java:493,
>> org.faktorips.uml.core.internal.ModelDelta.applyToUmlModel() ,ModelDelta.java:464,
>> org.faktorips.uml.core.ModelSynchronizer.synchronizeUmlModel (),ModelSynchronizer.java:168,
>> org.faktorips.uml.ui.actions.UpdateUmlModelAction.updateUmlM odel(),UpdateUmlModelAction.java:135,
>> org.faktorips.uml.ui.actions.UpdateUmlModelAction.run(IProgr essMonitor),UpdateUmlModelAction.java:70,
>> org.eclipse.jface.operation.ModalContext$ModalContextThread. run(),ModalContext.java:121,
>>
>>
>
>
|
|
| |
Re: Memory leak in uml2 ? [message #627276 is a reply to message #478058] |
Wed, 10 December 2008 16:11 |
Rafael Chaves Messages: 362 Registered: July 2009 |
Senior Member |
|
|
Alex, are you sure you are unloading all the resources in the resource
set? See this thread from the old eclipse.tools.uml2 newsgroup:
http://dev.eclipse.org/newslists/news.eclipse.tools.uml2/msg 04014.html
In a follow-up post to that one, I fixed my test case to unload all
resources in the resource set:
for (Iterator i = resourceSet.getResources().iterator(); i.hasNext();) {
Resource current = (Resource) i.next();
current.unload();
i.remove();
}
That would include resources loaded explicitly and implicitly.
Do you still see a leak in that case?
Also: instead of a 12 test cases, it would be better if you could run
your test case a thousand times. If there is a leak, it will probably
cause the test suite to fail at some point.
Cheers,
Rafael
http://abstratt.com/blog/
Alex wrote:
> Hi James
>
> The problem seems to be only with my JUnit tests. I have tried my
> application ... the memory consumption increases every time I start my
> export but that is just because GC is not running. If I export often
> enough the GC gives free everything again or when I start GC manual over
> the Eclipse gui.
>
> But with test cases more and more memory is needed with every test that
> is not given free. When the memory of the VM is full no Exception occurs
> but it takes longer and longer for a test to complete (6, 15, 16, 80,
> 180 seconds and so on). It seems the GC has fewer and fewer stuff to
> collect and needs to run longer and longer trying to find anything to free.
>
> I isolated the problem from my plugin and created an eclipse plugin
> project with a Junit Test Case and my profile and primitive library.
>
> In this Test Case I just create a platform project, a uml model, load my
> profile and my primitive types library, create some classes with
> attributes and applying stereotypes. In tearDown I unload my resources
> and close delete the platform project.
>
> I've uploaded to my server, you can import it as eclipse plugin project
> and run yourself. If you take a look into your system resource
> consumption panel you see that after each test method some megabytes are
> lost that are not being freed until the complete test run ends.
>
> Here is the project: http://www.starspring.de/uml2test.zip
>
|
|
|
control command and stereotypes [message #627277 is a reply to message #478059] |
Wed, 10 December 2008 22:13 |
|
Hi all,
when applying the "control" command on a package (or a component)
containing elements with applyed stereotypes the new sub-model does not
show those applied stereotypes.
When I open it as text file I can see that neither profile application
nor applied stereotypes are embedded int this file. In fact the applied
stereotypes are not lost but are simply stored (and visible) in the
parent file.
I think it can lead to confusion as the end user expects to see applied
stereotypes in the controlled resource in the same way he sees them in
the parent resource.
This was the first point but there is another one: how to apply
stereotypes in the controlled resource as profile data are not present?
If it is a package, then you can load the profile as an additional
resource and then apply it to the package. But what about a component?
As it is not possible to apply profiles on components, you will never be
able to apply stereotypes in a controlled UML component.
And this is for me a strong restriction...
So, I have a suggestion : when applying the "control" command on a model
element, perhaps we could have an option to ask the end user if he (she)
would like to keep a reference on the parent model in the controlled
resource.
If yes, the controlled resource would then access to the applied
profiles and to the applied stereotypes and would allow the user to both
see and apply stereotypes.
regards
raphaël
|
|
|
Re: control command and stereotypes [message #627278 is a reply to message #478060] |
Thu, 11 December 2008 01:31 |
Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, raphaël,
I agree with you that it would be more intuitive if the UML editor
customized the "Control" action to move stereotype instances to the new
resource, that are applied to elements that are move to that resource.
However, I don't think that you can expect an element (component or
otherwise) in a controlled resource to "work" without its containment
chain (in the parent resources) also being loaded. Composition in UML
is very strong dependency of a contained object on its parent, and one
aspect of this is profile applications, as you have observed.
Every element that is not a package must be contained, ultimately, in a
package because only packages may be root elements of the tree. Thus, a
component is not valid if it is not in a containing package, and when
that package is present, then naturally it could have profiles applied.
Cheers,
Christian
raphaël Faudou wrote:
> Hi all,
>
> when applying the "control" command on a package (or a component)
> containing elements with applyed stereotypes the new sub-model does not
> show those applied stereotypes.
> When I open it as text file I can see that neither profile application
> nor applied stereotypes are embedded int this file. In fact the applied
> stereotypes are not lost but are simply stored (and visible) in the
> parent file.
> I think it can lead to confusion as the end user expects to see applied
> stereotypes in the controlled resource in the same way he sees them in
> the parent resource.
>
> This was the first point but there is another one: how to apply
> stereotypes in the controlled resource as profile data are not present?
> If it is a package, then you can load the profile as an additional
> resource and then apply it to the package. But what about a component?
> As it is not possible to apply profiles on components, you will never be
> able to apply stereotypes in a controlled UML component.
> And this is for me a strong restriction...
>
> So, I have a suggestion : when applying the "control" command on a model
> element, perhaps we could have an option to ask the end user if he (she)
> would like to keep a reference on the parent model in the controlled
> resource.
> If yes, the controlled resource would then access to the applied
> profiles and to the applied stereotypes and would allow the user to both
> see and apply stereotypes.
>
> regards
> raphaël
>
>
>
>
|
|
|
Re: control command and stereotypes [message #627279 is a reply to message #478061] |
Thu, 11 December 2008 08:32 |
|
Hi Christian,
thanks for those tips.
Now my question is rather about methodology. What I like with components
is that you can build the product tree and it is probably from this
tree that you would like to split your model and dispatch pieces to
several subcontractors.
Until recently I wwas used to build this tree with packages and it there
were no problems except that I had to create one UML component for each
package to get the whole picture with component diagrams.
Would you have a suggestion or recommendation to avoid such a
duplication of semantics while dealing with profiles in a distributed model?
Cheers
raphaël
Christian W. Damus a écrit :
> Hi, raphaël,
>
> I agree with you that it would be more intuitive if the UML editor
> customized the "Control" action to move stereotype instances to the new
> resource, that are applied to elements that are move to that resource.
>
> However, I don't think that you can expect an element (component or
> otherwise) in a controlled resource to "work" without its containment
> chain (in the parent resources) also being loaded. Composition in UML
> is very strong dependency of a contained object on its parent, and one
> aspect of this is profile applications, as you have observed.
>
> Every element that is not a package must be contained, ultimately, in a
> package because only packages may be root elements of the tree. Thus, a
> component is not valid if it is not in a containing package, and when
> that package is present, then naturally it could have profiles applied.
>
> Cheers,
>
> Christian
>
> raphaël Faudou wrote:
>> Hi all,
>>
>> when applying the "control" command on a package (or a component)
>> containing elements with applyed stereotypes the new sub-model does not
>> show those applied stereotypes.
>> When I open it as text file I can see that neither profile application
>> nor applied stereotypes are embedded int this file. In fact the
>> applied stereotypes are not lost but are simply stored (and visible)
>> in the parent file.
>> I think it can lead to confusion as the end user expects to see
>> applied stereotypes in the controlled resource in the same way he sees
>> them in the parent resource.
>>
>> This was the first point but there is another one: how to apply
>> stereotypes in the controlled resource as profile data are not present?
>> If it is a package, then you can load the profile as an additional
>> resource and then apply it to the package. But what about a component?
>> As it is not possible to apply profiles on components, you will never
>> be able to apply stereotypes in a controlled UML component.
>> And this is for me a strong restriction...
>>
>> So, I have a suggestion : when applying the "control" command on a
>> model element, perhaps we could have an option to ask the end user if
>> he (she) would like to keep a reference on the parent model in the
>> controlled resource.
>> If yes, the controlled resource would then access to the applied
>> profiles and to the applied stereotypes and would allow the user to
>> both see and apply stereotypes.
>>
>> regards
>> raphaël
>>
>>
>>
>>
|
|
| | |
Re: control command and stereotypes - component hierarchy [message #627310 is a reply to message #478087] |
Mon, 05 January 2009 10:44 |
|
Hi all,
Happy new year !
Well, probably my prvious message was not very clear.
I try to explain my needs through a simple example.
Let us consider we have a system with 3 subsystems that communicate each
other.
I would like to show this communication : my idea is to use the
component diagram with subystems modelled as UML components with
"subsystem" stereotype.
Then,I would like to distribute those 3 subsystems to 3 different teams.
The most natural idea that comes to my mind is to control each UML
component and to give those new resources to the teams. Isn't it? Then I
loose the visibility of steretoype application...
As alternative I can create 3 packages (one for each subsystem) and then
control those packages but I find it redundant with the existing UML
components.
Recursively the same thing happens at a lower level. Let us suppose that
my first subsystem is decomposed into 4 components. I would like to
outsource two of those components.
Should I model those components as packages because package is the
element used to split resources?
I would prefer using UML components as they are the main natural
elements for product decomposition (Work Breadkwon Structure)...
Any piece of advice?
thanks
raphaël
Kenn Hussey a écrit :
> Raphaël,
>
> While components, like packages, do have packaging behavior, the semantics
> of components are are quite different from those of packages, so I'm not
> sure that there is much duplication of semantics here. If what you're
> looking to do it partition a package hierarchy across several resources, I'd
> recommend ensuring that the (root) package to which the profile is applied
> is loaded when working with a (nested) resource in which the component
> exists, as Christian has suggested...
>
> Kenn
>
> "raphaël Faudou" <raphael.faudou@atosorigin.com> wrote in message
> news:ghqj6t$qna$1@build.eclipse.org...
> Hi Christian,
>
> thanks for those tips.
> Now my question is rather about methodology. What I like with components
> is that you can build the product tree and it is probably from this
> tree that you would like to split your model and dispatch pieces to
> several subcontractors.
> Until recently I wwas used to build this tree with packages and it there
> were no problems except that I had to create one UML component for each
> package to get the whole picture with component diagrams.
> Would you have a suggestion or recommendation to avoid such a
> duplication of semantics while dealing with profiles in a distributed model?
>
> Cheers
> raphaël
>
> Christian W. Damus a écrit :
>> Hi, raphaël,
>>
>> I agree with you that it would be more intuitive if the UML editor
>> customized the "Control" action to move stereotype instances to the new
>> resource, that are applied to elements that are move to that resource.
>>
>> However, I don't think that you can expect an element (component or
>> otherwise) in a controlled resource to "work" without its containment
>> chain (in the parent resources) also being loaded. Composition in UML is
>> very strong dependency of a contained object on its parent, and one aspect
>> of this is profile applications, as you have observed.
>>
>> Every element that is not a package must be contained, ultimately, in a
>> package because only packages may be root elements of the tree. Thus, a
>> component is not valid if it is not in a containing package, and when that
>> package is present, then naturally it could have profiles applied.
>>
>> Cheers,
>>
>> Christian
>>
>> raphaël Faudou wrote:
>>> Hi all,
>>>
>>> when applying the "control" command on a package (or a component)
>>> containing elements with applyed stereotypes the new sub-model does not
>>> show those applied stereotypes.
>>> When I open it as text file I can see that neither profile application
>>> nor applied stereotypes are embedded int this file. In fact the applied
>>> stereotypes are not lost but are simply stored (and visible) in the
>>> parent file.
>>> I think it can lead to confusion as the end user expects to see applied
>>> stereotypes in the controlled resource in the same way he sees them in
>>> the parent resource.
>>>
>>> This was the first point but there is another one: how to apply
>>> stereotypes in the controlled resource as profile data are not present?
>>> If it is a package, then you can load the profile as an additional
>>> resource and then apply it to the package. But what about a component?
>>> As it is not possible to apply profiles on components, you will never be
>>> able to apply stereotypes in a controlled UML component.
>>> And this is for me a strong restriction...
>>>
>>> So, I have a suggestion : when applying the "control" command on a model
>>> element, perhaps we could have an option to ask the end user if he (she)
>>> would like to keep a reference on the parent model in the controlled
>>> resource.
>>> If yes, the controlled resource would then access to the applied profiles
>>> and to the applied stereotypes and would allow the user to both see and
>>> apply stereotypes.
>>>
>>> regards
>>> raphaël
>>>
>>>
>>>
>>>
>
>
|
|
|
Re: control command and stereotypes - component hierarchy [message #627311 is a reply to message #478103] |
Mon, 05 January 2009 13:32 |
Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Raphaël,
One consideration when sharing partial models in this way is the impact
that it has on the effective qualified names of elements. If you do not
make the containing chain of namespaces available to your consumers,
then the qualified names will be missing some segments.
This could be an issue for expression languages like OCL. Portability
of expressions from the partial model to the full model context (and,
esp., vice-versa) could be a problem.
It would probably be a good idea to ensure that, when re-distributing
only one of the components, that its containing package(s) be included,
as well, to ensure the integrity of names. This would mean, I suppose,
that these packages should only contain elements by proxy and that users
of the partial models will see several unresolved proxies in the content
tree. A robust UML application should be able to handle that.
Of course, it isn't necessarily the case that names are important to
your application ... I'm just waving my hands. :-)
Also, your example indicates that these subsystems communicate with each
other. If that implies some kind of dependencies between them, then
they don't stand on their own as complete models, anyway. OTOH, this
communication might be defined at a higher level of abstraction, in
protocols that these components implement without any such coupling
between them. Now my hands are waving frantically. :-D
Cheers,
Christian
raphaël Faudou wrote:
> Hi all,
> Happy new year !
>
> Well, probably my prvious message was not very clear.
> I try to explain my needs through a simple example.
>
> Let us consider we have a system with 3 subsystems that communicate each
> other.
> I would like to show this communication : my idea is to use the
> component diagram with subystems modelled as UML components with
> "subsystem" stereotype.
> Then,I would like to distribute those 3 subsystems to 3 different teams.
>
> The most natural idea that comes to my mind is to control each UML
> component and to give those new resources to the teams. Isn't it? Then I
> loose the visibility of steretoype application...
>
> As alternative I can create 3 packages (one for each subsystem) and then
> control those packages but I find it redundant with the existing UML
> components.
>
> Recursively the same thing happens at a lower level. Let us suppose that
> my first subsystem is decomposed into 4 components. I would like to
> outsource two of those components.
> Should I model those components as packages because package is the
> element used to split resources?
> I would prefer using UML components as they are the main natural
> elements for product decomposition (Work Breadkwon Structure)...
> Any piece of advice?
> thanks
> raphaël
>
-----8<-----
|
|
|
Re: control command and stereotypes - component hierarchy [message #627315 is a reply to message #478104] |
Tue, 06 January 2009 10:44 |
|
Christian W. Damus a écrit :
> Hi, Raphaël,
>
> One consideration when sharing partial models in this way is the impact
> that it has on the effective qualified names of elements. If you do not
> make the containing chain of namespaces available to your consumers,
> then the qualified names will be missing some segments.
>
> This could be an issue for expression languages like OCL. Portability
> of expressions from the partial model to the full model context (and,
> esp., vice-versa) could be a problem.
>
> It would probably be a good idea to ensure that, when re-distributing
> only one of the components, that its containing package(s) be included,
> as well, to ensure the integrity of names. This would mean, I suppose,
> that these packages should only contain elements by proxy and that users
> of the partial models will see several unresolved proxies in the content
> tree. A robust UML application should be able to handle that.
>
> Of course, it isn't necessarily the case that names are important to
> your application ... I'm just waving my hands. :-)
>
> Also, your example indicates that these subsystems communicate with each
> other. If that implies some kind of dependencies between them, then
> they don't stand on their own as complete models, anyway. OTOH, this
> communication might be defined at a higher level of abstraction, in
> protocols that these components implement without any such coupling
> between them. Now my hands are waving frantically. :-D
FWIW, Topcased 2.0 introduced new operations to better support these
kinds of use cases (splitting a model in sub-models which will be worked
on independently, and merging the new versions back).
It introduces Export/Import operations, which can be seen as extended
versions of Control/Uncontrol. The main difference is that an exported
sub-model will stand alone: everything it depends on (including
stereotypes) is copied in a new "cache" resource, so that the exported
sub-model and its cache are totally self-contained.
It is not perfect: there are some issues with ProfileApplications, and
as you mentionned we lose information on the qualified name of elements.
Basically, the exported model (+ its cache) is technically standalone,
but the semantics can never be exactly the same because as you said the
semantics of UML elements depdend on the context they are used in (e.g.
the name of their parent, the profiles applied 5 levels above, etc.).
Pierre-Charles David - Obeo
Need training or professional services for Sirius?
http://www.obeodesigner.com/sirius
|
|
| |
Re: control command and stereotypes - component hierarchy [message #627319 is a reply to message #478111] |
Wed, 07 January 2009 16:25 |
|
Hi Kenn, hi Christian,
Thank you very much for the attention you paid to my question and for
those answers.
I'm going to have a look at the API as you suggest and I will try to
enforce the loading of the parent model when controlling one component.
Cheers
raphaël
Kenn Hussey a écrit :
> Raphaël,
>
> I would suggest having the three components directly or indirectly owned by
> the same package/model and apply the profile to that package/model. When the
> components are separated into separate resources ("controlled"), their
> corresponding stereotype applications should be separated with them (I know
> the sample UML editor does not do this currently, but the APIs are there).
> Then, when a given team wants to work with their component, they need only
> load/open the root resource (containing the owning package/model) and the
> resource containing their component.
>
> As Christian has pointed out, it's possible that the components might have
> references between them, which might mean that one or more of the other
> resources (containing the other components) would need to be loadded/opened,
> but if a source control system were being used, only the resource containing
> the team's particular component need be checked out (committed),
> dependening, of course, on the nature of the changes and the potential
> impact on the other components.
>
> Kenn
>
> "raphaël Faudou" <raphael.faudou@atosorigin.com> wrote in message
> news:4961E49A.5060006@atosorigin.com...
> Hi all,
> Happy new year !
>
> Well, probably my prvious message was not very clear.
> I try to explain my needs through a simple example.
>
> Let us consider we have a system with 3 subsystems that communicate each
> other.
> I would like to show this communication : my idea is to use the
> component diagram with subystems modelled as UML components with
> "subsystem" stereotype.
> Then,I would like to distribute those 3 subsystems to 3 different teams.
>
> The most natural idea that comes to my mind is to control each UML
> component and to give those new resources to the teams. Isn't it? Then I
> loose the visibility of steretoype application...
>
> As alternative I can create 3 packages (one for each subsystem) and then
> control those packages but I find it redundant with the existing UML
> components.
>
> Recursively the same thing happens at a lower level. Let us suppose that
> my first subsystem is decomposed into 4 components. I would like to
> outsource two of those components.
> Should I model those components as packages because package is the
> element used to split resources?
> I would prefer using UML components as they are the main natural
> elements for product decomposition (Work Breadkwon Structure)...
> Any piece of advice?
> thanks
> raphaël
>
>
> Kenn Hussey a écrit :
>> Raphaël,
>>
>> While components, like packages, do have packaging behavior, the semantics
>> of components are are quite different from those of packages, so I'm not
>> sure that there is much duplication of semantics here. If what you're
>> looking to do it partition a package hierarchy across several resources,
>> I'd recommend ensuring that the (root) package to which the profile is
>> applied is loaded when working with a (nested) resource in which the
>> component exists, as Christian has suggested...
>>
>> Kenn
>>
>> "raphaël Faudou" <raphael.faudou@atosorigin.com> wrote in message
>> news:ghqj6t$qna$1@build.eclipse.org...
>> Hi Christian,
>>
>> thanks for those tips.
>> Now my question is rather about methodology. What I like with components
>> is that you can build the product tree and it is probably from this
>> tree that you would like to split your model and dispatch pieces to
>> several subcontractors.
>> Until recently I wwas used to build this tree with packages and it there
>> were no problems except that I had to create one UML component for each
>> package to get the whole picture with component diagrams.
>> Would you have a suggestion or recommendation to avoid such a
>> duplication of semantics while dealing with profiles in a distributed
>> model?
>>
>> Cheers
>> raphaël
>>
>> Christian W. Damus a écrit :
>>> Hi, raphaël,
>>>
>>> I agree with you that it would be more intuitive if the UML editor
>>> customized the "Control" action to move stereotype instances to the new
>>> resource, that are applied to elements that are move to that resource.
>>>
>>> However, I don't think that you can expect an element (component or
>>> otherwise) in a controlled resource to "work" without its containment
>>> chain (in the parent resources) also being loaded. Composition in UML is
>>> very strong dependency of a contained object on its parent, and one
>>> aspect of this is profile applications, as you have observed.
>>>
>>> Every element that is not a package must be contained, ultimately, in a
>>> package because only packages may be root elements of the tree. Thus, a
>>> component is not valid if it is not in a containing package, and when
>>> that package is present, then naturally it could have profiles applied.
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>> raphaël Faudou wrote:
>>>> Hi all,
>>>>
>>>> when applying the "control" command on a package (or a component)
>>>> containing elements with applyed stereotypes the new sub-model does not
>>>> show those applied stereotypes.
>>>> When I open it as text file I can see that neither profile application
>>>> nor applied stereotypes are embedded int this file. In fact the applied
>>>> stereotypes are not lost but are simply stored (and visible) in the
>>>> parent file.
>>>> I think it can lead to confusion as the end user expects to see applied
>>>> stereotypes in the controlled resource in the same way he sees them in
>>>> the parent resource.
>>>>
>>>> This was the first point but there is another one: how to apply
>>>> stereotypes in the controlled resource as profile data are not present?
>>>> If it is a package, then you can load the profile as an additional
>>>> resource and then apply it to the package. But what about a component?
>>>> As it is not possible to apply profiles on components, you will never be
>>>> able to apply stereotypes in a controlled UML component.
>>>> And this is for me a strong restriction...
>>>>
>>>> So, I have a suggestion : when applying the "control" command on a model
>>>> element, perhaps we could have an option to ask the end user if he (she)
>>>> would like to keep a reference on the parent model in the controlled
>>>> resource.
>>>> If yes, the controlled resource would then access to the applied
>>>> profiles and to the applied stereotypes and would allow the user to both
>>>> see and apply stereotypes.
>>>>
>>>> regards
>>>> raphaël
>>>>
>>>>
>>>>
>>>>
>>
>
>
|
|
|
Goto Forum:
Current Time: Wed Sep 25 22:49:33 GMT 2024
Powered by FUDForum. Page generated in 0.06247 seconds
|