The Alloy language and analyser has been used primarily to explore abstract soft- ware models and to assist in finding and correcting flaws in these models [Jac06].
Moreover, it has been successfully used for modelling and analysis in several differ- ent real-world domains including safety-critical systems [Den03] and the semantic web [DSW03]. We extend this domain of application by showing that Alloy can also be successfully applied to the the domain of MDE by using it to develop and analyse MOF-compliant metamodels.
Alloy is a formal specification language that has been developed by Daniel Jack- son and his colleagues at MIT [Jac06]. It is based on typed first-order relational logic. An Alloy specification is based around signatures and formulas such as facts, predicatesand assertions which are described next.
• Signatures: Signatures are used for defining the entities of a model and con- sist of a set of declarations that define the relations and operations of the entity.
• Facts: Facts impose constraints on a model. They are always enforced and must always hold true for all instances of a model.
• Predicates: Predicates are used to impose constraints on particular instances of a model. They may or may not be forced to hold true for a model.
• Assertions: Assertions follow from the facts of a model and specify the con- straints of the model that are assumed or claimed to be true. They are never enforced for a model.
A fully automatic tool, called the Alloy Analyser has been developed simultane- ously with the Alloy language. This is a “model-finder” tool that uses a constraint solver to analyse models written in Alloy. There are two types of analysis offered by the tool, namely simulation and checking. Simulation involves confirming the con- sistency of a predicate by generating a model instance that satisfies the predicate. Checking involves assessing the validity of assertions by finding counterexamples to the assertion. To make instance finding feasible, a user must specify a scope for the model under analysis. The scope puts a bound on how many instances of an entity may be observed in a model instance and thus limits the number of model instances to be examined.
The main concepts of Alloy are briefly illustrated with an example adapted from an Alloy tutorial [WTH]. The example is depicted in Figure 4.3 and shows a partial
sig Queue { root: lone Node } sig Node { next: lone Node }
fact nextNotReflexive { no n:Node | n = n.next } assert allNodesBelongToSomeQueue {
all n:Node | some q:Queue | n in q.root.*next }
pred show() {} run show for 2
check allNodesBelongToSomeQueue for 2
Figure 4.3: Alloy specification for the Queue model. This is an example of an Alloy
specification and defines the Queue data structure.
Alloy model specification for the Queue data structure. The Alloy code declares two signatures representing the entities Queue and Node in the model, along with their relations. In the declaration of Queue, the lone keyword specifies that the root relation maps each object of Queue to either zero or one object of Node. The model specification also contains a single fact that states that there is no Node that is equal to its successor.
It is possible to use Alloy to search for specific model instances that satisfy certain properties or constraints. This is done by formulating the constraint as a predicate and using Alloy to search for a model instance that satisfies this predicate. Alloy indicates and displays if an instance is found. However, if no instance is found no conclusion can be drawn as an instance may exist outside of the specified scope. In this example we want to demonstrate the consistency of the model, so therefore we want any instance of the model. To specify this we have written a predicate, show()that is empty and contains no additional constraints. To obtain a sample instance of the predicate the run command is used with a specific scope. Here, the scope is 2 which means Alloy will search for instances with at most two instances of each top level signature (i.e. at most two Queues and at most two Nodes). If an instance is found, Alloy indicates this and can be used to display the instance. An example of a model instance produced by Alloy that satisfies the predicate show is shown in (a) of Figure 4.4.
Figure 4.4: Output from the Alloy Analyser produced during the analysis of the Queue specification On the left is a model instance that satisfies the predicate show and an the right is a counterexample to the assertion allNodesBelongToSomeQueue.
as for the run command a scope must be specified. An example of an assertion, allNodesBelongToSomeQueue is also shown in Figure 4.3. This assumes that all Nodes belong to a least one Queue. To check this assertion Alloy searches all valid model instances with at most two instances of each signature for a coun- terexample i.e. a model instance that violates the assertion. If it finds one then the assertion is not valid and the counterexample is displayed. Otherwise the assertion may or may not be valid as a counterexample may exist outside of the specified scope. In the example shown here, Alloy has found a counterexample to the asser- tion and this is shown in (b) of Figure 4.4.
Recently, the parallel between specification in Alloy and modelling in UML has been noted by Massoni et al. [MGB04] and exploited by Anastasakis et al. [ABGR07]. Anastasakis et al. present a tool called UML2Alloy, that takes a UML class diagram, along with the associated OCL constraints, and translates this UML model into a corresponding Alloy model specification. The sample instances gen- erated by the Alloy Analyser then correspond to object diagrams from the UML model. However, their tool does not provide any automated handling of the gener- ated Alloy instances.
Several other researchers have used Alloy to analyse and reason about metamod- els. For instance, an alternative definition of the UML metamodel is presented in [NW02] and analysed using Alloy. Zito et al. use Alloy to formalise and analyse the
package merge concept of the UML 2.0 metamodel [ZD06]. Both these approaches are similar to the one presented in this chapter in that they use Alloy to describe a metamodel, as opposed to a model as with Anastasakis et al.. However, the main focus of their research has been on the analysis of the UML metamodel. The work described in this chapter is concerned with using Alloy to analyse a metamodel for object-oriented software measurement.