Home » Modeling » EMF » Ideas for Traceability
| Ideas for Traceability [message #431639] |
Sun, 19 July 2009 19:45  |
 Timothy Marc
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  |
Ed Merks
Messages: 33140
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Ideas for Traceability [message #431663 is a reply to message #431652] |
Tue, 21 July 2009 09:48 |
Timothy Marc
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 |
Ed Merks
Messages: 33140
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Ideas for Traceability [message #431726 is a reply to message #431639] |
Thu, 23 July 2009 09:25 |
Stefan Winkler
Messages: 307
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 |
Timothy Marc
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
|
|
|
Goto Forum:
Current Time: Wed Apr 24 14:09:49 GMT 2024
Powered by FUDForum. Page generated in 0.03009 seconds |
] 
Search
Help
Register
Login
Home
