Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » UML2 » Memory leak in uml2 ?
Memory leak in uml2 ? [message #478051] Sun, 07 December 2008 20:24 Go to next message
Alexander Weickmann is currently offline Alexander WeickmannFriend
Messages: 33
Registered: July 2009
Member
Hi there.

I've been programming the last five month on a model merge from the model
of our software to the uml2 format.

A few days ago I first noticed a memory leak in my plugin. I did not see
it earlier because everything went well so far because I had enough
memory. But now I have 300 JUnit tests and at about test 250 my system
gets very slow. So I looked into the system control and my memory was
absolutely full.

Then I tried my program itself and started the uml export. Depending on
the size of the model I get 5 to 10 megabyte memory that is allocated and
not beeing freed after the operation.

After killing a full day with trying to get eclipse tptp working (it is
totally bugged) I tried JProbe. I've gone trough the JProbe tutorials and
stuff and after another day now I know how to use that ^ ^

So I did the following:

- Start my plugin in eclipse (Eclipse application run)
- Connect JProbe to the current session
- As the eclipse was loaded with my plugin I started a use case in JProbe
which means from now on data will be collected
- Execute my uml2 export
- Finish the JProbe use case and shutting down everything.

Then JProbe saves me a snapshot which lets me investigate every instance
that has been allocated. I get a list with many hundreds of classes. I
first looked to my own classes, that from my plugin. Everything seems to
be ok there though. There are 0 instances in the memory except the action
which I suppose is left in the memory by eclipse. So I think that's ok.

Then I filtered for all instances org.eclipse.uml2.*

From org.eclipse.uml2.uml.internal.impl.StereotypeImpl there are 2376
instances in the memory and 0 dead. That means not a single one of these
2376 instances has been killed by garbage collection and is still in
memory after the operation. I can also take a look to the referers of
these objects. None of my classes is there, but for example
org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList still
refers to StereotypeImpls

I also have in memory after the operation:
1878 GeneralizationImpl (and 0 killed)
1665 Property[] (and 6 killed)
1622 ClassImpl (and 528 killed)
1584 ElementImportImpl (and 0 killed)

the list goes on ...

Now I'm really confused what to do? Can the problem be on my side? That I
don't free anything properly? But only my action delegate is in memory
after the operation. But the action is not listed in the referers to the
in memory objects mentioned above and it does not have any member
variables of these ... What can I do now?
Re: Memory leak in uml2 ? [message #478052 is a reply to message #478051] Mon, 08 December 2008 17:53 Go to previous messageGo to next message
Tim Myer is currently offline Tim MyerFriend
Messages: 81
Registered: July 2009
Member
Is it possible that you are creating ContentProviders or LabelProviders
using a ComposedAdapterFactory somewhere and not disposing them
properly? I had faced something similar and believe that turned out to
be the root cause of my problem. Just a thought.
----Tim----

Alex wrote:
> Hi there.
>
> I've been programming the last five month on a model merge from the
> model of our software to the uml2 format.
>
> A few days ago I first noticed a memory leak in my plugin. I did not see
> it earlier because everything went well so far because I had enough
> memory. But now I have 300 JUnit tests and at about test 250 my system
> gets very slow. So I looked into the system control and my memory was
> absolutely full.
>
> Then I tried my program itself and started the uml export. Depending on
> the size of the model I get 5 to 10 megabyte memory that is allocated
> and not beeing freed after the operation.
>
> After killing a full day with trying to get eclipse tptp working (it is
> totally bugged) I tried JProbe. I've gone trough the JProbe tutorials
> and stuff and after another day now I know how to use that ^ ^
>
> So I did the following:
>
> - Start my plugin in eclipse (Eclipse application run)
> - Connect JProbe to the current session
> - As the eclipse was loaded with my plugin I started a use case in
> JProbe which means from now on data will be collected
> - Execute my uml2 export
> - Finish the JProbe use case and shutting down everything.
>
> Then JProbe saves me a snapshot which lets me investigate every instance
> that has been allocated. I get a list with many hundreds of classes. I
> first looked to my own classes, that from my plugin. Everything seems to
> be ok there though. There are 0 instances in the memory except the
> action which I suppose is left in the memory by eclipse. So I think
> that's ok.
>
> Then I filtered for all instances org.eclipse.uml2.*
>
> From org.eclipse.uml2.uml.internal.impl.StereotypeImpl there are 2376
> instances in the memory and 0 dead. That means not a single one of these
> 2376 instances has been killed by garbage collection and is still in
> memory after the operation. I can also take a look to the referers of
> these objects. None of my classes is there, but for example
> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList still
> refers to StereotypeImpls
>
> I also have in memory after the operation:
> 1878 GeneralizationImpl (and 0 killed)
> 1665 Property[] (and 6 killed)
> 1622 ClassImpl (and 528 killed)
> 1584 ElementImportImpl (and 0 killed)
>
> the list goes on ...
>
> Now I'm really confused what to do? Can the problem be on my side? That
> I don't free anything properly? But only my action delegate is in memory
> after the operation. But the action is not listed in the referers to the
> in memory objects mentioned above and it does not have any member
> variables of these ... What can I do now?
>
Re: Memory leak in uml2 ? [message #478053 is a reply to message #478052] Tue, 09 December 2008 07:45 Go to previous messageGo to next message
Alexander Weickmann is currently offline Alexander WeickmannFriend
Messages: 33
Registered: July 2009
Member
No I don't. Is it maybe required to close uml resources in some way?
Re: Memory leak in uml2 ? [message #478054 is a reply to message #478053] Tue, 09 December 2008 11:11 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31009
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.
Re: Memory leak in uml2 ? [message #478055 is a reply to message #478054] Tue, 09 December 2008 13:38 Go to previous messageGo to next message
Alexander Weickmann is currently offline Alexander WeickmannFriend
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 Go to previous messageGo to next message
james bruck is currently offline james bruckFriend
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 Go to previous messageGo to next message
james bruck is currently offline james bruckFriend
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 #478058 is a reply to message #478057] Wed, 10 December 2008 08:04 Go to previous messageGo to next message
Alexander Weickmann is currently offline Alexander WeickmannFriend
Messages: 33
Registered: July 2009
Member
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
Re: Memory leak in uml2 ? [message #478059 is a reply to message #478058] Wed, 10 December 2008 16:11 Go to previous messageGo to next message
Rafael Chaves is currently offline Rafael ChavesFriend
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 Go to previous messageGo to next message
Raphael Faudou is currently offline Raphael FaudouFriend
Messages: 105
Registered: July 2009
Senior Member
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 Go to previous messageGo to next message
Eclipse UserFriend
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 Go to previous messageGo to next message
Raphael Faudou is currently offline Raphael FaudouFriend
Messages: 105
Registered: July 2009
Senior Member
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 #478064 is a reply to message #478059] Sat, 13 December 2008 12:51 Go to previous messageGo to next message
Alexander Weickmann is currently offline Alexander WeickmannFriend
Messages: 33
Registered: July 2009
Member
Hi Rafael

Thanks a lot for the tip. I iterate now over all the resources and unload
them like you said. That alone did not help but was surely part of the
problem. I needed also set every member attribute of my test to null in
the tearDown explicitly. Now the memory usage is constant.

So in our program it looks like this if anyone may encounter the same
problem in the future:

for (Iterator<Resource> i = resourceSet.getResources().iterator();
i.hasNext();) {
Resource current = (Resource)i.next();
current.unload();
i.remove();
}

valueDataTypesPackage = null;
resourceSet = null;
faktorIpsPrimitiveTypesModelLibrary = null;
faktorIpsProfile = null;
testUmlModel = null;
anotherTestUmlModel = null;

productCmptTypeStereotype = null;
policyCmptTypeStereotype = null;
configurationForPolicyCmptStereotype = null;
productCmptTypeAttributeStereotype = null;
policyCmptTypeAttributeStereotype = null;
productCmptTypeMethodStereotype = null;
policyCmptTypeMethodStereotype = null;
productCmptTypeAssociationEndStereotype = null;
policyCmptTypeAssociationEndStereotype = null;
productCmptTypeAssociationStereotype = null;
policyCmptTypeAssociationStereotype = null;
attributeTypeEnumeration = null;
Re: control command and stereotypes [message #478087 is a reply to message #478062] Mon, 22 December 2008 16:31 Go to previous messageGo to next message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
Rapha
Re: control command and stereotypes - component hierarchy [message #478103 is a reply to message #478087] Mon, 05 January 2009 10:44 Go to previous messageGo to next message
Raphael Faudou is currently offline Raphael FaudouFriend
Messages: 105
Registered: July 2009
Senior Member
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 Go to previous messageGo to next message
Eclipse UserFriend
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 Go to previous messageGo to next message
Pierre-Charles David is currently offline Pierre-Charles DavidFriend
Messages: 522
Registered: July 2009
Senior Member
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 #478111 is a reply to message #478103] Wed, 07 January 2009 16:18 Go to previous messageGo to next message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
Rapha
Re: control command and stereotypes - component hierarchy [message #478112 is a reply to message #478111] Wed, 07 January 2009 16:25 Go to previous message
Raphael Faudou is currently offline Raphael FaudouFriend
Messages: 105
Registered: July 2009
Senior Member
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 #627269 is a reply to message #478051] Mon, 08 December 2008 17:53 Go to previous message
Tim Myer is currently offline Tim MyerFriend
Messages: 81
Registered: July 2009
Member
Is it possible that you are creating ContentProviders or LabelProviders
using a ComposedAdapterFactory somewhere and not disposing them
properly? I had faced something similar and believe that turned out to
be the root cause of my problem. Just a thought.
----Tim----

Alex wrote:
> Hi there.
>
> I've been programming the last five month on a model merge from the
> model of our software to the uml2 format.
>
> A few days ago I first noticed a memory leak in my plugin. I did not see
> it earlier because everything went well so far because I had enough
> memory. But now I have 300 JUnit tests and at about test 250 my system
> gets very slow. So I looked into the system control and my memory was
> absolutely full.
>
> Then I tried my program itself and started the uml export. Depending on
> the size of the model I get 5 to 10 megabyte memory that is allocated
> and not beeing freed after the operation.
>
> After killing a full day with trying to get eclipse tptp working (it is
> totally bugged) I tried JProbe. I've gone trough the JProbe tutorials
> and stuff and after another day now I know how to use that ^ ^
>
> So I did the following:
>
> - Start my plugin in eclipse (Eclipse application run)
> - Connect JProbe to the current session
> - As the eclipse was loaded with my plugin I started a use case in
> JProbe which means from now on data will be collected
> - Execute my uml2 export
> - Finish the JProbe use case and shutting down everything.
>
> Then JProbe saves me a snapshot which lets me investigate every instance
> that has been allocated. I get a list with many hundreds of classes. I
> first looked to my own classes, that from my plugin. Everything seems to
> be ok there though. There are 0 instances in the memory except the
> action which I suppose is left in the memory by eclipse. So I think
> that's ok.
>
> Then I filtered for all instances org.eclipse.uml2.*
>
> From org.eclipse.uml2.uml.internal.impl.StereotypeImpl there are 2376
> instances in the memory and 0 dead. That means not a single one of these
> 2376 instances has been killed by garbage collection and is still in
> memory after the operation. I can also take a look to the referers of
> these objects. None of my classes is there, but for example
> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList still
> refers to StereotypeImpls
>
> I also have in memory after the operation:
> 1878 GeneralizationImpl (and 0 killed)
> 1665 Property[] (and 6 killed)
> 1622 ClassImpl (and 528 killed)
> 1584 ElementImportImpl (and 0 killed)
>
> the list goes on ...
>
> Now I'm really confused what to do? Can the problem be on my side? That
> I don't free anything properly? But only my action delegate is in memory
> after the operation. But the action is not listed in the referers to the
> in memory objects mentioned above and it does not have any member
> variables of these ... What can I do now?
>
Re: Memory leak in uml2 ? [message #627270 is a reply to message #478052] Tue, 09 December 2008 07:45 Go to previous message
Alexander Weickmann is currently offline Alexander WeickmannFriend
Messages: 33
Registered: July 2009
Member
No I don't. Is it maybe required to close uml resources in some way?
Re: Memory leak in uml2 ? [message #627271 is a reply to message #478053] Tue, 09 December 2008 11:11 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31009
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.
Re: Memory leak in uml2 ? [message #627272 is a reply to message #478054] Tue, 09 December 2008 13:38 Go to previous message
Alexander Weickmann is currently offline Alexander WeickmannFriend
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 Go to previous message
james bruck is currently offline james bruckFriend
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 Go to previous message
james bruck is currently offline james bruckFriend
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 #627275 is a reply to message #478057] Wed, 10 December 2008 08:04 Go to previous message
Alexander Weickmann is currently offline Alexander WeickmannFriend
Messages: 33
Registered: July 2009
Member
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
Re: Memory leak in uml2 ? [message #627276 is a reply to message #478058] Wed, 10 December 2008 16:11 Go to previous message
Rafael Chaves is currently offline Rafael ChavesFriend
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 Go to previous message
Raphael Faudou is currently offline Raphael FaudouFriend
Messages: 105
Registered: July 2009
Senior Member
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 Go to previous message
Eclipse UserFriend
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 Go to previous message
Raphael Faudou is currently offline Raphael FaudouFriend
Messages: 105
Registered: July 2009
Senior Member
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 #627281 is a reply to message #478059] Sat, 13 December 2008 12:51 Go to previous message
Alexander Weickmann is currently offline Alexander WeickmannFriend
Messages: 33
Registered: July 2009
Member
Hi Rafael

Thanks a lot for the tip. I iterate now over all the resources and unload
them like you said. That alone did not help but was surely part of the
problem. I needed also set every member attribute of my test to null in
the tearDown explicitly. Now the memory usage is constant.

So in our program it looks like this if anyone may encounter the same
problem in the future:

for (Iterator<Resource> i = resourceSet.getResources().iterator();
i.hasNext();) {
Resource current = (Resource)i.next();
current.unload();
i.remove();
}

valueDataTypesPackage = null;
resourceSet = null;
faktorIpsPrimitiveTypesModelLibrary = null;
faktorIpsProfile = null;
testUmlModel = null;
anotherTestUmlModel = null;

productCmptTypeStereotype = null;
policyCmptTypeStereotype = null;
configurationForPolicyCmptStereotype = null;
productCmptTypeAttributeStereotype = null;
policyCmptTypeAttributeStereotype = null;
productCmptTypeMethodStereotype = null;
policyCmptTypeMethodStereotype = null;
productCmptTypeAssociationEndStereotype = null;
policyCmptTypeAssociationEndStereotype = null;
productCmptTypeAssociationStereotype = null;
policyCmptTypeAssociationStereotype = null;
attributeTypeEnumeration = null;
Re: control command and stereotypes [message #627296 is a reply to message #478062] Mon, 22 December 2008 16:31 Go to previous message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
Rapha
Re: control command and stereotypes - component hierarchy [message #627310 is a reply to message #478087] Mon, 05 January 2009 10:44 Go to previous message
Raphael Faudou is currently offline Raphael FaudouFriend
Messages: 105
Registered: July 2009
Senior Member
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 Go to previous message
Eclipse UserFriend
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 Go to previous message
Pierre-Charles David is currently offline Pierre-Charles DavidFriend
Messages: 522
Registered: July 2009
Senior Member
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 #627318 is a reply to message #478103] Wed, 07 January 2009 16:18 Go to previous message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
Rapha
Re: control command and stereotypes - component hierarchy [message #627319 is a reply to message #478111] Wed, 07 January 2009 16:25 Go to previous message
Raphael Faudou is currently offline Raphael FaudouFriend
Messages: 105
Registered: July 2009
Senior Member
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
>>>>
>>>>
>>>>
>>>>
>>
>
>
Previous Topic:Unable to create 'ResourceSetImpl' instance in Eclipse 3.4.1
Next Topic:reflection: accessing UML classes from (instance) EObject?
Goto Forum:
  


Current Time: Wed Apr 01 21:53:03 GMT 2020

Powered by FUDForum. Page generated in 0.03147 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top