ºÝºÝߣ

Editor's Notes

• #4: Most data-centric software must deal with some form of import/export of their internal data model to an external data format. In many cases, this external data format is some sort of standard format, or otherwise dictated by external sources, and does not map one-on-one to the internal data model.
• #5: This was also the case for?CareConnect,?HealthConnect/Corilus¡® latest?Electronic Medical Recordsoftware.?CareConnect?must be able to import/export its data from/to?SUMEHR, PMF, and?GPSMF?documents. On top of this comes that?CareConnect¡¯s?internal data model consists of some 300 classes, which means there are a lot of mappings to define.
• #11: EMFTVM performance is roughly 80% better than the default ATL EMF-specific VM. EMFTVM has a JIT-compiler that improves performance of complex code blocks. It also allows for reuse of a pre-loaded VM instance (when invoking from Java), which is useful when invoking the same transformation on different models many times over. Finally, it uses an?adaptive rule matching algorithm?that configures itself against the metamodels and transformation modules used on the first run of the VM. The EcoreUtil.Copier entry is the standard Java implementation for copying Ecore models, and forms the baseline ("it doesn't get faster than this"). On the following lines one can see the evolution in performance of the various ATL VMs.
• #17: Note that the?MoDisco-EMiFy-EMF?round-trip scenario for generating the Ecore model and EMF reflective methods was performed for each change to our domain model, and takes about 10 minutes each time. Most of this time was taken up by running?MoDisco?and the EMF code generator. This takes up extra time from the developer who manages the domain model changes, besides the regular Java code changes and SQL migration code. The positive side of this picture is that the Ecore domain model can also be used reflectively to do dry-run transformations outside of the application codebase. This allows the ATL developers to test each change in isolation.
• #18: ATL is a mapping language, which applies its mapping rules top-down for each model element it can find, and uses a two-pass compiler approach to ¡°weave¡± the elements generated by different rules back together. This frees the programmer from dealing with model traversal and rule execution order: this is taken care of by ATL. Instead, the programmer can focus on defining the mapping between specific input and output elements. To give you an idea, here¡¯s what the ATL rule for mapping lab results?looks like.
• #19: Helpers can be used to encapsulate complex navigations. Helper attributes also improve performance, because their values are cached. They function as a sort of query index over the input data.
• #20: The references LabResultEntry instances from the LabResult rule are transformed here. This rule takes care of title entries...
• #21: ...and this rule takes care of the actual lab result values.
• #22: The implicit tracing mechanism has allowed us to distribute the transformation writing over three to four developers. One of these programmers was trained in .NET instead of Java, which turned out not to be a barrier for writing ATL code. Because we also chose to separate our transformation code from our file I/O and database interaction code, another developer could work on the file I/O and database interaction in Java. Finally, the Corilus XML conversion service for SUMEHR, PMF, and GPSMF was taken care of by a separate development team at Corilus HQ, and was based on existing code. The critical path in the development pipeline was therefore made up by the ATL code, which is exactly the kind of workload that can easily be dispersed over multiple developers.