openETCS / requirements

WP2: Top Level Project for openETCS requirements
5 stars 13 forks source link

Use of UML/SysML and/or Ecore DataStructure in D2.4 #37

Closed MatthieuPERIN closed 10 years ago

MatthieuPERIN commented 10 years ago

Hi,

The given version of document D2.4 refers to an Ecore model for the data structure (§ 7.2 Data Model), whereas actual works on Bitwalker to Papyrus made by Toolchain participant work on a XML description of the data from subset 26 directly included as a SysML/UML DatatStructure (see Issue https://github.com/openETCS/toolchain/issues/204 and model proposed here: https://github.com/openETCS/dataDictionary/tree/master/Example_model/SysML_Papyrus_CEA_example).

These two works must, IMHO, be merged to decide what model support the data structure.

A quick pros and cons may be necessary to decide, but It seems strange to me to build an Ecore DataStructure that will be then imported into SysML model (which is NOT an automatic process) when we can produce a high level DataStructure in SysML with a automated Ecore Structure Generation if needed.

MariellePetitDoche commented 10 years ago

The aim of D2.4 is to give a specification of the need, not a solution. Ecore model used it propose a specification of the need, not an implementation, The current state of the plug-in and its associated example do not allow me to write such clear specification and to ensure all the items discussed during previous telco are covered, and that all the process can be covered (all modelling step, with all language + VnV + safety). If it is the case, please to provide the specification of the items enclosed in the plug-in.

Besides, a discussion as already been arise on these topics : https://github.com/openETCS/toolchain/issues/213, and as I said, discussion and specification start first on the Ecore model, before a solution was proposed with Papyrus.

MariellePetitDoche commented 10 years ago

§7.2 "In the following, we give the specification of these items and the links between them. The specification of this data-model is based on an Ecore model. However it can be implemented with any means or tools, depending the decision of the project partners."

MatthieuPERIN commented 10 years ago

Thanks for the precision Marielle, I was just surprise to see Ecore model.

Thus, a hard point to me is that Ecore Model could not be easily re-used inside Papyrus without a lot of manual work, whereas a Ecore model can automatically be created from a SysML Model.

A DSL can be expressed in MOF and then be implemented inside Papyrus using a Profile, but we may then not use all the Built-in capabilities offered by UML/SysML (e.g. ValueType, Unit & Dimension).

In one word, It is strange to mo to express a specification that could not be automatically used as a basis of an implementation within a model-driven process.

MariellePetitDoche commented 10 years ago

In the current state of the project, no clear choice have been made how to deal with data dictionnary, and lot of question are still open. Besides we can consider the proposition here :https://github.com/openETCS/toolchain/issues/193 as a proposition of direct implementation from the Ecore model.

I repeat that the objective of this document is to give an informal specification of the need for the OpenETCS project, less ambiguous as possible and as easy to understand for everybody as possible.

As i can not write a DSL which covered this objective and which enough independent from tool and technical solution point of view, I propose to close this issue by the end of this week if not clear alternative is proposed to improve the document.