Home » Modeling » OCL » Limitations of OCL
| | |
| Re: Limitations of OCL [message #1011009 is a reply to message #1010989] |
Mon, 18 February 2013 16:51   |
 Ed Willink
Messages: 7669
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 #1011368 is a reply to message #1011337] |
Tue, 19 February 2013 12:22 |
Ed Willink
Messages: 7669
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 #1011483 is a reply to message #1011410] |
Tue, 19 February 2013 16:14 |
Cedric Moonen
Messages: 274
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 16:41 |
Ed Willink
Messages: 7669
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 ?
|
|
|
Goto Forum:
Current Time: Sun Sep 15 11:35:27 GMT 2024
Powered by FUDForum. Page generated in 0.04802 seconds |
] 
Search
Help
Register
Login
Home
