Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Ideas for Traceability
Ideas for Traceability [message #431639] Sun, 19 July 2009 19:45 Go to next message
Timothy Marc is currently offline Timothy MarcFriend
Messages: 547
Registered: July 2009
Senior Member
Hey all,

i have to deal with traceability between several Ecore models
programatically. So, in my opinion traceability is nothing more than a
map between two or more elements in way, that

- one source element maps bidirectional to a target element

- as well as any other related multiplicities like 1-n, n-1 or n-m
between source and target models.

Commonly, those elements belong to different metamodels. Now i have
spend some time to consider how a generic traceability model could be
established with EMF. I came to a simple and unspectacular result:

Trace:EClass
+ traces:TraceEntry[1..*]

TraceEntry:EClass
+ source:EObject [1..*]
+ target:EObject [1..*]

I know, that this isn't a very fine-grained trace representation, but i
think this could work for any relation between Ecore models, couldn't it?

It would be nice if anyone could give me a hint, whether this really
simple model, and in particular the most generic references of type
EObject, wouldn't work.

Thanks a lot.

Timothy
Re: Ideas for Traceability [message #431652 is a reply to message #431639] Mon, 20 July 2009 18:53 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30688
Registered: July 2009
Senior Member
Timothy,

Comments below.

Timothy Marc wrote:
> Hey all,
>
> i have to deal with traceability between several Ecore models
> programatically. So, in my opinion traceability is nothing more than a
> map between two or more elements in way, that
>
> - one source element maps bidirectional to a target element
>
> - as well as any other related multiplicities like 1-n, n-1 or n-m
> between source and target models.
>
> Commonly, those elements belong to different metamodels. Now i have
> spend some time to consider how a generic traceability model could be
> established with EMF. I came to a simple and unspectacular result:
>
> Trace:EClass
> + traces:TraceEntry[1..*]
>
> TraceEntry:EClass
> + source:EObject [1..*]
> + target:EObject [1..*]
There's the Mapping model you could reuse;
org.eclipse.emf.mapping.ecore2ecore in particular...
>
> I know, that this isn't a very fine-grained trace representation, but
> i think this could work for any relation between Ecore models,
> couldn't it?
>
> It would be nice if anyone could give me a hint, whether this really
> simple model, and in particular the most generic references of type
> EObject, wouldn't work.
>
> Thanks a lot.
>
> Timothy
Re: Ideas for Traceability [message #431663 is a reply to message #431652] Tue, 21 July 2009 09:48 Go to previous messageGo to next message
Timothy Marc is currently offline Timothy MarcFriend
Messages: 547
Registered: July 2009
Senior Member
Ed,

thanks. I just have had a little look on it... indeed, it seems to be a
good starting point for realizing a traceability. But is there any
information available, how to use the mapping model commonly? I searched
for a while, but didn't found anything.

Thanks in advance again.
Timothy

Ed Merks schrieb:
> Timothy,
>
> Comments below.
>
> Timothy Marc wrote:
>> Hey all,
>>
>> i have to deal with traceability between several Ecore models
>> programatically. So, in my opinion traceability is nothing more than a
>> map between two or more elements in way, that
>>
>> - one source element maps bidirectional to a target element
>>
>> - as well as any other related multiplicities like 1-n, n-1 or n-m
>> between source and target models.
>>
>> Commonly, those elements belong to different metamodels. Now i have
>> spend some time to consider how a generic traceability model could be
>> established with EMF. I came to a simple and unspectacular result:
>>
>> Trace:EClass
>> + traces:TraceEntry[1..*]
>>
>> TraceEntry:EClass
>> + source:EObject [1..*]
>> + target:EObject [1..*]
> There's the Mapping model you could reuse;
> org.eclipse.emf.mapping.ecore2ecore in particular...
>>
>> I know, that this isn't a very fine-grained trace representation, but
>> i think this could work for any relation between Ecore models,
>> couldn't it?
>>
>> It would be nice if anyone could give me a hint, whether this really
>> simple model, and in particular the most generic references of type
>> EObject, wouldn't work.
>>
>> Thanks a lot.
>>
>> Timothy
Re: Ideas for Traceability [message #431682 is a reply to message #431663] Tue, 21 July 2009 14:23 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30688
Registered: July 2009
Senior Member
Timothy,

There's next to no documentation for this. Sorry. :-(


Timothy Marc wrote:
> Ed,
>
> thanks. I just have had a little look on it... indeed, it seems to be
> a good starting point for realizing a traceability. But is there any
> information available, how to use the mapping model commonly? I
> searched for a while, but didn't found anything.
>
> Thanks in advance again.
> Timothy
>
> Ed Merks schrieb:
>> Timothy,
>>
>> Comments below.
>>
>> Timothy Marc wrote:
>>> Hey all,
>>>
>>> i have to deal with traceability between several Ecore models
>>> programatically. So, in my opinion traceability is nothing more than
>>> a map between two or more elements in way, that
>>>
>>> - one source element maps bidirectional to a target element
>>>
>>> - as well as any other related multiplicities like 1-n, n-1 or n-m
>>> between source and target models.
>>>
>>> Commonly, those elements belong to different metamodels. Now i have
>>> spend some time to consider how a generic traceability model could
>>> be established with EMF. I came to a simple and unspectacular result:
>>>
>>> Trace:EClass
>>> + traces:TraceEntry[1..*]
>>>
>>> TraceEntry:EClass
>>> + source:EObject [1..*]
>>> + target:EObject [1..*]
>> There's the Mapping model you could reuse;
>> org.eclipse.emf.mapping.ecore2ecore in particular...
>>>
>>> I know, that this isn't a very fine-grained trace representation,
>>> but i think this could work for any relation between Ecore models,
>>> couldn't it?
>>>
>>> It would be nice if anyone could give me a hint, whether this really
>>> simple model, and in particular the most generic references of type
>>> EObject, wouldn't work.
>>>
>>> Thanks a lot.
>>>
>>> Timothy
Re: Ideas for Traceability [message #431726 is a reply to message #431639] Thu, 23 July 2009 09:25 Go to previous messageGo to next message
Stefan Winkler is currently offline Stefan WinklerFriend
Messages: 301
Registered: July 2009
Location: Germany
Senior Member
Hi Timothy,

first of all, let me tell you that there's quite a bit of research
material on different aspects of EMF traceability.
You should have a look at the ECMDA-TW proceedings and at the work done
by INRIA and other research groups who are doing traceability as part of
model transformations. Also, have a look at "Loosely coupled
traceability for ATL" which is contained in the ECMDA-FA 2005
proceedings: http://www.sintef.no/upload/10558/ECMDA-Proceedings.pdf.

In general, your basic model would work:

> Trace:EClass
> + traces:TraceEntry[1..*]
>
> TraceEntry:EClass
> + source:EObject [1..*]
> + target:EObject [1..*]
However, you have to be aware that, technically, you are linking
unidirectional from the trace to the model element(s). This means, that
you won't be able to directly browse outgoing traces from a model
element. Instead you would have to iterate over all traces and find
those which are applicable.

The alternative would be (if you have the option), to use a
ITraceabilityTarget interface instead of EObject. This interface could
then realize the opposites of the source and target relations. However,
you would have to make every model element you want to be traceabale
inherit the interface.

A hybrid solution would be to use your basic model for recording traces
and if you want to browse traces you would build up a structure more
like my latter description to make navigation easier.


Cheers,
Stefan

>
> I know, that this isn't a very fine-grained trace representation, but
> i think this could work for any relation between Ecore models,
> couldn't it?
>
> It would be nice if anyone could give me a hint, whether this really
> simple model, and in particular the most generic references of type
> EObject, wouldn't work.
>
> Thanks a lot.
>
> Timothy
Re: Ideas for Traceability [message #431769 is a reply to message #431726] Fri, 24 July 2009 12:23 Go to previous message
Timothy Marc is currently offline Timothy MarcFriend
Messages: 547
Registered: July 2009
Senior Member
Hi Stefan,

i've found several papers concerning traceability, but i think i got a
wrong understanding of what a traceability implementatiotn should
support. IMHO it is just an ordinary mapping from one to another element
(eobject in case of EMF).

The additional interface ITraceabilityElement is only applicable, if the
developer has the full autonomy regarding the changeability and
maintenance of the involved models. If a new release cancels the
interface in a future release the whole thing won't work anymore.

So, i think, for inter-model traceability or intra-model, where all
models are under control of the developer (me), the interface variant
would work. In other cases, for example to establish traceability
between my model and a UML2 model, i need a more generic trace
framework, like ecore2ecore (or an own version). Even for the
traceability between model and informal artifacts (requirements inside a
spreadsheet), a generic approach had to be taken.

Am i right?!

Timothy

Stefan Winkler schrieb:
> Hi Timothy,
>
> first of all, let me tell you that there's quite a bit of research
> material on different aspects of EMF traceability.
> You should have a look at the ECMDA-TW proceedings and at the work done
> by INRIA and other research groups who are doing traceability as part of
> model transformations. Also, have a look at "Loosely coupled
> traceability for ATL" which is contained in the ECMDA-FA 2005
> proceedings: http://www.sintef.no/upload/10558/ECMDA-Proceedings.pdf.
>
> In general, your basic model would work:
>
>> Trace:EClass
>> + traces:TraceEntry[1..*]
>>
>> TraceEntry:EClass
>> + source:EObject [1..*]
>> + target:EObject [1..*]
> However, you have to be aware that, technically, you are linking
> unidirectional from the trace to the model element(s). This means, that
> you won't be able to directly browse outgoing traces from a model
> element. Instead you would have to iterate over all traces and find
> those which are applicable.
>
> The alternative would be (if you have the option), to use a
> ITraceabilityTarget interface instead of EObject. This interface could
> then realize the opposites of the source and target relations. However,
> you would have to make every model element you want to be traceabale
> inherit the interface.
>
> A hybrid solution would be to use your basic model for recording traces
> and if you want to browse traces you would build up a structure more
> like my latter description to make navigation easier.
>
>
> Cheers,
> Stefan
>
>> I know, that this isn't a very fine-grained trace representation, but
>> i think this could work for any relation between Ecore models,
>> couldn't it?
>>
>> It would be nice if anyone could give me a hint, whether this really
>> simple model, and in particular the most generic references of type
>> EObject, wouldn't work.
>>
>> Thanks a lot.
>>
>> Timothy
Previous Topic:EMF Ant Task Model Plug-in Class
Next Topic:make only particular EReferences considered by the CrossReferencer?
Goto Forum:
  


Current Time: Tue Dec 10 14:14:20 GMT 2019

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

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

Back to the top