Rule-based Speci cation of Behavioral Consistency based on the UML Meta-Model Gregor Engels, Reiko Heckel, and Jochen Malte Kuster University of Paderborn, Dept. of Mathematics and Computer Science D-33095 Paderborn, Germany reiko|
[email protected]
Object-oriented modeling favors the modeling of object behavior from di erent viewpoints and at di erent levels of abstraction. This gives rise to consistency problems between overlapping or semantically related submodels. The absence of a formal semantics for the UML and the numerous ways of employing the language within the development process lead to a number of di erent consistency notions. Therefore, general meta-level techniques are required for specifying, analyzing, and communicating consistency constraints. In this paper, we discuss the issue of consistency of behavioral models in the UML and present techniques for specifying and analyzing consistency. Using meta-model rules we transform elements of UML models into a semantic domain. Then, consistency constraints can by speci ed and validated using the language and the tools of the semantic domain. This general methodology is exempli ed by the problem of protocol statechart inheritance. Abstract.
Keywords: meta modeling, model veri cation, behavioral consistency
1
Introduction
A model in the UML usually consists of several diagrams specifying di erent viewpoints of the system at di erent levels of abstraction. However, these viewpoints are often not disjoint and models produced at di erent stages in the development process are semantically related. As a consequence, the handling of (in)consistency between diagrams or, more generally, between submodels, is an issue of major importance. As the term (in)consistency management suggests, we do not expect consistency between all submodels and throughout the development process [10, 11]. Nevertheless, it is important to be able to specify consistency constraints and to verify them, e.g., when certain milestones are reached or the model is completed. Thus, as a prerequisite for (in)consistency management, techniques are required for the speci cation and veri cation of consistency constraints. Although several approaches to consistency in formal speci cations exist [2], a general approach to consistency for the UML is still missing [5]. In particular, no general techniques have been proposed to deal with the consistency of behavioral diagrams.
Abstractly speaking, consistency means that the requirements expressed in di erent parts of a model do not contradict each other. Thus it is ensured that there exists an implementation satisfying all requirements. Consistency problems arise from the overlap between submodels within certain aspects. For example, both sequence and statechart diagrams express di erent views of the behavior of objects. In general, we may distinguish between syntactic and semantic consistency. In the context of the UML, syntactic consistency is concerned with the structural well-formedness of the abstract syntax as speci ed in the meta model [20] by means of class diagrams and the object constraint language. For example, identi er names used in one submodel must be properly de ned in another submodel. Semantic consistency is concerned, for example, with the compatibility of the speci ed behavior. A typical example is the compatibility between sequence diagrams modeling test scenarios and statechart diagrams describing the implementation of classes. In contrast to syntactic consistency, there exists no general techniques for specifying semantic (and, in particular, behavioral) consistency constraints. In this paper, we propose such a technique and exemplify its application by the well-known problem of statechart inheritance [4, 22, 13]. An \ideal approach" to semantic consistency would build on a complete formal de nition of the UML semantics, e.g., as a mapping M : UML ! D which associates every model m 2 UML with an element M (m ) of a (mathematically founded) semantic domain D , representing the \meaning" of m . Then, the semantic relation between submodels m1 and m2 could be deduced by studying their images M (m1 ) and M (m2 ) in the semantic domain, and consistency constraints could be expressed by requiring a certain relation. However, a complete formalization of the UML semantics is presently beyond hope. Moreover, as a general-purpose modeling language, the UML even lacks precise conceptual guidelines of how to use certain diagrams in the development process. As a consequence, the semantic relation between di erent diagrams or submodels cannot be xed once and for all. In order to meet the requirements of particular application domains, the UML provides extension mechanisms to de ne domain or project-speci c specializations and dialects, called pro les [19]. Since each of these may come with its own methodology, in general, semantic consistency constraints should be part of a pro le de nition. To make this feasible, meta-level techniques are needed in order to support the speci cation and veri cation of behavioral consistency constraints. Such speci cations have to be exible in order to support changes in the methodology (and revisions of the language) and local in order to provide the possibility of a partial speci cation for only those parts of the UML that are well enough understood. In this paper, we outline a general approach to the speci cation and veri cation of constraints for the UML. The approach consists of the following steps.
1. Identifying the consistency requirements. In order to formalize consis-
tency requirements, rst they have to be stated informally. Such a descrip-
2.
3.
4.
5.
tion should include the development context (the method employed and the localization of the problem), the model elements of interest, and the conceptual rules which describe the relation between these model elements in this context. Choosing a semantic domain. To support the formalization of constraints, a semantic domain must be chosen which provides a mathematical model for the consistency requirements identi ed before. Furthermore, the semantic domain should provide both a language for specifying constraints and analysis techniques for verifying them. Note, that the semantic domain is not supposed to provide a semantics of the UML in general. Thus, it can be speci cally tailored towards the aspect of interest. De ning a partial semantic mapping. Those aspects of the model that contribute to the consistency requirements identi ed in Step 1 have to be mapped onto the semantic domain chosen in Step 2. This mapping is the most subtle part of the overall process because it requires to establish a correspondence between the concepts of the semantic domain and the UML. Speci cation of consistency constraints. The consistency requirements are formalized in terms of the semantic representations of the model elements identi ed in Step 1 as de ned by the mapping de ned in Step 3. The constraints are given using the language of the semantic domain. Veri cation of consistency constraints. Using the analysis techniques of the semantic domain the validity of the previously formulated consistency constraints can be analyzed w.r.t. the individual models. Therefore, the relevant aspects of a model are translated into the language of the semantic domain and the corresponding veri cation techniques are used to establish the constraints.
In particular, Step 3 and 4 above are complicated by the fact that UML models have a graphical abstract syntax while most programming or speci cation languages (which provide the most interesting semantic domains) are textual and abstractly based on trees or terms. Thus, techniques for the translation of graphical into textual languages are required in order to simplify the formulation of these mappings. In this paper we use a hybrid, rule-based notation [6] which combines textual rules in the style of attribute grammars with meta model queries expressed as visual patterns. This generic approach is instantiated as follows. In the next section (Sect. 2), we review the consistency problem of statechart inheritance, which involves both statechart and class diagrams, and introduce two running examples. Then, Sect. 3 gives a brief introduction to CSP [14] which is our semantic domain for behavioral consistency and shows a rule-based mapping of (a subset of) statechart and class diagrams into this domain. In Sect. 4 we formulate the actual behavioral constraints by means of CSP re nement relations and discuss the automated veri cation of such constraints.
2
UML Protocol Statecharts and Inheritance
Following the roadmap outlined in the Introduction, in this section we identify (informally) the consistency requirements, discuss the development context and specify the relevant model elements in the UML meta model. In the UML, a statechart can be associated to a class in order to specify the object life cycle, i.e., the order of operations called upon an object of this class during its life-time. Given a class A and a subclass B of A, the behavioral conformity of the associated statecharts gives rise to the problem of statechart inheritance. In the literature, di erent notions are proposed (see, e.g., [4, 13, 22, 23]). In this paper, we will restrict ourselves to protocol statechart, i.e., statecharts without actions which are used, for example, in the Uni ed Process [15]. Even in this simpli ed case, (at least) two di erent notions of consistency can be de ned which are related to two dual interpretations of statecharts as specifying invocable or observable behavior. down
Tv
prog1
prog2 up
up down time
down
up
down
up up
time
prog4
prog3 down
Tv Remote
ch1
ch2 down
prog1
ch1 ch2 ch3 ch4
prog2 up
down
up
down
up up
time
prog4
prog3 down
ch4
Fig. 1.
ch3
Invocable behavior: The Tv example
Invocable behavior. In this view, which has its origin in object-oriented programming and is thus typical for behavioral descriptions at the design or implementation level, a statechart is seen as a contract between a class and its clients about the possible sequences of method calls whose implementation should be guaranteed. Thus, it speci es a lower bound to the behavior o ered by a class. The corresponding notion of behavior inheritance is based on the substitution principle requiring that an object of class B can be used where an object of class A is required. This means, any sequence of operations invocable on the superclass can also be invoked on the subclass [4]. In Fig. 1, a class Tv for a simple television set is introduced. The behavior is speci ed in the statechart as follows: The television only has four programs
and switching between these programs can only be done by calling up and down methods. The class TvRemote extends the Tv class and models a more sophisticated television set. It introduces additional methods for directly switching to a particular channel. For a client of the Tv class who is used to the simpler interface, it is important that the more elaborate device can still be used in the same way. In fact, any sequence of operations invocable on a Tv object can also be invoked on a TvRemote object, as the statechart of the former is completely included in the statechart of the latter. In order to associate a statechart to a class, we use a stereotyped dependency from the class to the statechart. In this case, the stereotype invoke expresses that the statechart models the invocable behavior of the class.
getsMarried
Person single birthday getsMarried getsDivorced
married
getsDivorced birthday
birthday
single
Traditional Person
getsEngaged
notengaged
engaged
getsEngaged birthday
birthday
getsDivorced
married getsMarried birthday
Fig. 2.
Observable behavior: The Person example
Observable behavior. At the earlier stage of development, a statechart is often used to describe all sequences of method calls that could be observed by the clients of an object. Thus, it speci es an upper bound to the behavior. In this case, the notion of inheritance re ects the idea that an object of the subclass should always behave like an object of the superclass if viewed only according to the superclass description. Hence, each sequence observable with respect to a subclass must result (under projection to the methods known) in an observable sequence of its superclass [4]. In Fig. 2, a statechart is introduced modeling the behavior of persons with respect to marriage: A Person may be either single or married, switching between the two states by means of methods getsMarried and getsDivorced. The class TraditionalPerson extends this behavior by the new method getsEngaged. A traditional person always gets engaged before getting married. This is modeled in the corresponding statechart by re ning the state single and changing the behav-
ior accordingly. In any state of a person, a birthday event may occur modeling that the person has grown one year older. From the point of view of an observer who does not care about engagement, the behavior of both classes coincides because, by ltering out the getsEngaged method, the sequences of methods of TraditionalPerson objects can be projected onto that of Person objects. Following similar conventions as above, we use an observe stereotype to express that the statechart models the observable behavior of the class. Meta model. In order to identify more precisely the model elements involved in the consistency problem, in Fig. 3 we present the relevant fragments of the UML meta model [20]. It covers a (simpli ed) notion of statechart diagrams and their association with classes by stereotyped dependencies. Note that the actual stereotypes visible in the examples are only de ned at the model level, e.g., as part of a pro le [19]. In addition, Generalization (between classes) is modeled. The presentation conforms to the UML meta model but for the attening of some inheritance relations and the introduction of one derived attribute events which shall contain the set of all events attached to the transitions internal to a State. All meta classes contain a meta attribute name:string which is not shown in the gure. (In the UML meta model this is inherited from the super class ModelElement).
Event 0..1 trigger source StateVertex 1 subvertex
target
Generalization parent 1 1 child
Transition internal
Class
client
context
Dependency
PseudoState kind: PseudoStateKind
0..1
CompositeState isConcurrent: Bool
State top events: Set(String) 1
SimpleState
StateMachine 0..1
extended Element supplier stereotype
Stereotype baseClass: String FinalState
Fig. 3. UML meta model fragment integrating statecharts, generalization of classes, and stereotypes
In Sect. 4, we shall formalize the two notions of behavior consistency discussed in this section by means of a mapping of meta model instances into CSP, which is de ned below. The meta model fragment in Fig. 3 identi es the domain of de nition of this partial semantic mapping.
3
Mapping Protocol Statecharts to CSP
In this section, we exemplify steps 2 and 3 of our general methodology. First, we give a brief introduction to CSP as semantic domain for behavioral consistency. Then, we describe, by means of meta model-based mapping rules, a translation of statecharts into CSP. CSP as semantic domain. Communicating Sequential Processes (CSP) [14] provide a mathematical model for concurrency based on a simple programming notation and supported by tools [8]. In fact, the existence of language and tool support are most important to our aim of specifying and verifying consistency constraints, despite the existence of more expressive mathematical models. Next, we brie y review the syntax and semantics of the CSP processes we are using. Given a set A of actions and a set of process names N , the syntax of CSP is given by P ::= STOP j SKIP j a
! P j P u P j P 2 P j P n a j pn where a 2 A, A A, and pn 2 N . Process names are used for de ning recursive
processes using equations pn = P . The interpretation of the operations is as follows. The processes STOP and SKIP represent, respectively, deadlock and successful termination. The pre x processes a ! P performs action a and continues like P . The processes P u Q and P 2 Q represent internal and external choice between P and Q , respectively. That means, while P u Q performs an internal ( -)action when evolving into P or into Q , for P 2 Q this requires an observable action of either P or Q . For example, (a ! P ) u (b ! Q ) performs in order to become either a ! P or b ! Q . Instead, (a ! P ) 2 (b ! Q ) must perform a or b and evolves into P or Q , respectively. This distinction shall be relevant for the translation of statechart diagrams below. Finally, the process P n a behaves like P except that all occurrences of action a are hidden. The semantics of CSP is usually de ned in terms of traces, failures, and divergences [14]. A trace is just a nite sequences s 2 A of actions which may be observed when a process is executing. A failure (s ; A) provides, in addition, the set A of actions that can be refused by the process after executing s . Divergences are traces that, when executed, are followed by an in nite internal computation. Together with these semantic models come several notions of process re nement. We write P vT Q if T (Q ) T (P ), i.e., every trace of Q is also a trace of P . Analogously, re nement relations based on failures and divergences are de ned. In general, the idea is that Q is a re nement of P if Q is more deterministic (more completely speci ed) than P . These re nement relations shall be used to express behavioral consistency constraints. Mapping rules for statecharts. As discussed in the introduction, the translation of graphical into textual languages is supported by a hybrid, rule-based notation which combines textual grammar rules with graphical patterns. Each rule consists of three parts: a meta model pattern, its concrete syntax, and a CSP
:StateMachine name = SM
top :State name = top
top
(1) Protocol(SM) = SM(top)
(2)
:CompositeState comp
SM(comp) = SM(default)
name = comp isConcurrent = false events = E default :PseudoState kind = initial source
s
:State name = default target
:Transition
:FinalState name = fin
SM(fin) = SKIP
:SimpleState name = s
SM(s) = extBeh(s)
Fig. 4.
(3)
(4)
Mapping rules for states
expression. Consider, for example, rule (2) in Fig. 4 which de nes the semantics of a composite (OR) state in terms of the semantics of its default state. In the center, this is represented by a meta model pattern showing the abstract syntax of the source language UML. On the right, the corresponding expression in the target language CSP is shown. It is parameterized over the names of the UML model elements and contains non-terminals like extBeh which are to be replaced by application of other rules. On the left, the corresponding concrete UML syntax is shown. The translation of (a simpli ed version of) statecharts into CSP processes is described by the rules in Fig. 4 and 5. In a top-down fashion, following the hierarchical decomposition of states, the rules (1) and (2) in Fig. 4 generate for each composite state an equation synthesizing its behavior from the behavior of its substates. The nal state translates into the process SKIP (cf. rule (3)) representing successful termination (instead of a deadlock). A simple state is de ned by rule (4) in terms of its external behavior which captures both the transitions directly starting from the state as well as the transitions from all (direct and transitive) superstates. This bottom-up computation of external behavior is speci ed in Fig. 5. If the state in question is already the top state of the state machine, its external behavior is empty (cf. rule (5)). In general, the external behavior of a state consists of an external choice between its direct behavior and the external behavior of its super state (cf. rule (6)). The di erence between external and internal non-determinism (2 and u) becomes obvious when looking at rules (7) and (8),
(5)
:StateMachine top
extBeh(top) ::= STOP
top
:State name = top
(6)
:CompositeState comp
extBeh(s) ::= directBeh(s) [] extBeh(comp)
name = comp
s
subvertex
:StateVertex name = s
s
(7)
:State name = s
e1 . . .
source trigger
en
:Transition
:Event name = {e1, ..., en}
(8)
:State name = s source
s1 e s e
. . .
sn
trigger
:Transition
directBeh(s) ::= succ(s,e1) [] ... [] succ(s,en)
:Event name = e
succ(s,e) ::= e −> State(s1) |~| ... |~| State(sn)
target
:State name = {s1, ..., sn}
Fig. 5.
Mapping rules for external behavior
respectively. In rule (7), the use of external choice formalizes the idea that the next event to be processed is determined by the environment of the statechart represented, e.g., by the client objects and the event queue. In contrast, once an event e is chosen, the choice between two transitions with the same trigger e is performed internally. The translation creates a system of (mutually recursive) equations, one for the overall state machine (using rule (1)) and one for every instance of meta class State (using rules (2{4)). Then, the rules (5{8) in Fig. 5 are used to replace all occurrence of the auxiliary (non-terminal) process names extBeh, directBeh, and succ by their corresponding process de nitions. Notice that we have used the machine-readable version of the CSP notation where [] and |~| denote 2 and u, respectively. Observe that the rules (7) and (8) contain multi-objects (denoted by shaded borders) which represent maximal sets of concrete objects. As a consequence, their attributes represent sets of values. For example in rule (7), the multiobject of class Transition matches all instances of this meta class connected via their source link to the state named s. Moreover, the multi-object of class Event matches all events connected to these transitions. The names of these events fe 1; : : : ; en g are listed in the name attribute of the multi-object. Next, the application of these rules to the statechart for the class TraditionalPerson is shown. (Assume that TP is the name of the state machine associated to the TraditionalPerson class.) In order to simplify the following derivation, we shall make use of the following equivalence (*) extBeh (single ) = directBeh (single )2extBeh (top ) = extBeh (top ) = STOP
which follows by rule (5,6,7) and the CSP axiom p 2 STOP = p . Intuitively, the external behavior of the top state (which is not visible in the concrete syntax and does not have outgoing transitions or super-states) is empty, and the same holds for state single which does not have outgoing transitions either. In the derivation below, the semantics of state single is de ned to be that of its default state notengaged. As notengaged is a SimpleState, rules (4) and (6) are applied. After dropping the super-state component using (*), we just collect the outgoing transitions using rules (7) and (8). The semantics of engaged and married is computed in a similar way. Protocol (TP ) = TP (top ) (1) TP (top ) = TP (single ) (2) TP (single ) = TP (notengaged ) (2) TP (notengaged ) = extBeh (notengaged ) (4) = directBeh (notengaged )2extBeh (single ) (6) = directBeh (notengaged ) () = succ (notengaged ; birthday )2succ (notengaged ; getsEngaged ) (7) = birthday ! TP (notengaged )2getsEngaged ! TP (engaged ) (8) TP (engaged ) = extBeh (engaged ) (4) = directBeh (engaged ) (6; ) = getsMarried ! TP (married )2birthday ! TP (engaged ) (7; 8) TP (married ) = directBeh (married ) (4; 6; ) = getsDivorced ! TP (notengaged )2birthday ! TP (married ) (7; 8)
As shown in this example, our mapping rules support not only the visual description of model translators based on the concrete and abstract syntax of the language, but they can also be used as a formal calculus to reason about such mappings.
4
Specifying and Analyzing Behavioral Constraints
As outlined by steps 4 and 5 of our roadmap, in this section formal consistency constraints for the two notions of statechart inheritance discussed in Sect. 2 shall be formulated based on the mapping of statecharts into CSP. Then, their veri cation w.r.t. the sample models shall be discussed. Speci cation. Consistency constraints are speci ed by identifying a model pattern which gives rise to a consistency problem (like a generalization between two classes with associated statecharts), and formulating the consistency constraint in the language of the semantic domain (e.g., as an assertion of trace re nement between two CSP expressions). The visual speci cation of these consistency constraints uses the same kind of mapping rules as in the previous section: In the center, the (meta) model pattern of is shown with the corresponding concrete syntax on the left, and the (textual speci cation of) the consistency constraint on the right. The upper part of Fig. 6 shows the constraint for invocation consistency which asserts that each trace of the (processes derived from the) superclass' statechart should also be contained in the set of traces of the statechart for the subclass. By de nition of trace re nement P vT Q i T (Q ) T (P ), this translates into a re nement in the opposite direction. Note that we use the notation supported by the FDR tool [8] where [T= denotes trace re nement vT . The constraint specifying observation consistency, where the superclass' statechart speci es an upper bound to the behavior of the subclasses, is shown in the lower part of Fig. 6. The assertion states that, after hiding (with n(E2 E1 )) all new events, the subclass' statechart is a trace re nement of the superclass' statechart. Analysis. In order to verify the consistency of an individual model, for each occurrence of a model pattern representing a consistency problem we derive a corresponding assertion as speci ed by rule (9) or (10). The assertions make reference to the CSP expressions derived by the mapping rules (1) to (8). Thus, in the case of the Person example in Fig. 2, we obtain the following assertion. assert Protocol(P) [T= Protocol(TP)
n
getsEngaged
Analogously, the Tv example in Fig. 1 yields assert Protocol(TvRemote) [T= Protocol(Tv)
client
SM1 C1
:Dependency
:Class name = C1
context
(9) supplier
:StateMachine name = SM1
parent
Generalization SM2 C2
child
:Class name = C2 client
context
:StateMachine name = SM2
:Dependency
:Dependency
C1
C2
:Class name = C2
(10)
:State events = E1 :State events = E2 top
context
stereotype
:Stereotype name = observe baseClass = Dependency
assert Protocol (SM1) [T= Protocol (SM2)\(E2−E1)
stereotype
:StateMachine name = SM2 :Dependency
Fig. 6.
stereotype
supplier
Generalization
client
assert Protocol (SM2) [T= Protocol (SM1)
supplier
top
context
parent
child
SM2
:Stereotype name = invoke baseClass = Dependency
:StateMachine name = SM1
client
:Class name = C1 SM1
stereotype
supplier
Behavioral constraints for statechart inheritance
The di erent assertions derived in the two examples result from the use of di erent stereotypes observe and invoke, respectively, and they formalize di erent requirements for consistency in both cases. Using the FDR tool, both assertions can be veri ed automatically. In the Person example, representing observation consistency, this means that all traces of TraditionalPerson are included in the set of traces of Person if we hide all occurrences of the getsEngaged operation, which is not de ned for Person. For the Tv example, representing invocation consistency, the assertion implies that any sequence of operations invoked on a Tv object is also invocable on a TvRemote object. On the contrary, observe that the two examples do not satisfy the respective dual notions of consistency. (This does not contradict the consistency of the models because the corresponding assertions are not produced by the rules in Fig. 6.) With respect to invocable behavior, Protocol(TP) is not a consistent re nement of Protocol(P) because the trace getsMarried is not invocable on instances of TraditionalPerson. Similarly, TvRemote is not observation consistent with Tv because the restriction of trace up ch4 time up invocable on TvRemote yields the trace up time up which is not a trace of Tv. Figure 7 shows a screenshot of the FDR tool with this example. The tool is essentially a model checker verifying re nements between CSP expressions. If this relation does not hold, a trace or failure is produced as a counterexample.
Fig. 7.
A screenshot of the FDR tool showing a counterexample
It is evident that, in order to make our approach usable in practice, an interface will be required which presents such counterexamples in UML notation. This could either be done via sequence diagrams representing the error trace, through animations of the respective submodels, or by back-annotating consistency errors in UML diagrams. Thus, ordinary modelers would not have to deal with formal notations such as CSP.
5
Conclusion
In this paper, we have proposed a methodology for specifying and analyzing behavioral constraints in the UML based on a mapping of models into a semantic domain with language and tool support. It was not our aim to provide a full denotational semantics for the UML (or even a reasonable sublanguage of it). On the contrary, the mapping can be de ned locally for the language features of interest, even if the semantics of other model elements is not yet clari ed. This methodology generalizes ideas from di erent approaches to the formalization and analysis of object-oriented models. Some of them are based on a complete formalization of the modeling language. For example, [18, 3] translate object-oriented models to LOTOS speci cations which can be analyzed for consistency using tools for state exploration and concurrency analysis. Thus, in this case LOTOS provides the semantic domain for specifying and checking consistency properties, with support for both data type and behavioral aspects. The design of a general-purpose semantic framework, which capture most aspects of object-oriented modeling through a combination of transition systems, algebraic speci cations, and transformation rules is the objective of [12]. Other approaches are dealing with one particular consistency problem in isolation. Fradet et al. [9], for example, propose an approach to consistency
checking of multiplicities in class diagrams. They de ne the semantics of a class diagram to be the set of all its instances ful lling the constraints. Consistency then means that this set is not empty. This is checked by solving a system of linear inequalities derived from the class diagram. A similar example is [17] who analyze timing constraints in sequence diagrams for their consistency by solving systems of linear inequalities. A rule-based mapping is used in [1] to translate UML fragments to (timed) Petri nets. Thus, in these examples, linear inequalities and Petri nets provide the semantic domains of choice. Our methodology is more in the line of the second category of \partial solutions", although the overall structure and the rule format could also support a complete mapping. In [7], the approach is applied to the problem of consistency of capsule statecharts and protocol statecharts in UML-RT, while [16] follows a similar idea for analyzing the consistency of timing constraints in sequence diagrams by calculating the worst-case execution times of statecharts. In order to be able to modify the notion of consistency (when the development process evolves or a new pro le is created), it is important that the semantic mapping is de ned in a exible and extensible way. We think, that the rulebased notation used in Sect. 3, which was rst used in [6] for describing Java code generation and is originally motivated by pair grammars [21], provides a good starting point. However, it has to be supported by a tool which is able to generate a model compiler from such a rule-based description. Currently, we are investigating the use of XSL transformations for this purpose.
References 1. L. Baresi and M. Pezze. Improving UML with Petri nets. In A. Corradini and M. Bauderon, editors, Proc. ETAPS 2001 Workshop on Uniform Approaches to Graphical Process Speci cation Techniques (UniGra 2001), Genova, Italy, Electronic Notes in TCS 51. Elsevier Science, 2001. 2. E. Boiten, H. Bowman, J. Derrick, and M. Steen. Viewpoint consistency in Z and LOTOS: A case study. In J. Fitzgerald, C. B. Jones, and P. Lucas, editors, Proc. 4th Intl. Symposium of Formal Methods Europe, Graz, Austria, LNCS 1313, pages 644{664. Springer-Verlag, 1997. 3. B. Cheng, L. Campbell, and E. Wang. Enabling automated analysis through the formalization of object-oriented modeling diagrams. In Proc. IEEE Intl. Conference on Dependable Systems and Networks. IEEE Computer Society, 2000. 4. J. Ebert and G. Engels. Structural and behavioral views of OMT-classes. In E. Bertino and S. Urban, editors, Proc. Object-Oriented Methodologies and Systems, LNCS 858, pages 142{157. Springer-Verlag, 1994. 5. G. Engels and L. Groenewegen. Object-oriented modeling: A roadmap. In A. Finkelstein, editor, Future Of Software Engineering 2000, pages 105{116. ACM, 2000. 6. G. Engels, R. Hucking, St. Sauer, and A. Wagner. UML collaboration diagrams and their transformation to Java. In R. France and B. Rumpe, editors, Proc. UML'99, Fort Collins, CO, USA, LNCS 1723, pages 473{488. Springer-Verlag, 1999. 7. G. Engels, J.M. Kuster, L. Groenewegen, and R. Heckel. A methodology for specifying and analyzing consistency of object-oriented behavioral models. In V. Gruhn,
8. 9.
10. 11. 12. 13. 14. 15. 16. 17. 18.
19. 20. 21. 22. 23.
editor, Proc. European Software Engineering Conference (ESEC/FSE 2001), Vienna, Austria. To appear. Formal Systems Europe (Ltd). Failures-Divergence-Re nement: FDR2 User Manual, 1997. P. Fradet, D. Le Metayer, and M. Perin. Consistency checking for multiple view software architectures. In O. Nierstrasz and M. Lemoine, editors, Proc. European Software Engineering Conference (ESEC/FSE 1999), LNCS 1687, pages 410{428. Springer-Verlag / ACM Press, 1999. C. Ghezzi and B. A. Nuseibeh. Special Issue on Managing Inconsistency in Software Development (1). IEEE Transactions on Software Engineering, 24(11), November 1998. C. Ghezzi and B. A. Nuseibeh. Special Issue on Managing Inconsistency in Software Development (2). IEEE Transactions on Software Engineering, 25(11), November 1999. M. Groe-Rhode. Algebra transformation systems and their compositions. In Proc. Fundamental Approaches to Software Engineering (FASE 1998), LNCS 1382, pages 107{122. Springer-Verlag, 1998. D. Harel and O. Kupferman. On the Inheritance of State-Based Object Behavior. Technical Report MCS99-12, Weizmann Institute of Science, Faculty of Mathematics and Computer Science, June 1999. C. A. R. Hoare. Communcating Sequential Processes. Prentice Hall, 1985. I. Jacobson, G. Booch, and J. Rumbaugh. The Uni ed Software Development Process. Addison Wesley, 1999. J. M. Kuster and J. Stroop. Consistent design of embedded real-time systems with UML-RT. In Proc. 4th IEEE International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC'2001), 2001. X. Li and J. Lilius. Timing analysis of UML sequence diagrams. In R. France and B. Rumpe, editors, Proc. UML'99, Fort Collins, CO, USA, LNCS 1723, pages 661{674. Springer-Verlag, 1999. A. Moreira and R. Clark. Combining object-oriented modeling and formal description techniques. In M. Tokoro and R. Pareschi, editors, Proc. 8th European Conference on Object-Oriented Programming (ECOOP'94), LNCS 821, pages 344 { 364. Springer-Verlag, 1994. Object Management Group. Analysis and design platform task force { white paper on the pro le mechanism, April 1999. http://www.omg.org/pub/docs/ad/ 99-04-07.pdf. Object Management Group. UML speci cation version 1.4, 2001. http://www. omg.org. T. W. Pratt. Pair grammars, graph languages and string-to-graph translations. Journal of Computer and System Sciences, 5:560{595, 1971. Jean Louis Sourrouille. UML behavior: Inheritance and implementation in current object-oriented languages. In R. France and B. Rumpe, editors, Proc. UML'99, Fort Collins, CO, USA, LNCS 1723, pages 457{472. Springer-Verlag, 1999. Markus Stumptner and Michael Schre . Behavior consistent inheritance in UML. In A.H.F. Laender, S.W. Liddle, and V.C. Storey, editors, Proc. 19th International Conference on Conceptual Modeling, Salt Lake City, Utah, USA, LNCS 1920. pages 527{542. Springer-Verlag, 2000.
