Towards a Formal Foundation of Behavioral Types for UML State-Machines

Transcription

1 1 Towards a Formal Foundation of Behavioral Types for UML State-Machines Jan Olaf Blech, Bernhard Schätz fortiss GmbH, Munich, Germany {blech,schaetz}@fortiss.org Abstract Behavioral s for model-based development comprise abstract behavioral aspects of the models they are associated with. Behavioral s allow checking that a model fulfills these behavioral aspects. Furthermore, as s can be related with each other, they support more complex checks and guarantees like compatibility in composition and refinement of models in a model based development process. We propose a behavioral system and explain its properties, specifically targeting a subset of UML state-machines. We present an early implementation that generates behavioral definitions out of an Eclipse-based modeling environment. These definitions are generated for the higherorder proof assistant Coq as files. We present checking and comparison techniques based on these files for behavioral aspects that can be derived from the model definition. 1 Introduction The use of s as a constructive form of quality assurance is one of the core means of supporting correctness of development in programming languages. Standards for safetycritical systems like IEC [13] highly recommend the use of strongly d programming languages. Type systems of common languages like C++ or Java feature basic s like booleans, integers, or strings, as well as means of composition for those s, e.g., structures and class definitions. While such s only form a very coarse abstraction of the behavior of a program under development, the static verification of the correctness via automatic checks of programs allows to avoid a substantial amount of relevant errors. In contrast to this rather coarse-grained form of abstraction, in the formal verification of the correctness of programs especially the verification of refinement relations in a topdown development process very fine-grained representations of the behavior of the systems are used. Here, often the more abstract models of the system under development exhibit an underspecified, more non-deterministic behavior than the final implementation. However, even the more abstract models can be used as a behavioral specification nevertheless. While this allows to formalize powerful refinement relations between a specification and its implementation, the limited automation of checking these refinements restricts their practical application. In the following, behavioral s are used as an intermediate approach between classical s detecting only the most basic violations of dataflow, and formal verification limiting the automation of correctness checks. The concepts are.uml generator.v interactive modeling in the Eclipse environment additional.v files Coq automatic and interactive checking in Coq Figure 1: Coq based behavioral s for UML demonstrated in the context of the Unified Modeling Language (UML) [17], widely used to specify systems from their requirements via their design to their implementation. In a (formal) model-based development process these models get refined and decomposed into sub-models via refinement steps until they are detailed enough to derive an implementation, e.g., via code generation. Here, we concentrate on behavioral aspects of models specified as UML state-machines at different phases in the development process. We use these specifications to demonstrate an Eclipse-based behavioral system for UML state-machines, based on state transition relations of the state-machines as behavioral s, allowing to detect inconsistencies between different phases in the development process. We illustrate the concepts by implementing behavioral s in the Coq proof assistant. As deciding whether a, i.e., transition system, implements another is generally undecidable, we use abstractions limiting the aspects covered by the s. These abstractions make the system decidable. However, the higher-order logic specification mechanism that comes with Coq and our framework, also supports more expressive s and the possibility to reason about them even interactively. Our behavioral s for state-machines are created from UML specifications automatically. The generation is integrated into an Eclipse based environment. At this stage, checking and further reasoning is done in the Coq environment using automated techniques for the restricted s or interactive proving for the more general s. As an additional advantage, the usage of the Coq proof assistant allows us to prove the correctness of the underlying techniques for checking as a long term goal. Figure 1 shows the proposed workflow: UML2 files (.uml) are parsed and Coq representations (.v files) of statemachines and sequence diagrams are generated. These can be used with Coq for reasoning about them.

2 2 1.1 Contribution While the presented work uses interrelation between behavioral specification on different levels of abstraction in form of UML state-machines as proof of concept, the focus here is not to introduce new approaches for semantical aspects of state-machines and other UML diagrams. Rather, we identify some techniques that have been individually used in formal approach for correct systems, organize them in the conceptual framework of behavioral s, identify major building blocks for their practical application, and illustrate their implementation. Although prefix-closed trace sets will be used as formalization of behavioral s, the focus of the presented approach is not a specific formalization but rather the identification of the core concepts of behavioral s. In detail, our main contributions are: The identification of the core concepts of behavioral s for components: the abstraction of behaviors to s, the notion of compatibility and implementation, and the composition of s. The proposal for a framework to reason on behavioral s for Eclipse based modeling tools. An implementation for automatic generation of Coq [10] representation files out of subsets of UML statemachines which is based on state transition relations and work on automated checking using Coq. In the following, behavioral s are supported by a higherorder proof assistant implementation for an integrated development environment. The implementation provides a proof of concept for simple subsets of state-machines and sequence diagrams. While the efficiency of the automated checks is not addressed there, all core concepts have been implemented and investigated based on the described tool chain. 1.2 Related Work A large body of work has been done on the semantics of UML. Relevant to this work is the abstract behavioral semantics for UML state-machines and sequence diagrams, studied in [6]. However, unlike the approach presented here, these techniques operate on the individual models and not on their abstractions. The concept of compatibility of behavioral specifications and suitable notions of refinement have been investigated in context of interface automata [1]. However, they focus on the aspects of expressive interface specifications rather then applying them in a behavioral systems. Behavioral s for component based systems have been investigated in [2]. In this work, the focus is put on the definition of a suitable formal representation to express s rather and investigate their methodical application in the context of a model-based development process. Behavioral s for component based systems have also been studied in [15], including compatibility and sub-typing. However, the focus is rather on the integration of different s of automata formalisms in a simulation framework than applying it to a model-based development process. The use of behavioral s has also been addressed in systems of synchronous dataflow languages like Lustre [9]. Focusing on the validity of signals, a compact representation of s and a decidable system supporting derivation and the checking of consistency is provided via the use of a clock calculus; however, the issue of refinement is not addressed. Concrete abstractions for extracting behavioral descriptions for automotive component systems have been studied in [7], however, without a more systematic investigation of the methodical aspects of a behavioral system. Formalization of UML and OCL using a higher-order proof assistant has been studied in [8]. Other work on UML statemachine semantics in Coq has, e.g., been done in [3]. UML diagrams specifying behavior have also been translated into Coq formulas in the context of protocol verification [14]. In contrast to those approaches, here we apply Coq for the checking of behavioral s. Another aspect of our work is the generation of theorem prover representations using Eclipse/EMF based techniques. We have applied techniques similar to the ones used in this paper for the generation of Coq code representing the semantics of systems before. This comprises, e.g., uses for PLC and the IEC standard [4], or for an asynchronous distributed component based modeling language [5]. 1.3 Overview Section 2 presents our ideas for a behavioral system for model based development. Work on our concrete implementation is divided into the generation of s in Section 3 and the handling/checking of s in Section 4. We conclude in Section 5 and present ideas for future work. 2 Behavioral Types In this section we give an overview on the core concepts of behavioral s, i.e., its abstracting nature and its support for the development of correct systems. Furthermore, we show how these concepts can be applied in model-based development for models of component systems. 2.1 Core Concepts To support a (model-based) development process of correct systems, (behavioral) s must provide a number of core concepts: Abstraction: Behavioral s represent aspects of (models of) programs, components, or systems, providing an abstraction from details concerning the interaction with their environment as well as their internal structure. Type : As in model-based development behavioral s are abstractions of models, is used to correctly relate a model to its behavioral.

3 3 while... switch... case... case... implementation implementation confomance refinement refinement composition inference Figure 2: Refinement checking scenario Type refinement: For supporting stepwise refinement, behavioral s provide the concept of refinement to ensure the correct implementation of abstract specifications by concrete components. Type compatibility: For supporting the combination of components, behavioral s provide the concept of compatibility to help ensure the useful composition of components to systems. Type inference: Furthermore, for the same reason, behavioral s provide the concept of inference to allow to infer the of a composed system from the s of its constituents. To be useful in a development process, of course, a suitable notion has to be selected with respect to refinement: For a pair of models conforming to a pair of s with the second model implementing the first, the second should be a refinement of the first. Furthermore, refinement, compatibility and inference should agree: If a compatible to a given is refined by another, the later should be compatible to the given one; similarly, if in a composed one is replaced by a more refined, the inferred of the first composition should be a refinement of the second composition. Also, for practical application in a model-based development process, a behavioral should not only be explicitly provided for a model by the user and checked for, but (automatically) constructed for this model. Finally, as checking of expressive behavioral s is in general undecidable, an adequate level of expressiveness is needed making checking feasible without over-restricting the expressiveness of the behavioral s. 2.2 Usage Using the above concepts, behavioral s can be helpful for different aspects of model-based development. Correctness of Implementation Behavioral s can be used to relate models and code, e.g., as products of different stages in a development process, to ensure a certain Figure 3: Compound components scenario coercion compatibility Figure 4: Compositionality checking scenario aspect of behavior is preserved. Figure 2 illustrates this with models of different degrees of abstraction state-machines and source code representing the same system. Explicitly providing or automatically constructing corresponding conformant s, correctness of refinement can be checked by using these s, ensure the correctness of the implementation with respect to the abstraction implied by the system. Furthermore, refinement checking is also used in structural refinement when implementing a component by a collection of subcomponents. As shown in Figure 3, the refinement relation is checked between the s of the composed components and the of the collection of subcomponents. The of the composed component can also be derived from the respective behavioral s of the subcomponents. Compositionality and Interfaces Behavioral s can furthermore be used to check whether components to be composed are compatible with each other, as shown in Figure 4. Additionally, using coercion i.e., the inference of the least abstract s refining the investigated pairs and being compatible basically incompatible components can be composed. This generally involves an adaption of the corresponding models by providing glue code similar to automatic casts for, e.g., integers of different length to make the two components interact with each other.

4 4 initialize compilation chain running system model extraction monitor generation monitor Figure 5: Behavioral s as monitors in RV Init inactive Simple Speed Control activate deactivate brake active other s for UML diagrams that specify some aspects of the behavior of speed control. This comparison can be used during the abstract and detailed design and not covered in this paper in a later implementation, supporting a stepwise refinement. For example in the next phase the active state can be specified in a more detailed way supporting several modes as shown in Figure 7. The standard, eco and sport mode may show different acceleration and braking behavior thereby supporting, e.g., more fuel-efficient driving in the eco mode. However, when abstracting from possible transition guards (), other behavioral functionality and other events these may limit the order of possible executions the original behavior specification still applies: Each mode supports braking and acceleration. We can now extract a behavioral of this more refined model and compare it with the first one. On this abstraction level regarding only brake and acceleration guards both specifications have the same set of execution traces. As an ultimate goal, the development environment should support the extraction and checking of behavior automatically and provide a means of informing the developer about any behavioral incompatibilities, i.e., understandable behavioral errors. accelerate Figure 6: A simple speed control state-machine Runtime Verification Finally, behavioral s can be used for runtime-verifying systems, supplying a monitor being executed in parallel with a system implementation. The monitor corresponding to a behavioral and checking all behavioral constraints specified via the observes the system behavior, reporting violations. Monitors may be generated from behavioral s automatically. Figure 5 shows a usage scenario for behavioral s in runtime verification. Using an explicitly provided or inferring it from the model, this serves as the basis for generating a runtime monitor which is then deployed with the compiled model as a runtime-verified system. This aspect is not treated in our current implementation. 2.3 An Example for Refinement of Behavioral Types Figure 6 shows a state-machine speed control as part of an adaptive cruise control system in a car, using the graphical model of the Eclipse-based Papyrus UML tool [16]. This state-machine provides an abstract component specification created during requirements specification in the development process. It specifies that this component shall be able to perform acceleration and braking. It can be compared with 3 Theorem Prover Representations of UML State-Machines For automatically generating theorem prover representations conforming to UML state-machines, we address a subset of the UML2 meta-model that comprises flattened, but parallel state-machines and other entities like events and guards. Basic operational elements of state-machines We regard a state-machine as a state transition system. Distinct system states are taken during its execution. The semantics of a UML state-machine is defined by its states (including initial and final states) and transitions. Different operational elements having some effect on the operational semantics can be associated with transitions and can be encountered during a system run. These operational elements can be used in the diagrams of the UML2 meta-model. Here we concentrate on three s of such elements: events, guards, and behavioral functions. They are associated with state-machine transitions 1. In a typical interpretation, events shall indicate a reaction of a system to some external or internal event, guards are predicates which check the current system s state (e.g., comprising a memory which maps variables to their current values) for some condition, and behavioral functions perform some update on the system state. 1 In addition to events, guards, behavioral functions, other elements exist in the meta-model. They can not only be associated with transitions, but also with states. We do not regard these elements in this paper. Furthermore, events, guards and behavioral functions can be structured in a more fine grained way using Object Oriented concepts like inheritance.

5 5 Speed Control Active Init brake accelerate Eco mode Standard Mode brake accelerate Sport mode brake accelerate Figure 7: Refining the active state All events, guards, and behavioral functions have names. The meta-model and in many cases the concrete UML models do not specify a comprehensive operational semantic definition of these elements, e.g., for behavioral functions we often do not have a state transition function. This is especially true for early phases in a system development. We rather regard these elements as abstract placeholders which one can distinguish by their names, their and the order in which they may occur in a system run. Regarding the s, we assume, that in a final implementation behavioral functions and guards can be evaluated and guards return a boolean value. Our Coq work allows (but does not require) an integration of concrete functions for behavioral functions and guards if they are specified. UML state-machines We handle flat state-machines in this work and allow parallel execution. In Coq as in the UML2 meta-model we represent parallel state-machines independently. Each non-parallel state-machine as a transition system (S, S 0, T ) of states S, a set of initial states S 0 and a set of transitions T. Each transition is a tuple (s, g, f, E, s ) featuring a start state s, an optional guard g, an optional behavioral function f, and a list (can be empty) of events E. The generated state transition relations realize behavioral s in our framework. An example of a generated transition relation is given in Figure 8. It is generated from the model shown in Figure 6. State names are referred to using long names which are constructed by our tool. This means, that the initial state becomes: model Simple Speed Control Region0 Init The first line shows the name of the definition which is extracted from the UML2 model. The next five lines are the definition of the transition relation. The next lines give a list definition :: represents a concatenation to a list, nil represents an empty list of state transition tuples. 4 Using Behavioral Types in our Framework Here we describe our Coq based framework for using the generated behavioral definitions as well as design goals. 4.1 The Coq Framework For using our Coq representations of UML diagrams one has to distinguish two different goals: The framework itself shall be general enough to support various kinds of behavioral aspects. Checking that a state-machine corresponds to a can be done interactively using the theorem prover environment. The framework should support checking with only minor if at all manual effort for a developer for some forms of abstraction of behavior. For our Coq framework we advocate (abstracted) state transition systems as representations for behavioral s. The state transition system may represent an overapproximation of the actual system definition. They are represented as described in Section 3. Various formalisms can be used to relate syntactical representations of behavioral s, e.g., (weak-)simulation, (weak-)bisimulation (cf. [11]), final value semantics for terminating systems, trace inclusion. In this work, we favor a semantical interpretation of our syntactical representations as sets of traces (or fragments of them).

6 6 Definition Transitions_model Simple_Speed_Control Region0 : list (STATES_model Simple_Speed_Control Region0 * option CONSTRAINTS * (list EVENTS) * option FUNCTIONS * STATES_model Simple_Speed_Control Region0) := ( model Simple_Speed_Control Region0 Init, None, nil, None, model Simple_Speed_Control Region0 inactive ) :: ( model Simple_Speed_Control Region0 inactive, None, model ActivateSCEvent :: nil, None, model Simple_Speed_Control Region0 active ) :: ( model Simple_Speed_Control Region0 active, None, model DeactivateSCEvent :: nil, None, model Simple_Speed_Control Region0 inactive ) :: ( model Simple_Speed_Control Region0 active, None, model BrakeEvent :: nil, None, model Simple_Speed_Control Region0 active ) :: ( model Simple_Speed_Control Region0 active, None, model AccelerationEvent :: nil, None, model Simple_Speed_Control Region0 active ) :: nil. Figure 8: A generated transition relation We define two dimensions of relationships between s based on sets of traces which represent (in our standard cases an overapproximation of) the system behavior. Trace inclusion Abstraction level of traces Both dimensions are the basis for checking refinement and compatibility. In our case we are regarding overapproximations of a model behavior using sets of abstracted traces. These overapproximation may contain various trace-fragments which may not be present in the real system. Traces comprise transitions encountered by the system as elements (s, g, f, E, s ). Single transition elements are an overaproximation of transitions occurring in concrete system runs, too: E may contain several elements, whereas in a transition step conducted in a concrete execution only one element would be there. Semantically, we can use in the absence of concrete guards, true instead and a form of undefined functions for non-specified behavioral functions. Keeping entire transitions as elements in the traces facilitates induction proofs on traces, when proving (inductive) invariants. 4.2 Automatic Type Checking For a refinement and compatibility checking, we are not taking the effects (i.e., modifications to some non-visible system state) of events, guards and behavioral functions into account. This introduces potential non-determinism and realizes the over-approximation of the system behavior compared to a real implementation. We are only taking the set inclusion and possible abstractions on the transition relations into account. This is defined for two transition relations T, T 2 as: statemap. (s, g, f, E, s ) T. (s 2, g 2, f 2, E 2, s 2) T 2. statemap (s 2) = s statemap (s 2 ) = s g 2 g f 2 f E 2 E The operator denotes an equivalence check between guards, behavioral functions and lists of events. Equivalence between lists of events is defined such that every permutation of a list is equivalent to the original list. Semantically this corresponds to check inclusion of abstractions of sets of fragments of traces defined inductively in the following way for a state-machine (S, S 0, T ): nil FragTraces S,S0,T (s, E, g, f, s) FragTraces S,S0,T if (s, E, g, f, s) T (s, E, g, f, s) :: (s, E previous, g previous, f previous, s previous ) :: rest FragTraces S,S0,T if (s, g, f, E, s ) T (s, E previous, g previous, f previous, s previous ) :: rest FragTraces S,S0,T :: denotes concatenation of an element to a trace, nil denotes the empty trace. Since we are checking trace fragment inclusion compatibility is a non-symmetric property and corresponds to our notion of refinement of a state-machine. Abstractions comprise the mapping of states from one system to

7 7 Lemma correctness_functions_dec_i : forall f f, f = f <-> Is_true (FUNCTIONS_dec_i f f ). Proof. intros; split; destruct f; destruct f ; simpl; intros; try congruence; try contradiction; auto. Qed. Figure 9: A generated example lemma + proof corresponding states in the other system (using the statemap function). 4.3 Proving Refinement and Equality between two State-Machines We have implemented a checker for state-machines, which realizes refinement and compatibility checks and serves as a basis for more complex behavioral operations. It is realized using a function that checks for a given statemachine and a given equality / inclusion of trace fragments as described in Section 4.1. In addition to this it uses functions that decide the equality of event lists, guards, behavioral functions and states in a for higher-order proof assistants fast way by using computational reflection (see, e.g., [12] for a similar application). This allows using an executable function instead of reasoning on equality symbolically in our function definition in Coq. Using this approach, the checking process does not have to go to all term-rewriting steps, but gets rather executed like in a virtual machine in the Coq environment. This does not enlarge the trusted-computing base. In our framework the additional equality checker functions for comparing event lists, guards and behavioral functions are automatically generated with the representations of sequence diagrams and state-machines. Furthermore, we generate lemmas stating their correctness equality checker function implies equality and proofs (just a few lines) automatically in our framework. An example of such a generated correctness proof for deciding behavioral function equality is shown in Figure 9. The refinement checker uses a small function transition refinement (cf. Figure 10) to perform the check of trace fragment inclusion based on a transition relation. It requires the specification of yet another function St2St which maps states from one state-machine to the second. It checks whether each transition in the one system has a corresponding transition in the second system. That is a transition that has the same list of events assigned to it and both start and succeeding states correspond to each other indicated by St2St. Checking is done using computational reflection which can be seen in the use of functions existsb and forallb which implement and for finite lists (instead of sets) of elements. Definition transition_refinement (St St C E F : Type) (decidest_i : St -> St -> bool) (decidest _i : St -> St -> bool) (decideel_i : list E -> list E -> bool) (states1 : list St) (St2St : St -> St ) (transitions1 : list (St * option C * list E * option F * St)) (transitions2 : list (St * option C * list E * option F * St )) := forallb (fun s1 => forallb (fun t1 => match t1 with (s,c,el,f,s ) => if decidest_i s s1 then existsb (fun t2 => match t2 with (s_,c_,el_,f_,s _) => if decidest _i s_ (St2St s1) then andb (decideel_i el el_) (decidest _i s _ (St2St s )) else false end ) transitions2 else true end ) transitions1 ) states1. Figure 10: Checking transition relation refinement Parameters decidest i, decidest i and decideel i are instantiated by computable equality checking functions for the states of the two state-machines and lists of events which are automatically generated as described above. In addition to this, modified versions of decideel i may perform filtering of events and thereby allow comparison of models with different levels of event abstractions. The St2St function is the only ingredient required for comparing s from state-machines of our framework that should be provided manually in the current state of implementation. We believe that this should not hinder the acceptance of the approach in a real implementation since it should be possible to keep track of the refinement relations between states in different versions of models automatically in a well designed integrated development environment. This keeping track of refinement should allow an automatic generation of St2St. Another solution for overcoming this manual step which we have already implemented is to replace it by an existentially quantified version. A working realization of St2St can be discovered automatically in an explorative way. In principle every possible mapping is tried. This means, that for given numbers of states St and St the theorem prover

8 8 has to try St St or St St different mappings depending on the direction of refinement. Although we realized this check using computational reflection, it is not feasible for big models. We have implemented similar functions for checking different kinds of refinement together with abstractions (i.e., guard and behavioral function based). 4.4 Checking Additional Properties Regarding our core concepts for behavioral s: Checking compatibility of interfaces is based on our refinement checks. Type inference requires additional definitions. Compatibility of interfaces Compatibility of interfaces described using state-machines is regarded as a refinement check using appropriate abstractions which vary depending on the problem domain. Type inference Creating s for parallel compositions of state-machines and performing checking operations is done using a function that creates the cross product of parallel running state-machine transition relations which we have defined in Coq. Based on this, we can check refinement and equality with other parallel and non-parallel state-machine transition relation using the ingredients described above. 5 Conclusion We advocated a framework for creating and checking behavioral s in an Eclipse based environment. In particular, we presented an implementation for UML state-machines and Coq based checking. The presented work features an implementation for generating behavioral s for UML state-machines and Coq. Possible topics for future work comprises further integration into the Eclipse environment and more automation (automatic discovery of corresponding states or keeping track of them during a refinement). Covering a larger subset of state-machines and more refined s that take more aspects of the behavior into account are desirable goals for the Coq and semantics parts of our work. Proving our automatic Coq checkers correct is also important to us. Conducting and evaluating larger case-studies is yet another goal. References [1] L. de Alfaro and T. A. Henzinger. Interface automata. European Software Engineering Conference, ACM SIG- SOFT, [2] F. Arbab. Abstract Behavior Types: A Foundation Model for Components and Their Composition. Formal Methods for Components and Objects. vol of LNCS, Springer-Verlag, [3] F. Barbier and C. Ballagny. Proved metamodels as backbone for software adaptation. Symposium on High Assurance Systems Engineering, IEEE, [4] J. O. Blech and S. Ould Biha. Verification of PLC Properties Based on Formal Semantics in Coq. Software Engineering and Formal Methods, Montevideo, Uruguay, [5] J. O. Blech and M. Périn. Generating Invariant-based Certificates for Embedded Systems. ACM Transactions on Embedded Computing Systems. accepted [6] F. S. de Boer, M. M. Bonsangue, M. Steffen und E. Ábrahám. A Fully Abstract Semantics for UML Components. Formal Methods for Components and Objects, vol of LNCS, Springer-Verlag,2005. [7] P. Braun, J. Philipps and B. Schätz. Signals, States, Events, and Modes Automotive Software Workshop in San Diego, March [8] A. D. Brucker and B. Wolff. HOL-OCL - A Formal Proof Environment for UML/OCL. Fundamental Approaches to Software Engineering. vol 4961 of LNCS, Springer- Verlag, [9] J.-L. Colaço and M. Pouzet. Clocks as first class abstract s. EMSOFT, vol of LNCS, Springer, [10] The Coq Development Team. The Coq System. http: // coq. inria. fr. [11] R.J. van Glabbeek. The linear time - branching time spectrum II; the semantics of sequential processes with silent moves. CONCUR 93, vol. 715 of LNCS, Springer- Verlag, [12] B. Grégoire and A. Mahboubi. Proving equalities in a commutative ring done right in Coq. Theorem Proving in Higher Order Logics, Springer-Verlag, [13] International Electrotechnical Commission. Functional safety of electrical/electronic/ programmable electronic safety-related systems, [14] H. Jiang, D. Lin and X. Xie. Embedding UML and Type Theory to Formalize the Process of Requirement Engineering. Technology of Object-Oriented Languages and Systems (TOOLS Asia), IEEE, 2000., [15] E. A. Lee and Y. Xiong. A Behavioral Type System and Its Application in Ptolemy II. Formal Aspects of Computing, Volume 16, Number 3, August [16] Papyrus UML. http: // www. papyrusuml. org [17] Unified Modeling Language (UML), Version 2.0. Object Management Group, August 2005.