Shahar Maoz, Jan Oliver Ringert, and Bernhard Rumpe

CISC836: Models in Software Development Fall 2011 

CD2All CD2Alloy: 

Class Diagrams Analysis 

Using Alloy Revisited 

Shahar Maoz, Jan Oliver Ringert, and Bernhard Rumpe 

AMAL KHALIL Paper Presentation 

About the Paper 

�� In: Model Driven Engineering Languages and Systems 

(MODELS 2011), Wellington, New Zealand. pp. 592- 

607, LNCS 6981, 2011. 

Th 1 st h Sh h M f l PhD 

� The 1 st author, Shahar Maoz, was formerly a PhD 

student of David Harel (Co-founder of Statecharts). 

13/11/2011 

1

Agenda 

� Introduction 

� Background 

� The CD2Alloy Plug-In 

� The CD2Alloy Translation 

� The CD2Alloy Specific Features 

� Di Discussion i 

� Related Work 

� Conclusion 

Introduction 

� Alloyy is a textual modelingg language g g developed p byy Daniel 

Jackson and his team at MIT. 

� It is a formal language which has a concise syntax and formal semantics. 

� It has been used primarily, with its analyzer, in analyzing code for conformance 

to a specification and as an automatic test case generator. 

�� On the other hand hand, the Unified Modeling Language (UML) is 

the de-facto standard for modeling in the field of objectoriented 

systems. 

� It is a semi-formal language, since its syntax and static semantics are defined 

precisely but its dynamic semantics are not specified formally. 

13/11/2011 

2

Introduction 

� Model Transformation has been extensively used to allow analysis of UML models 

by transferring these models to formal languages, which in turn can be used for 

conducting various types of automated analysis. 

� It allows the designer to benefit from the capabilities provided by these formal 

languages and the analysis tools associated with them. 

� It helps in verifying and improving the models at earlier stages of the development 

process and hence increasing the reliability of software systems. 

� I should not forget to mention that for such transformation to be beneficent it has to 

be a bidirectional transformation, which means that the outcome of the analysis 

should also be transferred back to the language used in the design space. 

Introduction 

� An example of such transformation is UML2Alloy. 

� The method adopted in this tool makes use of Model 

Driven Architecture (MDA) techniques for defining and 

implementing the transformations from models captured 

in the UML class diagram and OCL into Alloy. 

� In the MDA a model transformation is defined by 

mapping the constructs of the meta-model of a source 

language into constructs of the meta meta-model model of a 

� 

destination language. 

Then every model, which is an instance of the source 

meta-model, can be automatically transformed to an 

instance of the destination meta-model with the help of a 

model transformation framework [3]. 

13/11/2011 

3

Introduction 

� For UML2Alloy, the instance of the destination model is an Alloy instance 

which can be analyzed to identify the inconsistencies between various parts 

of the design defined by the source model and to identify if the model is 

under- or over-constrained. 

� Alloy can produce a counter-example helping to reveal the source of 

inconsistency. 

� If a counter-example is found, it must be transferred to a UML objectdiagram 

which is an instance of the class diagram in the design space that 

represents a violation of a property of the system. 

Introduction 

� Snapshots from the UML2Alloy tool are shown. 

The input to the tool is an 

XMI file of the UML class 

diagram created by 

ArgoUML. 

The output from the 

tool in the form of 

object diagrams. 

13/11/2011 

4

Introduction 

� This paper presents a new translation of UML class diagrams to Alloy, which is 

based on a deeper embedding strategy, as the authors claim. 

� Rather than mapping each CD construct to a semantically equivalent Alloy construct, the 

new translation defines (some of) the CD constructs as new concepts within Alloy. 

� For example, class inheritance is not mapped to its Alloy's counterpart – the extends 

keyword. Instead, it is defined using several of Alloy's language constructs – facts, 

functions, and predicates, whose semantics reflects the semantics of class inheritance in CDs 

[1] [1]. 

� The new translation is implemented in a prototype Eclipse plug-in called CD2Alloy. 

� The authors claim that existing translations are missing the support for several CD 

language features such as multiple inheritance and interface implementation and 

are limited to the basic analysis of a single CD. 

Introduction 

� The paper starts with a brief background on the CD and OD languages 

and a short overview on Alloy. 

� After that it describes the new translation from CDs to Alloy and back to 

ODs, side by side with the shallow translation demonstrated by UML2Alloy. 

� The paper then shows how the new translation can be used to solve several 

analysis problems involving more than one CD. 

� Following that, a comprehensive comparison between the existing shallow 

translations and the new one, considering their strengths and weaknesses is 

provided with a thorough discussion of related work and a brief conclusion. 

13/11/2011 

5

Background 

Class and Object Diagrams 

� The authors used the CD and OD sub-languages of a refined alternative of UML, 

called UML/P, which is designed for low-level design and implementation. 

� The semantics of CDs is given in terms of sets of objects and relationships between 

these objects. It is defined using three parts: 

1. A definition of the syntactic domain, i.e., the syntax of the modeling language CD and 

its context conditions conditions. 

2. A semantic domain, consisting of all finite object models. 

3. A mapping [sem: CD � P(OM)], which relates each syntactically well-formed CD 

to a set of constructs in the semantic domain OM. 

Background 

A Brief Overview of Alloy 

� Alloy is a textual modeling language based on relational first-order logic. 

� An Alloy module consists of signature declarations, fields, facts and predicates. 

� Each signature denotes a set of atoms, which are the basic entities in Alloy. 

� Relations between two or more signatures are represented using fields and are interpreted as sets of 

tuples of atoms. 

� Facts are statements that define constraints on the elements of the model. 

� Predicates are parameterized constraints that can be included in other predicates or facts. 

� Alloy modules can be analyzed using Alloy Analyzer, a fully automated constraint solver. 

� This is done by a translation of the module into a Boolean expression, which is analyzed by SAT solvers 

embedded within the Analyzer. 

� The tool can find the instances that prove the satisfiability of the user-specified predicates within the 

given scope. 

13/11/2011 

6

The CD2Alloy Plug-In 

� The input for the implementation is a textual 

specification ifi ti off a UML/P CD th thatt iis written itt iin 

MontiCore (a framework for an efficient 

development of domain-specific languages) 

� 

grammar and generated Eclipse editor. 

The transformation to Alloy is implemented using 

template written in FreeMaker (a Java-based 

template engine that can be used to generate any 

kind of text output) output). 

� The execution of the generated module’s run 

� 

commands is done using Alloy’s APIs. 

CD2Alloy allows you to edit a CD, to analyze it 

using Alloy, to view the generated Alloy code, and 

to view the instances that the SAT solver finds back 

in the form of ODs. 

The CD2Alloy Plug-In 

� Snapshots from the CD2Alloy 

tool are shown. 

13/11/2011 

7

The CD2Alloy Translation 

�� CD2Alloy takes a 

CD as input and 

generates an Alloy 

module. 

�� The module consists 

of two parts: 

1. A generic part 


13/11/2011 

8


2. ACDspecific p part, p , which includes a predicate p that describe 

the CD itself. 


� Snapshots from the CD2Alloy 

Plug-In and the output from the 

Alloy module generated. 

13/11/2011 

9


� Similar transformation is done using the UML2Alloy but with the need to 

write a specific OCL constraint to specify the multiplicity ranges. 

The CD2Alloy Specific Features 

� The semantics of composition 

requires i th that t a parttcannott exist without a whole and that it 

belongs to exactly one whole. 

� The semantics of CD’s 

composition has no counterpart 

in Alloy and so it isn’t supported 

by existing translations such as 

UML2Alloy. 

� Butitissupportedbythenew 

translation. 

13/11/2011 

10


� Inheritance, Interfaces and Multiple Inheritance 

� The translation of UML2Alloy uses Alloy’s built-in support for inheritance and 

hence directly maps CD class inheritance to Alloy’s extends keyword. 

� In the new translation the semantics of inheritance is explicitly expressed using sub 

functions that define the set of sub classes of each class. 

� The use of these functions provides the flexibility required to support multiple 

inheritance. 

� This feature is not supported by existing translations like UML2Alloy. 

� Similar functions are used to support interfaces. Every interface is defined by a 

function that returns all classes implementing the interface. 

� Also existing translations do not support interfaces. 


� Here is an example p on multiple p 

inheritance. 

13/11/2011 

11


� Example p on multiple p inheritance (Cont.): ( ) 


� Multiple CD Analysis 

� The new translation allows you to solve several analysis problems that involve more than 

one class diagram. 

� Examples of such analysis problems are intersection and refinement. 

� To handle the creation of multiple CDs in one Alloy module, we need to do the 

followings: 

�� Define signatures for the union of classes from all input CDs CDs. 

� Divide the CD specific functions (sub class functions, enumeration value functions) between 

the CDs by adding the suffix CDi to all the functions generated for the i-th CD. 

� Create several predicates, cd1, cd2, etc., one for each of the input CDs. Each predicate 

cdi uses the functions with suffix CDi and defines constraints to not include any objects of 

classes not in cdi. 

13/11/2011 

12


� Multiple CD Analysis Example 


� Multiple CD Analysis Example 

(Cont.) 

� Analyzing the two class 

diagrams cd1 & cd2 reveals 

that the intersection is not 

� 

empty. 

It also shows that neither cd1 

nor cd2 is a refinement of each 

other. 

13/11/2011 

13


� Multiple CD Analysis Example (Cont.) 

� On the other hand, analyzing the two class 

diagrams cd1 & cd3 reveals that cd3 is a 

(strict) refinement of cd1. 

� Note that cd m is a (strict) refinement of 

cd n iff: 

� The predicate cdm and not cdn is inconsistent 

(has no instances) instances). 

&& 

� The predicate cdn and not cdm is consistent (has 

instances). 

i.e. all instances of cdm arealsoinstancesof 

cdn (but not vice versa). 

Discussion 

� CD2Alloy demonstrates the tradeoff between the readability and 

intuitiveness of a simple shallow translation in one hand and the 

expressiveness of a deeper translation on the other hand. 

13/11/2011 

14

Related Work 

�� The authors in this paper provide a thorough 

discussion of the related work including most, if not 

all, the existing tools in the subject area. 

� Tools such as UML2Alloy, UML CD, UML ODs, 

UML2CSP UML2CSP, UML/OCL UML/OCL, the USE tool tool, and CDDiff are 

briefly discussed. 

Conclusion 

� CD2Alloy is a translation from UML CDs to Alloy, which takes 

the advantage of the Alloy’s expressive power and 

advances the state-of-the-art in CD analysis. 

� Since MDE is currently in the research stage, having more 

than one possible translation can be worthwhile. 

� The choice of which translation to use depends on the 

specific f needs off the application at hand. 

� Future work includes additional language features and 

analyses such as constrained generalization sets. 

13/11/2011 

15

References 

� S.Maoz,J.O.Ringert,B.Rumpe.CD2Alloy: Class Diagrams Analysis Using Alloy 

Revisited. In Model Driven Engineering Languages and Systems (MODELS 2011), 

Wellington, New Zealand. pp. 592-607, LNCS 6981, 2011. [1] 

� K. Anastasakis, B. Bordbar, G. Georg, and I. Ray. On challenges of model 

transformation from UML to Alloy. Software and Systems Modeling, 9(1):69-86, 

2010. [3] 

�� S. M. A. Shah, K. Anastasakis, and B. Bordbar. From UML to Alloy and back again. 

In S. Ghosh, editor, MoDELS Workshops, volume 6002 of LNCS, pages 158-171. 

Springer, 2009. [22] 

� S.Maoz,J.O.Ringert,andB.Rumpe.CDDiff: Semantic differencing for class 

diagrams. InECOOP, volume 6813 of LNCS, pages 230-254. Springer, 2011. [16] 

THANK YOU 

? 

Fall 2011 

AMAL KHALIL Paper Presentation 

13/11/2011 

16

Shahar Maoz, Jan Oliver Ringert, and Bernhard Rumpe

Create successful ePaper yourself

Delete template?

Save as template?