Hi Thomas and others, Before you start reading, I want to tell you, I think OpenEhr is a very valuable project, and many people want to use the concepts. There are however difficulties which I want to address. If sometimes my writings seem unpolite or harsh, please keep in mind that English is not my second language, in fact it is the fourth language I learned in my live. This can cause some of my expressions to be clumsy or harder then I meant to.
I spent quite some time last week with studying the OpenEhr-website, and, as I said, it is very valuable, there are also a lot of frustrations one has to experience when diving into the project. I express myself with a lot of words, I often do, afraid people do not understand me, I do a lot of over-explaining. I admire when people can express themselves with not so many words, but as I see, sometimes this can also come to misunderstandings. This is an important subject for me, at this time, so I do not want to take risks of misunderstanding. Sometimes I also repeat myself because, different text-portions require a similar but slightly different approach or answer. So please be patient with me. A long introduction (I will not do it again!!) > > there is a Java ITS guide, which will be included here. The > documentitself is available at > http://svn.openehr.org/specification/BRANCHES/Release-1.0-candidate/publish >ing/its/Java/openEHR-JavaITS.pdf This document must be new, or I just have missed it. It is for a programmer very interesting document. Such documents prevents that programmers have to re-invent things, and can prevent unnecessary branching of code and concepts, which without such information can easily happen. Necessary branching, which is explainable can be a good thing, but unnecessary or unintentional branching can be very bad and confusing. > > > - Although there is a lot of Java-code, but it represents a previous > > version, and there is no guaranteed effort that it will be up to date > > with the official Openehr-Eiffel-code. > > It can be used as is, but for own risk for missing the project > > developments. > > this is correct, it is not up to date. The intention is that it will be > brought up to date very soon after the Feb 1 publishing of Release 1.0, > probably by my group at UCL in London. I will wait a bit with studying the code, anyway, I start studying the code when I start the project, I am thinking of. The expectation is that this will be very soon. > > > - One can say, the Eiffel-code, as Thomas states somewhere, is the > > case-tool, it represents the formal state of work/definitions. > > One can create dotnet-libraries with it, which is already done. I can > > load them in my Visual Studio and Delphi.NET. But I have no way of > > checking if there is something happening behind the > > interface-properties, or if they are just there as placeholders for > > later use. My knowledge of Eiffel is really not enough for judging the > > source-files. > > are you talking about the ref_impl_eiffel repository? You don't have to > use that if you are not interested in Eiffel. But I don't know what you > mean by "interface properties" above... It may be a way of describing, connected to other programming environments. Some people may find following a bit boring, but I use this to explain what I mean by mixing two enviroments and the problems I experience. Anyway, just to make it clear. <example> A class has an "interface", this what it makes visible to other classes. A property is some characteristic of a class. F.e a class Person has a property bodyLength. This can be in inches or centimeters. For example bodyLength can give you centimeters or inches, depending on which Local is configured: In java one publishes the getters and setters, they do not use properties often,though it could be possible. In object pascal one publishes the property, and private implements the getters and setters, they do not have to be public or published, the compiler arranges the connection. One can also publish the getters and setters in object pascal In Eiffel I don't know. As you can see on the pseudo-code below, I am used to Pascal, Java and C(++), I mix them so anyone can understand. I call it Jascal++ ;-) const BRITISH = 0; const OTHER=1; class Person{ public property bodyLength:Integer read getLength; public property Local write setLocal; private function getLength:Integer; private procedure setLocal(value:Integer); private fLength:Integer; private fLocal:Integer; } procedure Person.SetLocal(val:Integer); { fLocal:=val; } function Person.getLength:Integer{ if fLocal=BRITISH then Result := fLength/2.54 else Result := fLength } </example> In a case tool, only the class-interfaces is mentioned, and in a short way, eventually documentation added. In a case tool a class would look like Person ---------------- bodyLength:Integer Local:Integer; <comment> (In XMI one would get about the same (but then in XML). A case-tool can load the XMI, and generate code following the syntax and programming standards of that particular language. I know there are shortcomings in XMI, but still I think, it is better then nothing, in accompanying docs, want could explain the shortcomings. Most of the classes and their particularities can be expressed in XMI) </comment> The implementation-part is in the code, never seen implementation-parts in a case-tool. It is possible, but rarely done. When you use a case-tool which is at the same time a programming-enviroment, then you can eventually compile the code, but there will be no implementation behind the class-properties/methods, and in the compiled product, it is hard to discover which property/method has implementation-code behind and which not. Escpecially when it is not explicitely said. When I find a DLL, which is compiled code, one could assume, it has all the implementation-code in it, why would one else compile it. But the user of the environment as a case-tool may also want to compile, just for checking for errors. So in this mixed case/programming-environment it is possible to find a dotnet-dll, which is large, publishing all the classes, but has no or not all implementation-code. > > > This is a confusing and maybe conflicting situation. > > Because the code is at the same time case-tool storage, it serves two > > purposes, which can for an outsider be confusing. > > In a case-tool there is no need to write code behind the properties of > > a class, one does not want to do that because code-writing is another > > kind of job then software-architecture. A case-tool is a tool for an > > architect, a designer, not for a programmer, although those two > > professions can come together in one person, an outsider can never be > > sure who was talking here behid this particular property or method. > > From my point of view, it is very simple. We express the openEHR models > in Eiffel, which is a nearly pure OO environment, and we compile the > model to get code. If you write code into the routines, then it is the > same as programming. That's the whole idea seamless software > development. We then build executables on Windows (.exe or .Net > assembly), Linux (we're not doing this yet, but you just recompile on > Linux to get an executable) and on the Mac (we have done some initial > recompiles of the ADL workbench on the Mac, but there are some GUI > anomalies to be solved). But all this is only relevant if you want to > have any contact with Eiffel. Then I understand that the Eiffel-code has its implementation-parts worked out. <comment> The dotnet-DLL could then be used in a project. Maybe it even can be used in Mono, because there want be much Windows-API-stuff in it. Depending of course on the dotnet-version. I think the OpenEhr kernel does not take advantage of dotnet 2.0, so for compatibility reasons one could stick to dotnet 1.1, for the time being </comment> I can understand, that using Eiffel in this way has a lot of advantage for you, but for people using other programming environments it is difficult. So interoperability to other programming environments is not so good. This is a bit of a vendor lockin, or better said, to a programminglanguage-lockin <eiffelstudio> One is stuck to a certain environment. I downloaded the community-version of Eiffel-studio 5.6, and I really had problems to get the thing going. And I am used to many IDE's, Visual Studio, Borland-IDE's, KDevelop, and more. Also worked a bit with Eclipse. Mostly it is simple, start a project, create new classes or add existing ones by adding sourcefiles. Eiffel Studio does these thing a different way, even in the helpfile there is no entry which says: "Add a source file to a project." I used it a few hours, then went back to tools in which I am much more productive. I can get used to it, but I must say, it is not very intuitive for me to work with. </eiffelstudio> And since the "case-tool" Eiffel can only generate Eiffel-code, users op other programming environments have to completely rewrite the code from scratch. If one could use an XMI-model, which is an OMG-standard, one could easily import/generate the code/classes and use them in an IDE and language of choice. Most programming languages have a way to connect to XMI. Still there will be a lot work to do, but much less then now, and one can easier, and is also forced more to follow the code-concepts. I understand from a previous mail from you years ago, there are two main advantages of Eiffel, multiple inheritance and the use of generic template-types. For many languages, Java and object pascal, and also C# are solutions. More or less elegant. As ACode proves, it is possible to write the kernel in Java, this is good news. It maybe possible to write it in other languages. Though, I had problems importing the code in Rose and in magicDraw, for re-engineering purposes, but I did not really try hard. Maybe it is possible. > > - There are no example implementations of a complete openehr-system on > > this website, does this mean that there are no open source > > implementations? > > Only parts can be found, which are interesting pieces of work, but the > > things do not come together now. > > that's is true. To my knowledge, there are no complete open source > implementations. That will take time. If it was possible to export the code-concepts in a vendor-independent way, Openehr could become useable by much more programmers. This would really speed up the coming of open source implementations. Also there is a need of more ITS and example projects. There is f.e. no persistence layer and no example GUI-layer, and though there is a lot of documentation, it is hard to get the pieces together. It takes weeks to read and understand the complete docs, after one must start programming, with bad luck, from scratch. At this moment OpenEhr seems to me more like a OpenConcept-project instead of an OpenSource-project. > > > - Are there any known closed source implementations which run fine? > > You can see the list of (some) openEHR projects at > http://www.openehr.org/projects/t_projects.htm I tried some of those, hoping to gain some knowledge of OpenEhr implementing, but I found some of them not even mentioning the OpenEhr project, and some of them did not have much activity in the OpenEhr mailinglists. (I (re)search for, to discover which ones can really help.) But I also found some, which do very promising work. > > > - Can the experienced programmers be hired? > > - why is the ITS and knowledge coming from the closed source-projects > > not returned to the project? "Give and Take" is the idea of open > > source which I like. > > well, that is always up to the individual projects. Official openEHR.org > projects (i.e. the ones you see under the website "project" link) are > all completely open source. I did not find a project which does the complete implementation. maybe I missed it. But reading further, i can see that I have to wait. That is a bit of a problem. It is not that I am on a day to day schedule, but some investors want to have some time-schedule.They do not want to hear something like somewhere next year. But maybe, I found a company willing to help us, I did not agree to mention its name publicly, sorry for that. But it is possible, that there will be some news in short time. The people investing in the project are willing to donate the ITS coming from their project into the OpenEhr project. What is needed most, for now, in my humble opinion, is an example persistence layer and an example GUI-project for representing medical data >From your other email: > we continue to use Eiffel simply because it actually implements > object-oriented semantics properly, and allows us to validate the model. > I don't know of any equivalent tool. I have no problem with that, I am looking for a way to help more "Worlds" (specially mine ;-) > > I have seen magicDraw UML in the SVN=tree, but is it always updated as > > the Eiffel-code is? Can it safely be used to generate code? > > Is it complete enough do do a signifant part of the code-generation? > > it is not currently up to date, and we had to introduce some real hacks > to include even basic things like List<String>. My impression after > working for some months with this tool, and also other supposedly top > quality UML tools is that they are basically diagramming tools and do By the way, I saw in the Eiffel Studio a menu-option: Export To XMI. Could that be useful? Is it possible to do those basics things here Regards Bert Verhees
