Term Definition
Model A set of artefacts representing a simplified abstraction of reality, that are valid to the constraints of a modelling language.
Metamodel Defines a valid type of model for a particular domain according to a set of defined syntax and semantics.
Programming Language A general-purpose modelling language with a specific syntax, semantics, and compilation into a lower-level language.
Framework The extension and abstraction of a programming language, contained within the same language, to simplify common tasks.
Domain-Specific Language (DSL)
A domain-specific programming language with a specific syntax, semantics, and transformations into a lower-level language.
Model Transformations The translation of one model instance into another model instance, within the same, or across different, metamodels.
Code Generation A model transformation with a target metamodel on theCodelevel of the MDA viewpoint architecture.
Model-Driven Development (MDD)
A development approach that considers models as first-class development cit- izens.
Model-Driven Engineering (MDE)
A development approach that encourages domain-specific languages and au- tomated model transformations.
Model Driven Architecture (MDA)
Two four-layer architectures illustrating the relationships between different models in an integrated model-driven environment.
Table 3.2: The relationships between different modelling approaches
this thesis, a language is defined as aprogramming languageif its intent is to be general-purpose, and as amodelling languageormetamodelotherwise.
3.1.12 Metamodelling Environments
As discussed earlier in Section 2.3.1, a modelling environment should be supported with software tools in order to maximise the benefits of using models [180]. Such tools can include tools to define model instances, code generators, and analysis tools [300].
While the abstraction of complex systems has always been a part of software development, it is only recently with the development of new modelling software platforms that general-purpose model- driven software has become common. New model-driven technologies such as the Eclipse Modeling Framework [314] and the Graphical Modeling Framework [136] can provide a platform which encour- ages the cheap and quick development of model-driven approaches. A comprehensive evaluation of some of these existing frameworks is provided later in Section6.2.
3.2
Model Completion
When designing a modelling language, a key challenge is balancing the level of detail in its design [369]. A language that is too simple will result in a rigid approach that cannot adapt to many situa- tions; conversely, too much flexibility will force the developer to create and maintain large monolithic models. Software frameworks have to deal with this problem as well; the frameworks must be flexible, but also simple to develop with. Web application frameworks such as Ruby on Rails [321] and Sym- fony for PHP [274] have proposed to resolve this balance through the use ofdocumented conventions.
Figure 3.8: The model completion process within model-driven development, adapted from Wright and Dietrich [369]
Model completion, as proposed by Wright and Dietrich [369], adapt the concepts behind software frameworks to the model-driven domain in order to provide this flexibility and simplicity to the model- driven development of systems. The remainder of this section will briefly discuss the semantics behind this process, which are necessary to ensure the consistency of the approach; for more detail, the interested reader is referred to the paper [369].
3.2.1 Documented Conventions
Within these frameworks,documented conventionsare an approach to automatically complete missing parts of the application [369]. The intent behind this process is to improve the productivity and effi- ciency of using the framework in common situations. For example, as web applications often require database integration, the Symfony web application framework supports the definition of an abstract database schema, which is then translated automatically into code for a particular database platform.
Three important aspects must be considered when using this completion process. Firstly, the conventions must be well-documented, so that the developer can anticipate changes without having to inspect source code. Secondly, the intent of the developer must always override the intent of the framework, and these intentions must never be overwritten; the developer must always be able to override these conventions, otherwise these conventions would become restrictions. Finally, if the framework has too many “magic” conventions, then it is likely that the complexity of the framework will become a mental burden for the developer.
3.2.2 Model Completion Concepts
Model completion is a single model transformation operating on a base model defined by a single metamodel, illustrated in Figure3.8. Following documented conventions, a CASE tool takes the initial
3.2 Model Completion 53
model and transforms it into anintended modelcomplete with all necessary detail. As discussed earlier in Section2.3.1, implementing this process within a CASE tool is essential in order to maximize the benefits of MDE [180].
This approach also maps well onto evolutionary development processes, as once the base model is transformed into an intended model, it may be used as input to other tools such as code generators or analysis tools [300], and evaluated in order to obtain feedback. This feedback can then influence refinements to the base model as part of a new development iteration [369].
Importantly, model completion needs to complete the intended system based on incomplete knowl- edge, a process known asnon-monotonic reasoning[115]. Applied to our domain, this states that when we add additional information to the system, any information inferred may be retracted in the presence of new knowledge. This reasoning philosophy provides a great deal of flexibility.
To illustrate this point, consider a user interface element representing a boolean property within the system. This interface element is part of a platform-independent model, allowing us to ignore the technical details of its implementation. It is reasonable to assume that by default, this property should be rendered by a checkbox. However, the developer may instead wish to represent this property with a drop-down list containing the valuesyesandno. In this case, the default checkbox should be removed; it should no longer be generated through model completion, nor override this new knowledge.
If negative existentials are used in defining part of a convention, non-monotonicity may be a con- sequence. For example, thisdefault checkbox rulecan be expressed non-monotonically as:
IF (there exists a boolean property) AND (there does not exist an editor for it) THEN (create a checkbox editor for it)
Model completion restricts retraction within non-monotonic reasoning to only facts inferred by the reasoner itself; that is, the reasoning process can never retract any information in the base model. This is important to ensure developer effort is never inadvertently discarded.
3.2.3 Model Completion Semantics
In order to prove the consistency and correctness of this inference process within a model-driven implementation, we need to investigate the formal semantics of models and the model completion operation. This definition is essential to ensure that model completion preservesconsistencywith the original model [203]. Using the metamodel definitions provided earlier in Section3.1.10, the model completion process itself will now be defined formally; for more detail, the interested reader is referred to Wright and Dietrich [369].
Given a metamodel S such that model ∈2M and S ⊆2M, model completion is defined as a
functionC:S →S operating within the same metamodel. That is, all completed models will also be valid models in our domain. For a model completionC(X) operating on a model X ⊆S, two conditions need to be imposed:
1. Extensive: Model completion must not retract any existing information in the base model, i.e.
X⊆C(X). This is in contrast to many rule-based reasoners which permit the retraction of facts within the base model [311].
2. Idempotent: Once the intended model has been completed from a base model, applying model completion on this intended model will not change the model, i.e.C(X) =C(C(X)).
Φ1= property(a)
Φ2= property(x)∧ ¬∃y:editor(y)∧editorFor(x,y)
→checkbox(newCheckbox(x))∧editorFor(x,newCheckbox(x)) Φ3= checkbox(x)→editor(x)
Φ4= dropdown(x)→editor(x)
Figure 3.9: Definition of the rule programCfor thedefault checkbox ruleconvention, adapted from Wright and Dietrich [369]
A= {property(a)}
C(A) = {property(a),checkbox(newCheckbox(a)), editorFor(a,newCheckbox(a))}
Figure 3.10: Model completionC(A), adapted from Wright and Dietrich [369]
These two conditions are part of Tarski’s classical axioms for inference operators [317]. Mono- tonicity is not a necessary condition; in the face of new information within a base model, previously inferred knowledge may need to be retracted, i.e.X⊆Y ⇒C(X)⊆C(Y)[369].
In order to implement these conditions on the model completion function, new elements must be created according to afactory function, and introduced into the intended model using the concept of
stratification[327]. This allows for the conventions to be represented as a set of rule formulae in a
rule program, which may be evaluated against a model instance to complete the intended model. By using aninsertion cachein the implementation of the factory function, the model completion process has been demonstrated to satisfy the extensive and idempotent conditions onC(X)[369].
Within this definition of model completion, thedefault checkbox rulemay be expressed using the rule programC illustrated in Figure3.9. This can then execute on an initial model Ato create the completed modelC(A), as in Figure 3.10. The full expansion of the steps necessary to complete the intended model in this example through model completion is not provided here; the interested reader is instead referred to Wright and Dietrich [369].