Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Limitations of OCL
Limitations of OCL [message #1010968] Mon, 18 February 2013 10:29 Go to next message
Cedric Moonen is currently offline Cedric Moonen
Messages: 270
Registered: August 2009
Senior Member
Hello,

I'm currently using OCLinEcore to describe my domain model, add constraints to it and provide derivation of the derived properties (so that I don't have to edit the generated Java code).

I have a derived property for which I am not sure if I will be able to express the derivation using OCL and I would like to have some advice about it.

Here a simplified domain model to illustrate the problem:
package components : components = 'platform:/resource/Components/model/components.oclinecore'
{
	class Container
	{
		property components : Component[*] { ordered composes };
		property connectors : Connector[*] { ordered composes };
		property firstComponent : Component { ordered };
		property lastComponent : Component { ordered };
		property paths : Path[*] { ordered derived transient volatile }
		{
			derivation:;
		}
	}
	class Component
	{
		property connections#components : Connector[+] { ordered };
	}
	class Connector
	{
		property components#connections : Component[2..2] { ordered };
	}
	class Path
	{
		property components : Component[*] { ordered };
	}
}


So, in brief I have a top-level container which contains components and connectors. A connector always connect two components together and a component lists the connectors to which it is tied (this is an EOpposite relation).

The Container indicates which are the first and the last components in the chain.

I would like to be able to retrieve all possible paths of my system, starting from the first component and ending at the last component and excluding loops in the paths (so, a same component cannot be traversed twice in a path).

For this, I created the convenience class Path that collects all components traversed by a path.

But I quickly got stuck on how to implement the derivation for the paths property. Any clue how I could achieve this using OCL (if there is a way to do it) ?
Re: Limitations of OCL [message #1010981 is a reply to message #1010968] Mon, 18 February 2013 10:54 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4035
Registered: July 2009
Senior Member
Hi

OCL has many similarities to other OO languages such as Java or C++,
neither of which allow to you override properties.

If you want dynamic overloading you need to use operations.

Regards

Ed Willink

On 18/02/2013 15:29, Cedric Moonen wrote:
> Hello,
>
> I'm currently using OCLinEcore to describe my domain model, add
> constraints to it and provide derivation of the derived properties (so
> that I don't have to edit the generated Java code).
>
> I have a derived property for which I am not sure if I will be able to
> express the derivation using OCL and I would like to have some advice
> about it.
>
> Here a simplified domain model to illustrate the problem:
> package components : components =
> 'platform:/resource/Components/model/components.oclinecore'
> {
> class Container
> {
> property components : Component[*] { ordered composes };
> property connectors : Connector[*] { ordered composes };
> property firstComponent : Component { ordered };
> property lastComponent : Component { ordered };
> property paths : Path[*] { ordered derived transient volatile }
> {
> derivation:;
> }
> }
> class Component
> {
> property connections#components : Connector[+] { ordered };
> }
> class Connector
> {
> property components#connections : Component[2..2] { ordered };
> }
> class Path
> {
> property components : Component[*] { ordered };
> }
> }
>
>
> So, in brief I have a top-level container which contains components
> and connectors. A connector always connect two components together
> and a component lists the connectors to which it is tied (this is an
> EOpposite relation).
>
> The Container indicates which are the first and the last components in
> the chain.
> I would like to be able to retrieve all possible paths of my system,
> starting from the first component and ending at the last component and
> excluding loops in the paths (so, a same component cannot be traversed
> twice in a path).
>
> For this, I created the convenience class Path that collects all
> components traversed by a path.
>
> But I quickly got stuck on how to implement the derivation for the
> paths property. Any clue how I could achieve this using OCL (if there
> is a way to do it) ?
Re: Limitations of OCL [message #1010989 is a reply to message #1010981] Mon, 18 February 2013 11:08 Go to previous messageGo to next message
Cedric Moonen is currently offline Cedric Moonen
Messages: 270
Registered: August 2009
Senior Member
Hi Ed,

Thanks for the reply. I don't get your point: what I'm trying to achieve here is to have a property called paths in my Container, which is in fact a list of possible paths in the container. Since this property can be derived from the existing elements, it is marked as derived (but I have no clue how to implement the derivation in OCL).

A simpler example would be that each component have a weight, and that the Container has a derived property called weight which is derived by the sum of the components' weight. This is perfectly doable with OCL. But what is the difference then with the paths property (except of course that it is a lot more complex here) ?

Thanks
Re: Limitations of OCL [message #1011009 is a reply to message #1010989] Mon, 18 February 2013 11:51 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4035
Registered: July 2009
Senior Member
Hi

Sorry leaped to the FAQ too quickly.

There are two tools that may be useful to you.

A Set has no duplicates, so you may add duplicates with impunity (apart
from execution time); this applies to sets of Sets too.

The closure() is the only built-in iteration can compute a transitive
function easily, so you need to align your iteration with the growth of
a closure domain; ie each step adds paths to the set of paths. If you
use OrderedSet directly as a Path, the OCL closure will flatten your
nested collections, so to you may need to wrap your path OrderedSet
inside aTuple.

Something like....

let seedPath = Tuple{path : OrderedSet(Component) =
seedComponent->asOrderedSet()} in
seedPath->closure(t |
let path : OrderedSet(Component) = t.path in
let nexts : Set(Component) =
path->last().connections->collect(components->at(2)) in
let acyclicNexts : Set(Component) = nexts->reject(next |
path->includes(next)) in
acyclicNexts->collect(next | Tuple{path : OrderedSet(Component) =
path->append(next)})
)->including(seedPath)

once debugged, might work. It might even work without the Tuples.

Regards

Ed Willink

On 18/02/2013 16:08, Cedric Moonen wrote:
> Hi Ed,
>
> Thanks for the reply. I don't get your point: what I'm trying to
> achieve here is to have a property called paths in my Container, which
> is in fact a list of possible paths in the container. Since this
> property can be derived from the existing elements, it is marked as
> derived (but I have no clue how to implement the derivation in OCL).
>
> A simpler example would be that each component have a weight, and that
> the Container has a derived property called weight which is derived by
> the sum of the components' weight. This is perfectly doable with OCL.
> But what is the difference then with the paths property (except of
> course that it is a lot more complex here) ?
>
> Thanks
Re: Limitations of OCL [message #1011337 is a reply to message #1011009] Tue, 19 February 2013 05:53 Go to previous messageGo to next message
Cedric Moonen is currently offline Cedric Moonen
Messages: 270
Registered: August 2009
Senior Member
Hi Ed,

Thanks a lot for your time.

I'm trying to understand your OCL expression and I'm having some difficulties here...
It contains a couple of mistakes (it gives me error when I try to execute it) so I tried to correct it. Furthermore, it has some evaluation "inaccuracies":
- it doesn't take into account the first and the last components (the path has to start from a very specific component and end at a specific component too)
- the expression components->at(2) is not valid neither, since a connection can link components in any order. The component at index 2 in the connection doesn't mean that it "follows" component at index 1.

I tried to simplify the expression to start from something simple (but incorrect of course) and I'll try to add complexity little by little and trying to understand what I'm doing.

So far, I came up with the following expression:

let startComp : Component = self.firstComponent in
let endComp : Component = self.lastComponent in
startComp->closure(currentComp : Component | currentComp.connections->collect(components->select(nextComp : Component | nextComp<>endComp and nextComp <> startComp and nextComp <> currentComp)  ))


So what this does it is indeed looking at the paths and stops when the end component is reached (if I have a component which is only connected to the last component it will be excluded from the path, which is what I want).

Problems with this expression:
- the first and the last components are not added to the collection
- I end up with a flat list of components instead of having a collection of collection.

For my second point, I would like to create a new Collection each time I iterate iver a nextComp element in my closure, and this collection should be filled up with the path so far (plus my nextComp). Is this feasible or am I going in the wrong direction here ?

Thanks for your feedback.
Re: Limitations of OCL [message #1011368 is a reply to message #1011337] Tue, 19 February 2013 07:22 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4035
Registered: July 2009
Senior Member
Hi

I had no idea of the semantics of your connection, but since it was a
directed graph, I assumed that the ordered components would be directed too.

Obviously if you have more complex semantics you need to account for them.

If the connector ordering is random, it is often helpful to provide an
otherEnd(someEnd) helper function.

Regards

Ed Willink

On 19/02/2013 10:53, Cedric Moonen wrote:
> Hi Ed,
>
> Thanks a lot for your time.
>
> I'm trying to understand your OCL expression and I'm having some
> difficulties here... It contains a couple of mistakes (it gives me
> error when I try to execute it) so I tried to correct it. Furthermore,
> it has some evaluation "inaccuracies": - it doesn't take into account
> the first and the last components (the path has to start from a very
> specific component and end at a specific component too)
> - the expression components->at(2) is not valid neither, since a
> connection can link components in any order. The component at index 2
> in the connection doesn't mean that it "follows" component at index 1.
> I tried to simplify the expression to start from something simple (but
> incorrect of course) and I'll try to add complexity little by little
> and trying to understand what I'm doing.
>
> So far, I came up with the following expression:
>
> let startComp : Component = self.firstComponent in
> let endComp : Component = self.lastComponent in
> startComp->closure(currentComp : Component |
> currentComp.connections->collect(components->select(nextComp :
> Component | nextComp<>endComp and nextComp <> startComp and nextComp
> <> currentComp) ))
>
>
> So what this does it is indeed looking at the paths and stops when the
> end component is reached (if I have a component which is only
> connected to the last component it will be excluded from the path,
> which is what I want).
>
> Problems with this expression:
> - the first and the last components are not added to the collection
> - I end up with a flat list of components instead of having a
> collection of collection.
> For my second point, I would like to create a new Collection each time
> I iterate iver a nextComp element in my closure, and this collection
> should be filled up with the path so far (plus my nextComp). Is this
> feasible or am I going in the wrong direction here ?
>
> Thanks for your feedback.
Re: Limitations of OCL [message #1011383 is a reply to message #1011368] Tue, 19 February 2013 08:01 Go to previous messageGo to next message
Cedric Moonen is currently offline Cedric Moonen
Messages: 270
Registered: August 2009
Senior Member
The connector end was not really a problem, since I could solve it in my OCL expression. However, for convenience purposes I tried to add an "otherEnd" convenience method as you suggested (a bit simplified here):

	class Connector
	{
		property components#connections : Component[2..2] { ordered };
		operation otherEnd(anEnd : Component) : Component { ordered }
		{
			body: if anEnd = components[0] then components[1] else components[0] endif;
		}
	}


Unfortunately, this is not accepted by the OCLinEcore editor as there is an error marker on top of the editor. The error message says: "Null pointer exception: null (see logs for details)". So I guess this is probably a bug.

Here is the stack trace:
java.lang.NullPointerException
	at org.eclipse.ocl.examples.xtext.essentialocl.cs2pivot.EssentialOCLLeft2RightVisitor.visitBinaryOperatorCS(EssentialOCLLeft2RightVisitor.java:851)
	at org.eclipse.ocl.examples.xtext.essentialocl.cs2pivot.AbstractEssentialOCLLeft2RightVisitor.visitBinaryOperatorCS(AbstractEssentialOCLLeft2RightVisitor.java:1)
	at org.eclipse.ocl.examples.xtext.essentialocl.essentialOCLCST.impl.BinaryOperatorCSImpl.accept(BinaryOperatorCSImpl.java:166)
	at org.eclipse.ocl.examples.xtext.base.cs2pivot.CS2PivotConversion.visitLeft2Right(CS2PivotConversion.java:1279)
	at org.eclipse.ocl.examples.xtext.essentialocl.cs2pivot.EssentialOCLLeft2RightVisitor.visitInfixExpCS(EssentialOCLLeft2RightVisitor.java:1015)
	at org.eclipse.ocl.examples.xtext.essentialocl.cs2pivot.AbstractEssentialOCLLeft2RightVisitor.visitInfixExpCS(AbstractEssentialOCLLeft2RightVisitor.java:1)
	at org.eclipse.ocl.examples.xtext.essentialocl.essentialOCLCST.impl.InfixExpCSImpl.accept(InfixExpCSImpl.java:219)
	at org.eclipse.ocl.examples.xtext.base.cs2pivot.CS2PivotConversion.visitLeft2Right(CS2PivotConversion.java:1279)
	at org.eclipse.ocl.examples.xtext.essentialocl.cs2pivot.EssentialOCLLeft2RightVisitor.visitIfExpCS(EssentialOCLLeft2RightVisitor.java:988)
	at org.eclipse.ocl.examples.xtext.essentialocl.cs2pivot.AbstractEssentialOCLLeft2RightVisitor.visitIfExpCS(AbstractEssentialOCLLeft2RightVisitor.java:1)
	at org.eclipse.ocl.examples.xtext.essentialocl.essentialOCLCST.impl.IfExpCSImpl.accept(IfExpCSImpl.java:334)
	at org.eclipse.ocl.examples.xtext.base.cs2pivot.CS2PivotConversion.visitLeft2Right(CS2PivotConversion.java:1279)
	at org.eclipse.ocl.examples.xtext.oclinecore.cs2pivot.OCLinEcoreLeft2RightVisitor.visitOCLinEcoreConstraintCS(OCLinEcoreLeft2RightVisitor.java:69)
	at org.eclipse.ocl.examples.xtext.oclinecore.cs2pivot.AbstractOCLinEcoreLeft2RightVisitor.visitOCLinEcoreConstraintCS(AbstractOCLinEcoreLeft2RightVisitor.java:1)
	at org.eclipse.ocl.examples.xtext.oclinecore.oclinEcoreCST.impl.OCLinEcoreConstraintCSImpl.accept(OCLinEcoreConstraintCSImpl.java:182)
	at org.eclipse.ocl.examples.xtext.base.cs2pivot.CS2PivotConversion.visitLeft2Right(CS2PivotConversion.java:1279)
	at org.eclipse.ocl.examples.xtext.base.cs2pivot.BasePostOrderVisitor$ConstraintCSCompletion.execute(BasePostOrderVisitor.java:80)
	at org.eclipse.ocl.examples.xtext.base.cs2pivot.CS2PivotConversion.progressContinuations(CS2PivotConversion.java:736)
	at org.eclipse.ocl.examples.xtext.base.cs2pivot.CS2PivotConversion.update(CS2PivotConversion.java:1212)
	at org.eclipse.ocl.examples.xtext.base.cs2pivot.CS2Pivot.update(CS2Pivot.java:505)
	at org.eclipse.ocl.examples.xtext.base.utilities.CS2PivotResourceAdapter.refreshPivotMappings(CS2PivotResourceAdapter.java:129)
	at org.eclipse.ocl.examples.xtext.base.utilities.CS2PivotLinker.afterModelLinked(CS2PivotLinker.java:69)
	at org.eclipse.xtext.linking.impl.AbstractCleaningLinker.linkModel(AbstractCleaningLinker.java:44)
	at org.eclipse.xtext.resource.XtextResource.doLinking(XtextResource.java:279)
	at org.eclipse.xtext.linking.lazy.LazyLinkingResource.doLinking(LazyLinkingResource.java:82)
	at org.eclipse.ocl.examples.xtext.essentialocl.utilities.EssentialOCLCSResource.doLinking(EssentialOCLCSResource.java:98)
	at org.eclipse.xtext.resource.XtextResource.updateInternalState(XtextResource.java:247)
	at org.eclipse.xtext.resource.XtextResource.updateInternalState(XtextResource.java:237)
	at org.eclipse.xtext.resource.XtextResource.update(XtextResource.java:218)
	at org.eclipse.xtext.ui.editor.reconciler.XtextReconcilerUnitOfWork.process(XtextReconcilerUnitOfWork.java:55)
	at org.eclipse.xtext.ui.editor.reconciler.XtextReconcilerUnitOfWork.process(XtextReconcilerUnitOfWork.java:1)
	at org.eclipse.xtext.util.concurrent.IUnitOfWork$Void.exec(IUnitOfWork.java:36)
	at org.eclipse.xtext.util.concurrent.AbstractReadWriteAcces.modify(AbstractReadWriteAcces.java:49)
	at org.eclipse.xtext.ui.editor.model.XtextDocument$XtextDocumentLocker.modify(XtextDocument.java:181)
	at org.eclipse.xtext.ui.editor.model.XtextDocument.internalModify(XtextDocument.java:90)
	at org.eclipse.xtext.ui.editor.reconciler.XtextDocumentReconcileStrategy.reconcile(XtextDocumentReconcileStrategy.java:44)
	at org.eclipse.xtext.ui.editor.reconciler.XtextReconciler.run(XtextReconciler.java:254)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)



However, as I said this is not really my main problem but I'm rather stuck on how to create a collection of collections in my OCL expression, since what I get in return is a flat list of components. Any idea how to reach this ?

Thanks for the help.
Re: Limitations of OCL [message #1011410 is a reply to message #1011383] Tue, 19 February 2013 09:24 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4035
Registered: July 2009
Senior Member
Hi

components[0] is the syntax for a qualified association; not properly
supported yet. (https://bugs.eclipse.org/bugs/show_bug.cgi?id=401185
raised).

You need a 1-based ->at(i) for ordered collection access.

Regards

Ed Willink

On 19/02/2013 13:01, Cedric Moonen wrote:
> The connector end was not really a problem, since I could solve it in
> my OCL expression. However, for convenience purposes I tried to add an
> "otherEnd" convenience method as you suggested (a bit simplified here):
>
> class Connector
> {
> property components#connections : Component[2..2] { ordered };
> operation otherEnd(anEnd : Component) : Component { ordered }
> {
> body: if anEnd = components[0] then components[1] else
> components[0] endif;
> }
> }
>
>
> Unfortunately, this is not accepted by the OCLinEcore editor as there
> is an error marker on top of the editor. The error message says: "Null
> pointer exception: null (see logs for details)". So I guess this is
> probably a bug.
>
> Here is the stack trace:
> java.lang.NullPointerException
> at
> org.eclipse.ocl.examples.xtext.essentialocl.cs2pivot.EssentialOCLLeft2RightVisitor.visitBinaryOperatorCS(EssentialOCLLeft2RightVisitor.java:851)
> at
> org.eclipse.ocl.examples.xtext.essentialocl.cs2pivot.AbstractEssentialOCLLeft2RightVisitor.visitBinaryOperatorCS(AbstractEssentialOCLLeft2RightVisitor.java:1)
> at
> org.eclipse.ocl.examples.xtext.essentialocl.essentialOCLCST.impl.BinaryOperatorCSImpl.accept(BinaryOperatorCSImpl.java:166)
> at
> org.eclipse.ocl.examples.xtext.base.cs2pivot.CS2PivotConversion.visitLeft2Right(CS2PivotConversion.java:1279)
> at
> org.eclipse.ocl.examples.xtext.essentialocl.cs2pivot.EssentialOCLLeft2RightVisitor.visitInfixExpCS(EssentialOCLLeft2RightVisitor.java:1015)
> at
> org.eclipse.ocl.examples.xtext.essentialocl.cs2pivot.AbstractEssentialOCLLeft2RightVisitor.visitInfixExpCS(AbstractEssentialOCLLeft2RightVisitor.java:1)
> at
> org.eclipse.ocl.examples.xtext.essentialocl.essentialOCLCST.impl.InfixExpCSImpl.accept(InfixExpCSImpl.java:219)
> at
> org.eclipse.ocl.examples.xtext.base.cs2pivot.CS2PivotConversion.visitLeft2Right(CS2PivotConversion.java:1279)
> at
> org.eclipse.ocl.examples.xtext.essentialocl.cs2pivot.EssentialOCLLeft2RightVisitor.visitIfExpCS(EssentialOCLLeft2RightVisitor.java:988)
> at
> org.eclipse.ocl.examples.xtext.essentialocl.cs2pivot.AbstractEssentialOCLLeft2RightVisitor.visitIfExpCS(AbstractEssentialOCLLeft2RightVisitor.java:1)
> at
> org.eclipse.ocl.examples.xtext.essentialocl.essentialOCLCST.impl.IfExpCSImpl.accept(IfExpCSImpl.java:334)
> at
> org.eclipse.ocl.examples.xtext.base.cs2pivot.CS2PivotConversion.visitLeft2Right(CS2PivotConversion.java:1279)
> at
> org.eclipse.ocl.examples.xtext.oclinecore.cs2pivot.OCLinEcoreLeft2RightVisitor.visitOCLinEcoreConstraintCS(OCLinEcoreLeft2RightVisitor.java:69)
> at
> org.eclipse.ocl.examples.xtext.oclinecore.cs2pivot.AbstractOCLinEcoreLeft2RightVisitor.visitOCLinEcoreConstraintCS(AbstractOCLinEcoreLeft2RightVisitor.java:1)
> at
> org.eclipse.ocl.examples.xtext.oclinecore.oclinEcoreCST.impl.OCLinEcoreConstraintCSImpl.accept(OCLinEcoreConstraintCSImpl.java:182)
> at
> org.eclipse.ocl.examples.xtext.base.cs2pivot.CS2PivotConversion.visitLeft2Right(CS2PivotConversion.java:1279)
> at
> org.eclipse.ocl.examples.xtext.base.cs2pivot.BasePostOrderVisitor$ConstraintCSCompletion.execute(BasePostOrderVisitor.java:80)
> at
> org.eclipse.ocl.examples.xtext.base.cs2pivot.CS2PivotConversion.progressContinuations(CS2PivotConversion.java:736)
> at
> org.eclipse.ocl.examples.xtext.base.cs2pivot.CS2PivotConversion.update(CS2PivotConversion.java:1212)
> at
> org.eclipse.ocl.examples.xtext.base.cs2pivot.CS2Pivot.update(CS2Pivot.java:505)
> at
> org.eclipse.ocl.examples.xtext.base.utilities.CS2PivotResourceAdapter.refreshPivotMappings(CS2PivotResourceAdapter.java:129)
> at
> org.eclipse.ocl.examples.xtext.base.utilities.CS2PivotLinker.afterModelLinked(CS2PivotLinker.java:69)
> at
> org.eclipse.xtext.linking.impl.AbstractCleaningLinker.linkModel(AbstractCleaningLinker.java:44)
> at
> org.eclipse.xtext.resource.XtextResource.doLinking(XtextResource.java:279)
> at
> org.eclipse.xtext.linking.lazy.LazyLinkingResource.doLinking(LazyLinkingResource.java:82)
> at
> org.eclipse.ocl.examples.xtext.essentialocl.utilities.EssentialOCLCSResource.doLinking(EssentialOCLCSResource.java:98)
> at
> org.eclipse.xtext.resource.XtextResource.updateInternalState(XtextResource.java:247)
> at
> org.eclipse.xtext.resource.XtextResource.updateInternalState(XtextResource.java:237)
> at
> org.eclipse.xtext.resource.XtextResource.update(XtextResource.java:218)
> at
> org.eclipse.xtext.ui.editor.reconciler.XtextReconcilerUnitOfWork.process(XtextReconcilerUnitOfWork.java:55)
> at
> org.eclipse.xtext.ui.editor.reconciler.XtextReconcilerUnitOfWork.process(XtextReconcilerUnitOfWork.java:1)
> at
> org.eclipse.xtext.util.concurrent.IUnitOfWork$Void.exec(IUnitOfWork.java:36)
> at
> org.eclipse.xtext.util.concurrent.AbstractReadWriteAcces.modify(AbstractReadWriteAcces.java:49)
> at
> org.eclipse.xtext.ui.editor.model.XtextDocument$XtextDocumentLocker.modify(XtextDocument.java:181)
> at
> org.eclipse.xtext.ui.editor.model.XtextDocument.internalModify(XtextDocument.java:90)
> at
> org.eclipse.xtext.ui.editor.reconciler.XtextDocumentReconcileStrategy.reconcile(XtextDocumentReconcileStrategy.java:44)
> at
> org.eclipse.xtext.ui.editor.reconciler.XtextReconciler.run(XtextReconciler.java:254)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
>
>
>
> However, as I said this is not really my main problem but I'm rather
> stuck on how to create a collection of collections in my OCL
> expression, since what I get in return is a flat list of components.
> Any idea how to reach this ?
>
> Thanks for the help.
Re: Limitations of OCL [message #1011483 is a reply to message #1011410] Tue, 19 February 2013 11:14 Go to previous messageGo to next message
Cedric Moonen is currently offline Cedric Moonen
Messages: 270
Registered: August 2009
Senior Member
Hi Ed,

Thanks again for the time you take into this.

I still have issue figuring things out so, I will make my example easier and give a concrete example of the results am I looking for. I hope this will make things easier for you to understand.

So, I adapted my domain model to take the connectors out of the picture (the components list the other components to which they are connected):

package components : components = 'platform:/resource/Components/model/components.oclinecore'
{
	class Container
	{
		property components : Component[*] { ordered composes };
		property firstComponent : Component { ordered };
		property lastComponent : Component { ordered };
		property paths : Path[*] { ordered derived transient volatile };
	}
	class Component
	{
		attribute name : String[?] { ordered };
		property linkedComponents#linkedComponents : Component[*] { ordered };
	}

	class Path
	{
		property components : Component[*] { ordered };
	}
}


Now, if I have an instance of this meta-model which looks like in the attached image and with comp1 being the first component and comp4 being the last component (defined in the container), what I would like to have as a result is this (the first Set can be any kind of collection):
Set { OrderedSet {comp1, comp2, comp4}, OrderedSet{comp1, comp3, comp4} }


All pathes have to start from comp1 and finish at comp4. So, if a fifth component is attached to comp4, it should be rejected from the path (since the last component is already reached). Any idea how to do that ?
Re: Limitations of OCL [message #1011501 is a reply to message #1011483] Tue, 19 February 2013 11:41 Go to previous message
Ed Willink is currently offline Ed Willink
Messages: 4035
Registered: July 2009
Senior Member
Hi

Have the closure body return null when you don't want to do any more.

Regards

Ed Willink


On 19/02/2013 16:14, Cedric Moonen wrote:
> Hi Ed,
>
> Thanks again for the time you take into this.
>
> I still have issue figuring things out so, I will make my example easier and give a concrete example of the results am I looking for. I hope this will make things easier for you to understand.
>
> So, I adapted my domain model to take the connectors out of the picture (the components list the other components to which they are connected):
>
> package components : components = 'platform:/resource/Components/model/components.oclinecore'
> {
> class Container
> {
> property components : Component[*] { ordered composes };
> property firstComponent : Component { ordered };
> property lastComponent : Component { ordered };
> property paths : Path[*] { ordered derived transient volatile };
> }
> class Component
> {
> attribute name : String[?] { ordered };
> property linkedComponents#linkedComponents : Component[*] { ordered };
> }
>
> class Path
> {
> property components : Component[*] { ordered };
> }
> }
>
> Now, if I have an instance of this meta-model which looks like in the attached image and with comp1 being the first component and comp4 being the last component (defined in the container), what I would like to have as a result is this (the first Set can be any kind of collection):
> Set { OrderedSet {comp1, comp2, comp4}, OrderedSet{comp1, comp3, comp4} }
>
> All pathes have to start from comp1 and finish at comp4. So, if a fifth component is attached to comp4, it should be rejected from the path (since the last component is already reached). Any idea how to do that ?
Previous Topic:EssentialOCL editing support in papyrus for OrderedSet
Next Topic:CompleteOCL standalone validation of uml model
Goto Forum:
  


Current Time: Sun Aug 31 02:33:30 EDT 2014

Powered by FUDForum. Page generated in 0.02021 seconds