Hi all! I am on a trip in Brazil to learn more about openEHR/13606/MLHIM-related projects, actors and companies. At LNCC <http://www.lncc.br/> we discussed among other things EMF <http://www.eclipse.org/modeling/emf/> versions of openEHR models and then I realized there was an off-list discussion that some of us had and intended to move to the tech-list but obviously forgot to. Below you find a slightly shortened version of the discussion.
Feel free to join in. If I understood things right LNCC has experimented with creation of EMF models from openEHR XML schemas or something similar. Some partly related info on the openEHR wiki: http://www.openehr.org/wiki/display/dev/Experimental+generation+of+code+and+documentation+from+UML ( or as short URL: http://www.openehr.org/wiki/x/OwAt ) Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 Forwarded conversation Subject: XMI exchange of class models ------------------------ From: *Eric Browne* <eric.bro...@montagesystems.com.au> Date: Wed, Oct 13, 2010 at 01:56 To: Erik Sundvall <erisu at imt.liu.se> Cc: Thomas Beale <thomas.beale at oceaninformatics.com> Hi Erik, I don't know if you still have an interest in this, but I've just stumbled on this recent Masters Thesis by Stefan Teijgeler that may be of use. There's a section devoted to examining the import/export/exchange capability of various UML modelling tools. Results are pretty depressing, and there's not a huge amount of analysis as to the reasons for incompatibilities. fmt.cs.utwente.nl/msc-completed/teijgeler.pdf regards, eric ---------- From: *Erik Sundvall* <erik.sundv...@liu.se> Date: Wed, Oct 13, 2010 at 07:55 To: Eric Browne <Eric.Browne at montagesystems.com.au> Cc: Thomas Beale <thomas.beale at oceaninformatics.com>, Tim Cook < timothywayne.cook at gmail.com> Hi! > http://fmt.cs.utwente.nl/msc-completed/teijgeler.pdf Thanks for the info Eric. Had a quick look and I come to the same summary as you do. So that probably means: if using Eclipse-based tools it's better to go directly for an ecore model than trying to be UML/XMI-centric when modelling. My impression is also that generics is a lot easier in ecore than UML/XMI (see e.g. http://eclipse.dzone.com/articles/generics-eclipse-modelling-fra). The quote "the UML representation is verbose and intricate in comparison to Ecore or Java." from http://www.eclipse.org/articles/article.php?file=Article-Defining-Generics-with-UML-Templates/index.html also indicates ecore might be easier than UML for generics modelling. There seems to be a default ecore to XMI serialisation mechanism if we need XMI output, but it's just one (probably incompatible) dialect of XMI if Teijgeler's thesis is correct. I believe it would not be too hard to convert between ecore and Tom's DADL-formalisation of the RM. Perhaps the same thing is possible for your formalisation Eric? Whatever we do, one interesting question is probably who will be doing RM modelling for specification updates and what tools will they prefer. After answering that I believe it would be useful to create an automated conversion path from that preferred format to at least ecore (unless ecore is the preferred editing format of course). Could you, Eric and Tom, bring up the issue (of determining at least one formal machine readable RM-specification format) in the openEHR Architecture Review Board? It might also be a good idea to bring up on the openEHR technical list, is it OK that I forward parts of this conversation to the list? Link list: EMF/ecore: http://www.eclipse.org/modeling/emf/?project=emf Acceleo, model to Java/Python/C++/C#/php etc conversion: http://www.acceleo.org/pages/home/en A textual form of ecore: http://wiki.eclipse.org/Emfatic Topcased, UML-ish graphical model editing: http://www.topcased.org/ Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 ---------- From: *Thomas Beale* <thomas.be...@oceaninformatics.com> Date: Wed, Oct 13, 2010 at 08:45 To: Erik Sundvall <erik.sundvall at liu.se> Cc: Eric Browne <Eric.Browne at montagesystems.com.au>, Tim Cook < timothywayne.cook at gmail.com>, Seref Arikan < serefarikan at kurumsalteknoloji.com> All, Seref and I have had a look at this issue, and came to exactly the same conclusion. I even bought the EMF book. It is depressingly weak in formal terms, and generics are dealt with in an appendix or final chapter from memory, where a reworked EMF core model is shown. Their modelling is quite bad, it is really amazing for me to see books promulgating such poor models, but at least it is there, it has generics, and AFAIK, it does work, since there are quite a lot of people using it now. In situations where I have to recommend some tool basis for doing a 'modelling stack' for e-health, EMF (despite the above comments) is the only thing I am able to suggest. One aim we have is to get openEHR fully represented in EMF, and quite frankly if we have to rewrite the ecore model properly, we will do it. One thing they got right is that tooling accepts changes you make even to core models. XMI should be avoided at all costs if you value your sanity. It cannot be saved because a) it is based on the hopelessly overcomplicated UML2 'infrastructure' and 'superstructure' specifications (I know people who quit the OMG committees in disgust when these were developed) and b) it mixes graphical rendering semantics with model semantics. The whole reason ecore exists is because XMI is such a dog to work with. Re: the dadl formalisation of the RM, our current intention is to morph it towards using ecore-friendly meta-model keywords (e.g. matching 'attribute', 'property', all that stuff). This won't be 100% perfect because the ecore model is not very good, and its generics model probably has a way to go. Nevertheless they do have a pretty good tooling vision, and it won't hurt us to move the dadl model in that direction. Whether we get to the point of being able to automatically suck it in to EMF remains to be seen, but we will try. If any of you have thoughts or wisdom to share on this, it is very welcome. Please keep Seref in the cc: loop because he works in Java (and Eiffel;-) an is keen to make some progress here. Just for reference, the openEHR RM models in their dadl form are posted at http://www.openehr.org/svn/knowledge2/TRUNK/rm_schemas/ - thomas ---------- From: *Seref Arikan* <serefari...@kurumsalteknoloji.com> Date: Wed, Oct 13, 2010 at 18:50 To: Thomas Beale <thomas.beale at oceaninformatics.com> Cc: Erik Sundvall <erik.sundvall at liu.se>, Eric Browne < Eric.Browne at montagesystems.com.au>, Tim Cook <timothywayne.cook at gmail.com> Dear all, EMF is a significant piece of work, and I've tried to identified its pros and cons in the context of openEHR related work. (I too bought the book btw, and I suggest that you do the same if you want a single document to use) Pros: ecore based approach allows access to lots of features, ranging from source code generation to persistence. Ecore drives XMI for you, which is good, since I personally hate digging XML based/related artefacts. Eclipse as a platform is investing heavily into EMF, and there is a huge amount of projects in the modelling space in Eclipse ecosystem, around EMF. Even though the book does not go into details much, generics support in EMF is very important IMHO, Here is the reason: in the context of openEHR implementation with Java, I am really not comfortable with java's implementation of generics. I think Sun choose backward compatibility over power, and implemented generics with type erasure. In various use cases, I ended up with implementation tasks where during runtime, I needed to identify actual types used for generic parameters, and you simply can't do this in Java, unless you've resorted to some weird hacks in your class design (which I'd rather avoid) EMF's generics support is worth looking into since it may allow us to encapsulate information which we can't easily express&use with Java types. Rather than going through lots of workarounds and hacks with java generics, EMF may provide a cleaner tool for many tasks. Cons are also important for us, since they are the things we'll have to deal with. here is a list of things I've found out. Please feel free to correct me if you think anything is wrong here. Cons: EMF puts itself into the centre of many things, so you have to think in Ecore to build stuff. However, linking this rich domain to other things like the XSD schema(s) used in openEHR and other relevant standards may be tricky. Even connecting EMF models to well established software stacks may be a problem, for example: web service stacks has support for consuming plain java objects, but EMF objects end up being too heavyweight and complex for this kind of task. I've found some options, but none of them is trivial work. EMF uses ecore, and Ecore is a formalism that has been implemented mostly in Java at the moment. The reason I said mostly is, there is a project for generating c# code from ecore models, but time will tell if that'll be reliable and up to date. (their web page is down as of this moment) Overall, EMF is pretty much the strongest candidate out there for a capable, well established modelling technology, and just like Tom, I could only point towards EMF if you ask my choice for a large modelling tool/stack. To make use of it though, we'll probably have to sit down and model the RM in ecore, than start looking into ways of connecting this to other parts of our software. Eclipse ecosystem is rich enough (at least for me) to justify investment into EMF, but the size of the work is significant. I'm still trying to get my head around how to place things together: XML, EMF, Java, RM, web services.... I'd like to hear your opinions too. Where do you place EMF/Ecore in your work? Kind regards Seref ---------- From: *Tim Cook* <timothywayne.c...@gmail.com> Date: Wed, Oct 13, 2010 at 20:27 To: Seref Arikan <serefarikan at kurumsalteknoloji.com> Cc: Thomas Beale <thomas.beale at oceaninformatics.com>, Erik Sundvall < erik.sundvall at liu.se>, Eric Browne <Eric.Browne at montagesystems.com.au> On Wed, 2010-10-13 at 22:50 +0100, Seref Arikan wrote: > I'm still trying to get my head around how to place things together: > XML, EMF, Java, RM, web services.... I'd like to hear your opinions > too. Where do you place EMF/Ecore in your work? IMO, you are more likely to get answers by having this discussion on some Java modelling specific mailing list. At least that is where I would try. EMF/Ecore doesn't have a place in mine. Cheers, Tim ---------- From: *Erik Sundvall* <erik.sundv...@liu.se> Date: Mon, Oct 18, 2010 at 14:00 To: Seref Arikan <serefarikan at kurumsalteknoloji.com> Cc: Thomas Beale <thomas.beale at oceaninformatics.com>, Eric Browne < Eric.Browne at montagesystems.com.au>, Tim Cook <timothywayne.cook at gmail.com> Hi all! Thanks for the info regarding EMF plans. Seref wrote: > Where do you place EMF/Ecore in your work? I'd like to have an updated RM in a formal computer readable format that can... - generate maintainable code stubs in various languages using e.g. Acceleo ( http://www.acceleo.org/pages/home/en) - generate class diagrams and possibly other visualisations that can be used to explain openEHR - be used as source for generating diagrams and class explanation tables in the official openEHR specifications so that specs and implementations can be synchronized easier. Perhaps we could steal the "adopt an archetype"-thought and make tech-nerd version called "adopt an openEHR package" and via a wikipage coordinate an effort to turn the class documentation in the specification into EMF/Ecore piece by piece (preferrably in some kind of dependency order). I believe something like that was done to create/check parts of OSHIP. (Did that work fine Tim?) I previously asked if anybody minds that we copy this discussion to the openEHR technical list. I now ask again. If i hear no objections before Friday I'll try to find time to post it or parts of it to the list (and perhaps start a related wikipage). ---------- From: *Seref Arikan* <serefari...@kurumsalteknoloji.com> Date: Mon, Oct 18, 2010 at 14:32 To: Erik Sundvall <erik.sundvall at liu.se> Cc: Thomas Beale <thomas.beale at oceaninformatics.com>, Eric Browne < Eric.Browne at montagesystems.com.au>, Tim Cook <timothywayne.cook at gmail.com> Erik, I personally have no problem with this being carried to technical list. In fact, I was thinking that we were having the discussion under the tech list. We can go into more specific issues around a potential EMF based RM representation. I've encountered some issues, and worked some problems in my head, and I'd love to discuss them with others. Kind regards Seref ---------- From: *Thomas Beale* <thomas.be...@oceaninformatics.com> Date: Mon, Oct 18, 2010 at 16:17 To: Erik Sundvall <erik.sundvall at liu.se> Cc: Seref Arikan <serefarikan at kurumsalteknoloji.com>, Eric Browne < Eric.Browne at montagesystems.com.au>, Tim Cook <timothywayne.cook at gmail.com> it seems to me that since we already have a computable format, albeit non-standardised, but nevertheless formal and working (including representing generics properly) we should try and find a way of morphing that and/or converting it to a target model format, such as EMF. If we do this, we don't need a brute force package-by-package approach - we just need to work out the conversion algorithm and execute it. its no problem to me - that is where it should be! - thomas* * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110302/c91816e7/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110302/c91816e7/attachment.asc>
