Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [auto-iwg] Traceability

Dimitar,

The Modeling Platform is also looking at how to implement model version management to address the history of changes.   The intention is to have the modeling platform integrated with a model repository.

I hope this helps,
Ian


On 7/27/2010 10:17 AM, Dimitar.Peikov@xxxxxxx wrote:

Hello Andreas,

Model elements may change with the time, how to address history of changes (suspicious state for the link) and other attributes/properties of the traceability link?


Best regards,
________________________________
Dimitar Peikov
Engineering Manager
Software Lead Expert / Driver Information
Engineering
Electronics Division Europe
Automotive Experience
Tel.: +359 2 930 6412
Fax: +359 2 930 6462
Mobile: +359 888 122 609
e-mail: Dimitar.Peikov@xxxxxxx
Internet:
www.johnsoncontrols.com

Johnson Controls Electronics Bulgaria EOOD
40 Tsarigradsko shose Blvd - EUROPARK building
1784 Sofia, Bulgaria



From: Andreas Graf <andreas.graf@xxxxxxxxx>
To: Automotive Industry Working Group <auto-iwg@xxxxxxxxxxx>
Date: 07/27/2010 03:22 PM
Subject: [auto-iwg] Traceability





Dear all,

as an action from our meeting, here is the description of "traceability" as addressed by the Eclipse Modeling Platform Working Group. Note that this basically fits
to a solution that we are currently developing as part of a research project and will be releasing as open source:

5. Traceability to identify connection between model elements.
5.1 The MP must support the ability to create relationships between models and model
artifacts that are independent of the meta-model. Tools must be able to show these
relationships and provide a level a traceability between the model elements.
5.2 Artifact authors should be able to specify the relationships a high level and then elaborate
in more detail and provide traceability a different levels of the model hierarchy.
5.3 The MP must support the traceability between non-modelled artifacts and various types of
models and elements/parts of models.
Use Case
Ericsson
For example, requirements might not be modelled but we still need to be able to trace from
them to various types of models and elements/parts of models.
An example can be to trace from a requirement to models/model elements where the
requirement is designed and implemented and to models where it is verified.
And vice versa from design,


--
Andreas Graf
BDM Automotive
Mobil: +49 (0) 151-10860479 (preferred)
Tel.: +49 (0) 7231 / 1 54 71-0
Fax.: +49 (0) 7231 / 1 54 71-29


Web:
http://www.itemis.de
Mail:
andreas.graf@xxxxxxxxx
Xing:
http://www.xing.com/profile/Andreas_Graf
Twitter:
http://www.twitter.com/grafandreas

itemis GmbH
Blücherstrasse 32
D-75177 Pforzheim
Rechtlicher Hinweis:
Amtsgericht Mannheim, HRB 50700996
Ust.Id.Nr.: DE250574762
Geschäftsführer: Sebastian Neus[attachment "smime.p7s" deleted by Dimitar Peikov/EUR/Johnson_Controls]
_______________________________________________
auto-iwg mailing list
auto-iwg@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/auto-iwg


_______________________________________________ auto-iwg mailing list auto-iwg@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/auto-iwg

--
Ian Skerrett
Director of Marketing
Eclipse Foundation
Tel: 613-224-9461 ext 227
Blog: ianskerrett.wordpress.com
Twitter: IanSkerrett

Plan to Attend Eclipse Summit Europe
Nov. 2-4, 2010 Ludwigsburg Germany

Back to the top