Recently, while digging into the Internet searching illuminating words about MDA, I found an interesting article written by Ashley McNeile. The author presents very clearly the opposition of two mainstreams in developing MDA tools, the Elaborationist and Translationist approaches. Recently, during the last year, I've been involved in two different MDA projects, the first was actually an Elaborationist one, and the latter absolutely a Translationalist MDA project. I have a steady personal idea about the two approaches, quite a clear envision, supported also by these two recent personal experiences.
Is really so difficult for the opposite methodologies to converge into a comprehensive one?
I've my personal opinion about it, stay in touch, I'll write out more in the future...
31 August, 2006
Software engineering: and oximoron (and it will be forever)
The civil engineering principles and practises start from the obvious real fact that "it costs more (much more) to change than to create" and this undoubtable fact is reflected and it influences the entire approch.
In IT, on the other hand, the undoubtable fact is that it costs less (much less) to change than to create (at least in the short term in the life cycle of projects) and this has badly influenced the IT practises until the early time when complexity and urgency became a preminent factor.
But now we are not yet able to get rid of the Software Engineering principle in IT! We still look at it as the leading light, the guiding principles. But this is badly influencing the practise, approach and methods of IT. The early 90s heavvy methods are still here with us even thought something is moving in the right direction: MDA.
The software developement processe need to leverage its own advantages which is flexibility and adaptability instead of flighting it. The fact that is cheaper to change than to build is a value added, unque to IT because of its inner "soft" soul, it's not a deficiency to fight.
Beside the fact that in IT no one can affort to wait one or two years before having a usable software product (which is common for planning, builiding and using a bridge or a skyscraper). Let's assume that in IT we first build and then we change: it's in the human nature. In engineering practise, we first want to plan and then to build because we can not economically and practically afford to move a house or to move a window. This approach has emerged naturally more then 2000 years ago, IT is not as lucky: it is just 50 years old and we are probably now understanting how to deal with it.
Software artifacts are far more adaptable then any other hardware or concreate stuff. Let's then create an approach, process and supporting tools that not only accept this fact but also use it at the value add, the leading principle. In essence MDA is exactly doing this: creating an approach founded on "flexibility" that accepts, admits and wants IT system to be build by continuous changes. Yes it sounds like the Iterative & Incremental approach, but not as a cure to the heavvy engineering approach of IT, but as a prime strategy. In essence MDA wants to even ease and support the fact that it is cheaper to change than to build and put it as a "method".
We have to dare, and to get rid of the past approaches and go in another direction supporting a characteristic that was considered the "devil", it is in reality a good think if wrapped around a formal approach that OMG is actually defing and formalizing.
On the other hand, we shall not fall in the error of considering that MDA is "do & try", "do & fix" or "plan afterward" on the contrary: changes need to be planned. MDA, making a comparison with civil engineering, is building a development method (development here is used in a broader sense) around the uncontrovertible fact that the cost of moving a pillar is far less expensive then the cost of building it! Would we have the actual Eng. methods in civil construction, for example, if adding a story to a building would be as cheap as building it since tbe begining? Not indeed, then we have to assume the same in IT, and start all over again with a different new mindset: a tabula rasa.
In IT, on the other hand, the undoubtable fact is that it costs less (much less) to change than to create (at least in the short term in the life cycle of projects) and this has badly influenced the IT practises until the early time when complexity and urgency became a preminent factor.
But now we are not yet able to get rid of the Software Engineering principle in IT! We still look at it as the leading light, the guiding principles. But this is badly influencing the practise, approach and methods of IT. The early 90s heavvy methods are still here with us even thought something is moving in the right direction: MDA.
The software developement processe need to leverage its own advantages which is flexibility and adaptability instead of flighting it. The fact that is cheaper to change than to build is a value added, unque to IT because of its inner "soft" soul, it's not a deficiency to fight.
Beside the fact that in IT no one can affort to wait one or two years before having a usable software product (which is common for planning, builiding and using a bridge or a skyscraper). Let's assume that in IT we first build and then we change: it's in the human nature. In engineering practise, we first want to plan and then to build because we can not economically and practically afford to move a house or to move a window. This approach has emerged naturally more then 2000 years ago, IT is not as lucky: it is just 50 years old and we are probably now understanting how to deal with it.
Software artifacts are far more adaptable then any other hardware or concreate stuff. Let's then create an approach, process and supporting tools that not only accept this fact but also use it at the value add, the leading principle. In essence MDA is exactly doing this: creating an approach founded on "flexibility" that accepts, admits and wants IT system to be build by continuous changes. Yes it sounds like the Iterative & Incremental approach, but not as a cure to the heavvy engineering approach of IT, but as a prime strategy. In essence MDA wants to even ease and support the fact that it is cheaper to change than to build and put it as a "method".
We have to dare, and to get rid of the past approaches and go in another direction supporting a characteristic that was considered the "devil", it is in reality a good think if wrapped around a formal approach that OMG is actually defing and formalizing.
On the other hand, we shall not fall in the error of considering that MDA is "do & try", "do & fix" or "plan afterward" on the contrary: changes need to be planned. MDA, making a comparison with civil engineering, is building a development method (development here is used in a broader sense) around the uncontrovertible fact that the cost of moving a pillar is far less expensive then the cost of building it! Would we have the actual Eng. methods in civil construction, for example, if adding a story to a building would be as cheap as building it since tbe begining? Not indeed, then we have to assume the same in IT, and start all over again with a different new mindset: a tabula rasa.
28 August, 2006
MDA TOOLS using MICROSOFT LIVE WRITER
This page gives an overview of some MDA-oriented tools, some of which are pure code generation tools, others more full fletched model-driven tools. They may all be part of someones MDA (™)process. Of course, UML tools may also be considered MDA tools, and will often be central in model-driven development. If that is what you look for, see the UML tools link.
Below are some open source tools of different character:
- MOFScript , a model to text transformation tool, based on one of the OMG MOF Model to Text Transformation submissions - Eclipse plugin, based on metamodels/models in EMF.
- The IBM Model Transformation Framework (MTF) is an EMF based model transformation framework , for now available at alphaWorks. It provides a declarative means of specifying metamodel relationships, similar to that of QVT relations.
- The ATL Engine is a QVT-based transformation language, developed by the INRIA Atlas team. The ATL Engine is currently available as open source under Eclipse GMT. It is developed as a set of Eclipse plugins and works as a development IDE for transformations, with execution and debugging. Currently integrates with EMF and MDR. The ATL Engine will be developed further within the ModelWare IP.
- MTL Engine - Another QVT-like implementation, by the INRIA Triskell team. Uses the MTL language. Integrates with Netbeans MDR and Eclipse EMF.
- ModFact A MOF Repository and QVT-like engine from LIP6, Paris. Based on the TRL language. LIP6 are also working on an open source ModelBus implementation, which will enable MDD tools interoperability.
- Generative Model Transformer (GMT), an eclipse project that is providing/will provide model transformation technology for the eclipse platform. Currently the FUUT-je tool, a code generator tool, is the primary GMT deliverable. (ATL, mentioned above, provides core transformation technology....)
- Kent Modelling Framework (KMF), a tool for generation of languages with support for dynamic constraint checking.
- OpenArchitectureWare , a flexible, template-based generator framework integrated with XMI.
- OpenMDX, an open source MDA environment, which integrates with several tools through XMI and supports code generation towards several target platforms (J2EE, .Net).
- AndroMDA, an open source template-based tool for J2EE code generation from UML/XMI. Uses VTL (Velocity Template Engine) as scripting language and Netbeans MDR as a model API.
- XDoclet, an open source, attribute based code generation tool for J2EE. Not really model-based, but can be combined with generation tools such as UMT to achieve good model-based value.
- Middlegen, an open source, database driven code generator based on JSBC, Velocity, Xdoclet and Ant.
MDD/MDA and the role of the Development Process
MDD tends often to underestimate the impact of the software factory: in details, the role of the process. The organization of work and the hierarchy changes, it is not the usual software engineering process with Analysis-design-code-test, but a rather different approach where test happens in either a PIM environment, where the design happens is an parallel task out of the streamlined production process.
Under-estiamating the role of the process can reduce the advantage of MDD/MDA.
The development process when working with in MDD/MDA has been devided between different groups, testing and technology mapping have to be considered.
MDD can push the development process at a speed where the planning is postponed and will create obstacle and difficoulties in further phases of the project like it happended with 4GL. Planning as well as an accurate requirement capture and a proper analisys modeling greatlny contribute to the success of and MDD based development process.
Embracing the usual software engineeting process when applying MDD is overlookin the problem and increases the risk of the project.
Obeo MDA Tool by Acceleo
Obeo has released an MDA Open Source tool, Acceleo.
It interesting to notice that more and more MDA tools are available out there which also support UML2, QVT, MOF and are based on the Eclipse framework.
Last but not least this is FL/OSS
It interesting to notice that more and more MDA tools are available out there which also support UML2, QVT, MOF and are based on the Eclipse framework.
Last but not least this is FL/OSS
Subscribe to:
Posts (Atom)
Posts
