Model-driven engineering

From Wikipedia, the free encyclopedia

 The introduction to this article provides insufficient context for those unfamiliar with the subject.
Please help improve the article with a good introductory style.

Model-driven engineering (MDE) finds its roots in the 1980s with the development of Computer Aided Software Engineering (CASE) tools. Companies like Integrated Development Envrionments (IDE - StP), Cadre Technologies, Bachman Information Systems, and Logicworks (BP-Win and ER-Win) were pioneers in the field. But CASE had the same problem that current MDA/MDE tools have today: the model gets out of sync with the application (see below). The government got involved in the modeling definitions creating the IDEF specifications. With several variations of the modeling definitions (see Grady Booch, Jim Rumbaugh, Ganes, Sarson, Harel, Shlaer, Mellor, and others) they were eventually joined creating the Unified Modeling Language (UML). Rational Rose the dominate product for UML implementation was done by Rational Corporation (Booch) which in 2002 was acquired by IBM.

MDE is the systematic use of models as primary engineering artifacts throughout the engineering lifecycle. MDE can be applied to software, system, and data engineering. Models are considered as first class entities. The best known MDE initiative is the Object Management Group (OMG) called Model-Driven Architecture (MDA), which is a registered trademark of OMG.[1] Another related acronym is Model-Driven Development (MDD) which is also an OMG trademark.[1]

Contents

[edit] MDE as used in software engineering

As it pertains to software development, model-driven engineering refers to a range of development approaches that are based on the use of software modeling as a primary form of expression. Sometimes models are constructed to a certain level of detail, and then code is written by hand in a separate step. Sometimes complete models are built including executable actions. Code can be generated from the models, ranging from system skeletons to complete, deployable products. With the introduction of the Unified Modeling Language (UML), MDE has become very popular today with a wide body of practitioners and supporting tools. More advanced types of MDE have expanded to permit industry standards which allow for consistent application and results. The continued evolution of MDE has added an increased focus on architecture and automation.

MDE technologies with a greater focus on architecture and corresponding automation yield higher levels of abstraction in software development. This abstraction promotes simpler models with a greater focus on problem space. Combined with executable semantics this elevates the total level of automation possible. The Object Management Group (OMG) has developed a set of standards called model-driven architecture (MDA), building a foundation for this advanced architecture-focused approach.

Model-integrated computing is yet another branch of MDE.

According to Douglas C. Schmidt, model-driven engineering technologies offer a promising approach to address the inability of third-generation languages to alleviate the complexity of platforms and express domain concepts effectively[2].

[edit] MDE Has Problems to Solve

There are several facets missing from the practice of software engineering. For Software Development to be an engineering profession we need a reproducible discipline[1] with the artistry of authoring removed. The creativity is in the solution to the problem not the use of the computer language in an artistic form. Further software engineering needs the ability to control, test, act, trace, debug, and be modified easily, it needs a clearly understood temporal component[2], and a robust ability to handle misuse.

It is well understood by all seasoned computer science professionals why Dr. Brooks and Dr. Lee wrote papers about the lacking of such fundamental topics. These papers are elegant proof of how intensely the computer science profession embodies the “cobbler’s children” cliché. What both of these distinguished professors lament about is the lack of discipline in an engineering science run by young artist. As a result of this lack of engineering discipline software engineering managers are unable to control this unruly profession[3].

A way of solving this discipline problem is to eliminate the programmer by creating a Model Driven Architecture (or Model Driven Engineering) that can manufacture the application code. But, the MDA/MDE approach has failed because for one reason there is a lack of continuity between the model and the implementation. “Often, once construction begins, the teams leave the model behind and never update it to reflect their changing conceptions of the project.”[4] This current MDA/MDE approach has failed because it does not solve the fundamental problems of the programmer going in and adding ‘spaghetti code’ and not synchronizing the code with the model[5].

The discipline required to meet Brooks’ specification can be achieved. Keep control-flow and data-flow separate. This is an orthogonal approach where the work-flow is the result of the orthogonal components control-flow and data-flow. This orthogonal approach makes it impossible to create “spaghetti code”, but does not prevent the creation of “spaghetti logic”. Even bad logic is easier to debug when it has been separated from bad coding. In a profession not known for its discipline, this cultural change will be a challenge, but it can be accomplished through an MDA/MDE approach. Steve McConnell suggests in his book 'Code Complete' that logic-flow can be kept separate from data-flow by using logic tables. A simple engine to traverse the logic also makes trace and verification easier since debug test code goes into the application only in one place.

MDE needs a user interface that supports the abstraction down to the implementation without the requirement for synchronization or 'round-trip' engineering. MDE needs a good process model that will directly represent the logic of the application. Decades of use have shown that the boxes with strings approach have not worked at the implementation level, other than to produce a lot of wall paper.

The modeling image below (click to enlarge) is a tree structure with red and green lines to represent the true and false logic. With hyper links to associated true and false windows to represent the data manipulation. A modeling approach that nearly replicates the implementation yet is contained in the UML abstraction is required before MDE will truly be realized. An approach like this would allow the modeler the highest level of abstraction with the ability to edit down to the implementation level. Test and debug could also take place in the environment since the model is the application.

All of the pieces are there to truly make some great steps forward in Model Driven Engineering if only the powers that be can change.

[1] – Frederick P. Brooks, Jr, “Three Great Challenges for Half-Century Old Computer Science”.

[2] - Edward A. Lee, “Absolutely Positively on Time” –Editorial, March 8, 2005, U of C at Berkeley

[3] - Robert N Charette, “Why software fails, we waste billions of dollars each year on entirely preventable mistakes” © 2005 IEEE Computer, September 2005, Page 42.

[4] - Thomas Mesevery, Kurt Fenstemacher, “Transforming Software Development: An MDA Road Map”, © 2005 IEEE Computer, September 2005, Page 52.

[5] Code Generation Controversy - Wiki - 'Model Driven Architecture'


Possible Model Approach

[edit] See also

[edit] References

  1. ^ a b Object Management Group (2006-05-24). OMG Trademarks. Retrieved on 2008-02-26.
  2. ^ Schmidt, D.C. (February 2006). "Model-Driven Engineering". IEEE Computer 39 (2). , "A promising approach to address platform complexity — and the inability of third-generation languages to alleviate this complexity and express domain concepts effectively — is to develop Model-Driven Engineering (MDE) technologies..."

[edit] External links