Matilda: A Generic and Tailorable Framework for Direct Model Execution in Model-Driven Software Development

Introduction

Software modeling has advanced to the point where it can offer significant leverage to manage complexity and improve productivity in software development. A driving force in this advance is a series of mature modeling technologies. For example, the Unified Modeling Language (UML) provides a wide range of modeling notations and semantics used in various types of applications (UML Super Structure Specification 2.1.2, 2007). The Business Process Modeling Notation (BPMN) provides a set of well-defined notations and semantics for business process modeling (Business Process Modeling Notation (BPMN) 1.0, 2004). UML and BPMN allow developers to specify and communicate their application designs at a high level of abstraction. Using these modeling technologies, the notion of model-driven development (MDD) aims to graphically build application design models and transform them into running applications.

A key process in MDD is automated (or semi-automated) transformation of implementation independent models to lower-level models (or application code) specific to particular implementation/deployment technologies such as programming languages, databases, middleware and business process engines (Booch, Brown, Iyengar, Rumbaugh, & Selic, 2004; Sendall & Kozaczynki, 2003). Traditional MDD frameworks allow developers to model their applications with modeling languages such as UML and BPMN, generate skeleton code in a programming language such as Java, and manually complete the generated skeleton code by, for example, adding method code (Figure 1). There exist three critical research issues in traditional MDD frameworks: (1) abstraction gap between modeling and programming layers, (2) a lack of traceability between models and programs, and (3) a lack of customizability to support various combinations of modeling technologies and implementation technologies.

Figure 1.

Traditional MDD process

The first issue is that, when programmers complete generated skeleton code to the final (compilable) code, they often suffer from abstraction gap between modeling and programming layers because the granularity of skeleton code is usually much finer than that of models. Skeleton code tends to be complicated to read and maintain. Thus, it is hard for programmers to obtain a broad view of an application design, and they have to repeatedly go up and down abstraction gap to identify where to implement what in skeleton code.

The second issue is that models tend to lose synchronization with programs through development process. For example, when programmers find bugs or design/implementation alternatives in the final (compilable) code, they often change the code directly rather than models. As a result, the program code becomes untraceable from models. Due to the above two issues, traditional MDD frameworks do not maximize the benefits of modeling application designs at a higher level of abstraction than programming layer.

The third issue in traditional MDD framework is that they often lack generality to support a variety of choices in modeling technologies and lack customizability to tailor model transformation and code generation according to the implementation/deployment technologies used in application development. This degrades reusability and longevity of application models; it is often hard to evolve application models for a long time by, for example, introducing new modeling technologies and changing implementation/deployment technologies.