Open rivettp opened 5 years ago
There are actually discrepancies between the UML diagrams and the ecore file - see issue #4.
The UML diagrams in the readme were manually created and do not exit in XMI format. You can, however, initialize an ecore diagram (which looks like a class diagram) from the ecore file (Right click on the file -> Initialize Ecore Diagram ...).
@hamzaed that assumes I have a whole Eclipse/EMF environment, which I don't, and don't really want to. I just want the metamodel as UML or MOF. TBH I'm a bit shocked that you guys don't use a UML model-driven approach since I saw you as MDA leaders. I would have thought it important for the project's future to keep the ecore file and the documentation in sync: the discrepancies (in both directions) in issue #4 were concerning - and those were just the ones I spotted by browsing quite casually through the ecore text - I suspect there may be more. That's why we have MDA so the artifacts are generated not hand-matched or re-created each time. And it seems onerous for someone (possibly me!) wanting to make a PR of metamodel changes to have to recreate the diagrams from scratch EACH TIME. What tool DO you use for editing the ecore - not a XML text editor I hope! And what tool for the UML diagrams?
I take your point on the need for better alignment between our metamodel and the documentation. We could indeed write a transformation from our Ecore metamodel to a "pure" UML class diagram but for us, the Ecore visualization has worked well enough.
To add to what @jcabot said, we aim at developing a model-driven approach using EMF which requires the use of Ecore to represent metamodels. We didn't want to target a full-MDA approach yet. This allows us to rely only on a basic Eclipse installation (just with EMF) and later the user can select other modeling standards like UML.
Eclipse includes a tree based editor with property views to manipulate Ecore models. It is also possible to use Ecore diagrams for this purpose. We used UML diagrams (which we drew manually) to facilitate understanding the metamodel. We agree that a better support for UML would be useful for the future.
Regarding the inconsistencies you mentioned, we have to admit that this is a prototype and therefore this kind of issues may appear. We’ll try to fix them as soon as possible. As an open source project, we invite anyone to contribute to improve the project so any help on this direction is welcome.
Clearly a UML model exists since the metamodel is represented in the readme using UML diagrams. However the UML (either in XMI or a tool-specific format for the diagrams) is not part of the project. That would be useful for maintaining and extending it (e.g. for new versions of OAS).