Thomas Baar

The KeY tool

KeY is a tool that provides facilities for formal specification and verification of programs within a commercial platform for UML based software development. Using the KeY tool, formal methods and object-oriented development techniques are applied in an integrated manner. Formal specification is performed using the Object Constraint Language (OCL), which is part of the UML standard. KeY provides support for the authoring and formal analysis of OCL constraints. The target language of KeY based development is Java Card DL, a proper subset of Java for smart card applications and embedded systems. KeY uses a dynamic logic for Java Card DL to express proof obligations, and provides a state-of-the-art theorem prover for interactive and automated verification. Apart from its integration into UML based software development, a characteristic feature of KeY is that formal specification and verification can be introduced incrementally.

Making metamodels aware of concrete syntax

Language-centric methodologies, triggered by the success of Domain Specific Languages, rely on precise specifications of modeling languages. While the definition of the abstract syntax is standardized by the 4-layer metamodel architecture of the OMG, most language specifications are held informally for the description of the semantics and the (graphical) concrete syntax. This paper is tackling the problem of specifying the concrete syntax of a language in a formal and non-ambiguous way. We propose to define the concrete syntax by an extension of the already existing metamodel of the abstract syntax, which describes the concepts of the language, with a second layer describing the graphical representation of concepts by visual elements. In addition, an intermediate layer defines how elements of both layers are related to each other. Unlike similar approaches that became the basis of some CASE tools, the intermediate layer is not a pure mapping from abstract to concrete syntax but connects both layers in a flexible, declarative way. We illustrate our approach with a simplified form of statecharts.

Refactoring OCL annotated UML class diagrams

Refactoring of UML class diagrams is an emerging research topic and heavily inspired by refactoring of program code written in object-oriented implementation languages. Current class diagram refactoring techniques concentrate on the diagrammatic part but neglect OCL constraints that might become syntactically incorrect by changing the underlying class diagram. This paper formalizes the most important refactoring rules for class diagrams and classifies them with respect to their impact on attached OCL constraints. For refactoring rules that have an impact on OCL constraints, we formalize the necessary changes of the attached constraints. Our refactoring rules are specified in a graph-grammar inspired formalism. They have been implemented as QVT transformation rules. We finally discuss for our refactoring rules the problem of syntax preservation and show, by using the KeY-system, how this can be resolved.

On the usage of concrete syntax in model transformation rules

Graph transformations are one of the best known approaches for defining transformations in model-based software development. They are defined over the abstract syntax of source and target languages, described by metamodels. Since graph transformations are defined on the abstract syntax level, they can be hard to read and require an in-depth knowledge of the source and target metamodels. In this paper we investigate how graph transformations can be made much more compact and easier to read by using the concrete syntax of the source and target languages. We illustrate our approach by defining model refactorings.

A graphical approach to prove the semantic preservation of UML/OCL refactoring rules

Refactoring is a powerful technique to improve the quality of software models including implementation code. The software developer applies successively so-called refactoring rules on the current software model and transforms it into a new model. Ideally, the application of a refactoring rule preserves the semantics of the model, on which it is applied. In this paper, we present a simple criterion and a proof technique for the semantic preservation of refactoring rules that are defined for UML class diagrams and OCL constraints. Our approach is based on a novel formalization of the OCL semantics in form of graph transformation rules. We illustrate our approach using the refactoring rule MoveAttribute.

Semantics of OCL specified with QVT

The Object Constraint Language (OCL) has been for many years formalized both in its syntax and semantics in the language standard. While the official definition of OCL’s syntax is already widely accepted and strictly supported by most OCL tools, there is no such agreement on OCL’s semantics, yet. In this paper, we propose an approach based on metamodeling and model transformations for formalizing the semantics of OCL. Similarly to OCL’s official semantics, our semantics formalizes the semantic domain of OCL, i.e. the possible values to which OCL expressions can evaluate, by a metamodel. Contrary to OCL’s official semantics, the evaluation of OCL expressions is formalized in our approach by model transformations written in QVT. Thanks to the chosen format, our semantics definition for OCL can be automatically transformed into a tool, which evaluates OCL expressions in a given context. Our work on the formalization of OCL’s semantics resulted also in the identification and better understanding of important semantic concepts, on which OCL relies. These insights are of great help when OCL has to be tailored as a constraint language of a given DSL. We show on an example, how the semantics of OCL has to be redefined in order to become a constraint language in a database domain.

Tool support for OCL and related formalisms – needs and trends

The recent trend in software engineering to model-centered methodologies is an excellent opportunity for OCL to become a widely used specification language. If the focus of the development activities is shifted from implementation code to more abstract models then software developers need a formalism to provide a complete, unambiguous and consistent model at a very detailed level. OCL is currently the only language that can bring this level of detail to UML models. The purpose of the workshop was to identify future challenges for OCL and to discuss how OCL and its current tool support can be improved to meet these challenges. The workshop gathered numerous experts from academia and industry to report on success stories, to formulate wishes to the next generation of OCL tools, and to identify weaknesses in the language, which make OCL sometimes cumbersome to use. The workshop could also attract numerous people whose aim was to get an overview on the state of the art of OCL tool support and on how OCL can efficiently be applied in practice.

OCL and graph-transformations: a symbiotic alliance to alleviate the frame problem

Many popular methodologies are influenced by Design by Contract. They recommend to specify the intended behavior of operations in an early phase of the software development life cycle. Formal contract specification languages, however, are still rarely used because their semantics often mismatch the needs of software developers. Restrictive specification languages usually suffer from the ”frame problem”: It is hard to express which parts of the system state should remain unaffected when the specified operation is executed. Constructive specification languages, instead, suffer from the tendency to make specifications deterministic. This paper investigates how a combination of OCL and graph transformations can overcome the frame problem and can make constructive specifications less deterministic. Our new contract specification language is considerably more expressive than both pure OCL and pure graph transformations.

An OCL semantics specified with QVT

Metamodeling became in the last decade a widely accepted tool to describe the (abstract) syntax of modeling languages in a concise, but yet precise way. For the description of the languages semantics, the situation is less satisfactory and formal semantics definitions are still seen as a challenge. In this paper, we propose an approach to specify the semantics of modeling languages in a graphical way. As an example, we describe the evaluation semantics of OCL by transformation rules written in the graphical formalism QVT. We believe that the graphical format of our OCL semantics has natural advantages with respect to understandability compared to existing formalizations of OCLs semantics. Our semantics can also be seen as a reference implementation of an OCL evaluator, because the transformation rules can be executed by any QVT compliant transformation engine.

Non-deterministic constructs in OCL – what does any() mean

The Object Constraint Language (OCL) offers so-called non-deterministic constructs which are often only poorly understood even by OCL experts. They are widely ignored in the OCL literature, their semantics given in the official language description of OCL is ill-defined, and none of todays OCL tools support them in a consistent way. The source of the poor understanding and ill-defined semantics is, as identified in this paper, OCLs attempt to adopt the concept of non-determinism from other specification languages with fundamentally different semantical foundations. While this insight helps to improve the understanding of non-deterministic constructs it also shows that there are some formidable obstacles for their integration into OCL. However, in some cases, non-deterministic constructs can be read as abbreviations for more complex deterministic constructs and can help to formulate a specification in a more understandable way. Thus, we suggest to integrate non-deterministic constructs in other specification languages such as Z, JML, Eiffel whose semantical foundations are similar to those of OCL.