Using Alloy to model-check visual design notations

Anthony J. H. Simons, Carlos Alberto Fernández y Fernández Department of Computer Science, University of Sheffield {A.Simons, C.Fernandez} @dcs.shef.ac.uk

Abstract

This paper explores the process of validation for the abstract syntax of a graphical notation. We define a unified specification for five of the UML diagrams used by the Discovery Method and, in this document, we illustrate how diagrams can be represented in Alloy and checked against our specification in order to know if these are valid under the Discovery notation.

Keywords Formal specification, model checking, Alloy, visual modelling, UML

1. Introduction

The Unified Modeling Language (UML) [1] is an eclectic set of notations for modelling object-oriented designs. Under the supervision of the Object Management Group (OMG), the notation set has grown larger, to accommodate the concerns of different stakeholders in business and industry. This has led to some criticisms regarding the open ended semantics and the lack of direction given in modelling [2].
Various attempts to formalise parts of UML include the work of the Precise UML group (pUML) [3], which aims to clarify the semantics of UML and create tools to support the rigorous analysis of UML models.
Jointly with IBM, pUML submitted a Meta-Modelling Framework (MMF) [4] to the OMG as an option to the original UML metamodel. Out of this work came the desire to create an Unambiguous UML, an idea partly inspired by the Catalysis method [5]. The Unambiguous UML (2U) Consortium [6], which grew out of pUML, submitted a full proposal for UML2.0 based on a set of architectural principles. Related work on the development of model checkers and tools for UML has been quite slow. Some examples include the Hugo tool, which compiles UML state machines into a format processed by the PROMELA model checker [7]. The USE tool (UML- based Specification Environment) [8] allows UML diagrams to be annotated with constraints written in OCL (the Object Constraint Language [9]), after which the validity of models may be checked, using predicates also written in OCL. The tool verifies model instances against explicit predicates and also implicitly against the invariants defined in the model. A prerequisite to developing high-quality model checkers is the ability to encode model diagrams in a suitable abstract syntax, and from this to develop an abstract semantics [10]. This paper reports on a series of initial experiments conducted into converting a small object-oriented design notation into an abstract syntax, which was then submitted to the model checker Alloy [11, 12], to verify the correctness of models against the abstract syntax. The design notation is a subset of UML used by the Discovery Method [13, 14]. We demonstrate that it is possible to validate model instances of different types against an abstract syntax specification. We also show how a combination of consistent model instances yields a single, consistent abstract syntax; and the converse, that inconsistent models are rejected against the abstract syntax specification. The Alloy analyzer proves to be a tricky tool to use well in this context, and we report also on various different approaches to encoding diagram information and the tactics adopted to focus the work of the model checker. The rest of this paper is organized as follows:
section 2 discusses the relationship between UML and the notation of the Discovery Method; section 3 gives a brief explanation of the Alloy analyzer; section 4 describes the research methodology; section 5 introduces the abstract syntax model for encoding Discovery Method notations in Alloy; section 6 gives an example of usage and model-checking; section 7 gives an initial evaluation of Alloy and its usefulness for modelling diagram syntax constraints; and finally section 8 presents our conclusions. A graph depicting the Alloy abstract syntax metamodel for Discovery Method notations is also included in an appendix.

2. UML and the Discovery Method

Supporters of UML argue that designers benefit from being able to choose whatever diagram elements they need, with some latitude to interpret the diagrams as they see fit. Others argue that this freedom is undesirable, resulting from the lack of any unified semantics in UML [15]. In fact, Booch [16] has stated that the current UML specification does not restrict graphical formats and “there really is no ‘illegal’ UML graphical syntax” (sic). Notwithstanding, we believe that UML should be a more precise language. In fact, UML’s “semantics” are not really formal semantics at all, but a metamodel describing how syntactically well-formed UML diagrams should be constructed; which is not the same as giving the meaning of the UML notation [17-19]. The Discovery Method for developing object- oriented systems was

…(Full text truncated)…