Bert Verhees wrote: > but as I see, there are very impressive projects in the > deploymentsector on the website. > They must have used databases, other programming languages, UML > created, component-interfaces, plans about how to follow the > OpenEhr-developments. > F.e. it does not seem effici?nt to me to rewrite the codebase in C#, > java, whatever, by hand when the OpenEhr defintions changes signicantly.
Release 1.0 is intended to be the end of significant changes. Only error corrections and some additions, but no other changes will be allowed to that release after it is published. Other enhancements will go in later releases. But we expect Release 1.0 to be extremely stable. > It would be very nice if those people would share what they know, and > discovered. > I am not asking them to publish their commercial-product code. well, maybe people asking them on these lists will help... > > I guess, we must regard toEiffel in OpenEhr-context as a case-tool, > not as a programming-environment, because both serve another purpose, > and one must be able to distinguish the two. So if the Eiffelcode must > be regarded as a product of a case-tool. I must say, I like XMI better. > I understand, Thomas likes working with Eiffel, many people have their > tools, Thomas has Eiffel. We need a bridge between Thomas his favorite > tool and more common case tools, so code can be generated for many > other environments. 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 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 not implement object-oriented modelling ideas properly. They are mostly tied to particular programing langaugues, so that it is difficult to create formal abstract models. And the details are all different in each target programming language. We also investigated the XML-schema and Java output, and there were major errors, due in my opinion to wrong design in the tool, not bugs. We tried to get the manufacturers interested in correcting these, but they have not so far shown any interest. I guess they can still sell lots of copies to people who don't understand the issues. - thomas beale
