of the target field of application. The dependability of the target application necessitates the fulfillment of several quantitative requirements, as well. For instance ...
VIATRA - Visual Automated Transformations for Formal Verification and Validation of UML Models (Tool demonstration) Gy¨orgy Csert´an
G´abor Huszerl
Istv´an Majzik Zsigmond Pap D´aniel Varr´o Budapest University of Technology and Economics Department of Measurement and Information Systems varro,pataric @mit.bme.hu
Abstract
Andr´as Pataricza
dard was not intended to capture non-functional requirements, like dependability. The assurance of the qualitative correctness of a system necessitates the checking of (i) the completeness and consistency of the system specification, (ii) global correctness attributes, like the deadlock freedom of the design, and (iii) application-specific requirements, like safety requirements of the target field of application. The dependability of the target application necessitates the fulfillment of several quantitative requirements, as well. For instance, (i) timeliness of the application is one of the major criteria in real-time system design, or (ii) reliability and availability measures are crucial in the system design phase during the selection process among alternatives. During the last decades computer science has successfully attacked the majority of this problems by providing mathematic methods and tools for the modeling and analysis of dependability attributes. However, these methods are not widely used in the industry primarily due to the high level of abstractness of the mathematical modeling and analysis techniques. Additionally, the proper coverage of the different aspects of dependability requires the combined use of a variety of different mathematical paradigms. The tediousness of this mathematical process confines the use of analysis methods to the very specialized workgroups in the industry, primarily dealing with missioncritical applications. On the other hand the assurance of a proper quality of the services delivered by a complex IT system demands more and more the proven quality of the target design. A former ESPRIT project under the acronym HIDE (carried out together with FAU Erlangen, CNUCE Pisa and two industrial partners [3]) has shown the feasibility of an automated, multi-aspect dependability evaluation of UML designs in terms of the expressiveness of the models, and the
The VIATRA (VIsual Automated model TRAnsformations) framework is a transformation-based verification and validation environment for improving the quality of systems designed within the Unified Modeling Language by automatically checking consistency, completeness, and dependability requirements. In the current paper, we present an overview of (i) the major design goals and decisions, (ii) the underlying formal methodology based on metamodeling and graph transformation (iii) the software architecture based upon the XMI standard, (iv) and several benchmark applications of the VIATRA framework.
1. Introduction The advent of visual design languages promises not only a better requirement capture and easier software architecture process, but a radical increase in software productivity, as well. This increase can reach as much as one order of magnitude if the entire process is completely automated starting from the early specification until an automated code generation. UML, the Unified Modeling Language [17], was standardized by the Object Management Group (OMG) and its rapid spread as the dominant object-oriented CASE technology clearly indicates the market need for effective visual design technologies. However, the use of visual CASE methodologies does assure neither the correctness of the design, nor its dependability. The designer can still construct syntactically correct but semantically incorrect models just in the same way as erroneous programs can be written in an arbitrary high-level programming language. Moreover, the original UML stan1
run-time complexity of the mathematical analysis. The workflow of mathematical model analysis of HIDE was composed of the following main steps:
Enrichment of the UML model of the target design by local dependability attributes (like fault and repair rates) associated to the individual components. An expert can estimate these attributes in a very similar way as the parameterization of traditional dependability models;
Among all the problems, the incompleteness of the UML semantics is the most crucial one. Some definitions were omitted by error from the standard, but the exact meaning of such sensitive parts like statecharts was intentionally left open to the implementation in order to give UML a wide field of application.
Inclusion of qualitative requirements in the form of a checking automaton 1
The characteristics of the underlying platform or communication mechanisms are included neither in the standard nor in the UML model of the application. As the main objective of the entire transformation based V & V is to guarantee the correctness of the implementation, all such implementation-related issues completing the definition of the semantics of the UML standard notations have to be included into the transformation.
Automatic derivation of mathematical models (like hierarchical automata and temporal logic for the proof of logic correctness, or SPN for the quantitative evaluation of dependability) from the UML model of the target design under evaluation.
This way the use of mathematical analysis embedded into the UML based CASE tools follow two main directions:
Several CASE vendors offer embedded V & V for some specific aspects. For instance, i-Logix offers formal verification and validation analysis embedded into his Statemate Magnum system [2]. This approach is characterized by the fact that the entire technology is closed for the user forming a complete and dedicated chain of tools covering the modeling, model checking and code generation phases.
Back-annotation of the results from the mathematical analysis to the UML model for presentation to the designer.
2. Design guidelines for a transformation framework
An important experience gained from HIDE was that an ad-hoc implementation of transformations lacks the necessary preciseness, thus implementation errors can make the transformations be the weakest point in the chain of tools serving for dependability evaluation. This way a mathematically precise paradigm was searched for leading to a general-purpose framework for the definition and implementation of transformations. Another argument towards the use of such a framework was the need for a high-degree of flexibility due to the following main reasons:
On the other hand, open platforms — like our approach — try to offer standard interfaces in order to incorporate different mathematical analysis tools and support different implementation styles. The flexibility of an open platform necessitates a proper support for the customization of the transformation rules. As a summary, the proper implementation of an open, transformation based V & V framework necessitates (i) a general purpose, mathematically solid paradigm and a user friendly methodology for the definition of UML notations (dialects) and transformations towards a variety of mathematical analysis tools; (ii) an efficient and mechanized methodology to derive model transformation and back-annotation programs from these definitions. Our new framework (called VIATRA: VIsual Automated model TRAnsformations; depicted in Fig. 1) for UMLbased system verification has the following main attributes:
The current UML standard is changing. The practical use of UML has revealed nearly 500 major problems in the standard [9]. This way, in the nearest future, UML will face a major revision affecting both the syntax and semantics.
Additionally, UML introduces standard methodologies for the extension and specialization of the language in order to increase the expressiveness. OMG itself defines domain specific dialects (so-called profiles) for some major application areas (like RT-UML or BPM). Moreover, the user can introduce his own notations by stereotypes and/or tagged values.
1 Requirement modeling is still one of the least established fields in UML based analysis. Alternate approaches use OCL [6] or some form of CTL for requirement modeling.
2
Both the UML dialect to be used by the modeler of the target design and the input notation of the target mathematical analysis tool are defined by their respective metamodels. This metamodel based approach offers a high degree of flexibility both towards the UML dialect used (like the inclusion of different OMG standard profiles or adaptation to a modeling and implementation style used in an enterprise) and the target mathematical language.
UML profile
Transformation rules
quantitative dependability evaluations and (iv) highlevel fault modeling and analysis.
Metamodel of the mathematical paradigm
Current pilot applications implemented in co-operation with industrial partners cover mission critical designs like the controller of an artificial kidney and a module of a railway control system. The previous characteristic features distinguish VIATRA from other existing metamodel-based model transformation frameworks including MTRANS [15], the UML Object Diagram based approach of [12], ATOM3 [8], and the GME environment [18]. In the following sections, we first provide a brief overview of the modeling concepts in VIATRA. Afterwards, in Sec. 4, a technological overview is given on the VIATRA framework. Benchmark applications include summarized in the paper the formal verification of distributed object-oriented systems (Sec. 5) and system safety requirements 6 with benchmark applications in an industrial environment 7. Finally, Sec. 8 concludes our paper.
VIATRA code generator Standard UML
transformation program VIATRA transformation core
Mathematical modeling language
Analysis tool
(a) Transformation designer view UML profile as modeling language
System model under analysis
transformation program VIATRA transformation core
Mathematical modeling language
Analysis tool
3. Modeling concepts in VIATRA (b) User view
A model transformation-based verification approach for UML models requires the precise definition of models from various application domains, which are specified uniformly by visual metamodeling techniques in VIATRA. A precise metamodeling method includes (at least) the formal definition of the abstract syntax, the static and dynamic semantics of a language. In VIATRA, the static syntax of a modeling language is specified in the form of UML class diagrams (following basically the concepts of MOF metamodeling [13]) and formalized by typed, attributed and directed graphs. Metamodels are interpreted as type graphs, and models are valid instances of their type graphs indicated by typing homomorphisms. Moreover, our experiments show that mathematical notations described by a corresponding metamodel are much more expressive for engineers than pure mathematical formulae. Therefore, in VIATRA, the metamodeling techniques not only handle the definition of UML profiles but they also specify the notation and structure of mathematical models. In traditional metamodeling approaches (e.g., [4]), the static semantics of a modeling language is defined using the Object Constraint Language (OCL). However, OCL has several disadvantages from an engineering point of view as it is purely textual (in contrast to the visual UML class diagrams) and not declarative (rather a programming language than a specification language). VIATRA uses a declarative and pattern-based description technique for static semantics where the majority of well–formedness constraints is provided by graph patterns, which has the clear advantage over
Figure 1. The architecture of the VIATRA framework
Transformations can be defined in the form of a set of simple transformation rules correlating individual UML notational elements with the target mathematical notation. These transformation rules themselves can be designed in UML thus providing an easy-to-use interface for the designer of the transformation.
The transformers are automatically derived from the rules by using the mathematically well-defined and widely used principle of graph transformations [5] (a generalization of the Chomsky-grammars used in compiler construction).
A back-annotation engine (based directly upon the automatically generated transformer) provides the user with the analysis results integrated into the original UML model thus avoiding the interpretation of mathematical results. It has to be noted, that the entire transformation definition and implementation framework is hidden from the end user in the VIATRA framework, as he deals only with the back-annotated results. The pilot transformations include (i) formal proof of logic correctness of UML statechart specifications, (ii) check of their completeness and consistency, (iii) 3
attributed graphs . An edge e1 (of type states) may lead between a1 (of type Automata) and s1 (of type State) if there exist a node Automata in the metamodel, which itself or one of its superclasses is connected to a node State (or to a superclass of State). The interested reader is referred to [20] for further theoretical details on mapping our models into graphs.
OCL and other textual constraint languages that it preserves visuality. Graph patterns also play a major role in the definition of the dynamic semantics of a model as the evolution of a model is described by graph transformation rules [5]. Transformations within and between models are uniformly specified by corresponding graph transformation rules thus providing an easy-to-understand visual way for semantic definitions. StartState
transtions a1:Automata t2:Transition
current
Automata e1:states states
transitions
current AccState
name:String
to
transitions
states
State
from
from to
s1:State
Transition
s2:State
t1:Transition
from
to
char: Char
(a) Before rewriting current transtions a1:Automata t2:Transition
Figure 2. The metamodel of finite automaton A sample metamodel taken from a mathematical domain is depicted in Fig. 2 to demonstrate the metamodeling concepts of VIATRA. The metamodel of finite automata is composed of
e1:states states
transitions
s1:State
to
s2:State
t1:Transition
from
Nodes: (i) MetaClasses such as Automata, or Transition; (ii) MetaAttributes like name or char ; (iii) Basic Types, such as String, for instance;
from
to (b) After rewriting
Figure 3. A model of finite automata
Edges: (i) Aggregation relations (associations) between MetaClasses, e.g. an Automata is composed of States and Transitions by states and transitions links; (ii) Reference relations, which define for instance that a Transition is related to a from State and a to State by the corresponding associations; (iii) Inheritance relations: an InitState is a State thus it may be connected to other states via transitions;
3.2. Defining Dynamic Semantics The semantic parts of metamodeling are mainly established by static aspects (investigating how well–formed models are constructed) and dynamic aspects (answer the question: how a model evolves during its life-cycle). In VIATRA, both parts of semantics are based upon the patternbased manipulation techniques of graph transformation. is a 3-tuple
Agraph transformation , where rule is the left-hand side graph, is the right-hand side graph, while is (an optional) negative application condition graph. A sample graph transformation rule is depicted in Figure 4. The application of a rule to a model graph (UML model of the user) rewrites the user model by replacing pat with . the tern defined by the pattern of the This is performed by
The reference relation current is a dynamic concept in the metamodel as it will be modified by transformation rules later on, while static components are never changed after their creation.
3.1. Models In general, models are instances of metamodels; in other words, they are instantiated on a lower metalevel. For example, the sample automata in Fig. 3(a) is a valid instance of the metamodel of Fig. 2. This means that an instance (also called object in terms of UML) of the MetaClass State is a concrete state s1 in a specific instance a1 of an Automata. Additionally, an instance e1 of a metamodel relation (e.g. states) is a concrete link between the previous objects. To formalize the concepts of models and metamodels, in VIATRA, both of them are handled as directed, typed and
1. finding an occurrence of graph pattern matching),
in
(also denoted as
2. checking the negative application conditions which prohibit the presence of certain nodes and edges 4
3. removing that can be mapped
abutpartnotofthethe graph graph to the (yielding the context graph),
S1:State
current
states
Figure 5. A static well-formedness pattern
a1:Automata
s2:State
t1:Transition
from
RHS
to
current
a1:Automata
states
transitions
s1:State
3.4. Model Transformation Rules
s2:State
t1:Transition
from
Static constraints can be checked at any time, practically, after each application of a graph transformation rule. However, checking complex patterns is expensive (since graph pattern matching is required), therefore, a more efficient (but, naturally, less precise) approach would verify the validity of constraints after having executed a sequence of rules. Further constraints on dynamic behavior (e.g., safety or liveness criteria) are expressed by temporal logic formulae where atomic propositions are formulated by elementary graph patterns.
states
transitions
s1:State
states
S2:State
NEG
4. gluing and the context graph, and obtaining the derived model .
LHS
current A1:Automata current
to
As the main goal of model transformation is to derive a target model from a given source model, source and target objects are linked together to form a single graph. For this reason, the concepts of reference graphs are introduced. The structure of a reference graph is also constrained by a corresponding reference metamodel, which contains (i) references of existing source and target metamodel nodes; (ii) novel reference nodes that provide a typed coupling of source and target objects, and (iii) reference edges interrelating nodes. Reference graphs also provide the primary basis for the back–annotation of analysis results. The entire operational semantics of a VIATRA model or its transformation is defined by a model transition system, where the next graph transformation rule to be applied in a specific mode is constrained by a control flow graph. As the majority of rules perform local modifications on the models they can be executed parallelly for all occurrences (forall mode). Alternatively, a rule is applied on a (nondeterministically chosen) single matching (try mode), or, it is applied as long as possible (loop mode).
Figure 4. Dynamic semantics of finite automaton
When the rule of Fig. 4, which describes the dynamic operational semantics of finite automata (i.e., how a transition can be fired), is applied to the model graph of Fig. 3(a), then, at first, such a transition of the automaton has to be found that has an active source state, i.e., which has a state connected by a from edge and marked as current. Finally, a new finite automata model is obtained (depicted in Fig. 3(b)) where the active state is changed to the to state of the transition as indicated by the rewritten current edge.
3.3. A Pattern-Based Definition of Static Semantics In addition to dynamic behavior, a majority of static well-formedness constraints (e.g. circular inheritance is forbidden in UML Class diagrams) can also be expressed by graph patterns (or graph transformation rules without rewriting). Such patterns have the clear advantage over OCL and other textual languages used for expressing static semantical constraints that they preserve visuality. A sample static constraint (see Fig. 5) expressing that in a valid finite automata, only a single state is allowed to be active at a time, i.e., it must not contain two current edges. The constraint states that the pattern must not be found at any time in a well-formed finite automaton.
4. A Technological Overview of VIATRA The current section gives a brief technological overview of the VIATRA framework by describing a typical scenario of model transformations in a UML environment. The overall ideas are summarized in Fig. 6. The general technological concept of the framework is the use of the XMI standard for arbitrary MOF-based metamodel (simultaneously including UML and mathematical models like Petri nets, 5
UML CASE tool (Rational Rose)
Ref meta UML Class
VIATRA interface
Ref meta XMI
Ref model XMI
Ref meta Prolog
Ref model Prolog
information meta−information meta−metainformation
Src meta UML Class
Src meta XMI
Src meta Prolog
Src model (UML)
Src model XMI
Src model Prolog
MetaMeta Prolog
TransProg Prolog
Rule meta Prolog
Rule model Prolog
Rule meta XMI
Rule model XMI
Ref meta UML Class
Rule model Class+SC
Trg meta Prolog
Trg meta XMI
Trg model Prolog
Trg model XMI
Trg meta UML Class
Automated program generation
Figure 6. Technological overview of VIATRA
dataflow networks, hierarchical automata, etc.) in order to obtain an open, tool-independent architecture.
transformation systems, and exported into the UML XMI format.
Design phase The interaction with VIATRA commences with a design phase performed within a traditional UML CASE tool.
Automated program generation In the next phase, a Prolog implementation of the transformation program is generated automatically.
1. As the initial step, we create the MOF metamodels of the source and target modeling language. Afterwards, we relate the source and target objects to each other by constructing the reference metamodel. For this purpose, any UML CASE tool can be used that has XMI export facilities for MOF.
1. The source, target, and reference metamodels are compiled into an internal Prolog representation. The compilation process is driven by a common metametamodel against which user metamodels are validated. 2. Secondly, the transformation program is generated in the form of a Prolog code. This automated program generation method itself, which is the semantic core of the VIATRA framework, was also designed and implemented by consecutive model transformations in a reflective way. More details on automated program generation can be found in [19].
2. We export our metamodels in an XMI format that conforms to the MOF Model (the metamodel of the MOF language) [13]. These files serve as primary inputs for VIATRA. 3. For the next step, the transformation rules and the control structures are created by a special UML profile (in the form of a Rational Rose Add-In) tailored to graph
Automated transformations Finally, the previously generated transformation programs can be applied to the trans6
combining internal data structures and thread of control seem like natural models for concurrent components. Designing concurrent OO systems usually necessitates a thorough verification of concurrency control (synchronization and communication). To do this, the behavioral UML models of the system have to be transformed to mathematical models amenable to formal verification. SPIN is a widely used tool for analyzing the logical consistency of distributed systems [7]. We selected this target tool since its modeling language called Promela (Process Meta Language) allows for the dynamic creation of concurrent processes (threads of control), and communication can be directly modeled using both synchronous and asynchronous (i.e., buffered) channels. Requirements can be expressed in the form of assertions (invariants), a never-claim or linear temporal logic formulas. VIATRA is used to help in transforming the UML statechart models of concurrent objects to Promela. The extended UML model is transformed by about 40 VIATRA rules to a semantically equivalent formal model called Extended Hierarchical Automata (EHA). The EHA format has the advantage that the interlevel and compound transitions are resolved and the state refinement is expressed in a strict tree structure. Then the XML representation of the EHA is post-processed by a Java application to generate the corresponding Promela code. The results of the verification (counter-examples) are available in the SPIN graphical environment both in the form of message sequence charts and traces to be back–annotated to the UML CASE environment. In the following we present the steps of the model transformation in more detail. In a distributed system, objects communicate through method calls and asynchronous events. The UML semantics introduces the notion of event queue and event dispatcher; however, it does not describe how to specify them in the model. Accordingly, we defined a set of modeling conventions.
formation of various source models. 1. As for the typical case, the UML model created by a software engineer will serve as the input of a transformation thus it is exported into an XMI format. 2. The source model is compiled into an internal Prolog representation. Meanwhile, the syntactic correctness of the source (UML) model is validated against the source (UML) metamodel. 3. The source model is transformed by the transformation program, and two models are generated as the output: the reference and the target model (conformance with their metamodels are checked for both models at this point). 4. Finally, the output models are exported in an XMI format (corresponding to their own XMI dialect). The concrete input language of a specific analysis tool can typically be generated from this XMI format by either (i) simple Prolog programs (ii) XSLT transformations, or (iii) Java programs. By this intermediate XMI format, VIATRA becomes independent from any specific tool of a formal mathematical paradigm. Verification of transformations As an ongoing activity, we also aim at the formal verification of model transformations in order to provide a higher level of quality and faithfulness for such transformations. Without verifying the transformations themselves the consistency between UML and mathematical models cannot be assured: the designer does not know whether a flaw detected by the formal analysis (i) has true origins in the system model, or (ii) it was erroneously introduced by an incorrect transformation. 1. Syntactic correctness and completeness can be verified by planner algorithms [20]. In this case, a successful verification step proves, for instance, that the output target model of the transformation is a well-formed model of the target language.
2. Semantic correctness of transformations is being verified by projecting model transformation rules into the SAL intermediate language [1], which provides access to an automated combination of symbolic analysis tools (like model checkers and theorem provers). In case of semantic correctness, we show that certain dynamic properties (e.g., deadlock freedom, safety) are preserved by the model transformation.
Event queues are modeled by instances of stereotyped UML classes with attributes defining the type and size of the queue. This solution allows simple representation in the metamodel.
Objects are assigned to event queues by grouping them in stereotyped packages. It allows a flexible (hierarchical) structuring of the queues. Targets of send actions can be specified either by event queues or by named objects.
5. Formal verification of distributed objectoriented systems
5.1. Generating the EHA format
The object-oriented (OO) paradigm is becoming more and more popular in distributed system design. Objects
In [10] a transformation from a subset of UML statecharts (covering all aspects of concurrent behavior) to 7
Promela was presented. The transformation was formalized and proved to be correct for single statecharts. This approach was extended to cover multiple statecharts (i.e. objects) communicating through event queues. The objects specified in the UML model are represented by a set of separate EHAs. The structure of an EHA corresponding to an object is determined by the statechart of the parent class of that object. The complete instantiation is handled by VIATRA rules. Each EHA is assigned to an event queue belonging to the package of the corresponding object. The package relations are exploited by another rule. A single EHA is composed of simple sequential automata related by a state refinement function. The transformation phase from a statechart to an EHA is easily described by a set of VIATRA rules: (i) there is a direct correspondence between the states of the statechart and the EHA; (ii) each UML transition is mapped to a unique transition in the automaton that contains all the source and target states (the original source and target states are included in the label of the transition in case of compound and interlevel transitions); (iii) labels of transitions are composed of the original source and target states, the trigger event, the guard and the action of the transition; (iv) targets of send actions are linked to event queues. The events and the event queues are also extracted from the UML model and stored in XML format besides the elements of the EHA.
The extensions implemented in the transformation enable the verification of reconfigurable distributed objectoriented systems.
6. System safety Most of the accidents caused by computer programs occur due to flaws in the specification; mainly because of its incompleteness, inconsistency, or non–determinism. For this reason, Leveson has specified 47 criteria for the specification of safety-critical software [11]. When using UML as the specification language for such software, the majority of these criteria should be verified on statecharts. However, the standard metamodel of statecharts is not directly appropriate for an automated analysis due to its complex state hierarchy (composite and concurrent states), and conditional and concurrent branches. In order to automate the verification process, we introduced a reduced form of statecharts which is (i) a flat model without inherited transitions, (ii) it has only basic elements like states, events, transitions and actions, and, (iii) it lacks chained constructions and guard conditions [14]. Most of the statically verifiable criteria can be checked directly on this representation (or, on intermediate representations of the transformation process), moreover, the applied method also supports linear temporal logic code generation for the rest in order to provide access to model checking tools. We imposed the following restrictions on the constructs allowed in a user statechart model: (i) the guard conditions must be Boolean expression of binary terms; (ii) the use of history states and deferred events are not allowed; (iii) jumping out of a concurrent machine (by using interlevel transitions) is not safe thus forbidden. The transformation process to the reduced form of statecharts can be divided into two major steps: (i) the transformation of model elements, and (ii) the evaluation of guard conditions. The first step is responsible for the following:
5.2. Generating the Promela code In the case of a single statechart, the Promela code implements the step relation as specified in [10]. Practically, a Promela process is required to expand the tree-like structure of an EHA. This basic approach was extended as follows:
Each EHA is represented by a separate Promela process.
Each event queue is modeled by a data structure and a Promela process that implements the event dispatcher forwarding the events to the target processes.
1. preprocessing: filtering out irrelevant information from the original statechart model, and resolving the links to subdiagrams.
The ordering of events in FIFO queues is sensitive to the ordering of the actions that generate them. The non-deterministic execution order of the actions is modeled by concurrent sub-processes.
2. flattening the statechart hierarchy by eliminating composite states;
Limited number of object creations is modeled by starting new Promela processes.
3. simplifying the statechart by converting (i) conditional, join and fork transitions into normal ones (ii) completion transitions into normal transitions with trigger events, and (iii) internal transitions into selfloops.
System reconfiguration (i.e. changing the deployment of an object by a distinguished action of another object) is modeled by dynamically linking the moved object to another event dispatcher. 8
The second part of the transformation is the evaluation of the guards. This is a special expression evaluator program written in C++, which is solved by an external program. The transformation process has been implemented using the VIATRA system. All rules have been designed in a graphical form using Rational Rose. The first part of the transformation needs approximately 60 rules. However, the structure of these rules is very simple, thus the transformation process is very fast. The main safety criteria (as being static well–formedness constraints) are also stated in the form of graph patterns, and requires to introduce some additional 40 rules having a criterion on the left-hand side and an error message object on the right. The user is informed about the results of analysis via an XML file generated by VIATRA.
when the train has left the station, and both Station A and B about the arrival of the train. Both example systems are dependability critical, both of them necessitate the analysis of their models for correctness, completeness and consistency, and both of them extend the analysis goals with application dependent safety requirements.
8. Conclusions and future work The first experiences with VIATRA, which includes more than 10 complex model transformations (manipulating source models having more than 50,000 graph objects), are promising. The generation time of a new transformation program lies in the range of several minutes on a usual desktop PC. The generation of the mathematical model itself takes typically less than a few of tens of seconds for the models of small and medium size evaluated so far. The combination of visual design of transformation rules as definition language and graph transformation based generation of transformers seem to be an effective way to conquer the problems related to the implementation of complex mathematical software. This approach still has a further potential for dependability evaluation. Ongoing work aims at the graph transformation based implementation of fault modeling by associating fault injection rules to the elements at the metamodel level. Similarly, hierarchical abstraction implemented by a series of transformations is a favorite candidate to cope with complexity problems usually evolving during formal verification. 2
7. Pilot examples We used the UML models of two industrial dependability-critical systems in order to validate our approach. This way we are able to prove the modeling, transformation and analysis of real industrial systems by the help of our framework. One pilot design is a safety-critical part of an artifical kidney system consisting of components like pumps for maintaining the (external) circulation, steady blood pressure and flow rate measurement for control of the therapy, safety air detectors to prevent air-bubbles from getting into the circulation of the patient, etc. Timing checks have to be performed for the functioning in the absence of external power in order to guarantee the completion of an already started therapy by relying only on an uninterruptable power supply. The second pilot is the core part of a railway supervisory traffic control and optimization system. This inter-station message exchange module provides a real-time global view of the traffic for central control and optimization, but has no direct influence on the safety of the railway traffic. However, it delivers information for operator decisions to be executed in the subordinate railway interlocking systems. The railway traffic necessitates the availability of the inter-station communication system, and the correctness and consistency of the provided view is critical for the safety of the traffic. An extract from a UML Sequence diagram of the system is depicted in Fig. 7. According to the typical scenario, Station A first generates a permission request for a train aiming to pass towards Station B. The generated permission object notifies Station B by a message, and if the traffic conditions are safe than Station B accepts the permission request by sending a grant message. For safety reasons, Station A sends an acknowledgment message about the granted permission for Station B. Later, the vehicle tracer subsystem will notify Station A
References [1] S. Bensalem, V. Ganesh, Y. Lakhnech, C. Munoz, S. Owre, H. Rueß, J. Rushby, V. Rusu, H. Sa¨ıdi, N. Shankar, E. Singerman, and A. Tiwari. An overview of SAL. In C. M. Holloway, editor, LFM 2000: Fifth NASA Langley Formal Methods Workshop, pages 187–196, 2000. [2] T. Bienmueller, W. Damm, and H. Wittke. The STATEMATE verification environment – making it real. In Proc. 12th Int. Conf. on Comp. Aided Verification, volume 1855 of LNCS, pages 561–567. Springer, 2000. [3] A. Bondavalli, M. D. Cin, D. Latella, I. Majzik, A. Pataricza, and G. Savoia. Dependability analysis in the early phases of UML based system design. International Journal of Computer Systems - Science & Engineering, 16(5):265– 275, 2001. [4] T. Clark, A. Evans, and S. Kent. The Metamodelling Language Calculus: Foundation semantics for UML. In H. Hussmann, editor, Proc. Fundamental Approaches to 2 Footnote to the reviewers: previous publications of the authors are available at the URL: http://www.inf.mit.bme.hu
9
"!#%$'&($*) +,
-.0/(1 23 45463 798 E9F0GIHJF=K%L=F9M $ONP
HYF9MM &9R F N S F0T F R G & HVU S G &) ,DP E=FGWHYXZG &,$ ]\9^(N9P
:!;#/(?;3 @6A /6B%1 C@6/D1
HQF9MM &=R F N S FT F R G & HVU S G & ) ,DP E9FGWHYXZG &0,D$ F9[ N9P
HQF9MM &=R F N S F T F R G & VH U S G & ) ,DP M $*& G $ S G &) , N S G & ) ,DP
HYF9MM &9R F N S F0T F R G & HVU S G &) ,DP
G'F0E + G $ GWG ) _D& T NP
$ G & ) , GWG ) _D& T N S G & ) ,DP
Figure 7. Granting permission for a train to pass
[5]
[6] [7] [8]
[9] [10]
[11] [12]
[13]
Software Engineering, FASE 2001 Genova, Italy, volume 2029 of LNCS, pages 17–31. Springer, 2001. A. Corradini, U. Montanari, F. Rossi, H. Ehrig, R. Heckel, and M. L¨owe. In [16], chapter Algebraic Approaches to Graph Transformation — Part I: Basic Concepts and Double Pushout Approach, pages 163–245. World Scientific, 1997. S. Flake and W. Mueller. An OCL extension for real-time constraints. In Advances in Object Modelling with the OCL. G. Holzmann. The model checker SPIN. IEEE Transactions on Software Engineering, 23(5):279–295, 1997. H. V. Juan de Lara. Atom3: A tool for multi-formalism and meta-modelling. In R.-D. Kutsche and H. Weber, editors, 5th International Conference, FASE 2002: Fundamental Approaches to Software Engineering, Grenoble, France, April 8-12, 2002, Proceedings, page 174. Springer. C. Kobryn. UML 2001: A standardization Odyssey. Communications of the ACM, 42(10), 1999. D. Latella, I. Majzik, and M. Massink. Automatic verification of UML statechart diagrams using the SPIN modelchecker. Formal Aspects of Computing, 11(6):637–664, 1999. N. G. Leveson. SAFEWARE: System Safety and Computers. Addison Wesley, 1995. D. Milicev. Automatic model transformations using extended UML object diagrams in modeling environments. IEEE Transactions of Software Engineering, 28(4):413– 431, April 2002. Object Management Group. Meta Object Facility Version 1.3, September 1999.
[14] Z. Pap, I. Majzik, and A. Pataricza. Checking general safety criteria on UML statecharts. In U. Voges, editor, Computer Safety, Reliability and Security (Proc. 20th Int. Conf., SAFECOMP-2001), volume 2187 of LNCS, pages 46–55. Springer, 2001. [15] M. Peltier, J. B´ezivina, and G. Guillaume. MTRANS: A general framework, based on XSLT, for model transformations. In J. Whittle et al., editors, Workshop on Transformations in UML, pages 93–97, 2001. [16] G. Rozenberg, editor. Handbook of Graph Grammars and Computing by Graph Transformations, volume 1: Foundations. World Scientific, 1997. [17] J. Rumbaugh, I. Jacobson, and G. Booch. The Unified Modeling Language Reference Manual. Addison-Wesley, 1999. [18] J. Sprinkle and G. Karsai. Defining a basis for metamodel driven model migration. In Proceedings of 9th Annual IEEE Internation Conference and Workshop on the Engineering of Computer-Based Systems, Lund, Sweden, April 2002. [19] D. Varr´o. Automatic program generation for and by model transformation systems. In H.-J. Kreowski, editor, Proc. AGT 2002: Workshop on Applied Graph Transformation, 2002. [20] D. Varr´o, G. Varr´o, and A. Pataricza. Designing the automatic transformation of visual languages. Science of Computer Programming. In print.
10
