Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
Tracking change and innovation in the enterprise software development community
Posted by Floyd Marinescu on Jun 25, 2008 03:16 PM
Model-driven software development no longer belongs to the fringes of the industry but is being applied in more and more software projects with great success. In this article, Sven Efftinge, Peter Friese, and Jan Köhnlein pass on, based on the experiences gathered in the past few years, their own contribution to its MDD's best practices.
Read Best Practices for Model-Driven Software Development.DSLs and code generators can, when used appropriately, be an immensely useful tool. But the focus should always be the problem to be solved. In many cases, it makes sense to describe certain, but not all, aspects using DSLs. Projects which decide from the get-go to follow a model-driven approach are ignoring this last piece of advice.Are you doing MDD? What have been your experiences?
Open Source Middleware Reference Architecture Whitepaper
Intel® SOA Expressway Performance Comparison to IBM® DataPower XI50
Usage Landscape: Enterprise Open Source Data Integration
I've seen some tools represent XMI UUIDS as an xpath-like path and uuid. This way they can generate an intelligent error message when the referenced object is missing. If you are thinking of going down the XMI path and sharing large artifacts with a large team then I would highly recommend stress testing the tools to see what pain they give you. There are lots of gotchas that can cause issues with the development process. For example how will the tool handle language changes and branching and will you effectively lose your version history if you make changes to your language. Don't blindly trust vendor claims. For some tools the model validation process is very important for preserving the integrity of the model. If the validation process runs so slowly that developers don't run it then you can get some nasty problems. One popular XMI framework proxies cross model references and if the actual reference can't be found when the proxy is interrogated then it will give back incorrect values instead of an error. This can create subtle errors if models are compiled without being validated first. I also have strong doubts about embedding in another modelling language like UML. One of the advantage of writing your own language from scratch is that you can embed a lot of the rules of the language in the structure of the language. If you are willing to embed in another modelling language then I think you should consider embedding in a programming language. Embedding in a programming language can make development faster because you can harness incremental compilation and quick validation performed by the IDE (though this will often be weak). Situations where you are not heavily using the semantic checking or where interpreting is easy and fast or where you have to write custom code side by side with the model make embedding in a programming language more attractive. I think the most important thing the MDA community has to realise is that MDA doesn't necessarily mean UML and MDA doesn't necessarily mean graphical diagrams. There seems to be some kind of obsession with UML and programming with pictures.
Nice article! I can confirm based on my work with MDSD tools that these best practices are crucial.
In the development of Sculptor we have actually used all of the best practices described in the article, except 'Use graphical syntax correctly' which is not applicable for us.
Sculptor is an Open Source tool that applies the concepts from Domain-Driven Design and Domain Specific Languages.
You express your design intent in a textual specification, from which Sculptor generates high quality Java code and configuration. Sculptor takes care of the technical details, the tedious repetitive work, and let you focus on delivering more business value – and have more fun.
The generated code is based on well-known frameworks, such as Spring Framework, Spring Web Flow, JSF, Eclipse RCP, Hibernate and Java EE.
The DSL and the code generation drives the development and is not a one time shot. It is an iterative process, which can be combined with Test Driven Development and evolutionary design.
Sculptor home: http://fornax-platform.org/cp/x/aAQ
I would like to add one imho essential best practice: only start creating a Generator/DSL if you really know, what kind of code is to be generated and where the points of variance are. At best you have created at least some 20 similar artifacts by hand, only then you can really identify which part of the code is common and should therefore be generated and which part should be added manually. Then you have a good starting point, where you have to place "extension points" (template methods etc.). If you don't do that you will get bitten, by either the lack of usable extension points, or by overly complex generators that try to generate code for the corner cases.
That leads to two other observations:
1) be careful when you do your DSL iteratively that you do not have to rewrite your existing DSL instances (i.e. artifacts that are written in your DSL) again and again, when your DSL definition changes too often. DSL instances aren't easily refactored.
2) depending on the stability of your generator, you should really think hard about not checking in the generatted artifacts. Are you sure that your current generator will still work in two years? Do you have archived everything needed, so that it can still run (IDE?, JDK?, Ant?, All needed Jar-Files?, Maven-Repository? ...)?
In extra large applications, where you have a separation between the core and the application team in a way that the core team can advance with the versions and the application team is working with one of the previous version, it's sometimes WASTE OF PRECIOUS BUILD TIME ! Ask yourself: Do this gen-ed code realy changes that often? How much of it do we have? How much time does it take to generate it? Sometimes it will be better to check in the gen-ed code and when needed just regen' it and override the existing version. Eyal's blog: http://blogs.microsoft.co.il/blogs/eyal
I'm sorry, but it is always true.
When separating along the lines of a core and an application team one should be giving the application team the binary artifacts of the core team build typically in form of libraries.
In most build environments one produces these binaries as a matter of course and does not check them in.
Hi all ... if you are interested in this topic I'd love your feedback on a new tool I've created called Viewpoints, which is a business-driven modeling and code generation tool for Visual Studio .NET 2008.
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.
This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.
This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.
This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.
After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.
IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.
Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.
6 comments
Watch Thread Reply