Swinging UML How to Make Class Diagrams and State Machines Amenable to Constraint Solving and Proving

Abstract

Swinging types (STs) provide a specification and verification formalism for designing software in terms of many-sorted logic. Current formalisms, be they set- or order-theoretic, algebraic or coalgebraic, rule-or net-based, handle either static system components (in terms of functions or relations) or dynamic ones (in terms of transition systems) and either structural or behavioral aspects, while STs combine equational, Horn and modal logic for the purpose of applying computation and proof rules from all three logics.UML provides a collection of object-oriented pictorial specification techniques, equipped with an informal semantics, but hardly cares about consistency, i.e. the guarantee that a specification has models and thus can be implemented. To achieve this goal and to make verification possible a formal semantics is indispensable. Swinging types have term models that are directly derived from the specifications. The paper takes first steps towards a translation of class diagrams, OCL constraints and state machines into STs. Partly, we proceed along examples, partly we describe generally how, e.g., classes can be turned into signatures.Swinging types are particularly suitable for interpreting UML models because they integrate static and dynamic components. UML treats them separately, STs handle them within the same formalism. Hence, one may check, for instance, whether static operations are correctly refined to local message passing primitives.A crucial point of a formal semantics of UML models is a reasonable notion of state. If constraints involve static data as well as states and state transitions, the modal-logic view on states as (implicit) predicates is less adequate than the ST representation as terms denoting tuples of attribute values, "histories" of object manipulations or compositions of substates (composite states).