The main goal of the workshop was to get a better understanding of where we are with MDA by taking a look at successful uses of MDA in the industry. Another goal was to ask critical questions and offer alternative approaches, especially in the areas of web-services, semantic technologies. And finally I wanted to confront the generative technologies with the high-level dynamic approach used in Smalltalk. Are generative technologies only popular because of the weakness of the current platforms?
a practical use of MDA at large companies (by Markus Reiter, Joachim Hengge - Softlab/HDM)
Automatic composition of business processes between companies - using semantic technologies and SOA. (by Christoph Diefenthal - Fraunhofer IAO/HDM)
Practical metamodelling techniques using Smalltalk (by Claus Gittinger, exept AG)
MDA used for a large scale enterprise application integration framework (by Marcel Rassinger, e2e Basel)
I gave a short introduction to what we did in generative computing this term and what we learned. Practical work included building a generative support package for Struts using eclipse modeling framework and JET, AspectJ applications, bytecode generation etc. I only wish I had known more about the current developments in Model-Driven Software Development MDSD (Markus Voelter, Jorn Bettin)
And I wanted to get some answers on the following questions:
|Do you need generative approaches if you have a truly powerful programming language? (Are domain specific languages necessarily different from implementation languages? Do you always have to generate code or is intelligent interpretations of models a more flexible alternative?)|
|Service-oriented architecture puts a lot of emphasis on semantic technologies lately (RDF(s), OWL). Is this competition to UML/MOF concepts by the OMG? is XML more than a dump format?|
|Current limits of MDA use in Industries?|
|How does one define custom semantics in modelling languages and which tools provide support for this in UML?|
|What do employees need to learn to successfully use generative technologies? (Is there really some value in theoretical computer science? (;-))|
|Genertion without models - useful? What are the options (frame processing, templates etc.)? What are the limits?|
If you can read german I'd suggest to read the article by Markus Voelter on MDA in the latest object sprectrum magazine. It provides an overview to current issues with MDA. Download from Voelter's homepage or a short introduction to MDSD by Dave Frankel. The MDSD homepage has more resources to generative approaches. Softmetaware has a nice collection with MDA/MDSD tools e.g. OpenArchitectureWare, an open source framework for MDA/MDSD generation purposes. Or go for Jorn Bettin, Model-Driven Software Development which covers MDSD quite extensively.
The talk by Markus Reiter and Joachim Hengge was an excellent example of model-driven software development. The generator used is the open-source version of b+m informatik AG, now called openArchitectureWare. The process uses is a top down generation with a focus on technical architecture mapping to e.g. the J2EE platform. No Computation Independent Model is used. Interestingly, the final touch is provided through XDoclet based transformations to the final platform code. Like most projects in this area it does not follow the MDA rules defined by OMG strictly.
Both speakers mentioned the problem of generated code and manually changed artifacts getting out of sync.
Producing platform conformant code for J2EE or .NET seems to be a big problem today and model-driven approaches are successfully used in this area. The project used e.g. a Struts model. But behind all that lingers still the question: is it not because of the complexity and uglyness of our current application server based computing platforms that we desperately need generative techniques? At one point in the discussion somebody made a statement like "large scale development technology good only for large scale companies". We will see how this compares to Smalltalk.
Like in our first workshop most speaker reported problems with using XMI as a transport format. It seems to be so complex that most developers use only parts of it or invent their own schema. This really is a big problem because it also means that tools in the MDA area are far less compatible as has been promised. BTW: Magic Draw seems to be the hottest UML editor right now, Poseidon got some really bad publicity.
The speaker - Christoph Diefenthal - presented an implementation of a generator that automatically generates combined business processes between different companies. The talk showed nicely how far the initial claims about UDDI where from reality and how much additional information is needed to map different vocabularies and process definitions between companies. He used RDF and OWL to describe business processes.
Again I realized that I need to learn more about UML because I was unable to decide whether I could express the same process semantics in UML and whether this would be ugly or easy going. In XML seems to be quite easy but of course: the standards problem is pretty much the same as in UML. Only that the XML meta-model of element and attribute is probably very simple compared to classifier etc. I was able to cite a nice example on the difference between XML and RDF (from Mark Baker, XML-DEV list). He used a simple xml fragment consisting of a person with a name and address child. If this is seen as a XML fragment the only thing one can derive from it is about the parent element having two child elements and perhaps if a third child element would be legal. The same fragment seen as a RDF document reveals much more information. The trick is simply in tying the elements to external definitions through e.g. dublin core.
During the talk the audience also became aware of the social consequences once semantically rich information is used to generate and automate business processes: A lot of current IT-jobs involves schema mapping and migration tasks. In the end this technology might force a large number of programmers out of their jobs.
Claus Gittinger told us he had not been able to come up with a concept - instead, he took us on a tour the force through the last 30 years of comuting and into the flexibility of a dynamic language. He showed us several examples of generative technologies used in the past and how easy it is e.g. in LISP to change from generating executable statements to generating equivalent code in any kind of concrete language.
Then he began a quick intro of the Smalltalk language and piece by piece he showed the reflective and dynamic capabilities of this language. I admit that after working with C++, Java and J2EE for many years I seem to have already forgotten how easy things can be...
By showing us the dynamic features he was able to demonstrate that in many cases generative approaches in Smalltalk are unnecessary because code changes are easy and quickly made. The main technologies needed are:
|Everything is an object. Sounds harmless but just think about the rift between Java and XML artifacts in J2EE: no common ground.|
|Every addition to the system is immediately available for extension and re-use. Oh my god: Think about what EJB calls a component. We don't even have a name for it in Java and UML packages are only a weak substitute.|
|Only the capability to send messages is needed. No static typing etc. Use of reflection in Java and C# grows like mushrooms in wet weather and more and more problems are found at runtime - only with almost no debugging features available.|
|The language is here for the user and should make programming easy and fun. Strange, to think in these terms about C++, Java, C# etc.|
I may have forgotten some other points but these seem to be the most important ones.
SOme participants also noticed that if we take all the developments in Java and J2EE together (eclipse plug-ins, unit-tests etc.) we might end up with something that roughly resembles a smalltalk system - just not as elegant or integrated.
Did this close the case on model-driven approaches - accusing them of being only necessary because of bad platforms and languages? Not really. Some interesting points where said about UML in this context: Even for Smalltalk UML diagrams are useful. Object or system state e.g. is not easily captured in code and UML has a definitive advantage here.
We did not go too deep into this. Nobody used a computation independent model. And most platform independent models turn out to be far from platform independent. But there is still one important point about DSL: Users understand (or at least should understand) the DSL. A lot of transformation processess in the PIM/PDM area seems to be only necessary for technological reasons like generating for .NET and J2EE. But a DSL captures domain knowledge which should be computation independent. This is where the real value of modeling could be.
Like last year Marcel Rassinger of e2e demonstrated the power of the e2e Enterprise Application Integration framework. This framework has several remarkable capabilities: Requirements are captured through UML diagrams which make the error-prone translation of paper-specs into models unnecessary. The UML diagrams are then exported via XMI. A generation processes generates the final information (adding platform dependent information) and the resulting information is interpreted by a server. The generator is basically a virtual UML machine.
Marcel showed us how - based on this capability - an error at lower levels during execution can be traced back to the model.
He also raised a number of questions on the future of the product. A very interesting one e.g. was whether the product would be interesting for developers if it was an open source project. This was confirmed by the audience even though e.g. the community around openArchitectureWare is still small and the original developers are the most active contributors.
During Marcels talk it became clear that a lot of problems are caused by bad tooling and not by UML itself which has sind 1.4 all features needed for such a project to deliver. This projects seems also to use UML in a very clean and productive way.