OCL(ID:5692/ocl002)Object Constraint Languagefor Object Constraint Language Modelling language for use with UML Related languages
References: INTRODUCTION What is the smallest modelling notation that can express a useful range of structural properties, is easy to read and write, and can be analyzed automatically? This paper describes an attempt to answer this question. Alloy is an experimental language with a small syntax, built on an even smaller kernel. The kernel has a precise semantics, and is expressive enough to capture complex properties, while remaining amenable to efficient analysis. Almost all recent development methods factor out the structural aspect of a software system, usually called the ‘object model,’ for separate description. Alloy supports the description of basic structure (graphically, or as textual declarations), as well as more intricate constraints and operations describing how structures change dynamically (both expressed as logical formulas). It thus incorporates not only the object model, but also the ‘operation model’ of Fusion or the ‘behaviour model’ of Catalysis, and is comparable to the Object Constraint Language of UML. Alloy is not for describing dynamic interactions between objects, nor for describing syntactic structure in an implementation, such as the class hierarchy and packaging. Alloy is amenable to a fully automatic semantic analysis that can provide checking of consequences and consistency, and simulated execution. To gain ‘executability,’ Alloy does not sacrifice abstraction: it can generate sample transitions of an operation described implicitly, using negation and conjunction. Alloy, and its predecessor NP, have been used to model and analyze a variety of artifacts, including architectural frameworks, a mobile internet protocol, a resource discovery scheme, the UML core metamodel, and a message filtering device. Alloy’s starting point is Z, an elegant and powerful language with a particularly simple mathematical foundation. It selects from Z those features that are essential for object modelling, and incorporates a few constructs that are ubiquitous in more recent (but less formal) notations. The semantics of Alloy thus bridges the gap between Z and object models, and shows how to give simple and robust meaning to widely used forms, such as navigation expressions, and object model diagrams. Semantics has been a vital design tool in this project, ensuring that the language elements are clear and well defined, and can be composed flexibly without unexpected interactions. In most other attempts to combine the benefits of formal and informal notations, semantics has been used, instead, to explain and make sense of existing elements. Although this explanatory approach can remedy the imprecision and ambiguity of an informal notation, it does not make it simpler, and may even sanction its complexity. Alloy recognizes value in current informal notations, not in their popularity per se, but in the particular features that repeatedly appear because of their elegance and utility. Extract: Design The Object Constraint Language [Warmer and Kleppe 1999] of UML was designed with many of the same goals as Alloy. In some respects it is more expressive than Alloy: it has integer and string datatypes, and sequences. It does not have transitive closure, however, and the attempt to form closures using operations (as used repeatedly in the UML metamodel) is not well founded. Indeed, the reason for including closure is that it is known not to be expressible in first-order logic. Giving OCL a semantics is likely to be challenging, because of its rather elaborate type system (which has been shown to admit Russell’s paradox, implicit coercions, inheritance, and iteration construct. Progress has been made for a subset, but it remains to be seen whether the entire language can be definedcleanly without significant change. in Information and Software Technology 44(4) 31 March 2002 view details |