Swinging UML 1 Introduction - CiteSeerX

6 downloads 0 Views 275KB Size Report
Jul 12, 2000 - transformation of class diagrams into STs with product and sum sorts that re ...... M. Gogolla, M. Richters, Transformation Rules for UML Class ...
1

Swinging UML

How to Make Class Diagrams and State Machines Amenable to Constraint Solving and Proving Peter Padawitz [email protected] http://ls5.cs.uni-dortmund.de/peter University of Dortmund July 12, 2000

Abstract.

Swinging types (STs) provide a speci cation and veri cation formalism for designing software in terms of many-sorted logic. Current formalisms, be they set- or order-theoretic, algebraic or coalgebraic, ruleor 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 speci cation techniques, equipped with an informal semantics, but hardly cares about consistency, i.e. the guarantee that a speci cation has models and thus can be implemented. To achieve this goal and to make veri cation possible a formal semantics is indispensable. Swinging types have term models that are directly derived from the speci cations. The paper takes rst 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 re ned 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).

1 Introduction

Given a system to be analyzed or synthesized, there are two conceptionally and technically rather di erent views on the relationship between its static structure on the one hand and its dynamic behavior on the other. We call them the twotiered view and the one-tiered view, respectively. The former is the prevailing one. It ia based on temporal and modal logic where each state is associated

2

with its own interpretation of all syntactic entities building up assertions about the system. The formal semantics is a Kripke structure, i.e. a collection (e.g. a sequence) of models each of which describes a single state. The state structure does not interfere with the transition relation that captures the dynamics and only the dynamics of the system. In contrast to this, formal approaches adopting the one-tiered view regard states not as di erent models (\worlds"), but as di erent elements of a single model. This allows one to keep to predicate logic, but in its many-sorted version: state domains must be distinguished from visible domains such as numbers or nite lists. To our knowledge only three approaches favor the one-tiered view: dynamic data types [4,3,2], hidden algebras [14,15], and swinging types. Hidden algebras are closely related to models of behavioral speci cations [7] and subsumed by models of coalgebra speci cations [31,34, 23]. Hidden algebras handle behavioral equivalence, dynamic data types specify transition relations, only swinging types do both. A swinging type (ST) separates from each other visible sorts that denote domains of data identi ed by their structure; hidden (\state") sorts that denote domains of data identi ed by their behavior in response to observers; -predicates (least relations) that represent inductive(ly provable) properties; and  -predicates (greatest relations) that represent complementary \coinductive" properties. Swinging types combine features of model-oriented approaches with those of axiomatic, deduction-oriented formalisms because their models are Herbrand structures and thus consist of terms, which is natural, opens up the use of powerful proof rules like unfolding, induction and coinduction [27,30]. and generalizes the syntax and semantics of functional, logic or constraint languages. The models that are usually associated with such languages are the \godfathers" of ST models. The ST approach evolved from 25 years of research and development in the area of formal methods for software construction. It aims at keeping the balance between a wide range of applications and a simple mathematical foundation. To this end boundaries between many research communities had to be crossed. STs employ concepts, results and methods from many-sorted and modal logic, algebraic speci cation, term rewriting, automated theorem proving, structural operational semantics, functional and logic programming, xpoint and category theory, universal algebra and coalgebra. Whatever was adopted from these areas, could be reformulated in terms of many-sorted logic with equality. Section 2 illustrates the ST speci cation of UML classes at an example presented in [20]. Section 3 deals with re nements or (abstract) implementations of STs. A re nement of an ST is another ST that meets certain correctness conditions on the Herbrand models of both types and on a given signature morphism from the \abstract" type to the \concrete" one. Section 4 proposes a rule-based transformation of class diagrams into STs with product and sum sorts that re ect the inheritance relationships in a class diagram. Section 5 confronts OCL with logic-based constraint languages. Section 6 deals with the integration of state

3

machines into STs representing class diagrams. Here we present two examples involving guards, generic states and action-event communication.

2 UML and algebraic speci cation

[20] asserts a conceptual di erence between the algebraic speci cation methodology and the object-oriented modelling approach: the former favors if not demands a high degree of data encapsulation and constraint locality, while the latter admits, at least on higher design levels, the \free use of information from almost anywhere in the current system state." On lower levels, the object-oriented approach achieves locality \by enriching the operation lists of the classes and by switching to a message-passing semantics. Sending a message to a locally known object and reading the result may be the equivalent to a complex navigation over the object community|however, the global actions, which are caused by sending a message, are invisible to the invoking object."

Figure 1. Two associated classes (Figure 3 of [20])

It might be a widespread practice in algebraic speci cation to enforce a high degree of locality and encapsulation, but this is not inherent to the approach. [20] claims a general one-to-one correspondence between a class and a speci cation unit. However, a simple look at the graph structure of a class diagram reveals that this cannot work as soon as the graph involves cycles such as those created by bidirectional associations (cf. Fig. 1). A class does not correspond to a whole speci cation, but just to a single sort. Due to the \static" semantics, an algebraic speci cation is structured hierarchically. Its use relationships form a collapsed tree. Even the nest speci cation structure re ecting a class diagram has to encapsulate all data and operations involved in a use cycle into a single speci cation unit. But this does not mean that the other extreme, recommended by [20], must be adopted, i.e., translating the entire class diagram into a single speci cation with a global state sort. The \coalgebraic features" of STs allow us to avoid the introduction of state sorts that are not sums or products of sorts representing classes. Any ST starts out from constructors (constructs) for visible or hidden sorts (vissorts resp. hidsorts). Each sort is equipped with a structural and a behavioral equality. For visible sorts, both equalities coincide. Constructors build up data, but only visible constructors do this uniquely w.r.t. structural equality. Object constructors (objconstructs) are hidden constructors that build up

4

entry PERSON_SET

FINSET Person Meeting

MEETING_SET

Figure 2. FINSET as a template (parameterized class)

data uniquely w.r.t. behavioral equality. On the basis of constructors, an ST de nes functions (defuncts) and -predicates (-preds) in terms of nitary implications (Horn clauses with or without universal quanti ers in the premise) whose purpose ranges from stating pre/postconditions of functions to specifying transition systems in an SOS style. Complementary  -predicates ( -preds) are speci ed in terms of co-Horn clauses that mostly describe aspects of behavior \in the in nity", such as reachability or invariance conditions on state sequences. -predicates are interpreted as least, -predicates as greatest solutions of their Horn resp. co-Horn axioms. Structural equalities are -predicates induced by congruence axioms. Behavioral equalities are -predicates induced by behavior axioms, which are determined by those de ned functions that are declared as destructors (destructs) and those predicates that are declared as separators or transition predicates. Destructors, separators and transition predicates are called observers. -predicates and further -precicates, which are speci ed in terms of generalized Horn clauses, are sucient for specifying most operators of any modal or temporal logic. While co-Horn clauses may involve existentially quanti ed conjunctions in the conclusion, generalized Horn clauses may involve universal quanti ed implications in the premise. A -predicate is static or dynamic. Structural equalities are dynamic. Other dynamic predicates represent \non-deterministic functions". In general, behavioral equalities are only zigzag compatible with dynamic predicates. The set of hidden sorts of an ST splits into reachable or nitely generated sorts (gensorts), destructor sorts (dessorts) and constructor sorts (consorts). A reachable sort is interpreted as a set of behavioral-equivalence classes of constructor terms and thus represents a domain of nitely generated data. A destructor sort s represents a class and is interpreted as a set of|usually in nite| tuples of context functions that represent behaviors of s-objects. The contexts are composed of destructors (see above). A constructor sort is interpreted as a set of constructor terms, which are built upon reachable constructor terms and destructor-sorted constants. In UML, constructor sorts denote sets of composite states. Data constraints (constraints) for a sort s are formulas that restrict the set of s-term classes resp. s-object behaviors to a certain subdomain. In the latter case, data constraints for s correspond to invariants for the class represented by s. For precise de nitions, see the appendix or consult [27,30]. Example 2.1 The bidirectional association between the classes Person and Meeting in Fig. 1 suggests a single ST, but two sorts for person states and meeting states, respectively. The following ST covers Fig. 1 and the OCL constraint of [20], Fig. 4 (see Section 5). For speci cation operators and symbol

5

mappings, we adopt the syntax of CASL [8]. The ST extends a parameterized speci cation FINSET of nite subsets of a totally ordered set1 provided by the parameter sort entry and provided by the parameter speci cation ENTRY (cf. [27,28]). BOOL and NAT are further imports and cover Boolean resp. natural number arithmetic. The UML template of FINSET and its two instances used later on is given by Fig. 2. i and i denote the i-th projection of a product s1      sn resp. i-th injection (constructor) of a sum (disjoint union) qi2I si of at most countably many sorts si , i 2 I (cf. [30]). 1 is the unit sort with the single constructor () :! 1. FINSET = ENTRY[entry; 0 set = set(entry) = qn2Nsetn for all n 2 N objconstructs ( ; : : :; ) : entryn ! setn destructs i : setn ! entry for all 1  i  n > 0 defuncts add : setn ! setn+1 for all n 2 N insert : setn ! setn + setn+1 remove : entry  setn ! setn?1 + setn filter : (entry ! bool)  setn ! qni=0 seti map : (entry ! entry)  setn ! setn forall : (entry ! bool)  setn ! bool j j : setn ! nat vars x; x1; : : :; xn : entry f : entry ! entry g : entry ! bool s : set n : nat constraints issetn (x1; : : :; xn) ) x1 <    < xn Horn axioms add(x; (x1; : : :; xn))  (x; x1; : : :; xn) insert(x; ())  1 (x) insert(x; (x1 ; : : :; xn))  1 (x1; : : :; xn) ( x  x1 insert(x; (x1 ; : : :; xn))  2 (x; x1; : : :; xn) ( x < x1 insert(x; (x1 ; : : :; xn))  i (add(x1; s)) ( x > x1 ^ insert(x; (x2 ; : : :; xn)  i (s) remove(x; ())  1 () remove(x; (x1 ; : : :; xn))  i (s) ( x  x1 ^ remove(x; (x2 ; : : :; xn)  i (s) remove(x; (x1 ; : : :; xn))  i+1 (add(x1; s)) ( x 6 x1 ^ remove(x; (x2 ; : : :; xn)  i (s) filter(g; ())  1() filter(g; (x1 ; : : :; xn))  i(s) ( g(x1 )  false ^ filter(g; (x2 ; : : :; xn)  i (s) filter(g; (x1 ; : : :; xn))  i+1(add(x1; s)) ( g(x)  true ^ filter(g; (x2 ; : : :; xn)  i (s) map(f; (x1 ; : : :; xn))  (f(x1 ); : : :; f(xn )) forall (g; (x1; : : :; xn))  g(x1 ) ^    ^ g(xn ) j(x1; : : :; xn)j  n 1

The order is necessary for obtaining a unique term representative for each set.

6

PERSON SET = FINSET[entry 7! Person] then vars p; p0 : Person Horn axioms p > p0 ( name(p) > name(p0 ) MEETING SET = FINSET[entry 7! Meeting] then vars m; m0 : Meeting Horn axioms m > m0 ( title(p) > title(p0 ) PERSON&MEETING = PERSON SET and MEETING SET and STRING and DATE&TIME then dessorts Person Meeting constructs checkDate : Meeting ! Meeting cancel : Meeting ! Meeting destructs name : Person ! String meetings : Person ! set(Meeting) title : Meeting ! String start; end : Meeting ! Date isCon rmed : Meeting ! bool participants : Meeting ! set(Person) constraints isMeeting (m) ) jparticipants(m)  2j defuncts numMeetings : Person ! Nat numCon rmed Meetings : Person ! Nat duration : Meeting ! Time consistent : Meeting  Meeting ! bool vars p : Person m; m0 : Meeting ms : set(Meeting) ps : set(Person) Horn axioms numMeetings(p)  jmeetings(p)j numCon rmed Meetings(p)  jfilter(isConfirmed; meetings(p))j duration(m)  end(m) ? start(m) consistent(m; m0 )  not(isCon rmed (m0 )) or end(m) < start(m0 ) or end(m0 ) < start(m) isCon rmed (checkDate(m))  forall (m0 :consistent(m; m0 ); remove(m; ms)) ( participants(m)  ps ^ map(meetings; ps)  ms isCon rmed (cancel(m))  false Non-composite methods (here: checkDate and cancel) come as constructors. Unspeci ed function symbols have the expected meaning. The standard model that we associate with the above ST is the Herbrand model of the coalgebraic completion of the ST (cf. [30]). This model consists of all ground terms built up of constructors of ST and additional constants for all behaviors of Person-, Meeting-, setn (Person)- or setn (Meeting)-objects. ❏

7

[27] presents the theoretical foundations of STs, in particular standard models, criteria for their existence and basic proof rules. [28] explores various application areas and integrates traditional special-purpose approaches. Sections 3 and 6 of [28] provide more UML-related examples than the lack of space allows us to work out here. [29] and [30] deals with extensions, such as the coalgebraic completions, and re nements of STs.

3 Re nements

Notions of re nement or abstract implementationnotions have a long tradition in data type theory (cf., e.g., [1]). They de ne more or less implicit abstraction operators transforming models of the implementing|concrete|speci cation, say SP , into models of the implemented|abstract|speci cation, say SP 0 . While the original approaches focused on particular models of SP and SP 0 like initial or nal ones (cf. [18,17,16,11]), later approaches consider model classes (cf. [36,35,25,6]). The correctness requirement that abstraction operators generate SP 0 -models from SP -models is sometimes strengthened by the condition that a re nement does not identify data that are distinct with respect to SP 0 [11,25]. Which are|intuitively|the operators, which transform an SP -model A into an SP 0 -model B? A re nes B if B can be constructed from A by translating the symbols of SP 0 to symbols of SP along a signature morphism rep (representation function), by restricting the set of data of A to the rep-image of B, and, nally, by identifying concrete data with respect to the kernel of an abstraction homomorphism from A to B. As the identi cation step is supposed to hide implementation details, this is quite natural. Since STs cope with visible and hidden sorts, they allow us to design within a common framework both behavioral re nements and \structural" implementations as proposed in, e.g., [11]. [36,25,6,22] pay particular attention to the identi cation step and consider congruences induced by behavioral equivalences. In other words, visible \abstract" sorts are mapped to as hidden \concrete" sorts. Accordingly, rep may map structural by behavioral equalities. Another practically important class of re nements involves mappings from global operations to local message passing primitives. [20] claims that such steps require the change of the underlying logics, namely from algebraic to object-oriented formalisms. If the ST approach is adopted, the formalism need not be changed because STs integrate functional and state-based logics. For instance, a re nement of global operations by local message passing primitives could be formalized by a signature morphism that maps static to dynamic predicates. The precise de nition of a re nement of SP by SP 0 is based on the following notions. Let  = (S; F; P) and  0 = (S 0 ; F 0; P 0) be the signatures of SP resp. SP 0 (see the appendix). A signature morphism rep :  !  0 consists of a function repsorts : S ! S 0 and S + -sorted sets of functions repfuncts = frepw : 0 0 Fw ! Frep g and reppreds = frepw : Pw ! Prep g such that for all f : w ! (w ) (w ) s 2 F and r : w 2 P, rep(f) and rep(r) have the type rep(w) ! rep(s) and rep(w), respectively.

8

Given a  0 -structure A, the rep-reduct Ajrep of A is the -structure de ned by (Ajrep )s = Arep(s) for all s 2 S and f Ajrep = rep(f)A for all f 2 F [ P. There is a least reachable -substructure of Ajrep denoted by Arep . SP 0 re nes SP along rep if Her (SP 0 )rep is an SP -model and SP 0 is consistent w.r.t. (SP ; rep ). If SP has complements and rep preserves them, then the consistency condition follows automatically [27,29]. Hence even when designing re nements and proving them correct we need not reason about other than Herbrand models. When several models are under consideration, they should rst be related to each other syntactically, i.e., in terms of signature morphisms. It often turns out that what seems to be two structures A and B of a single signature is better handled if A and B are represented as Herbrand structures of di erent signatures related by signature morphisms.

4 From classes to signatures STs combine results obtained in thirty years of research on applying equational, Horn or modal logic to program speci cation and veri cation. Readers who are familiar with at least one of these logics or those the common language CASL [8] is based upon should be able to follow the outlined proposals to equip UML with some algebra and logic, although the lack of space enforces a rather sketchy presentation. rule 1

cl1

....

cl

cl

cln

cl1

....

cln

rule 2

π1

cl

cl ×cl1 × ... ×cln

d

πn

d rule 3

cl

cl

d

d κ1

cl

cl + cl1 + ... + cln

κn

rule 4

cl1

....

cln

cl1

....

Figure 3. Sorts induced by generalizations

cln

9

As was already stated, a class cl corresponds to a hidden sort s0 . An attribute of cl with values in a domain denoted by the sort s0 yields a destructor att : s0 ! s0 . An operation op(x1 : s1 ; : : :; xn : sn )f: sg of cl provides a function symbol fop : s0  s1  : : :  sn ! si1  : : :  sik where fi1 ; : : :; ik g = f0  i  n j 9 (a; a1; : : :; an) : op(a; a1; : : :; an) causes a change of (the state of) aig: An n-ary association relates n classes cl1 ; : : :; cln is a relational object of a (hidden) set sort rel with the membership function 2: (cl1      cln )  rel ! bool as the destructor. Rolenames attached to the ends of rel correspond to attributes in a relational database [9,10]. If the association is binary and anonymous, we need not introduce a sort for the asscociation. Instead, each rolename becomes a destructor of one of the two connected classes as in Ex. 2.1. The range sort of the destructor depends on the multiplicity at the target end of the association. If the multiplicity is 1, 0..1 or something else, the range sort is s, 1 + s or set(s), respectively. Further multiplicity constraints are modelled as data constraints on set(s) (cf. Ex. 2.1). Generalizations in a class diagram yield additional product or sum sorts. They are obtained if the graph replacement rules of Fig. 3 are applied to the diagram in the following order. At rst, rule 1 is applied to all maximal classes (w.r.t. the inheritance relationships). Then sequential applications of rule 2 traverse the diagram top-down and turn each local subclass to the product of itself and all its parent classes. In addition, rule 2 introduces projections 1; : : :; n as unidirectional associations that allow cl-objects returned by a function d to access attributes and operations of cl1 ; : : :; cln . Subsequently, rule 3 is applied to all minimal classes. Then applications of rule 4 traverse the diagram bottom-up and turn each local superclass to the sum of itself and all its children. Finally, rule 4 introduces injections 1; : : :; n as unidirectional associations that allow a function d de ned on cl to access cli -objects. The boldface-framed nodes denote intermediate class states that disappear at the end of the described transformation of the diagram. In accordance with [33], classes with quali ers establish further product sorts. [13] compiles generalizations and quali ers into more basic UML concepts, but this changes the graph structure signi cantly and does not take us closer to a veri able model.

5 On constraints

UML class diagrams are equipped with invariants, associations with multiplicity or Boolean constraints, operations with pre/postconditions, often in terms of state transitions. All these conditions are expressed in OCL, the \object constraint language" UML is associated with (cf. [37]). In the ST approach, pre/postconditions are presented as Horn axioms for de ned functions, while invariants and multiplicity constraints become data constraints (cf. Ex. 2.1). Some of the latter, however, are better regarded as requirements class instances. The di erence to other constraints is that requirements need not have models, let alone be satis ed by the intended models or by those constructed from the

10

class speci cation (such as the Herbrand model of a corresponding ST). It is the purpose of a model checker or theorem prover to check the requirements against those models. But this can be done only when the class speci cation contains all operations that are intended to generate or modify class instances. Ex. 2.1 includes an ST version of an OCL constraint that describes the e ect of checkDate and originally reads as follows:

context Meeting :: checkDate() post : isCon rmed =

self.participants -> collect(meetings) -> forAll(m j m self and m.isCon rmed implies (after(self.end,m.start) or (after(m.end,self.start)))

(cf. [20], Fig. 4). The syntax of OCL is horrible! Striving for a language far from mathematical notation the authors of the language created a cryptic, error-prone formalism that only disguises mathematical notions with which one must be familiar for using that language correctly. For instance, the collection operations of OCL re-invent basic second-order functions on sets, bags or lists and are folklore for any functional programmer. As Ex. 2.1 shows, the above constraint can be expressed easily in terms of classical equational logic. \In order to write unambiguous constraints, so-called formal languages have been developed. The disadvantage of formal languages is that they are useable only to persons with a strong mathematical background, but dicult for the average business or system modeler to use. OCL has been developed to ll this gap." [26] \Although it seems a good candidate for a precise unambiguous notation, a mathematical notation cannot be used as a standard constraint language. The aim of a standard is that it be widely used and not that it be exact but rarely used. We need the rigor and precision of mathematics, but the ease of use of natural language. These are con icting requirements, so we need to nd the right balance." [37] In fact, OCL is not a bit closer to natural language than any other speci cation formalism|which is not surprising because any formalism relies on mathematical concepts and notations, no matter whether this is acknowledged or denied. Still, it is annoying if one wants to sell us for an inherent drawback of formal methods (\con icting requirements") what only follows from the bad training of software engineers in basic logic and algebra. Admittedly, the above citations also put a shame on formal-methods communities, which|after 30 (!) years of intense research|have not achieved a little more acknowledgement among their clients. I doubt that OCL is easier to use than a speci cation language based on wellestablished functional-logic concepts. Moreover, OCL's lack of a formal semantics favors inconsistent, i.e. non-implementable speci cations. \Rigor and precision" is not the main purpose of a formal semantics. Natural-language speci cations can also be rigorous and precise. However, only a formal semantics ensures the existence of models and thus of implementations of what has been speci ed.

11

Only a formal semantics can establish evaluation, solution and proof rules that are indispensible for analyzing the speci ed systems. A bare class diagram usually contains only a small subset of all desired use relationships between attributes, operations and rolenames. As [20] points out, it is the additional constraints like invariants or pre/postconditions that de ne \strongly connected" subdiagrams. Each of them covers all attributes and rolenames that occur in some constraint because all of these must be navigated for checking the constraint. For accomplishing an adequate class hierarchy, [20] proposes the re nement of a class diagram in a way that turns the strongly connected subdiagrams into new superclasses (generalizations). This strategy raises the question whether a reasonable grouping of operations into classes can be achieved at all before most of the constraints have been xed. One may plead for hierarchical, parameterized speci cations rather than class diagrams in those early design phases where many constraints are not yet known. But this is debatable because class diagrams allow people, as a referee puts it, \to look at parts of the map" without being bothered by a \counter-productive" hierarchy \when the design is still rather vague and prone to changes".

6 Adding state machines

State machines are labelled transition systems that adopt (part of) the statechart approach [21].2 The general form of a transition from state st1 to st2 is: st e(x)[g(x)]=act(x) > st : 1

2

The transition is triggered by a parameterized event e(t) if the guard (= Boolean expression) g(x) applied to t evaluates to true. During the state transition, the action act(t) is executed. UML distinguishes between several kinds of events and actions. The crucial point in a formal semantics of state machines is the notion of a state and what it is to represent. [37] regards states as values of a particular attribute. What distinguishes a state attribute from other attributes? That it can take only nitely many values? Are not state attributes always determined by other attributes? If one goes the other|more reasonable|way and de nes states as tuples of values over all attributes of a class, then state sets will, in general, be in nite. [19] associates states with predicates whose validity for objects may change when transitions take place. Then some heuristics should be provided as to which predicates form states and which form guards. At some advanced stage of model re nement, a state (predicate) s will imply all guards labelling transitions starting out from s. States-as-predicates realize the two-tiered view of modal logic and Kripke structures: a state is a model, state transitions change models. Consequently, the structure of states and the structure of transition systems are expressed on di erent levels in di erent languages. Alternatively, process algebra 2

For di erences between statecharts and state machines concerning the semantics of synchronization, see [24], Section 2.4.

12

[5], hidden algebra [14] and swinging types proclaim the one-tiered view where states and state transitions pertain to the same|term|model. UML employs state machines as a description tool. If they shall serve as a semantic domain with respect to which (dynamic) properties of a system may be veri ed, one should decide whether the one- or the two-tiered view is to be adopted. We think that the one-tiered view is more adequate because, in general, transition-de ning events and actions are operation calls received resp. sent by objects, while states represent sets of objects. The two-tiered view regards a state of an object of sort s as a predicate p : s, while in the term model, a state is an normal form of sort s. In the beginning of a system development, both notions may coincide. Then s has no observers and only object constructors (cf. s = resource in Ex. 6.2). In general, an object has several|behaviorally equivalent|normal form representations, but di erent objects cannot be in the same state. So what is an object in the model? An object can only be identi ed via an object identi er or a key attribute (address, name, number, etc.) in the sense of relational data bases (cf., e.g., [10]). Object identi ers are distinguished attributes. State transitions must preserve behavioral equivalence in the way they preserve bisimulations, i.e. behavioral equivalence is zigzag compatible with the transition relation. Intuitively, this means that the ability of a transition to re and the result of the transition do not depend on the source resp. target object's term representation.

Figure 4. A state machine with events and guards, but no actions (Figure 4-4 of [37])

Example 6.1 BOTTLESTATE = NAT and BOOL then hidsorts Bottle constructs makeBottle : nat ! Bottle fill : Bottle  nat ! Bottle cap : Bottle ! Bottle destructs capacity; contents : Bottle ! nat separator uncapped : Bottle static -preds empty; filled; partially filled : Bottle

13

n : nat b : Bottle capacity(makeBottle(n))  n contents(makeBottle(n))  0 uncapped(makeBottle(n)) capacity(fill(b; n))  capacity(b) contents(fill(b; n))  min(contents(b) + n; capacity(b)) uncapped(fill(b; n)) capacity(cap(b))  capacity(b) contents(cap(b))  contents(b) empty(b) ( contents(b)  0 filled(b) ( contents(b)  capacity(b) partially filled(b) ( 0 < contents(b) < capacity(b) The speci cation reveals that all states in Fig. 4 represent subranges of attribute (= observer) values. Hence they should be formalized as predicates and not as values of an additional \state attribute" (cf. [37], Section 4.1.5). Moreover, state predicates and transition guards belong to the same class of semantical entities. Both represent preconditions for the ring of a transition. BOTTLETRANS = BOTTLESTATE then vissorts event constructs Fill : nat ! event Cap :! event dynamic preds ?! : Bottle  event  Bottle Horn axioms b Fill ?!(n) fill(b; n) ( empty(b) ^ uncapped(b) b Fill ?!(n) fill(b; n) ( partially filled(b) ^ uncapped(b) Cap b ?! cap(b) ( filled(b) ^ uncapped(b) Fill(n) and Cap are events that cause transitions from a state (= object; see above) b to the state fill(b; n) resp. cap(b). A consequence of representing states by terms is the identi cation of a state and the entry action executed when the state is entered. BOTTLES = BOTTLETRANS and BAG[entry 7! Bottle] then constructs Add : nat ! event dynamic preds =) : bag(Bottle)  event  bag(Bottle) vars b; b0 : Bottle bs : bag(Bottle) e : event Horn axioms bs Add =)(n) bs + [makeBottle(n)] e b0 bs =e) (bs ? [b]) + [b0] ( b 2 bs ^ b ?! In terms of UML, the functions on bags (= multisets) are class-scope operations because they generate or modify object collections. Class-scope operation induce events that trigger transitions between set-or bag-valued states. ❏ There are two kinds of \state" constructors: object generators like makeBottle and object modi ers like fill and cap. Formally, object generators have a hiddensorted range, while object modi ers have a distinguished hidden-sorted argument vars Horn axioms

14

and a range of the same sort. Composite states are terms built up of nonrecursive object generators, i.e. the sort of a composite state di ers from the sort of each of its substates. Example 6.2 The following state machine involves action-event communication and describes the mutually-exclusive access of an unbounded number of users to a single resource. Like the preceding examples, the corresponding ST splits into speci cations of hidden sorts, single-object transitions and multipleobject transitions, respectively. However, the potentially in nite number of (user) states does not admit a UML-compatible graphical representation of the state machine MUTEX = INT and BOOL and SET[entry 7! user] then vissorts event label hidsorts user resource environment = set(user)  resource constructs new : int ! user access; release : user ! user New : int ! event Request; Access; Release :! event : : int  event ! event = : event ! label = : event ! label = : event  event ! label objconstructs free; used :! resource destructs id : user ! int uses : user ! bool ?! : user  label  user dynamic preds ?! : resource  label  resource =) : set(user)  label  set(user) =) : environment  label  environment ! : environment  environment  -preds mutex; 2mutex : environment vars i : int u; u0 : user r; r0 : resource s : set(user) e; a : event l : label env; env0 : environment Horn axioms id(new(i))  i uses(new(i))  false id(access(u))  id(u) uses(access(u))  true id(release(u))  id(u) uses(release(u))  false u =Request ?! u ( uses(u)  false Access= u ?! access(u) ( uses(u)  false u =Release ?! release(u) ( uses(u)  true free i:Request=i:Access ?! used

15

used i:Release= ?! free New(i)= s =) s [ fnew(i)g =a 0 s ==i:a ) s n fug [ fu0g ( u ?! u ^ id(u)  i i:e= e= s =) s n fug [ fu0g ( u ?! u0 ^ id(u)  i e=a 0 e (s0 ; r0) ( s ==e (A) (s; r) =) ) s0 ^ r ?! r e=a 0 a= 0 a 0 0 (B) (s; r) =) (s ; r ) ( r ?! r ^ s =) s e= 0 e (s0 ; r0) ( s ==e (C) (s; r) =) ) s0 ^ r ?! r l env0 env ! env0 ( env =) mutex(s; r) ) ((u 2 s ^ u0 2 s ^ uses(u) ^ uses(u0 )) ) id(u)  id(u0)) 2mutex(env) ) mutex(env) 2mutex(env) ) (env ! env0 ) 2mutex(env0 )) Axioms (A), (B) and (C) establish communications between objects, here between a user and the resource. The resource is never accessed by two users simultaneously, i.e. the Herbrand model of MUTEX satis es 2mutex(;; free). ❏

7 Conclusion

We have presented rst steps towards a translation of UML concepts, in particular class diagrams and state machines, into swinging types, which adopt a meanwhile widespread many-sorted logic. Swinging types have simple term models that admit prototypical executions (constraint solving) as well as proving correctness conditions by employing the powerful inference rules that come with term models (cf. [27,28,30]). While class diagrams describe static aspects of a system, state machines are concerned with the dynamics. The one-tiered approach of swinging types handles both in a uniform logic and also allows us to talk about the interaction of static structure and dynamic behavior. Which other UML concepts should and could be integrated? Does the sketched logical interpretation of UML suggest the redesign of certain UML (and OCL) concepts, in order, for instance, to avoid inconsistencies that remain unnoticed as long as UML has no logical foundation? Would it not be reasonable to equip UML with a little more well-known logic instead of inventing new notations for old concepts even if the old notations have proved useful and adequate? The aim of this paper is rather to provoke a debate on these questions than to give nal answers.

8 Appendix

Given an expression e, var(e) and free(e) denote the sets of all resp. free variables of e. e is ground if var(e) is empty. e(t) denotes an expression that includes the (tuple of) subexpression(s) t. e[t/u] stands for e with t substituted for u. De nition 8.1 (signatures, terms and atoms) A signature  = (S; F; P) consists of a set S of sorts and S + -sorted sets F of function symbols and P of predicates such that F splits into a set CO of constructors and a set DF

16

of de ned functions and P splits into sets P of -predicates and P of  -predicates. s; s0 , etc. stand for single sorts, w for sort sequences. A function symbol f 2 Fws is written as f : w ! s and a predicate r 2 Pw as r : w. For all s 2 S, P implicitly contains the structural equality (predicate) s : ss.3  is swinging if  S splits into a set visS of visible sorts and a set hidS of hidden sorts,  for all s 2 hidS, CO includes object constructors f : w ! s, DF contains destructors g : sw0 ! s0 and P includes separators r : sw and transition predicates  : sws0 ,  for all s 2 S, P implicitly contains the behavioral equality s : ss. A function symbol f : w ! s is visible if ws 2 visS + . f is hidden if f is not visible. For all constructors c : w ! s, s 2 visS implies w 2 visS  . A predicate r : w is logical if r is not an equality predicate. r is visible if w 2 visS + . r is hidden if r is not visible. Structural equalities are -predicates. Destructors, separators and transition predicates are called observers. Certain -predicates may be declared as dynamic predicates. These include all transition and hidden equality predicates. Non-dynamic logical predicates are called static except for the visible equality predicates, which are static and dynamic. Let X be a set of S-sorted variables. T (X) and T denote the S-sorted sets of -terms and ground -terms, respectively, which are de ned as usual. A  normal form is a -term that consists of constructors and variables. NF (X) and NF denote the S-sorted sets of -normal forms and ground -normal forms, respectively. t 2 T (X)s is visible resp. hidden if s is visible resp. hidden. Given r : w 2 P and t 2 T (X)w , r(t) is a  -atom. If r is a -predicate, then r(t) is a -atom. Otherwise r(t) is a  -atom. r(t) is an equation if r is an equality predicate. An equation between term tuples t and t0 stands for the conjunction of the equations between corresponding components of t resp. t0. An atom r(t) is logical, visible, hidden, static or dynamic if r is visible, hidden, static or dynamic, respectively. ❏ +,  and ! are implicit sort constructors. A sum sort s1 +    + sn has the injections i : si ! s1 +    + sn as its implicit (object) constructors. A product sort s1      sn has tupling as its implicit constructor and the projections i : s1      sn ! si as its implicit destructors. A functional sort s ! s0 has apply : (s ! s0 )  s ! s0 (function application) as its implicit destructor. Hence every functional sort is hidden, while a sum resp. product sort is hidden i at least one of its summands resp. factors is hidden. A sorted -term (x : s):(t : s0 ) with free variables x1 : s1 ; : : :; xn : sn is regarded as a constructor of type s1      sn ! (s ! s0 ).Projections and function applications to -terms are speci ed as usual. Sum sorts arise naturally when partial functions, exceptions, 3

We use \" for distinguishing the symbol for structural equality from semantical identity, which is denoted by \=".

17

non-determinism or inheritance are to be speci ed. Sum sorting is a restricted way of order sorting [14] that keeps to simple many-sorted syntax. De nition 8.2 (formulas) A (simple) goal is a nite conjunction of atoms. Given a nite subset Y of X and goals G and H, the formula 9Y G is an existential goal. Given a simple goal G, a logical predicate r and a de ned function f, r(t) ( G resp. f(t)  u ( G is a Horn clause for r resp. f. Given a nite disjunction ' of existential goals, r(t) ) (G ) ') is a co-Horn clause for r. ❏ A signature  implicitly includes congruence axioms for , i.e. Horn resp. co-Horn clauses expressing re exivity, symmetry and compatibility with the function symbols and - resp. -predicates of . De nition 8.3 Given a signature  and a set AX of rst-order -formulas, SP = (; AX ) is a speci cation and AX is the set of axioms of SP . SP is a swinging type if  is swinging and SP has two subspeci cations visSP  hidSP  SP such that hidSP and SP implicitly include the Horn resp. co-Horn clauses among the congruence axioms for  and the following conditions hold true: (1) The visible level visSP consists of visible sorts and visible constructors, a set DF of de ned functions, a set P of static -predicates, Horn clauses f(t)  u ( ' for DF and r(t) ( ' for P such that (a) t is a tuple of normal forms and var(u)  free (t ; '). (2) The hidden level hidSP n visSP consists of hidden sorts and hidden constructors, a set DF of de ned functions, a set P of static -predicates, a set DP of dynamic predicates and Horn clauses f(t)  u ( ' for DF, r(t) ( ' for P and (t; u) ( ' for DP such that (a) holds true and (b) ' is weakly modal *** and var(t) \ out(') = ;. (3) The  -level SP n hidSP consists of a set P of -predicates (including the behavioral equalities) and co-Horn clauses r(t) ) (G ) ') for P such that (a) holds true, G ) ' is poly-modal *** and G is a goal over hidSP . The axioms for behavioral equalities are called behavior axioms and read as follows: x s y ) x  y for all visible sorts s x s y ) (x  f(x0 ) ) 9y0 (y  f(y0 ) ^ x0  y0 )) x s y ) (y  f(y0 ) ) 9x0(x  f(x0 ) ^ x0  y0 )) x s y ) g(x; z)  g(y; z) x s y ) (r(x; z) ) r(y; z)) x s y ) (r(y; z) ) r(x; z)) x s y ) ((x; z; x0) ) 9y0 ((y; z; y0 ) ^ x0  y0 )) x s y ) ((y; z; y0 ) ) 9x0((x; z; x0) ^ x0  y0 )) for all hidden sorts s, object constructors f : w ! s, destructors g : sw0 ! s0 , separators r : sw and transition predicates  : sws0 of .

18

A swinging type SP leads directly to its Herbrand model, which consists of ground terms and interprets structural and behavioral equalities as term relations, called structural resp. behavioral SP -equivalence and denoted by SP resp. SP . Initial and nal models are obtained as quotients of the Herbrand model by SP resp. SP (cf. [27]). De nition 8.4 Let SP = (; AX ) be a swinging type. The Herbrand SP model, Her(SP ), is the Herbrand -structure that is de ned as follows:  For all predicates r 2 hidSP , rHer (SP ) = rlfp() where  is the hidSP consequence operator on T .  For all r 2 SP n hidSP , rHer (SP ) = rgfp( ) where is the (SP n hidSP )consequence operator on Her (SP )jhidSP . SP =def Her (SP ) is called structural SP -equivalence. SP =def Her (SP ) is called behavioral SP -equivalence. SP is behaviorally consistent if SP is a weak -congruence. Given t 2 T and u 2 NF , u is a normal form of t if t and u are SP -equivalent. SP is complete if each ground -term has a normal form. SP is (structurally) consistent if each two SP -equivalent ground normal forms are equal. A complete and consistent swinging type is called functional. ❏

Theorem 8.5 [27] Let SP = (; AX ) be a swinging type. Her (SP ) is an SPmodel that interprets - and  -predicates as the least resp. greatest relations on T . ❏

De nition 8.6 (semantical notions) Let  = (S; F; P) be a signature. A  -structure A consists of an S-sorted set, the carrier of A, also denoted by A, for all f : w ! s 2 F, a function f A : Aw ! As , and for all r : w 2 P, a relation rA  Aw . r : w 2 P is called the complement of r w.r.t. A if rA = Aw n rA. A is a Herbrand structure if for all s 2 S, As = T;s , and for all f : w ! s 2 F and t 2 T (X)w , f A (t) = f(t). The interpretation of -terms in a -structure A and the validity of closed -formulas are de ned as usual.4 A j=b ' denotes the validity of ' under the valuation b : X ! A. A j= ' denotes the validity of ' under all valuations in A. A is reachable if for all a 2 A there is t 2 T such that a is the interpretation of t in A. Two formulas ' and are equivalent if all -structures satisfy ' , . Given a speci cation SP = (; AX ), a -structure A is an SP -model if A satis es AX and EQ . Given a subspeci cation SP 0 = ( 0 ; AX 0) of SP , AjSP denotes the reduct of A to a  0 -structure. An S-sorted binary relation   A2 is compatible with f : w ! s 2 F if for all a; b 2 Aw , a  b implies f A (a)  f A (b).  is compatible with r : w 2 P if for all a; b 2 Aw , a  b implies a 2 rA i b 2 rB .  is zigzag compatible with  : ws 2 P if for all (a; a0) 2  A , a  b (resp. b  a) implies (b; b0) 2  A for some b0 2 As with a0  b0 (resp. b0  a0).  is a  -congruence (resp.  congruence) if  is re exive, symmetric, transitive, compatible with F and all 0

4

Free variables are bound by implicit universal quanti ers at the beginning of the formula.

19

static predicates of P and compatible (resp. zigzag compatible) with all dynamic predicates of P. ❏ De nition 8.7 Let SP = (; AX ) be a speci cation, SP 0 = ( 0 ; AX 0) be a subspeci cation of SP , A be a  0 -structure and C be the class of -structures whose  0 -reduct agrees with A. The (SP n SP 0 )-consequence operator on A,  : C ! C , is de ned as follows. Let r 2  n  0 and B 2 C . If r is a predicate, then a 2 r(B) i there are (r(t) ( ') 2 AX n AX 0 and b : X ! A such that a = b (t) and B j=b '. If r is a -predicate, then a 2 r(B) i for all (r(t) ) ') 2 AX n AX 0 and b : X ! A, a = b (t) implies B j=b '.  is monotone if for all B; C 2 C and r 2  n  0, rB  rC implies r(B)  r(C) .



If  is monotone, then, by the well-known xpoint theorem of Knaster and Tarski,  has a least and a greatest xpoint, denoted by lfp () resp. gfp ().

References

1. E. Astesiano, H.-J. Kreowski, B. Krieg-Bruckner, eds., Algebraic Foundations of Systems Speci cation, IFIP State-of-the-Art Report, Springer 1999 2. E. Astesiano, M. Broy, G. Reggio, Algebraic Speci cation of Concurrent Systems, in [1] 3. E. Astesiano, G. Reggio, Algebraic Speci cation of Concurrency, Proc. WADT'91, Springer LNCS 655 (1993) 1-39 4. E. Astesiano, M. Wirsing, Bisimulation in Algebraic Speci cations, in: H. AitKaci, M. Nivat, eds., Resolution of Equations in Algebraic Structures 1, Academic Press (1989) 1-31 5. J.C.M. Baeten, W.P. Weijland, Process Algebra, Cambridge University Press 1990 6. M. Bidoit, R. Hennicker, Proving the Correctness of Behavioural Implementations, Proc. AMAST '95, Springer LNCS 936 (1995) 152-168 7. M. Bidoit, R. Hennicker, M. Wirsing, Behavioural and Abstractor Speci cations, Science of Computer Programming 25 (1995) 149-186 8. The CoFI Task Group on Language Design, CASL: The Common Algebraic Speci cation Language, 1998, http://www.brics.dk/Projects/CoFI/Documents/CASL/Summary 9. E.F. Codd, A Relational Model for Large Shared Data Banks, Communications of the ACM 13 (1970) 377-387 10. B. Demuth, H. Humann, Using UML/OCL Constraints for Relational Database Design, Proc. UML '99, 1999 11. H. Ehrig, H.-J. Kreowski, B. Mahr, P. Padawitz, Algebraic Implementation of Abstract Data Types, Theoretical Computer Science 20 (1982) 209-263 12. H. Ehrig, B. Mahr, Fundamentals of Algebraic Speci cation 1, Springer 1985 13. M. Gogolla, M. Richters, Transformation Rules for UML Class Diagrams, Proc. UML '98, Springer LNCS 1618 (1998) 92-106 14. J.A. Goguen, R. Diaconescu, An Oxford Survey of Order Sorted Algebra, Mathematical Structures in Computer Science 4 (1994) 363-392 15. J.A. Goguen, G. Malcolm, A Hidden Agenda, UCSD Technical Report CS97-538, San Diego 1997, www-cse.ucsd.edu/users/goguen/ps/ha.ps.gz 16. J.A. Goguen, J.W. Thatcher, E.G. Wagner, An Initial Algebra Approach to the Speci cation, Correctness and Implementation of Abstract Data Types, in: R. Yeh, ed., Current Trends in Programming Methodology 4, Prentice-Hall (1978) 80-149 17. J. Guttag, E. Horowitz, D.R. Musser Abstract Data Types and Software Validation, Report ISI/RR-76-48, University of Southern California 1976

20 18. C.A.R. Hoare, Proof of Correctness of Data Representations, Acta Informatica 1 (1972) 271-281 19. A. Hamie, F. Civello, J. Howe, S. Kent, R. Mitchell, Re ections on the Object Constraint Language, Proc. UML '98, 1998 20. H. Humann, M. Cerioli, G. Reggio, F. Tort, Abstract Data Types and UML Models, Report DISI-TR-99-15, University of Genova 1999 21. D. Harel, M. Politi, Modeling Reactive Systems With Statecharts: The STATEMATE Approach, McGraw-Hill 1998 22. B. Jacobs, Behaviour-Re nement of Coalgebraic Speci cations with Coinductive Correctness Proofs, Proc. TAPSOFT '97, Springer LNCS 1214 (1997) 787-802 23. B. Jacobs, J. Rutten, A Tutorial on (Co)Algebras and (Co)Induction, EATCS Bulletin 62 (June 1997) 222-259 24. J. Lilius, I.P. Paltor, The Semantics of UML State Machines, TUCS Technical Report 273, Turku Centre for Computer Science 1999 25. G. Malcolm, J.A. Goguen, Proving Correctness of Re nement and Implementation, Technical Monograph PRG-114, Oxford University Computing Lab 1994 26. OCL Speci cation, Version 1.1 27. P. Padawitz, Swinging Types = Functions + Relations + Transition Systems, Report, University of Dortmund 1998, http://ls5.cs.uni-dortmund.de/ peter/Rome.ps.gz, to appear in Theoretical Computer Science 28. P. Padawitz, Sample Swinging Types, Report, University of Dortmund 1998, http://ls5.cs.uni-dortmund.de/peter/BehExa.ps.gz 29. P. Padawitz, Modular Swinging Types, Report, University of Dortmund 1999, http://ls5.cs.uni-dortmund.de/peter/MST.ps.gz 30. P. Padawitz, Swinging Types and Coalgebras, Report, University of Dortmund 2000, http://ls5.cs.uni-dortmund.de/peter/BehCoalg.ps.gz 31. H. Reichel, An Approach to Object Semantics based on Terminal Coalgebras, Math. Structures in Comp. Sci. 5 (1995) 129-152 32. M. Richters, M. Gogolla, On Formalizing the UML Object Constraint Language OCL, in: Proc. Conceptual Modeling- ER '98, Springer LNCS 1507 (1998) 449-464 33. J. Rumbaugh, I. Jacobson, G. Booch, The Uni ed Modeling Language Reference Manual, Addison-Wesley 1999 34. J.J.M.M. Rutten, Universal Coalgebra: A Theory of Systems, Report CS-R9652, CWI, SMC Amsterdam 1996 35. D. Sannella, A. Tarlecki, Toward Formal Development of Programs from Algebraic Speci cations: Implementations Revisited, Acta Informatica 25 (1988) 233-281 36. M. Wand, Speci cations, Models, and Implementations of Data Abstractions, Theoretical Computer Science 20 (1982) 3-32 37. J.B. Warmer, A.G. Kleppe, The Object Constraint Language, Addison-Wesley 1999 38. M. Wirsing, Algebraic Speci cation, in: J. van Leeuwen, ed., Handbook of Theoretical Computer Science, Elsevier (1990) 675-788