|
#REDIRECT [[model-driven engineering]]
Model-driven development (MDD) can be said to be the industrialization of software development, even if making production lines may take some extra time than making the actual product. Once it is made we can produce many different products in relatively less time. Then why people do not like it? Because they do not believe MDD can cope with major changes in requirements, also doing minor changes for customization in a copied code is simple which eliminates the need of MDD. But some people claim it has more benefits other than productivity as abstraction increases simplicity. MDD became the centre of discussion among technologists over past years. This essay is dedicated to find the more potential of MDD along with its pros and cons.
“Model-driven development (MDD) is a paradigm for writing and implementing computer programs quickly, effectively and at minimum cost.” (TechTarget, 1 May 2007). ”Model-driven development is simply the notion that we can construct a model of system that we can then transform into the real thing. Where model is a coherent set of formal elements describing something (for example, a system, bank, phone, or train) built for some purpose that is amenable to a particular form of analysis”, (Stephen J. et al., 2003).”Model-Driven Development (MDD) gives architects the ability to define and communicate a solution while creating artifacts that become part of the overall solution”, (Joseph Hofstader, November 2006).
“Some of the leading companies in software development are paying attention to model-driven development (MDD) through development platforms like Microsoft's Oslo and IBM's Rational Software Architect”. Also Motorola is doing case study on model-driven Engineering on a Large Industrial Context (Paul baker, 2005). IBM continues producing tools for simplifying modeling; new improved models can be integrated into the existing development process using this tool (IBM lab, unknown). SpecExplorer is produced by Microsoft for modeldriven development in .NET ___domain (Wolfgang et al., 2004). Nokia is doing research mobile business process using MDD (Anna Ruokonen, 2008). All these organizations want to do their research and products in MDD because of its promises: reduce complexity, increase productivity and easy maintainability (Hailpern and Tarr, 2006).
“However some of the claimed benefits of MDD are arguable”. Some of the arguable areas of MDD are redundancy, which may increase since there will be multiple representations of same model e.g. there may be one model for execution another for specifications. Increase in complexity of models, because of abstraction the complexity in lower level will move to higher level which may become more complex there. More expertise and skill are needed comparing to the traditional method (Hailpern and Tarr, 2006).
“Is there a realistic advantage in the use of MDD in software development at this moment? Is model-driven engineering a false promise?” This essay tries to answer this question so it continues by analysing the changes that MDD would bring to the existing software lifecycles. This study also tries to evaluate the potentials of MDD by analysing the experience of people who used MDD as their solution to business problems, the success or failure acquired by these people are taken into account and mistakes they made are also evaluated briefly.
2. Life Cycle Benefits
Model Driven Development asserts various applicable benefits, which plays vital role in consideration of adapting to this software development technique. Life cycle benefits of MDD are: it is economical, machine readable, less defective, more quality, cost effective, rapid development and easy integration.
MDD can be found more economical than other software development techniques as it needs lesser time in coding phase. Here most of the time is spent on analysis and design phase, which is basic need for any good software development technique. Time is one of the important factors needs to be considered while developing a computer system, since time here is directly proportional to money spent.
The models created using different tools are typically expressed in UML (Unified Model-ing Language) and have a standard machine-readable serialization format, so it enables the automation of code generation from models. One of the most beneficial factor of MDD is that models are machine readable, otherwise models could be no more than concepts drawn on papers and can be referenced only by human.
Models are easily comprehensible and thus amendable as requirements and analysis change. Once the analysis and requirements procedures are done, models can be created easily in accordance with analysis. Hence there are fewer chances of arising defects. Accu-rate code can be generated by accurate models, and that definitely increases the quality of the product or software. Quality of the model depends upon depth of analysis and amount perceived regarding implementing in UML.
Once model is ready, the code can be generated many times. It will reduce the cost of writing up the same code for many times, cost can be taken as Time as well as Money. MDD claims the rapid software development cycle, as much of the code generation is done automatically. MDD allows changing models and thus no need to put effort on writing up all the necessary code again because it can be re-generated according to new models.
Models can easily be integrated and easily changed. On abstract level where models are defined, if change is required according to our new requirements, an easy change is possible without leaving any ambiguity.
3. Life Cycle Difficulties
MDD being relatively very new technology and not mature enough is suffering from its recognition of benefits because of many reasons. Some steps involved in MDD life cycle are also offering some problems. The essay continues in trying to identify the problems and their causes, it also will see the possible solutions of each problem. Main identified problems with MDD life cycle are round trip, user escapes, model debugging, complexity, redundancy, lack or expertise, MDD languages and integration.
MDD life cycle can mainly be divided into two main steps i.e. development of a framework to generate applications secondly generating applications (Peter Swithinbank, et al., 2005). For less number of software to be produced it seems to be an overhead and less economical to first develop a platform and then start generating software and this has already been researched in past efforts e.g. (P.J. Molina, 2007). Solution to this problem is not to choose MDD as development technology for software development/generation and wait for the time it gets mature and quality tools are easily available.
Integration has evolved as big issue in MDD life cycle. The main causes of integration problem are newness of MDD, lack of tools and lack of experts. It has also been seen that companies are reluctant to purchase licensed tool and prefer spending open source and thus spend more on integration (Vlad VARNICA, 2009). Secondly for big projects integration has been seen near to impossible.
In round trip problem a change in an artefact affects other related artefacts, in case of MDD models at higher level of abstraction are used to generate code. It is not so simple, because only one model is not used to generate an entire application there may be more complicated types of models involved in generation process e.g. it may include meta-model. So a change in one is very difficult to handle in rest of artefacts. It gets worst when a change occurs in an artefact at low level and it has to be depicted in an artefact at very high level.
There is unavailability of debugging tools at the level where it is needed. As Models are the main artefacts to produce applications instead of debugging applications, the models are debugged to produce an error free code. If a code is found with bugs then instead of debugging it is good idea to debug model and then generate code again (Paul, et al., 2005). Mostly the projects using MDD have been producing their own model debugging tool or technique that certainly increases the input effort.
Projects e.g. (Paul, et al., 2005), (P.J. Molina, 2007) and (Bernhard, et al., 2007) found lack of expert people as one of the problems from which MDD suffers. Being new technology MDD has less experts thus traditional programmers when are involved they require an extra overhead of training increasing effort and cast. (P.J. Molina, 2007) suggests involving these programmers at modelling steps to increase level of understanding and skill. Though this solution is project specific and it will take time when experts are easily available in the market till then the problem will persist.
For future enhancements or maintenance an expert programmer may bypass model in top hierarchy by making manual changes in code and thus causing inconsistencies among various artefacts. This needs to be carefully monitored and watched. As a solution by (P.J. Molina, 2007) the system should be closely packed to avoid this and a separate expert team can be prepared to take efficient and quick steps.
So we see MDD lifecycle suffering from many problems. In our research some of the problems are due to newness of MDD technology as non availability of tools, lack of experts and lack of MDD languages and some are native to MDD e.g. redundancy and complexity.
4. Success Stories
After the study of number of projects which used MDD and code generation as a technique for software development, the essay in the following text tries to investigate the validity of claimed benefits of MDD in terms of increase in production, maintainability, adaptability, consistency, repeatability, improved understanding and communication, capturing expertise, models are changed less and portability or technology independence.
PISA (P.J. Molina, 2007) is a big project in scope, enjoyed increased quality in terms of compliance of generated code with set standards, 100% of code generation, increased productivity in terms of generation of new applications with very less effort and cost and reduced migration cost to adopt new technologies due to technology independence of business procedures in terms of developed DSL. The reason to choose MDD was also that business processes remain same for a long time and models represent business processes so life of models is as long as the life of business process . The problems faced during project are resistance of traditional programmers to the new change. Suggested solution was to involve traditional programmers in design and modelling step. To involve them it was suggested to have more sophisticated tools for better communication. Second problem is that as the system provides the functionality to add or plug new functionality so experienced and expert programmers can bypass the generator resulting inconsistency between platform and generated code. Suggested solutions were to give priority to such changes and prepare a team of experts. The last problem faced was non-existence of debugger at conceptual level where it was highly needed because in MDD all the errors need to be addressed at conceptual level to get error free code.
Second project is about generation of web applications with software product line and DSLs (Peter, 2009). Achieved efficient application development i.e. specification, generation and deployment of application take very less time, reduced cost of application development and improved performance. Initially it was expected that time to implement abstraction level will be large but actually it was fairly short and some big problems took reasonably less time to implement. There were some of the problems but had solutions. Like generation of large applications which are almost 100% different but they used layered approach and reusable metadata database to cope with this problem efficiently. It was found that generalized modelling techniques e.g. UML are not suitable to capture all the functionality. A solution was to use ___domain specific models (DSM) but combination of both was used to tackle this issue. No big problem is reported in the ___domain of web application.
The project Autoweb System develops web applications using MDD (Piero, et al., 2000). The benefits acknowledged are all the claimed benefits of MDD especially technology independence, efficient and low cost production, application quality and language independent presentation. To further enhance efficiency some optimization techniques were used e.g. caching of abstract pages, storing precompiled and executed queries and caching of actual output pages. Faced problem of integration of generated database with external data source and handled by existing tools. To achieve good results from code generator it required very fine tuning of models. To produce fast prototyping for the sake of enjoying MDD benefits the Autoweb included a prototype generator tool. Overall all the claimed benefits of MDD are achieved after dealing with the above mentioned problems.
The jABC (java application building centre) (Bernhard, et al., 2007) has used MDD to build a number of applications for a range of domains. As benefits of MDD the ease of communication was found to be as low as an hour to understand modelling process by new participants and another big recognized benefit is technology independence. To debug a model a model-checker is developed and the approach is found to be powerful system verifier. Limitation is that it only generates code in java or java servlet.
Motorola use model driven engineering for automation and cost reduction as main objectives (Paul, et al., 2005). Initially it used MDD for code generation for small projects. After finding it as an effective way of application development the technique was used at large scale for a number of domains including embedded systems. Practicing MDD by development of in-house and customized MDD tools gave quality of production at low cost and less efforts. It was found good to detect and correct any problem at model level by generated tests it also minimises or eliminates the round trip problem. The code generations and model level checking was so effective and productive that it could take about 24 hours for regeneration of previously erroneous code and again running its test suit that would have taken a couple of months otherwise. Purpose of in-house tools generation was due to the fact that the third party code generators generated less quality and erroneous code. On the problem side it is difficult to use two techniques MDD and hand written code side by side and more expertise are required. Other found problems but handled were lack of tools, lack of abstraction, lack of well defined semantics, lack of integrated tools, lack of scalability, lack of migration tools, coupling of data and behaviour and poor performance of tools and generated code.
The study of above experiences shows industry enjoyed rapid production, quality software, technology independence and capturing expertise by using MDD. The above study also reveals that none of the experiences is free of problems e.g. round trip, lack of expertise, integration problems and lack of mature tools and technologies. All the problems faced were tackled mostly in project or ___domain specific way to enjoy benefits of MDD. Study also reveals that benefits offered by MDD has more weight than the difficulties offered by the problems in using MDD consequently each project which are discussed here continued with MDD.
5. Failure Stories
As it is discussed above the MDD is being used to improve the quality and productivity of software and system development. This section tries to discover the cause of failure of some of the projects. By using the MDD programmer can get rid of repetitive boring work and focus more on challenging part. But a programmer has to develop the models and encoding techniques to achieve the desired. The thing that comes into mind when anyone hears or starts to use the MDD tool is that no work of tool can be 100% replacement of what a programmer can do being human(Rafael Chaves, 6 Feb. 2010).
In(Staron M, 2006), two companies one is ABB Robotics responsible for developing the embedded system for robots and their intentions for using the MDD were to improve such quality attributes of their software as portability correctness and early assessment. The second company was Ericson a mobile telecommunication company responsible for developing new services for mobile platforms. This case study it is to find the factors, scenario of models in software development and the requirements for adapting MDD. The conditions for adapting or not adapting MDD found in case study were Maturity of Modelling Technique, Maturity of modelling related methods, Process compatibility, Core engineering experts and goal Driven adoption process. ABB adapted the MDD but Ericson did not because they found MDD not suitable for their requirements, it is immature and uses only models for software development.
In (Rafael Chaves, 6 Feb. 2010), MDD is incomplete or too complex for round tripping, two views , first involving the round trip engineering makes the model unintelligible as it destroys the ability of model to be understood without reading code, second it make the model repetitive in expression. MDD is not mature and by including round tripping will be difficult to handle the changes in model.
Companies are afraid of investing huge money for training their developers and prefer alternative ways e.g. Eclipse Modelling Framework (EMF) is a main open source tool used by large and small vendors for MDD but programmers require huge training. Secondly, companies are not sure of the desired results. According to research it is proved that for making new usable tool for modelling requires experienced team and huge investment and both things are lacking.
6. Conclusion
In general MDD is found as a new technique suitable for agile software development. Mostly it is beneficial in terms of productivity gain, quality of software and technology independence and thus provides ease in maintenance in the areas like web, business and hardware specific application development.
Benefits of MDD are centre of discussion are arguable because related tools and technology to be used with MDD are not mature. Secondly people are reluctant to experiment it due to lack of expertise and discussion about its success. It is ideal to wait for removal of fog by letting people to do experiments.
<ref>
• Anna Ruokonen, Lasse Pajunen, Tarja Systa, (2008) "On Model-Driven Development of Mobile Business Processes," Sixth International Conference on Software Engineering Research, Management and Applications sera, pp.59-66, 2008
• Bernhard Steffen, Tiziana Margaria, Ralf Nagel, Sven Jorges and Christian Kubczak 2006. Model-Driven Development with the jABC, Springer-Verlag Berlin Heidelberg LNCS 4383, PP. 92-108.
• Hailpern and Tarr, (2006) IBM SYSTEMS JOURNAL, VOL 45, NO 3, Model-driven development: The good, the bad, and the ugly.
• IBM R&D labs, Model Driven Engineering Technology, https://www.resear ch.ibm.com/haifa/dept/services/mdet.html, [Accessed 23 April 2010].
• Joseph Hofstader (2006). Microsoft library, http://msdn.microsoft.com/en-us/Library/aa964145.aspx, [Accessed 23 April 2010].
• Paul Baker, Shiou Loh and Frank Weil 2005. Model-Driven Engineering in a Large In-dustrial Context-Motorola Case Study, Springer-Verlag Berlin Heidelberg LNCS 3713, pp. 476-491.
• Pedro J. Molina 2007. Focus: ‘The PISA Project’, [internet] available at: http://www.slideshare.net/pjmolina/the-pisa-project-a-mdd-case-study [Accessed 14 April 2010].
• Perry, C., 2001. What health care assistants know about clean hands. Nursing Times, 97(22), pp.63-64.
• Peter Bell 2009: Case Study: ‘Web application generation with Software Product Lines and DSLs’, [internet] available at: www.pbell.com/index.cfm/Software-Product-Line [Accessed 16 April 2010].
• Peter Swithinbank, et al., 2005. Patterns: Model-Driven Development Using IBM Rational Software Architecthttp://iris.nyit.edu/~kkhoo/Summer1_2008/715-OOAD/IBM/Redbook_MDA_SwArchitect_sg247105.pdf, [Accessed 20 April 2010]
• Piero Fraternali and Paolo Paolini 2000. Model-Driven Development of Web Applica-tions: The Autoweb System, ACM Transactions on Information Systems, Vol. 28, No. 4, October 2000, pp. 323-328.
• Rafael Chaves, 2010, Myths that give model-driven development a bad name:http://abstratt.com/blog/2010/02/06/myths-that-give-model-driven-development-a-bad-name/. [Accessed 17 April 2010]
• Staron M 2006, Adopting Model Driven Software Development in Industry – A Case Study at Two Companies. [Accessed 15 April 2010]
• Stephen J. Mellor, Anthony N. Clark, Takao Futagami (2003). "Guest Editors' Introduction: Model-Driven Development," IEEE Software, vol. 20, no. 5, pp. 14-18.
• TechTarget (2007), Model Driven Development. http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci1186687,00.html, [accessed 23 April 2010].
• Vlad VARNICA, 2009. Model-Driven Development is dying – discuss. http://www.modeldrivensoftware.net/forum/topics/modeldriven-development-is?commentId=2573822%3AComment%3A1541. [Accessed 21 April 2010]
• Wolfgang Grieskamp, Nikolai Tillmann, and Margus Veanes (2004), Instrumenting Scenarios in a Model-Driven Development Environment, Journal of Information and Software Technology
</ref>
| 