L V M DIAGRAM UML M T S - Politecnico di Milano · 1.2 Logic based-veriﬁcation of Multi-diagram...

POLITECNICO DI MILANODIPARTIMENTO DI ELETTRONICA E INFORMAZIONE

DOTTORATO DI RICERCA IN INGEGNERIA DELL’INFORMAZIONE

LOGIC-BASED VERIFICATION OF MULTI-DIAGRAM

UML MODELS FOR TIMED SYSTEMS

Doctoral Dissertation of:Alfredo Motta

Supervisor:Prof. Luciano Baresi

Tutor:Prof. Gianpaolo Cugola

The Chair of the Doctoral Program:Prof. Carlo Fiorini

2012 – XXV

Abstract

THE Unified Modeling Language (UML) has gone from a relatively basic descrip-tive tool (i.e., a tool that serves to document software systems) to a sophisti-cated prescriptive one, that is, a tool that can be used to specify, analyze and

implement complex software systems. Despite some good results in this field somefundamental problems hamper the actual adoption of UML models for the analysis ofthe systems in a real production environment.

First, a unified and coherent semantics of UML must be developed. In the last tenyears researchers have been trying to ascribe UML with many different semantics, butall these attempts have been partial. While there seems to be a general consensus on thesemantics of some individual diagrams, the composite semantics of the different viewsis still an open problem. The wide spectrum of the notation and the heterogeneity andoverlapping of the different modeling elements have played against its complete for-malization; as a matter of fact most of the existing approaches only focus on a limitednumber of diagrams (oftentimes they only consider a single type) and neglect the inter-dependencies with the other views of the system. However multiple views mean betterquality since different UML diagrams emphasize different aspects of the system.

Second, to spread the use of UML model verification at large scale the inherentcomplexity of formal methods in terms of usability must be decreased. For examplein the classical approach to formal analysis the user is required to manually constructthe formal model of the system in the language that is accepted by the verification tool.The construction of such model typically requires good knowledge of both the applica-tion domain and of the verification technology. In turn this activity requires masteringtechniques like abstraction and refinement, model checking, or theorem proving thatrequire a dedicated background. To avoid the manual construction of the formal modeldifferent tools have been developed to transform the UML models to a variety of formalnotations, but the vast majority of them neglet the difficulty of hiding the underlyingformal notations and tools to the UML user. Without a dedicated expertise in this fieldthe user is not able neither to enact the verification phase, or to understand the veri-fication results. Oftentimes a formal verification expert is required, making the UMLformal verification a niche activity.

I

This thesis presents a significant step towards solving these problems by means ofan advanced verification framework made of the following elements:

• A significant and consistent subset of UML, called MADES UML, where timed-related properties can be modeled carefully. MADES UML supports differentbehavioral views connected by means of a shared set of events.

• A formal semantics based on metric temporal logic which offers the flexibility andscalability we need to formalize a wide and rich notation like MADES UML. Theformal semantics is used to feed a bounded model/satisfiability checker to allowusers to verify their systems, even from the initial phases of the design.

• An advanced prototype verification tool called Corretto. Using CorrettoUML engineers can exploit both a well-known modeling notation and advancedverification capabilities seamlessly. Properties are expressed using a high-levelnotation, and verification results produced by the underlying verification tool arelinked back to the corresponding UML elements in the model.

II

Contents

1 Introduction 11.1 Towards the verification of UML models at large scale . . . . . . . . . 21.2 Logic based-verification of Multi-diagram UML models . . . . . . . . 51.3 Structure of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Related Work 92.1 Analyze the UML Behavior . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.1 Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . 122.1.2 Activity Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.3 State Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1.4 Multiple Views . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Contribution of this thesis . . . . . . . . . . . . . . . . . . . . . . . . 15

3 MADES UML 193.1 Meta-model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2 Class Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3 State Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.4 Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.5 Interaction Overview Diagrams . . . . . . . . . . . . . . . . . . . . . 283.6 Shared Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.7 Events Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.8 Time Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.9 Time Property Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . 32

4 Metric Temporal Logic Semantics 354.1 TRIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1.1 An example: a lamp with a timer . . . . . . . . . . . . . . . . . 384.2 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2.1 Predicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.2.2 Axioms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3 State Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

III

Contents

4.3.1 Predicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3.2 Axioms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.4 Interation Overview Diagrams . . . . . . . . . . . . . . . . . . . . . . 434.4.1 Predicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.4.2 Axioms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.5 Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.5.1 Predicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.5.2 Axioms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.6 Time Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.7 Shared Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.7.1 Operation Invocations . . . . . . . . . . . . . . . . . . . . . . . 494.7.2 Sequence Diagrams Events . . . . . . . . . . . . . . . . . . . . 514.7.3 Clocks and Signals . . . . . . . . . . . . . . . . . . . . . . . . 53

4.8 Extending the Semantics . . . . . . . . . . . . . . . . . . . . . . . . . 534.9 Analyze partial models . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5 Corretto: The MADES UML Verification Tool 595.1 Papyrus Modeling Tool . . . . . . . . . . . . . . . . . . . . . . . . . . 625.2 Zot Verification Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.2.1 The lamp example in Zot . . . . . . . . . . . . . . . . . . . . . 665.3 UML2ZOT Trasformation Tool . . . . . . . . . . . . . . . . . . . . . 685.4 Traceability Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6 Experimental Evaluation 776.1 Testing the Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.1.1 Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . 786.1.2 State Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . 816.1.3 Interaction Overview Diagram . . . . . . . . . . . . . . . . . . 83

6.2 CCAS Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856.2.1 MADES UML Model . . . . . . . . . . . . . . . . . . . . . . . 856.2.2 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896.2.3 Property and Results . . . . . . . . . . . . . . . . . . . . . . . . 94

6.3 TXT Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976.3.1 MADES UML Model . . . . . . . . . . . . . . . . . . . . . . . 986.3.2 Property and Results . . . . . . . . . . . . . . . . . . . . . . . . 99

6.4 CASSIDIAN Case Study . . . . . . . . . . . . . . . . . . . . . . . . . 1056.4.1 MADES UML Model . . . . . . . . . . . . . . . . . . . . . . . 1056.4.2 Property and Results . . . . . . . . . . . . . . . . . . . . . . . . 106

6.5 Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7 Conclusions 1137.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Bibliography 119

IV

List of Figures

1.1 An overview of the MADES Verification Framework. . . . . . . . . . 7

3.1 The structure of valid MADES UML model. . . . . . . . . . . . . . . 223.2 Data types in MADES UML.MADES models that need to be verified

can include variables of only one infinite type (but as many finite do-mains as desired). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3 Clocks in MADES UML. . . . . . . . . . . . . . . . . . . . . . . . . . 243.4 State diagram transitions in MADES UML. . . . . . . . . . . . . . . . 253.5 The Sequence Diagram meta-model of MADES UML. . . . . . . . . . 263.6 The SD, named mades_sd, contains a variable assignment specified us-

ing a self recursive message and a SD parameter, named sd_par, whichremains constant during the execution of the diagram. Finally, a timeconstraint is added to say that the diagram will lasts less then 5 time units. 27

3.7 MADES UML Meta-model of the Interaction Oveview Diagrams . . . 283.8 Interaction Overview Diagram with one Interruptible Region and one

accept event action. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.9 The MADES UML set of shared events. . . . . . . . . . . . . . . . . . 303.10 Example of a State Diagram using a time constraint for the guard. The

transition occurs only if the object owning the diagram remains in State0for less then 10 time istants. . . . . . . . . . . . . . . . . . . . . . . . 32

3.11 UML profile of the Time Property Diagrams. . . . . . . . . . . . . . . 333.12 Time Property Diagram example: If we are in State0 at the current time

instant, then we cannot be in State1 at the same time instant. . . . . . . 343.13 Time Property Diagram example: If the opB operation holds now, then

we will stay in State0 for the next 10 time instants. . . . . . . . . . . . 34

4.1 A history for the example of the timed lamp . . . . . . . . . . . . . . . 384.2 The transition from State0 to State1 of Figure 4.3(b) enables the opA

found message of Figure 4.2(a). The opB message of Figure 4.2(a) trig-gers the transition from State1 to State0 of 4.3(b) . . . . . . . . . . . . 50

V

List of Figures

4.3 An example of communication between one IOD and one StD usingSD’s shared events. The StD and the IOD starts concurrently. After 5time units the StD stops the execution of the sd_A SD. . . . . . . . . . 52

4.4 Two equivalent models defining a periodic Sequence Diagram. The StDhas a self-transition triggered by a clock event whose action is the startevent of the SD. The IOD is using an accept signal action - assigned toa clock tick event - followed by the SD. . . . . . . . . . . . . . . . . . 53

4.5 Read relationship between the different views. For each arrow, the dia-gram at the tail reads the predicates shared by the diagram at the head.The name of the shared predicates is shown on the arrow itself. . . . . . 55

4.6 Write relationship between the different views. For each arrow, the dia-gram at the tail writes the predicates shared by the diagram at the head.The name of the shared predicates is shown on the arrow itself. . . . . . 55

4.7 The CD of the model for the partial verification example. . . . . . . . . 574.8 The StD of the model for the partial verification example. . . . . . . . . 574.9 The TPD of the model for the partial verification example. . . . . . . . 584.10 The SD of the model for the partial verification example. . . . . . . . . 58

5.1 The Corretto verification workflow and tools. Figure 5.1(a) shows theabstract workflow, while Figure 5.1(b) shows the concrete tools we use. 61

5.2 A screenshot of the Papyrus modeling tool. . . . . . . . . . . . . . . . 635.3 Overall architecture of Zot . . . . . . . . . . . . . . . . . . . . . . . . 655.4 Overall architecture of UML2ZOT . . . . . . . . . . . . . . . . . . . . 695.5 The MADES UML package . . . . . . . . . . . . . . . . . . . . . . . 705.6 Subset of the UML model of the Car Collision Avoidance System. On

the left the state diagram of the BrakingSystem class is shown. On theright the sequence diagram fetching the distance from the facing car isshown; the ownedParameter field containing the distance variable mod-els the fetched distance. . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.7 Example property for the traceability tool. . . . . . . . . . . . . . . . . 735.8 Traceability navigation tool. The user inspects the counterexample at

time 0; by clicking on the predicate he discovers that the value of thedistance variable is equal to zero. . . . . . . . . . . . . . . . . . . . . 74

5.9 Traceability navigation tool. The user inspects the counterexample attime 45; by clicking on the predicate he discovers that the braking sys-tem is inside the idle state. . . . . . . . . . . . . . . . . . . . . . . . . 75

6.1 Testing the SD semantics: The CD of the model under test. . . . . . . . 796.2 Testing the SD semantics: The SD of the model under test. . . . . . . . 796.3 Testing the SD semantics: The TPD of the property to be tested: “ if

op2() holds now and in the next time instant we are not inside the SD,then we cannot have the op1() message”. . . . . . . . . . . . . . . . . 80

6.4 Testing the StD semantics: The CD of the model under test. . . . . . . 826.5 Testing the StD semantics: The StD of Class1. . . . . . . . . . . . . . 826.6 Testing the StD semantics: The StD of Class2. . . . . . . . . . . . . . 826.7 Testing the StD semantics: The TPD of the property to be proved. . . . 836.8 Testing the IOD semantics: The CD of the model under test. . . . . . . 83

VI

List of Figures

6.9 Testing the IOD semantics: The IOD of the model. . . . . . . . . . . . 846.10 Testing the IOD semantics: The TPD of the property to be proved. . . . 846.11 CCAS Class Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . 866.12 CCAS Object Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 866.13 CCAS Interaction Overview Diagram . . . . . . . . . . . . . . . . . . 866.14 CCAS Send Sensor Distance Sequence Diagram . . . . . . . . . . . . 876.15 CCAS Send Sensor Distance Parameter . . . . . . . . . . . . . . . . . 886.16 CCAS Send Sensor Distance Timed Event . . . . . . . . . . . . . . . . 886.17 CCAS Send Brake Command Sequence Diagram . . . . . . . . . . . . 886.18 CCAS State Diagram of Controller . . . . . . . . . . . . . . . . . . . . 896.19 CCAS State Diagram of the Braking System . . . . . . . . . . . . . . . 896.20 The TPD of the property to be proved for the CCAS . . . . . . . . . . 956.21 The interface to select the elements in the property . . . . . . . . . . . 956.22 The traceability interface. The user inspect the trace on the bottom right

and check the corresponding uml element in the bottom left of the screen. 966.23 Radar UI, Antenna and Processor . . . . . . . . . . . . . . . . . . . . 976.24 The Radar System Class Diagram. . . . . . . . . . . . . . . . . . . . . 996.25 TXT Case Study: Navigation to Environment SD . . . . . . . . . . . . 1006.26 TXT Case Study: Main MMI to Environment SD . . . . . . . . . . . . 1016.27 TXT Case Study: Radar to Environment SD . . . . . . . . . . . . . . . 1026.28 TXT Case Study: Panel Data to Environment SD . . . . . . . . . . . . 1026.29 TXT Case Study: Weather to Environment SD . . . . . . . . . . . . . 1036.30 TXT Case Study: The Main MMI StD . . . . . . . . . . . . . . . . . . 1036.31 TXT Case Study: The Navigation Data StD . . . . . . . . . . . . . . . 1036.32 TXT Case Study: The TPD of the property which has been verified

against the model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046.33 CASSIDIAN Case Study: The CD of the Radar Processor System. . . . 1076.34 CASSIDIAN Case Study: The Signal Packaging SD. . . . . . . . . . . 1076.35 CASSIDIAN Case Study: The Sweep Processing SD. . . . . . . . . . . 1086.36 CASSIDIAN Case Study: The Doppler Processing SD. . . . . . . . . . 1086.37 CASSIDIAN Case Study: The Data Thresholding SD. . . . . . . . . . 1086.38 CASSIDIAN Case Study: The PostProcessing SD. . . . . . . . . . . . 1096.39 CASSIDIAN Case Study: The IOD shows the transformation chain

done by the Radar Processor each time a new data is available. . . . . . 1096.40 CASSIDIAN Case Study: The Time Property Diagram saying that if

the AntennaDataInterrupt occurs, then within 100 time instants the put-Data_out_Message occurs. . . . . . . . . . . . . . . . . . . . . . . . . 110

VII

List of Tables

2.1 The different kind of UML semantics . . . . . . . . . . . . . . . . . . 17

4.1 TRIO derived temporal operators . . . . . . . . . . . . . . . . . . . . . 374.2 TRIO predicates associated to the Class Diagram . . . . . . . . . . . . 404.3 TRIO predicates associated to the State Diagram . . . . . . . . . . . . 414.4 TRIO predicates associated to the IOD . . . . . . . . . . . . . . . . . . 444.5 TRIO predicates associated to the Sequence Diagram . . . . . . . . . . 46

6.1 The performance of Zot with the different models analyzed. The time-boud (i.e. the search horizon for Zot) is equal to 100. . . . . . . . . . . 112

IX

CHAPTER1Introduction

Modern software systems are bigger and bigger, and software is the central innovatingfactor of many high-tech products of our daily life. Despite significant advances inprogramming languages and supporting integrated development environments (IDEs),developing these complex software systems using current code-centric technologies isstill problematic. A significant factor behind the difficulty of developing complex soft-ware is the wide conceptual gap between the problem and the implementation domainsof discourse. In recent years model-driven engineering (MDE) proposes a software de-velopment process that starting from product requirements aims to capture designs instandardized high-level notations. Software models are used to describe complex sys-tems at multiple levels of abstraction and from a variety of perspectives, and throughautomated support for transforming and analyzing models. In the MDE vision of soft-ware development, models are the primary artifacts of development and developers relyon computer-based technologies to transform models to running systems. To supportthis refinement chain a number of model transformation techniques has been studiedduring the years [54]. A model transformation usually specifies which models are ac-ceptable as input, and if appropriate what models it may produce as output.

The Unified Modeling Language (UML [60]) is a general-purpose platform inde-pendent modelling language, created and managed by the Object Management Group(OMG). The UML offers a heterogeneous set of diagrams to describe the differentviews of a software system during all the stages of the MDE software developmentprocess. The goal of the different UML diagrams is to provide a visual representationfor the UML model, which is the resulting artifact of the modeling process. To pre-cisely define the structure and well- formedness rules of the UML language the meta-modeling technique is used; i.e. the activity of bulding a model that describes itself, inthis case UML. The Meta-Object Facility (MOF) standard is the OMG metamodeling

1

Chapter 1. Introduction

architecture to write meta-models. It provides a metadata management framework, anda set of metadata services to enable the development and interoperability of model andmetadata driven systems.

As Model Driven Development (MDD) became more widespread, model verifica-tion has come at the forefront of research in this arena. Model verification can takemany different forms, including formal analyses such as performance analysis basedon queuing theory or safety-and-liveness property checking. Starting from the model-ing artifacts it is thus possible to generate different formal models (either manually, orautomatically). Formal models are then verified with advanced formal verification tool.Verification results often reveals unexpected errors in the models which, if left hidden,may lead to a tremendous cost in the late stage of the development. For this reason theformal verification of UML models has been a hot research topic in the last 10 years, butdespite some good results in this field some fundamental problems hamper the actualadoption of UML models for the analysis of the systems. To spread the UML formalverification technology at large scale appropriate technology and tools should be avail-able to allow to any average engineer to use any UML model at the earliest stages ofthe design, verify complex properties and follow the results of this verification. Rightnow this is not the case; the verification of UML models is still a niche activity.

In the following Section 1.1 highlights the problems that must be overcome to spreadthe UML formal verification technology at large scale. Section 1.2 presents the solutionaddressed in this thesis by means of a logic-based approach which overcomes some ofthe current limitations. Finally Section 1.3 presents the structure of the thesis.

1.1 Towards the verification of UML models at large scale

UML is a well known and widely used design notation that relies on models to improvethe quality and maintainability of software systems. Since its adoption as a standard in1997, UML has been taught and used more than any other modelling language. TheUML has rapidly gained popularity in industry [72], as it facilitated the communicationbetween most diverse stakeholders about a system at different phases of development,on one hand, and, on the other, several points of view on that system, including itscontext. During these years UML has gone from a relatively basic descriptive tool (i.e.,a tool that serves to document software systems) to a sophisticated prescriptive one,that is, a tool that can be used to specify, analyze and implement complex softwaresystems. Among the most interesting uses of UML the analysis of UML models bymeans of formal verification techniques is one of the most promising. However de-spite some good results, there are still fundamental problems which hamper its actualadoption. These limitations regards both the UML language and the formal verificationtechniques which have been proposed for its analysis.

The most fundamental criticisms made to UML by the models-based engineeringcommunity are divided in two groups. The first one regards its lack of formal se-mantics [30]. This is evident already from the organization of the UML specificationdocument. The sections describing the semantics of the different views are not gatheredin one place but are, instead, fragmented and scattered throughout the text. Accordingto the definition given by D. Harel in [40], a language consists of a syntactic notation(syntax), which is a possibly infinite set of legal elements, together with the meaning

2

1.1. Towards the verification of UML models at large scale

of those elements, which is expressed by relating the syntax to a semantic domain.Thus, any language definition must consist of the syntax semantic domain and the se-mantic mapping from the syntactic elements to the semantic domain. In its currentform, the Object Management Group’s documents do not offer a rigorous definition ofUML’s true semantics, not even of the semantic domain. Rather, they concentrate onthe abstract syntax, intermixed with informal natural-language discussions of what thesemantics should be. In the simplest case this natural language descriptions leave thedoor open to multiple and potentially contradictory interpretations of the same model.The second fundamental criticism to UML regards its dimension [31]. The language iswell know for being simply too big with many parts that overlap each other. This is adirect consequence of its general purpose nature which is meant to describe practicallyany software system at different level of details. For a typical end user of UML thismay not be a problem; knowing the entire elements of the language is not mandatoryto use a subset of UML properly. However to make formal verification feasible a mini-mal kernel of the language must be identified so that the research community can buildon top of it. To this end, UML 2.0 has been carefully modularized into a set of sub-languages many of which are independent of each other and the recent introduction offUML [61] is a good step towards this direction.

Given these premises a lot of research effort has been done to ascribe UML withmany different semantics, but all these attempts have been partial. The wide spectrumof the notation and the heterogeneity and overlapping of the different modeling ele-ments have played against its complete formalization. The different UML behavioralviews (Activity Diagrams, Sequence Diagrams, State Machines, etc. . . ) have beentranslated into several semantics domains where every domain is the most suitable torepresent the diagram of choice (i.e. Petri Nets for Activity Diagrams, LTS for StateMachines). This - partial - formalization effort lead to a number of formal semanticswhich neglect the interdependencies with the other views of the system, making theverification of heterogeneous UML models unfeasible. However supporting such setof heterogeneous behavioral views is definitely desirable; multiple views mean betterquality since different UML diagrams emphasize different aspects of the system. Forexample sequence diagrams are more suitable to describe the interactions among theobjects, while state machines are more suitable to represent their states. Supportingmultiple views is also needed to meet the requirements of the industry were UML mod-els are used for multiple purposes including but not limited to structuring the softwarelifecycle, documentation, or code generation. Supporting such large number of differ-ent views provides the means to smoothly integrate formal verification into the softwaredevelopment process ideally without affecting how the organization handles its mod-els. Defining the semantic domain of the full UML, which contains many diagrammaticsublanguages, is far from a simple matter; a satisfactory definition must involve com-binations of myriad elements, such as messages, states, events, data values, booleanvalues, time elements, and many combinations thereof. Whereas language designershave provided satisfactory semantics for several widely known modeling languages, in-cluding one or two of UML’s sub-languages, full UML, with its multitude of languagesand its complex set of interconnections between them, still suffers severely from thisdeficiency [10].

The other problem which hampers the spread of the UML model verification at large

3


scale is the difficulty for the UML system engineers to understand the principles offormal methods together with their tools. For example in the classical formal analysisapproach the user is required to manually construct the formal model of the system inthe language that is accepted by the verification tool. The construction of such modeltypically requires good knowledge of both the application domain and the verificationtechnology. In turn this activity requires mastering techniques like abstraction andrefinement, model checking, or theorem proving that require a dedicated background.Even being an expert of formal verification languages and tools, building such modelscan be extremely difficult and error prone, leading to an additional source of errors inthe process. In many domains the users do not want to pay the cost of managing suchcomplexity, but still formal verification is definitely required. As a result in the last tenyears researchers started building automatic translation tools from high-level modelinglanguages like UML to formal ones. Despite the advantages of having an automatictranslation process a number of problems still remain unresolved. Oftentimes the usermust be an expert of the generated formal model to enact the verification phase and evenif he is able to use the underlying verification tools the results may be extremely difficultto read and, more than this, it could be practically impossible to link them back to thesource model. If we consider the counterexamples produced by the model checkingtools these may take several forms; a valid marking in a Petri Net, an execution pathin a label transition system, and so on and so forth. To understand the counterexamplethe user needs to know how the entities represented in the formal model have beengenerated from the UML source model, which is often not the case.

Last, but not least, state-of-the-art verification technologies still deal with the typicalstate explosion problem when working with large models. Domain specific optimiza-tions, verification of partial models, better support for abstraction and refinement arejust some of the possible solutions to tacke this issue, but still no definitive answer hasbeen found.

To summarize in order to spread the UML formal verification at large scale the fol-lowing issues must be overcome. First, a unified semantics of the different behavioralviews must be developed. Having a unified semantics enables the possibility to verifymodels made of multiple views where both consistency checks and user defined prop-erties can be verified. Second, the UML semantics must be designed with extensibilityin mind. New diagrams may be added/removed/modified from the standard, domainspecific UML profiles will be defined together with user defined ones. The seman-tics must be flexible enough to cope with this variability by clearly defining extensionpoints without affecting the already existing formalization. Third, the verification toolsmust be able to hide the underlying formal notations to the user as much as possible.The user’s consciousness of the UML semantics can be gathered by appropriate simu-lation tools, while the analysis of the results produced by the verification tools must beunderstandable, even without being an expert of the underlying verification technology.This can be done using some high-level formalism to represent the results, preferablyUML. Finally, techniques to fight the state explosion problem must be found to makeformal verification feasible also for large sized models.

4

1.2. Logic based-verification of Multi-diagram UML models

1.2 Logic based-verification of Multi-diagram UML models

The work presented in this thesis proposes a solution to the aforementioned problemsto verify the quality of software models at the early stage of the design. My approachis designed specifically for timed system, i.e. systems whose behaviour depends uponcombinations of logical and temporal constraints; namely, constraints on the temporaldistances between occurrences of events. The tools have been designed to be easy touse and to mask completely the underlying formalism to the end user who only worksat the UML abstraction level. The proposed verification framework is based on thefollowing elements:

• A significant subset of UML with a consistent and coherent interpretation. Thissubset is called MADES UML, after the project in which it was defined1. MADESdeals with the model-based development of reactive, (time) critical embedded sys-tems, hence MADES UML is particularly well-suited for modeling this categoryof systems.

• A formal semantics based on the TRIO [16] metric temporal logic. We believethat, unlike many common notations like Petri nets, automata, and transition sys-tems, the use of a logic formalism for ascribing the semantics, offers the flexibilityand scalability we need to formalize a wide and rich notation like MADES UML.The logic-based formalization fosters: (a) decoupling, of the semantics with re-spect to the predicates that represent the elements of MADES UML models toease the definition of different semantics, (b) extensibility, since adding a newdiagram type entails defining the predicates that represent its elements, and theirassociated axioms, and (c) partiality, since it supports the analysis of partial mod-els by simply avoiding the translation of the diagrams the user is not interestedin.

• A UML-like notation for letting the user specify LTL (Linear Temporal Logic)properties in the same framework. The notation is called Time Property Diagrams(TPDs) and it is an extension of Class Diagrams defined by means of a suitableUML profile. TPDs are based on a well known graphical notation with the sameexpressive power of the underlying logic formalism. They represent an excellentcompromise between usability and expressiveness.

• A traceability mechanism for making formal verification results (counterexam-ples) understandable by our end users without being an expert of the undelyingformalism. The proposed mechanism resumes the debugging paradigm of wellknow programming languages, an environment that should be well known to theuser.

• Corretto: a prototype verification tool that groups the above mentioned featuresinside a nicely packaged Papyrus2 plugin. Corretto translates MADES UML mod-els into their corresponding temporal logic semantics; the result is used to feed theZot [66] bounded model/satisfiability checker for TRIO models.

1http://www.mades-project.org/2http://www.eclipse.org/modeling/mdt/papyrus/

5


Figure 1.1 shows an overview of the verification framework. The user creates theUML models inside the UML IDE of choice. Corretto supports Papyrus natively, butdifferent UML IDE can be added as soon as they are UML compliant. Thanks to theMADES profile it is possible to tag the diagrams the user wants to verify leaving therest of the model untouched. This is particularly useful when the user is not interestedin verifying the whole model but just a subset of it, leaving out unneeded diagrams.The framework supports both static and behavioral diagrams of different types. Thedifferent views communicates by means of a shared set of events enabling the possi-bility to define complex behaviors. Also, dedicated time concepts have been includedto predicate on the time dimension of the system. Clocks - taken from UML/MARTEprofile for the Modeling and Analysis of Real-Time and Embedded Systems [59] - areused to define periodic behaviors, or to constrain components from evolving accordingto some time scale, while time constraints can be used to refer to the passing of timein the MADES diagrams. The framework supports two type of checks. The first one isthe model consistency. The model is consistent if the different views do not contradicteach other. Formally this is translated into the fact that the underlying formal modelhas at least one execution trace. In this case no property is required. The second checkis made by means of user defined properties. Thanks to the Time Property Diagrams(TPDs) included in the MADES UML profile the user is able to specify the propertythat must be checked against the model. Time properties usually refer to the relation ofdifferent events in the system with some time constraint. A simple example is if mes-sage x occurs now, then within 10 time instants object y will be inside state z. TPDs arean extesion of CDs used to build temporal logic formulae in UML. Even if this requiressome basic knowledge of logic - for example how to build an implication - this choicehas two clear advantages: first we keep the expressiveness of the underlying formal-ism leaving open the possibility to specify complex properties; second, the user doesnot leave the UML environment to build the property such that the underlying formalnotation remains hidden.

Once the user decides to run the formal verification, the UML models are first ex-ported in the XMI format, and then translated into their corresponding TRIO metrictemporal logic semantics with a suitable transformation tool. The export step makesthe approach independent from the UML IDE chosen by the user; as soon as the XMIexported by the UML tool is compliant with the UML standard, different tools can beused. Zot is then feeded by the formal model. In turnsZot relies on both the Satisfiabil-ity solvers (SAT) and the Satisfiability Modulo Theories solvers (SMT) to verify if theproperty specified by the user holds or not. If the property holds no action is requiredon the model and the user is just notified of the result. If the property does not hold, acounterexample is returned. Counterexamples in Zot are simple text traces represent-ing an execution of the system that violates the property. The framework proposes asimple mechanism to trace back the results to the end user. Since every element of thecounterexample trace has been generated from one of the elements in the UML model,a simple traceability mechanism has been developed to associate every element of thetrace to the corresponding UML element such that our end user is able to understandthe results. Navigating the trace resume closely the debugging paradigm of well knowprogramming languages, an environment that should be well known to the user.

6

1.3. Structure of the thesis

Figure 1.1: An overview of the MADES Verification Framework.

1.3 Structure of the thesis

This thesis presents a framework for the verification of the UML software models fortimed systems. The framework includes a subset of the UML language, a metric tem-poral logic semantics, and a prototype verification tool. The different chapters presentwith great detail all the different parts of the framework.

Chapter 2 presents the research works related to this thesis. In particular it includesan in-depth discussion of the research papers in literature that analyzed any of the fol-lowing problems: how to assign a formal semantics to the UML, how to build verifica-tion tools that can be exploited for the verification of the UML models, and what kindof frameworks can be used to integrate the different UML semantics and views.

Chapter 3 presents the MADES UML language. MADES UML is a verifiable sub-set of UML enriched with timed features taken from the MARTE UML profile andMADES specific temporal operators. The main differences with respect to the stan-dard UML will be highlighted and the elements of the MADES UML language will beintroduced by means of a suitable meta-model.

Chapter 4 presents the metric temporal logic semantics ascribed to MADES UML.The semantics ascribed to each diagram will be presented in two steps; first the predi-cates ascribed to each MADES UML element will be shown, and afterwards the met-ric temporal logic formulae ascribing the models will be described. The chapter alsopresents the novelties introduced by the logic-based approach: the possibility to inte-grate the different UML behavioral views; the decoupling between the predicates as-cribed to the UML elements and their metric temporal logic semantics; the extensibilitymechanism of the semantics; and finally the verification of partial models.

Chapter 5 presents the Corretto prototype tool emphasizing the characteristics thatmake Corretto an easy and extensible tool for the verification of MADES UML mod-els. Corretto has been designed to hide to the end user the complexity of the under-lying formal model and tools. Using Corretto engineers can exploit the advantages

7


of using an advanced formal verification technology without leaving the UML environ-ment and notation.

Chapter 6 presents the experiments that have been performed to validate the effec-tiveness of the approach. Three case studies provided by the industrial parteners of theMADES project 3 have been successfully analyzed; one car collision avoidance sys-tem, and two components taken from a Radar system. The case studies demonstrateboth the features of the MADES UML notation and the details of the metric temporallogic semantics ascribed to the models. The end of the chapter collects the results ofthe analysis and suggests some further improvements.

Finally Chapter 7 states the conclusions of this work highlighting all the differentdirections which can be taken. These includes both improvements to the MADES UMLlanguage, the semantics, and the tools which have been developed in this thesis.

3http://www.mades-project.org/

8

CHAPTER2Related Work

During the last ten years many people have addressed the problem of giving seman-tics to UML to improve the quality of their models. The semantics of UML is oftenmisunderstood because no proper definition of semantics is provided [40]. A completesemantics includes a semantic domain, and a mapping between the source domain andthe semantic domain. Because of the way the UML standard has been proposed no oneof the works that can be found in literature is able to translate a general purpose UMLmodel made of different views combined to your liking into a formal representation.Most of the works only targets the subset of the UML diagrams that is best suited forthe specific domain they are addressing. Also, no absolute definition of correct/incor-rect semantics can be found. First because the UML specification itself is imprecise,and second because many works propose their own semantics variations that are bestsuited to their domain. In addition to that, even focusing on a single diagram type, thenumber of supported operators may vary, together with their semantics.

The works in literature can be divided in two groups: first, the ones that assigned asemantics to UML as a pure theoretical exercise using an abstract syntaxt and seman-tics. The goal here is to reveal inconsistencies contained in the UML specification. Anexample taken from this group is the work presented by Störrle [69]. Second, the onesthat not only assigned a semantics to UML, but also provide tools to execute the mod-els and formally verify them. An example taken from this group is the work presentedby Diethers and Huhn in [21]. The level of rigour of the theoretical works is usuallygreater then the one of the works whose goal is to produce a verification tool. The workpresented in this thesis mostly belongs to the second group, but we cannot leave out thefirst group of works which represents a solid foundation for the other ones.

An additional dimension regards the number and the type of the diagrams whichare analyzed, and in this case three sets can be identified: the first one contains the

9

Chapter 2. Related Work

works that only deals with the structural views of the system, the second one containsthe works that specifically address the behavior of the UML models, and the third onecontains the works that try to ascribe the entire UML language by means of a commonground semantics. The first set usually concentrates on the satisfiability of OCL con-straints over structural diagrams. Some well know example are the works presentedin [1, 14, 34]. The USE framework presented by Gogolla et al. in [34] gave semanticsto CDs and OCL constraints using a plain set thory. USE is then able to validate UMLmodels against properties expressed in OCL. Similarly Cabot et al. in [14] translateCDs and OCL constraints to a constraint satisfaction problem (CSP) which can be ver-ified automatically by letting the user defining a finite solution space. Finally Ahrendtat al. in [1] define a HOL semantics for CDs and OCL constraints. Using the Keytool it is possible to enable the formal verification of OCL constraints by means of asemi-automated theorem prover. The work presented in this thesis does not take intoaccount the verification of OCL constraints as it concentrates on the verification of theUML model’s behavior which is orthogonal to the previous one. As soon as the OCLconstraints have been successfully analyzed the user can concentrate on the behavior ofthe UML model.

While there seems to be a general consensus on (a large portion of) the static se-mantics of UML, the dynamic semantics of its behavioral diagrams, such as activities,interactions and state machines, is still an open problem [10]. The works addressing thebehavior of the UML models only focus on a limited number of behavioral diagrams(oftentimes they only consider a single type) and neglect the interdependencies withthe other views of the system. We will present the works belonging to this set later inthis section. This thesis significantly contributes to the above mentioned works with theverification of heterogeneous models made of different behavioral views, by exploitingthe characteristics of the underlying logic formalism.

Finally, the works belonging to the third set try to build a common ground semanticto integrate the different UML structural and behavioral views. These works have beenmade in response to the need of regulate the great number of semantics which havebeen produced for UML. The work of Gogolla et al. presented in [48] shows how acentral part of the Unified Modeling Language can be integrated into a single visualsemantic model. It discusses UML models composed of class, object, state, sequenceand collaboration diagrams and presents an integrated semantics of these models. Themain aim of this paper is to provide a formal framework that supports the visual sim-ulation of integrated UML specifications in which system states and state changes aremodeled in a straightforward way. The work of Broy at al. presented in [11] proposesa ground mathematical semantics, called the system model, to integrate the differentviews. The system model defines a universe of interacting state machines that describethe behaviour of the objects and their relationships with each other. Even if the work isvery promising at the current date the automated formal analysis of the UML modelshas not been achieved yet. On the other hand an interesting simulator based on thesystem model has been proposed in [45]. Paige et al. in [62, 63] use metamodels asa unifying framework in which it is possible to ensure and check the consistency ofthe different views of a model, while at the same time providing the means to distin-guish between valid and invalid models, i.e., conformance. A comparison in terms ofcompleteness and the level of automation between different approaches is provided.

10

2.1. Analyze the UML Behavior

Finally, the OMG itself recently released fUML [61]. The fUML specification identi-fies an executable subset of the UML 2 meta-model to provide a shared foundation forhigher-level UML modeling concepts, as well as the precise definition of the semanticsof that subset. The semantic domain is an execution model which is itself a model,written in fUML. The specification still does not define precisely how the mapping be-tween the UML foundation set and the high-level diagrams is performed. In additionsome semantics definitions are still uncovered, like the semantics of time, concurrencyand inter-object communication. Finally, even if the execution model represents a validsemantics, it cannot be directly executed by any of the available formal verificationtools, thus a further translation step would be needed.

Compared to Gogolla [48], Broy [11], Paige [62, 63] and fUML [61] the work pre-sented in this thesis proposes a solution to the problem of formalizing and integratingthe different UML behavioral views by exploiting the extendibility of the underlyingmetric temporal logic approach.

2.1 Analyze the UML Behavior

Table 2.1 group the works in literature that gave semantics to the UML behavioral di-agrams. The table includes six columns corresponding to the UML views which aretaken into account. The columns include Class Diagrams (CDs), Component Diagrams(CpDs), Communication Diagrams (CmDs), Sequence Diagrams (SDs), Activity Dia-grams (ADs) and State Machine Diagrams (SMs). For each diagram a score from oneto three stars is assigned to the work depending if (*) it supports only the basic op-erators of the view, (**) it supports most of the operators supported by the view and(***) it supports all the operators supported by the view. The OCL column follows thesame guidelines. The Heterogeneous (Het.) column is marked if it is possible to usemore then one behavioral view to describe the system. Notice that many approachesuse SMs to describe the behavior of the system, while SDs are used to specify therequirements that must be satisfied by the SMs. In this case there is only one view con-tributing to the behavior of the UML model (SMs), while the other one is only used tocheck the desired property (SDs). Therefore the heterogeneous column is not markedfor these approaches. The domain column specifies the semantic domain assigned tothe diagrams. The remaining columns are reserved to the works that provides an anal-ysis tool for the end user, in other words everything that can help the UML developerto understand the behavior of the UML model. We identified three kind of analysis:by simulation(S), automated (A) and manual (M). Simulation tools animate the UMLmodels according to the specified semantics. Automated tools provide the means toautomatically analyze properties of the system. Manual tools provide the instrumentsto conduct a formal proof on top of the semantics associated to the UML model. TheCASE column indicates whether the tool is integrated into some computer-aided soft-ware engineering environment (for example, Eclipse) or not. For the model checkingtools the Properties (Prop.) column specifies if it is possible to express the property tobe checked using some UML-like or equivalent high-level formalism, while the Results(Res.) column specifies if it is possible to associate the results of the model checkinganalysis to the UML model. In other words the user must be able to understand theresults of the analysis procedure without being an expert of the underlying notation and

11


tools.

2.1.1 Sequence Diagrams

The work by Storrle [69] defines the semantics of SDs using plain math concepts. Thework is distinguished by the high level of rigor that has been used and by the highlevel of adherence to the OMG specification. No tool has been provided to translatethe formal semantics into an executable language which can be used to analyze themodels. A similar work about SDs is the one presented by Stolen et al. in [41, 42, 53]which provides an operational semantics for SDs. The semantics is defined by means offunctions over an abstract syntact. Given this semantics a tool for the translation of SDsinto the Maude language is provided on top of which a test generation tool for SDs hasbeen developed. Cengarle and Knapp in [15] propose a denotational semantics for SDs.Compared to the previous ones a detailed analysis of the neg operator is provided. Y.Hammal in [37] proposes a semantics based on a branching time structure for SDs. Thebranching time structure is represented with graphs annotated with time informations.This enables the possibility to perform a timeliness and performance analysis. NeitherStorrle [69], Stolen et al. [53], Cengarle and Knapp [15] or Hammal [37] provide a toolfor the analysis of UML models made of SDs, while the work presented in this thesissupports a broader range of views and also provides a tool to automatically analyzethem. On the other hand the semantics presented here does not support yet some ofthe SDs operators presented in the previous works, for example combined fragments -which can be replaced with equivalent IOD’s constructs - or the neg operator. Eichneret al. in [23] propose a translation of SDs to Petri nets. This kind of semantics hasthe limitation that it cannot deal with object oriented features. The advantage of usingPetri nets is that the semantics is defined compositionally, based on basic Petri netcomposition operations. On the other hand this semantics cannot deal with the timedimension of the system (i.e. time constraints). An interesing tool called P-UMLautthat simulates the behavior of the SDs according to the Petri net semantics is provided.The work presented in this thesis only provides a verification framework without thepossibility to simulate the UML models but on the other hand is it possible to askrandom execution traces of the system.

2.1.2 Activity Diagrams

The work by Storrle [70] defines the semantics of ADs by means of Petri nets. Thework is distinguished by the high level of rigor that has been used and by the high levelof adherence to the OMG specification. No tool has been provided to analyze ADs.Also, no suggestion is provided on how to integrate the SDs semantics described by thesame author in [69]. The approaches presented by Eshuis and Wieringa in [25, 27, 28]gives semantics to the UML ADs at two different levels of abstraction (requirementslevel and implementation level) providing an algorithm whose output is a LTS. Startingfrom this semantics a mapping to the NuSMV model checker is provided. The pathcorresponding to the counterexample returned by NuSMV is highlighted in the AD.The work presented by Bouabana-Tebibel [7] proposes a semantics for IODs - a specificvariation of ADs where the nodes are SDs - based on hierarchical Petri Nets (HPN). Atranslation tool is provided to translate the IODs into the input language of PROD, amodel checker for HPN. The user can write a LTL formulae in PROD to enact the

12

2.1. Analyze the UML Behavior

verification phase or he can express simpler properties using the OCL language [8].In both cases the results are expressed in the underlying petri net formalism (i.e. amarking on the petri net violating the property). Apvrille at al. in [3] present theTURTLE framework which ascribes a formal semantics to an extension of CDs andADs specified by the TURTLE UML profile. The semantics is given in terms of aparticular process algebra, called RT-LOTOS. The framework is supported by a CASEtool and the properties must be expressed using a formulae over the reachability graphproduced by the formal specification. Compared to Eshuis and Wieringa [25], Apvrilleat al. [3] and Bouabana-Tebibel [7] our work contributes in terms of the number ofsupported diagrams (none of them supports SMs) and the possibility to express theproperty of interest using a UML-like notation. Like Eshuis and Wieringa [25] we alsosupport the possibility to translate back to the end user the verification results but ourcontribution is that we are able to do that in the case of heterogeneous models made ofdifferent views, while in [25] the proposed mechanism is valid only for ADs.

2.1.3 State Diagrams

The majority of the works ascribing a semantics to SMs [18, 19, 21, 36, 46, 52, 64, 68]also supports SDs (or CmDs) to check wheter the interaction shown in the SDs (orCmDs) can be satisfied by the behaviors described in the SMs. Therefore SDs (orCmDs) are only used as a property-specification mechanism and do not contribute tothe possible behaviors of the system. The approach presented in this thesis overcomesthis limitation and it is able to analyze models made of SDs, SMs, or both SMs andSDs, depending on the actual needs of our end user. The approach presented by Knappet al. in [46, 68] translates SMs and SDs into the input language of UPPAAL, the on-the-fly model checker SPIN, the system language of the theorem prover KIV, and intoJava and SystemC code. The SDs are used as a high-level property specification mech-anism. The work by Paltor and Lilius [52, 64] presents the vUML tool which is ableto verify CDs, SMs and CmDs using SPIN [32]. Both SDs and CmDs are used as ahigh-level property specification mechanism. The approach presented by Damm et al.in [18, 19] gives semantic to the subset rtUML of UML which includes CDs and SMs.The semantics is given in terms of a symbolic transitions system (STS). Properties areexpressed using Live Sequence Charts which is similar to the idea of using SDs with agreater expressiveness. The proposed semantics choice was evaluated with a prototypeof a discrete-time verification environment under the UML modelling tool Rhapsody.The work presented by Diethers and Huhn in [21] shows the VOODUU framework thatgave semantics to CDs, SMs and SDs using timed automata, which are subsequentlyanalyzed in UPPAAL. The SDs are used as a high-level property specification mecha-nism. Counterexamples returned by UPPAAL are then translated back to the user againby using SDs, but no example is provided. In our experience this solution does not scalegraphically. A plugin for the Poseidon CASE tool has been developed. Hammal in [36]presents a semantics of SMs by means of Petri nets. He suggests that once a timedpetri net representing one or more SM has been produced, it can be checked against theconstraints imposed by a SD. It could be interesting to understand how this could bedone using the SDs semantics proposed by the same author in [37], but unfortunatelyno further details have been provided. Compared to Knapp et al. [46, 68], Paltor andLilius [52,64], Damm et al. [18,19], Diethers and Huhn [21], and Hammal [36] we are

13


able to build properties using a UML-like notation based on CDs and we are alwaysable to bring back verification results in the UML environment using our traceabilitymechanism. Finally with respect to Paltor and Lilius [52, 64] and Damm et al. [18, 19]we are also able to deal with the time dimension of the system. The OMEGA frame-work presented by Ober and Dragomir in [57] ascribes a semantics to CDs, CompDsand SMs in terms of communicating extended timed automata subsequently translatedinto the IF language which is supported by a number of verification tools. The ap-proach presented by Hansen et al. in [38, 39] ascribes a semantics to xUML modelswhich includes CDs and SMs. The semantics is given using the mCRL2 formal spec-ification language. The system can then be model checked using the LTSmin modelchecker. Both Ober and Dragomir [57] and Hansen et al. [38, 39] express propertiesusing a variation of SMs where the user can tag the error states. We build propertiesusing a UML-like notation based on CDs since we believe is more flexible to expresstime properties. Hansen et al. [38, 39] are also able to display verification result usingSDs. We do not use SDs to display the verification results but we use textual counterex-amples whose entities are linked to the source UML model. We believe this solutionis general enough to work with any kind of UML model, regardless of the number andtype of behavioral views. Bouabana-Tebibel in [8] explicitely targets CDs, SDs andSMs giving semantics to them using Hierarchical Petri nets. In this case the CD andthe SD are used to specify the initial marking of the Petri net, while the actual behav-ior of the system is leaved to the SMs. Petri nets are analyzed with PROD, a modelcheker tool for predicate/transition nets. Basic properties can be expressed in OCL,but for advanced properties the user must specify a LTL formulae. No insight is givenon how this semantics is connected to the one of the IODs presented by the same au-thor in [7]. The approach presented by Mazzanti et al. in [71] ascribes a semantics toCDs and SMs using a LTS. The LTS description can be verified using the UMC modelchecker while properties must be expressed in temporal logic (UCTL). Verification re-sults (counterexamples) are sent back to the user using a graph visualization but themapping between the graph and the source UML model is left to the user. The workpresented by Burmester et at. in [12] proposes a semantics of a variation of CompDsand SMs (precisely real time state charts) using timed automata. The timed automatasemantics is verified with the UPPAAL model checker. This work proposes an ap-proach for the incremental verification of the system based on small patterns that mustbe satisfied within a subset of the model. The authors also implemented a plugin forthe Fujaba tool suite [13]. The local properties still need to be expressed in temporallogic, but a traceability mechanism is provided when the property does not hold (i.e.the part of the system associated with the property is highlighted). This is a solution forlocal properties, but not for general ones. The approach presented by Pap et al. in [65]gives semantics to SMs in an operational fashion using kripke structures [51]. The se-mantics has been mapped in the Promela language. The resulting specification can thenbe checked using the SPIN model checker. The authors support both static checking,by means of simple OCL expressions, and dynamic checking, by means of reachabil-ity analysis using SPIN. Properties for SPIN must be expressed in temporal logic; nohigh level formalism is supported. A plugin for the Rational Rose CASE tool is pro-vided. Compared to Bouabana-Tebibel [8], Mazzanti et al. [71], Burmester et at. [12]and Pap et al. [65] only Burmester et at. [12] is able to deal with the time dimension

14

2.2. Contribution of this thesis

of the system, and none of them support the possibility to specify properties using aUML-like notation. Also Pap et al. [65] and Burmester et at. [12] are the only onesproviding an integration with a CASE tool but in turn only Burmester et at. [12] sup-ports the possibility to highlight verification results in the UML model, however theirmethodology is tailored to work only with local properties. Finally, Kias et al. in [49]present a semantics expressed in higher order logic to CDs with OCL constraints andflat SMs. The characteristic of this work is that its semantics can be analyzed using thePVS theorem prover. This is complementary to our approach and the previous ones asit can be a viable solution when there is the need to navigate the details of the proofwhich demonstrates that a certain property holds for the system.

2.1.4 Multiple Views

The approach presented by Graw and Herrmann in [35] is based on a compositionalTemporal Logic of Actions semantics (cTLA). The work integrates in the modellingphase both CDs, SDs, ADs and SMs. The authors provide a trasformation tool fromXMI to cTLA. Afterwards the user can rely on the existing tools for the verificationof cTLA specifications. Compared to our work we are able to deal with the time di-mension of the system, we can express the properties to be checked using a UML-likenotation, and the verification results are linked back to the UML model using a simpletraceability mechanism. The work presented by Lano in [50] ascribes a semantics toCDs, SMs and SDs using the Real Time Action Logic formalism (RAL). A trasforma-tion tool from UML to B is provided as a standalone Java program. The analysis mustbe performed using the B Tools. Compared to Lano we are able to express the prop-erties of interest using a UML-like notation and to trace back the verification resultsin the UML environment. We are both able to predicate on the time dimension of theUML model but we decided to use clocks and time constraints following the guidelinesof the UML/MARTE specification [59]. Finally we integrated our tool with the PapyrusEclipse modeling environment. Both Lano [50] and Graw and Herrmann [35] are ableto consider heterogeneous models like us and their semantics is also based on temporallogic. This suggests us that the logic-based approaches are well suited to cope with thecomplex task of ascribing semantics to the UML models made of heterogeneous views.

2.2 Contribution of this thesis

From the survey presented in the previous section it is possible to underline three spe-cific results:

• None of the works that can be found in literature is able to translate a generalpurpose UML model made of different views combined to your liking into a for-mal representation. The works that propose a logic-based semantics have shownto be more suitable to integrate the different UML behavioral views [35, 50]. Allthe other approaches either ignore the problem or they use StDs and SDs in orderto check that the behavior specified in the SDs is accepted by the StDs. In otherwords the SDs are not contributing to the possible behaviors of the system.

• The majority of the verification tools do not support the possibility to specify theproperties of interest using some high-level UML-like notation. When they do,

15


the expressivity is fairly limited because the proposed graphical notation can notexpress complex properties.

• The vast majority of the tools are not dealing with the problem of tracing back theresults of the verification to the end user. When they do, this is made possible onlybecause one single view composes the system behavior. For models made of SMsthe counterexamples are displayed as SDs. But what if the model is made of SMs,SDs, and ADs? How the counterexample looks like?

The work presented in this thesis contributes to the state of the art by proposing con-crete solutions to the previous problems. A new verification framework together with aprototype tool called Corretto is presented, in particular:

• Corretto is able to verify time properties of UML models made of SMs, SDs andIODs. The diagrams have been ascribed with a metric temporal logic semanticspresented in Chapter 4.

• Using Corretto it is possible to express the properties of interest using a high-level UML-like notation (CDs extended with a UML profile) called Time PropertyDiagrams (TPD) which are presented in Chapter 3.

• Verification results are linked back to the source UML model by means of a sim-ple traceability mechanism. This way the user can navigate the counterexampleviolating the stated property by looking at the corresponding UML elements.

The previously stated points are summarized in Table 2.1. The possibility to both ex-press the properties of interest using a high-level notation and to inspect the verificationresults without leaving the UML environment form the basis of a verification frame-work where the end user does not need to be aware of the underlying formal notationto enact the verification phase.

16

2.2. Contribution of this thesis

CD

SC

PD

SC

MD

SS

DS

AD

SS

MS

OC

LH

ET.

DO

MA

INT

OO

LT

YP

EC

AS

EP

RO

P.R

ES.

Sequ

ence

Dia

gram

s

[69]

***

Mat

h[5

3]**

*M

ath

[15]

***

Mat

h[3

7]**

*G

raph

s[2

3]**

*Pe

trin

etP-

UM

Lau

tS

Act

ivity

Dia

gram

s

[70]

***

Petr

inet

[25,

28]

***

LTS

NuS

MV

Ax

x[7

]**

**Pe

trin

etPR

OD

Ax

[3]

****

Proc

ess

Alg

.R

T-L

OTO

SA

x

Stat

eM

achi

neD

iagr

ams

[46]

****

***

*PR

OM

EL

ASP

INA

x[6

4]**

***

***

PRO

ME

LA

SPIN

Ax

[18]

****

*ST

SdS

PIN

Ax

x[2

1]**

****

T.A

utom

ata

UPP

AA

LA

xx

[36]

***

Petr

inet

[57]

****

***

T.A

utom

ata

IF-T

oolk

itA

x[3

8]**

***

mC

RL

2LT

Smin

Ax

[8]

**

****

Petr

inet

PRO

DA

x[7

1]**

***

LTS

UM

CA

[12]

****

*T.

Aut

omat

aU

PPA

AL

Ax

x[6

5]**

***

Kri

pke

Str.

SPIN

Ax

[49]

****

**H

OL

PVS

M

Mul

tiple

Vie

ws

[50]

****

****

xA

ctio

nL

ogic

B-T

oolk

itA

[35]

****

****

xcT

LA

TL

CA

Cor

retto

****

****

xT.

Log

icZ

OT

Ax

xx

Tabl

e2.

1:Th

edi

ffere

ntki

ndof

UM

Lse

man

tics

17

CHAPTER3MADES UML

UML is a well know and widely used design notation which can be used for visualizing,specifying, constructing, and documenting the artifacts of software systems. Followingthe guidelines of the MDE [44] it provides a general-purpose modeling language whichguides the development of the system by abstracting away from its platform-specificdetails . UML models provide the means to separate the specification of the systemfunctionality from the implementation of that functionality on a specific technologyplatform. The same model specifying some system functionality can be realized onmultiple platforms through auxiliary mapping standards, or through point mappingsto specific platforms, and allows different applications to be integrated by explicitlyrelating their models, enabling integration and interoperability and supporting systemevolution as platform technologies come and go. In addition to that UML models havebecome increasingly popular during the years providing an effective mechanism forsharing the design of the system. Diagrams make the model accessible to non-IT pro-fessionals, while the formality of the notation provides the means to guide the imple-mentation and support code generation technologies.

Despite this UML brings with it some flaws that have been criticized over time [24][22]. Some of them includes: the model multiplicity resulting from excess diagramtypes and symbols; the complexity of managing both structural and behavioral viewsspread over nine diagram types; and the influence of programming languages fromwhere UML has evolved in a bottom-up fashion. In addition to that if we want to ex-ecute, analyze, and verify our models using formal methods and advanced verificationtechnologies we must face a number of additional problems. First, the semantics pro-vided by the UML specification is given in terms of textual descriptions which oftencontains ambiguities. Second, specifications in UML consist of a collection of looselycoupled models (class model, use case models, collaborations, activity models, etc.)

19

Chapter 3. MADES UML

which are tied together by very few and semantically quite weak rules [33]. Morerecently, the introduction of the MARTE/UML profile led to additional difficulties be-cause of the size of the specification and the lack of support to integrate standard UMLmodels together with the MARTE/UML domain-specific concepts.

MADES UML has been defined in the context of the MADES project 1. MADESaims to develop a holistic, model-driven approach to improve the current practice inthe development of embedded systems. The proposed approach covers all phases, fromdesign to code generation and deployment. In order to fulfill this goal different artifactshave been produced: support for the creation of standard MARTE/UML models hasbeen added to the modeling tools adopted in the project; support for the generation ofplatform agnostic code starting from the UML models has been developed; a MADEScomponent repository together with the software facilities to query the repository hasbeen created; and so on. The verification of UML models was one of the key goals inthe project and this thesis has been developed in this context. The contribution of theMADES partners is concentrated in the requirements phase, and in the validation phase.During the requirements phase the partners defined the expected functionalities of theverification framework while in the validation phase the partners provided different casestudies to be analyzed together with the feedback about the usability of the verificationtool which has been developed.

In this context since the initial phases of the project the need of simplifying the UMLspecification arised. The key decision was to restrict the expressivity of the languagein order to allow the formal verification. From this, MADES UML was conceived as averifiable subset of UML for timed systems, whose main goal are:

• Reduce the complexity of the UML specification.

• Define the models which can be formally verified.

• Select an interesting subset of MARTE/UML that can be used for the verificationof timed systems.

MADES UML was conceived to work mainly with software components, but it actuallydoes not distinguish between software and hardware elements:

1. The static parts of a system are covered through class diagrams. These diagrams,which can also be adopted to render components and objects, are used to definethe terms (the alphabet) of the specification.

2. The dynamic aspects and behaviour of the different parts are much more interest-ing and their modelling requires different means. The notation offers:

(a) State diagrams, used to model the behaviour of the different elements (com-ponents).

(b) Sequence diagrams, used to model the “local" interactions among the differ-ent elements of the system. These diagrams are usually adopted to describelimited scenarios that define how the system reacts to some particular condi-tions and/or inputs.


20

3.1. Meta-model

(c) Interaction overview diagrams, used to relate different sequence diagrams.This is to describe more complete interactions of the system, and thus, beable to state more general, and system-wide, properties of the system.

3. Orthogonally, clocks and time constraints are used to add the time dimension tosystems, constrain the behaviour of components, and be able to predicate on it.

4. Finally, Time Property diagrams provide the means to express the property ofinterest of the system. The system description together with its properties are theinput of the verification phase.

All these diagrams supply users with a complete, homogenous set of concepts torender the system-to-be in a consistent way, and thus pave the ground to its formal ver-ification. More aspects, for example borrowed from MARTE, could have been addedto MADES UML, but it was more effective to concentrate on a limited, but complete,set of concepts. The provided elements offer a coherent notation, and also keep theverification phase simple enough to be used by UML experts which are not necessarilyalso formal verification experts.

In the remaining of this chapter the MADES meta-model will be presented througha set of UML class diagrams (Sections 3.1-3.9). Sections 3.7 and 3.8 presents the timeconstraints and events notation which have been developed specifically for MADESUML.

3.1 Meta-model

A valid MADES UML model is made of the following elements (see Figure 3.1):

• Class Diagrams (CDs)

• State Diagrams (StDs)

• Sequence Diagrams (SDs)

• Interation Overview Diagrams (IODs)

• Time Property Diagrams (TPDs)

Class diagrams provide the static definitions of the elements in the system. Every classin the system should have at least one Instance Specification (object) instantiating theclass. The number of Instance Specifications must be finite in order to run the formalverification. Class diagrams can also introduce the clock types (CT) used in the systemto constrain the timed behavior of components [2, 59]. State diagrams (StDs) can beused to describe the behavior of the (significant) portion of the system representedby classes in the CD. Each Class may have one or more StDs associated, in whichcase the different state diagrams run concurrently. Moreover according to the MADESsemantics all the Instance Specifications of a certain class will behave accordingly tothe StD associated to the class. Sequence diagrams (SD) describe partial behaviors ofthe system. SDs describe the messages exchanged between the Instance Specificationsdefined in the CD. The messages should be instances of the operations defined in the CDfor that object. Interaction Overview Diagrams (IOD) constitute a high-level structuringmechanism that is used to compose SDs through standard operators such as sequence,

21


iteration, concurrency, or choice [5]. The different diagrams share a common set ofevents. Examples of events are signals, beginnings and ends of messages, SDs andexecution occurrences, clock ticks, and states entered and exited. Shared events allowthe different views to communicate. Time Property Diagrams are used to express theproperty of interest. They have been defined as an extension of CDs though the UMLprofile mechanism.

Figure 3.1: The structure of valid MADES UML model.

Most of the differences between MADES UML and UML become apparent look-ing at the corresponding meta-models. According to the UML specification (see [60])StDs must be owned by a behaviored classifier. Possible behaviored classifiers are Ac-tivity, Actor, AssociationClass, Behavior, Class, Collaboration, Component, Device,ExecutionEnvironment, FunctionBehavior, Interaction, Node, OpaqueBehavior, Proto-colStateMachine, StateMachine, Stereotype, UseCase. In MADES UML StDs can onlydescribe the behavior of one of the classes in the Class Diagram, therefore their owneris a Class (see Figure 3.1). Another representative example is the one of Lifelines inthe Sequence Diagrams. Each Lifeline in UML must specify a Connectable Elementwhich is the Element executing the Lifeline. Connectable Element is an abstract classwhich in turn can be an ExtensionEnd, a Parameter, a Port, a Property, or a Variable.MADES UML only restricts Connectable Elements to Instance Specifications. An In-stanceSpecification is a specific instance of a Class in the CD.

3.2 Class Diagrams

CDs provide the static definitions of the elements in the system. A CD in MADESUML may contain: Classes, Instance Specifications, Clocks, and Signals. Classes mayhave attributes and operations with parameters. Each class must have at least one In-stance Specification in order to be formally verified. Instance Specifications are typi-cally referenced in behavioral diagrams such as sequence diagrams (showing, e.g., thata message is sent from one object to another). Data types are of great significance. For

22

3.2. Class Diagrams

instance, typed elements can be defined over integers, or real numbers, or finite sub-sets thereof. Modelling tools normally allow mixing of different infinite types in thesame model (e.g. an operation parameter of type integer, one attribute of type double,another of type String, and so on). Nevertheless, an automated formal verification pro-cess cannot deal with variables of heterogeneous infinite types. Finite domains can berepresented through enumerations and do not pose particular problems apart from theusual state explosion that is typical of automated verification. Consequently, MADESmodels that need to be verified can include variables of only one infinite type, but asmany finite domains as desired (See Figure 3.2). CDs can introduce clock types to con-

Figure 3.2: Data types in MADES UML.MADES models that need to be verified can include variablesof only one infinite type (but as many finite domains as desired).

strain the timed behaviour of the components. Every clock type must specify a periodT and owns a special event, the clock tick, which occurs every T time units. For eachclock type one or more clock instances can be declared. Clock instances provide themeans to:

• Use the corresponding clock ticks events in the StDs and SDs. Given a clockci, the corresponding tick event is denoted by @ci.tick. The events notation isdescribed in detail in Section 3.7.

• Define association links between clock instances and classes. Informally thismeans that all the events (operation invocation, message reception, etc.) belongingto the instances of that class are synchronised with that clock (see Section 4.2).

The periods of the clocks in MADES UML are all expressed in relation to a uni-form ideal discrete time that underlies the whole model. This abstract view of time issuitable for high-level specifications of timed systems, and it is not intended to captureimplementation-level concepts such as the physical hardware clocks associated withcomputing devices. The notion of clock in MADES UML can be seen as an abstractionof such concepts, in which clocks can be used to introduce periodic behaviors in thespecification.

23


Figure 3.3: Clocks in MADES UML.

A class diagram can introduce signals. A signal defines a general purpose event forthe system. Signals defined in the CD can then be used inside state diagrams (StDs) andinteraction overview diagrams (IODs). In a StD we can listen to a signal si by using thenotation @si.sig inside the trigger of a certain transition. Once a StD refer to a signal itwill be automatically notified of the reception of that signal. The sender of the signal isunknown. Complementary we can use the same notation as the action of a transition tocreate the signal. In an IOD we can listen for a signal si using the accept event actions.When an IOD encounter an accept event action it stops its execution waiting for thespecified event. Complementary using send signal actions is it possible to create signalinstances.

3.3 State Diagrams

State diagrams (StDs) can be used to describe the behavior of the (significant) portionof the system represented by classes in the CD.

State Diagrams (StDs) are made of states and transitions. Right now MADES UMLdoes not support hierachical states even if there is no theoretical restriction in support-ing them. On the other hand each class can have more than one StD associated. In thiscase, the overall state of each instance (object) of the class is given by the product ofthe current states of its state diagrams. The StDs of an object evolve in parallel. Statesmay have invariants over the attributes of the object owning the state. For example ifthe class owning the state diagram owns an integer attribute a, then a < 10 is a validinvariant for the state.

Transitions may have a trigger, a guard and an action. If the trigger is not specified,then the transition will occur non-deterministically. End users who are not interestedin analyzing the behavior of the UML models, or to generate code automatically fromthem usually works with Strings for specifying triggers, guards and actions. Even if thiscould be a good way to abstract away some details in the early phase of the modeling,this cannot be accepted in a formal verification environment. The MADES languageprecisely defines what is the meaning of each field of the transition paying particular

24

3.3. State Diagrams

attention to the mechanism that provide the means to coordinate the different behavioralviews of the MADES UML model (SDs, StDs, IODs).

Figure 3.4: State diagram transitions in MADES UML.

The trigger can be the invocation of any of the operations belonging to the object,a signal, a clock tick , a SD start/end/stop event, or an IOD start/end event. Thesebelongs to the set of MADES shared events presented in Section 3.6. If the triggeris an operation invocation the notation @op.call must be used. Operation invocationsmay occur because some SD, which is running concurrently to the StD, is sending amessage istantiating the operation referenced in the trigger. If the operation owns aparameter, then it is possible to use the current value of the parameter in the guard ofthe StD. If the trigger is a signal s then the notation @s.sig must be used. If the triggeris a clock tick belonging to clock c, then the notation @c.tick must be used. If thetrigger is a SD start/end/stop event the notation @sdname.start, @sdname.end, [email protected] must be used respectively. If the trigger is an IOD start/end event thenotation @iodname.iodstart and @iodname.iodend must be used. It is also possibleto use time constraints as triggers, in which case the transition is performed when thetime constraint holds. Time constraints will be explained in detail in section 3.8. Theguard can be a time constraint or a boolean condition. The simplest boolean conditioncan be the value of a boolean attribute of the class, or the value of a boolean parameterowned by the operation referenced in the trigger. This can be also combined usingtradition logic operators like && and ‖‖ with arithmetic inequalities over the attributesof the class or the parameters of the invoked operation. The action specification canbe an event or an assignment. Possible events for the action specification are signals,SD’s start or stop events, operation invocations and IOD start events. The same type ofnotation described for the triggers can also be used to define an action. If the action isan assignment the classical arithmetic operations can be used paying attention that wecan only refer to the attributes of the class owning the state diagram.

25


3.4 Sequence Diagrams

Sequence diagrams (SD) describe partial behaviors of the system. SDs are made of aset of lifelines, each of them refer to an Instance Specification defined in the CD.

Figure 3.5: The Sequence Diagram meta-model of MADES UML.

In MADES UML the messages in a SD should be instances of the operations de-fined in the CD for that object. Right now no distinction between synchronous andasynchronous messages is supported. Execution occurrences shown in the lifeline rep-resents a time period in which the object is busy. The precise semantics of what busymeans will be explained in Section 4.5. Intuitively if the same object is running differ-ent SDs concurrently - thus, it is involved in different interactions at the same time - itcannot be inside two different execution occurrences at the same time. Otherwise thiswould be a violation of the intuitive semantics associated to the execution occurrences.On the other hand execution occurrences do not affect StDs, even if this could be a pos-sible extension to the current semantics. MADES UML supports variables inside theSDs, as opposed to most of the approaches in literature that give semantics to them [55].Variables can be used in two ways: First, it is possible to refer to the attributes of theInstance Specifications used in the lifeline. Second, it is possible to declare sequencediagrams parameters whose value remain constant during the interaction. This is par-ticularly useful if we need to send some value from one object to another betweendifferent lifelines. In the MADES project we found different use cases where this wasneeded but not easily supported by UML. The value of the attributes belonging to thedifferent objects involved in the interaction can be modified using assignments. Thereare two possible ways in which an assignment can be made: the first one is to use

26

3.4. Sequence Diagrams

self-recursive messages whose associated String is the assignment specification. Thesecond one is to append the assignment to a specific message through a comment. Thiskind of solution is mandatory in order to avoid that time elapses when we want to bothmake an assignment and specify the parameter of a message. In UML 2.0 the concept ofcombined fragment has been introduced [60]. Right now they are not supported by theMADES prototype tool, even if there is no theoretical limitation in including them. Onthe other hand it is possible to replicate most of the combined fragment constructs byusing the operators offered by the IODs, which are well supported in MADES. SDs can

Figure 3.6: The SD, named mades_sd, contains a variable assignment specified using a self recursivemessage and a SD parameter, named sd_par, which remains constant during the execution of the

diagram. Finally, a time constraint is added to say that the diagram will lasts less then 5 time units.

also have time constraints associated to them. Time constraints inside SDs may referto message start/end events, execution occurrences start/end events, and SD start/endevents. Given a message m the notation @m.send and @m.receive is used to refer tobeginning and to the end of a message inside the time constraint. Given an executionoccurrence e the notation @e.begin and @e.terminate is used to refer to the beginningand to the end of the execution occurrence. Finally, given a sequence diagram namedsd, the notation @sd.start and @sd.end is used to refer to the start and to the end of theSD. The syntaxt for building time constraints expressions will be explained in detail insection 3.8. SDs support the possibility to express periodic behaviors by using clocksand the timed event stereotype taken from the MARTE specification. Messages thathave the timed event stereotype must have a clock associated to them which defines theperiodic behavior of the message.

27


3.5 Interaction Overview Diagrams

Interaction Overview Diagrams (IODs) have been newly introduced UML2 [5]. Theyconstitute a high-level structuring mechanism that is used to compose scenarios throughmechanisms such as sequence, iteration, concurrency or choice. IODs are a special andrestricted kind of UML Activity Diagrams (ADs) where nodes are Sequence Diagrams(SDs), and edges indicate the flow or order in which these occur.

Figure 3.7: MADES UML Meta-model of the Interaction Oveview Diagrams

The constructs supported by MADES UML are the ones defined in the meta-modelof Figure 3.7. It is possible to have only one initial node, but multiple final nodes. Whenthe IOD arrives at the final node all the current interactions are stopped. Decision nodessupport guards to decide which path should be taken. Guards can be time constraintsor boolean expressions over the attributes of the objects declared in the CD. IODs inMADES may refer to the shared events defined in the model. In particular using theaccept event action is it possible to capture events, while using the send event action itis possible to create event instances. IODs may also contain interruptible regions (IRs)(see [60]). An IR is a set of SDs that may be interrupted because the event associatedto that region occurs (interrupt). As the name suggests this feature is useful to model

28

3.6. Shared Events

Figure 3.8: Interaction Overview Diagram with one Interruptible Region and one accept event action.

the interruption of a certain behavior at any point in time. The example of Figure 3.8shows an IOD with three SDs, namely sd_A, sd_B, sd_C, one Interruptible Region,and one accept event action connected with that region. The accept event action isthen connected to sd_C. The activity ends either because we successfully completedthe execution of the left part of the diagram, or because sig_A occurs inside sd_B andwe executed the right part of the diagram, made of sd_C.

3.6 Shared Events

MADES UML defines a set of shared events between the different views which enablethe communication between them. Figure 3.9 shows the meta-model defining the set ofevents supported in MADES UML. Each event is owned by a specific view and can belinked to one or more of the remaining views depending on the associated semantics.

Let’s consider this simple example: suppose the user models the interaction betweenthe different objects in the system using a SD. Let’s consider a message m in the SDwhich refers to an operation op defined in the CD. The class owning opmay in turn havea StD associated modeling the behavior of the objects belonging to that class. Supposethe StD defines a transition t between two different states s1, s2 which is fired when opis invoked. The expected behavior is that when m is received in the SD, then t is firedin the StD.

All these different modeling elements belonging to the different views are put incommunication thanks to a set of shared events. Back to the previous example foreach message in the SD the message start and message end events are declared. Theseevents are shared between the SD view and the CD view. In turn the CD view definesthe operation event which is shared between the SD view and the StD view. Finallythe StD defines the call operation event which is shared only with the CD view. Theoperation event holds when message end event defined in the SD view holds. In turnthe call operation event holds when the operation event holds.

When working inside a certain view the end user can only refer to the events belong-

29


ing to that view. However by adding and removing diagrams is it possible to changethe behavior of the model depending on how the different shared events are connectedeach other. In the previous example we can both remove the SD of the StD keepingthe model valid. If the StD is removed then the message in the SD will not affect thestate of the receiving object. If the SD is removed then the transition in the StD in firednon-deterministically. All these semantics choices will be explained in details when thesemantics associated to the different views will be presented (Section 4.7).

Figure 3.9: The MADES UML set of shared events.

3.7 Events Notation

The MADES events notation has been inspired from the notation used in MARTE torefer to time events (see [20]). With respect to this notation we decided to add typeextensions to uniquely identify the event type the user is referring to. The notation iseasily defined by the grammar shown in Listing 3.1. Event type extensions can be:

• @ID.enter, @ID.exit: ID is the name of the state of a state diagram and the twoevents refer to the time instants in which the object is entering the state and theobject is exiting the state.

• @ID.start, @ID.end, @ID.stop: ID is the name of a sequence diagram and thethree events refer to the time instants in which the sequence diagram is starting,ending, and stopped. A sequence diagram ends when it successfully completeall the interactions shown in the diagram. If the interactions are not completedsuccessfully we say that the sequence diagram has been stopped.

• @ID.tick: ID is the name of a clock instance defined in the class diagram and thetick event occurs every T time units, where T is the period defined by the clock inthe CD.

30

3.8. Time Constraints

• @ID.sig: ID is the name of a signal defined in the class diagram and the signalevent may occur non-deterministically or at the same time instant of the StDsactions invoking that signal.

• @ID.call: ID is the name of an operation defined in the class diagram and thecall operation event occurs when the corresponding operation occurs. For examplegiven an operation op defined in the class diagram, when a sequence diagramsends a message instantiating that operation, the @op.call event occur.

• @ID.send,@ID.receive: ID is the name of a message defined in a sequencediagram, and the two events refer to the time instants in which the message is sentand the message is received.

• @ID.begin, @ID.terminate: ID is the name of an execution occurrence in asequence diagram, and the two events refer to the time instants in which the exe-cution occurrence starts and ends.

• @ID.iodstart, ID.iodend: ID is the name of an IOD belonging to the modeland the two events refer to the time instants in which the IOD starts and ends.

• @now: The now event is a special kind of event which is referring to the currenttime instant.

Event :’@’ ID ’ . ’ E v e n t E x t e n s i o n s | ’@now’

;

E v e n t E x t e n s i o n s :’ e x i t ’ | ’ e n t e r ’ | ’ s t a r t ’ | ’ end ’ | ’ s top ’ | ’ t i c k ’ | ’ s i g ’ | ’

c a l l ’ | ’ send ’ | ’ r e c e i v e ’ | ’ begin ’ | ’ t e r m i n a t e ’ | ’ i o d s t a r t ’| ’ iodend ’

;Listing 3.1: Events notation grammar

3.8 Time Constraints

MADES UML is meant for the verification of timed systems. For this reasons it sup-ports the notion of time constraint where users can refer to the passing of time in theMADES diagrams. The notation used for this purpose has some characteristics takenfrom MARTE [59], but its syntax in the MADES notation is predominantly different.Time constraints can be added:

• as constraints associated with sequence diagrams, in which case they must betagged with the�TimeConstraint� stereotype (Figure 3.6), or

• on transitions in state diagrams, either in the trigger or the guard definition (Fig-ure 3.10).

The syntax of these constraints is:

ev1− ev2 ∼ K

31


where ev1 and ev2 are MADES model events (e.g., the sending of a message, or thestarting of the execution of a diagram),∼ is a relation of the set {<,≤,==, ! =,≥, >},and K is a numeric (integer) constant. In addition to the MADES model events the@now operator may also be used to refer to the current time instant. The time constraintshown in Figure 3.10 is used in the guard of the transition between State0 and State1.Whenever the callOp operation is invoked on the object, the truth value of the guard isevaluated. If the object remained in State0 for less then 10 time units - i.e. the distancebetween the current time instant and the time instant in which the object entered State0is less then 10 time units - then the transition is enable, otherwise it will be blocked.Another example of time constraint is the one used in Figure 3.6. In this case the modelstates that a time constraint is added to say that the sequence diagram will lasts lessthen 5 time units, i.e. the time distance between the end event and the start event of thesequence diagram is less then 5 time units.

Figure 3.10: Example of a State Diagram using a time constraint for the guard. The transition occursonly if the object owning the diagram remains in State0 for less then 10 time istants.

3.9 Time Property Diagrams

Time Property Diagrams (TPDs) are used to define the properties that must be provedfor the MADES UML model. They are an extension of CDs defined by means of anappropriate UML profile. Each stereotype corresponds to one of the temporal logic op-erators defined in the TRIO language which will be presented in detail in the semanticschapter (Section 4.1). TPDs are a user-friendly but powerful mechanism to build prop-erties. They are based on a well known graphical notation but with the same expressivepower of the underlying logic formalism. They represent an excellent compromisebetween usability and expressiveness.

Figure 3.11 shows part of the UML profile defining the TPDs. Apart from the stan-dard boolean operators like «Or», «And» or «Not», the fundamentals TRIO operatorsare used, like «Futr», «Alw» or «Lasts». The meaning of the different TRIO operatorsis often self-explanatory; for example the «Futr» operator is used to define somethingthat will be true t time units in the future, while the «Lasts» operator is used to definesomething which will remain true for the next t time units in the future. The «Term»stereotype refers to the atoms of the boolean formulae constituting the property. Exam-ples of valid terms are messages in a SD or states in a StD. The user does not need toknow which element can be a term, because they are automatically filtered by the UMLmodelling tool following the constraints declared in the profile. The «BooleanExpres-sions» stereotype is used to define time constraints and inequalities over the variables

32

3.9. Time Property Diagrams

declared in the UML model. Finally the «constant» stereotype is used to define dis-crete values - usually time intervals - which are used afterwards in conjunction with thepreviously stated TRIO operators.

Figure 3.11: UML profile of the Time Property Diagrams.

In order to use TPDs the user does not need to be an expert of the TRIO languagesince most of the operators are self-explanatory and can be learned in a short time.The diagrams of Figures 3.12-3.13 show two example properties demonstrating thisstatement. The one of Figure 3.12 states that if we are in State0 at the current timeinstant, then we cannot be in State1 at the same time instant. The one of Figure 3.13states that if the opB operation holds now, then we will stay in State0 for the next 10time instants. Both formulae use the Alw operator in order to declare that somethingholds at every time instant in the model. This is a common pattern for Time Propertydiagrams and for properties expressed in TRIO in general which is quite intuitive andeasy to understand.

33


Figure 3.12: Time Property Diagram example: If we are in State0 at the current time instant, then wecannot be in State1 at the same time instant.

Figure 3.13: Time Property Diagram example: If the opB operation holds now, then we will stay inState0 for the next 10 time instants.

34

CHAPTER4Metric Temporal Logic Semantics

The semantics of MADES UML is defined through the TRIO metric temporal logic[16]. An introduction to TRIO is presented in Section 4.1. This choice enables aformalization/verification approach that emphasizes:

• Decoupling. The semantics is decoupled from the predicates that represent theelements of MADES UML models. This means that one can change the seman-tics while keeping the translation from UML to the predicates unchanged. Forexample, if we wanted to change the semantics of time associated with clocks,we do not need to alter the generated predicates, but only the axioms associatedwith them. This also gives the opportunity to experiment and evaluate differentsemantics for the same model.

• Extensibility. The logic-based formalization is easy to extend. Adding a new di-agram type entails defining the predicates that represent its elements, and theirassociated axioms. If the new diagram type shares some predicates with the al-ready existing ones, then the coordination between diagrams is obtained seam-lessly through the formulae that predicate on the shared elements. If, for example,one wanted to add collaboration diagrams (CLDs) to the set of supported dia-grams, they can be integrated in the existing semantics by simply translating themessages into predicates as before and by adding the axioms describing the se-mantics of CLDs.

Introducing new predicates is also a means to increase the amount of details inthe temporal logic representation of the models. For example, messages in SDsare currently received directly by the object. However, one may be interested inmodeling the fact that an object can have a queue where messages are stored andpicked up later. This extension would be “implemented” by adding some new

35

Chapter 4. Metric Temporal Logic Semantics

predicates —and related axioms— to represent the queue, without modifying theformalization of the other diagrams.

• Partiality. Introducing new details may result in specifications that become toobig to be analyzed automatically. To this end, our approach supports the analysisof partial models by simply avoiding the translation of the diagrams the user is notinterested in. This results in a “lightweight” approach, in which the user can focusthe verification on the parts of the model that are really involved in the propertiesto be proved, without the need for translating the entire UML model.

Despite its interesting characteristics ascribing the TRIO metric temporal logic se-mantics has not been trivial. First, because of the declarative nature of the language.In fact metric temporal logic does not resemble the operational style of many of theUML behavioral diagrams, like sequence diagrams or activity diagrams. Even thoughthe considerable experience of the author in building such axiomatizations, a numberof technical difficulties came out over time together with alternative axiomatizationstyles. As a consequence the metric temporal logic semantics has been refactored sev-eral times during the lifetime of the research presented in this thesis to keep it bothas simple as possible and consistent with the intuitive semantics ascribed to the UML.Second, the lack of a formal semantics in the UML document specification togetherwith the huge amount of semantics ascribed by the research community complicatedthe work of building a consistent semantics in a formalism which integrates the differ-ent UML behavioral views. In fact, even though many works ascribed the semanticsof some UML diagrams in isolation, the composite semantics of the different viewshas never been addressed in detail. As a consequence it has been difficult to reuse thealready existing semantics for our purposes: for some of them it was difficult to under-stand how the existing semantics could be integrated with another one belonging to adifferent view; even when it was clear then we had to face the integration problem withour metric temporal logic formalism; finally some semantics lacks the tools to verifythat they behave as expected making this work even more difficult. Third, even if manysample UML models are publicly available for documenting different software system,or to automatically generate code from them, the same cannot be said for UML modelswhose primary goal is to be analyzed using some formal verification technique. Thesemodels needs to be precise enough for being executed by a machine therefore cannotcontain the typical shortcuts adopted by many early UML users: for example the usageof natural language sentences to describe some part of the system must be avoided; thescope of the variables in the model must be precisely defined; the organization of theUML model must be precisely defined other that the single views composing it; andso on and so forth. We partially solved some of the above mentioned problems withthe definition of MADES UML presented in Chapter 3, but still some details remainedunsolved before the definition of the formal semantics. This training phase in whichthe definition of how a precise UML model looks like, and what is the semantics weascribe to it, has been made in a iterative fashion also thanks to the support of samplemodels provided by the MADES industrial partners 1. The proposed semantics hasbeen partially validated by the same industrial partners checking that the high-level in-tuitive semantics is coherent with the one formally defined in TRIO by looking at the


36

4.1. TRIO

corresponding execution traces provided by our experimental tool presented later in thisthesis.The rest of the chapter is structured as follows. Section 4.1 provides a brief introductionto TRIO. Sections 4.2-4.5. introduce, for every MADES UML diagram, the predicatesthat are defined to encode the diagram, and then the axioms that formalize the meaningof the different concepts. Section 4.6 presents the notation to express temporal logicpredicates in MADES UML together with its associated semantics. Section 4.7 presentsthe detail of how the MADES UML semantics supports the comunication between thedifferent views through shared events. Finally, Sections 4.8-4.9 present how the currentsemantics can be extended and how it can be used to verify partial models.

4.1 TRIO

TRIO [16] is a first-order linear temporal logic that supports a metric on time. TRIOformulae are built out of the usual first-order connectives, operators, and quantifiers, aswell as a single basic modal operator, called Dist, that relates the current time, whichis left implicit in the formula, to another time instant: given a time-dependent formulaF (i.e., a term representing a mapping from the time domain to truth values) and a(arithmetic) term t indicating a time distance (either positive or negative), the formulaDist(F, t) specifies that F holds at a time instant whose distance is exactly t time unitsfrom the current instant. Dist(F, t) is in turn also a time-dependent formula, as its truthvalue can be evaluated for any current time instant, so that temporal formulae can benested as usual. While TRIO can exploit both discrete and dense sets as time domains,in the MADES semantics we assume the standard model of the nonnegative integersN as discrete time domain. For convenience in the writing of specification formulae,TRIO defines a number of derived temporal operators from the basic Dist, throughpropositional composition and first-order logic quantification. Table 4.1 defines someof the most significant ones, including those used in the MADES semantics.

OPERATOR DEFINITION

Past(F, t) t ≥ 0 ∧Dist(F,−t)Futr(F, t) t ≥ 0 ∧Dist(F, t)

Alw(F ) ∀d : Dist(F, d)

AlwP(F ) ∀d > 0 : Past(F, d)

AlwF(F ) ∀d > 0 : Futr(F, d)

SomF(F ) ∃d > 0 : Futr(F, d)

SomP(F ) ∃d > 0 : Past(F, d)

Lasted(F, t) ∀d ∈ (0, t] : Past(F, d)

Lasts(F, t) ∀d ∈ (0, t] : Futr(F, d)

WithinP(F, t) ∃d ∈ (0, t] : Past(F, d)

WithinF(F, t) ∃d ∈ (0, t] : Futr(F, d)

Since(F,G) ∃d > 0 : Lasted(F, d) ∧ Past(G, d)

Until(F,G) ∃d > 0 : Lasts(F, d) ∧ Futr(G, d)

Table 4.1: TRIO derived temporal operators

37


The TRIO specification of a system consists of a set of basic items, which are prim-itive elements, such as predicates, time-dependent values, and functions, representingthe elementary phenomena of the system. The behavior of a system over time is de-scribed by a set of TRIO formulae, which state how the items are constrained and howthey vary, in a purely descriptive (or declarative) fashion.

The goal of the verification phase is to ensure that the system S satisfies some de-sired propertyR, that is, that S |= R. In the TRIO approach S andR are both expressedas logic formulae Σ and ρ, respectively; then, showing that S |= R amounts to provingthat Σ⇒ ρ is valid.

TRIO is supported by a variety of verification techniques implemented in prototypetools. In this paper we use Zot [66], a bounded satisfiability checker which supportsverification of discrete-time TRIO models. Zot2 encodes satisfiability (and validity)problems for discrete-time TRIO formulae as propositional satisfiability (SAT) prob-lems, which are then checked with off-the-shelf SAT solvers. More recently, we de-veloped a more efficient encoding that exploits the features of Satisfiability ModuloTheories (SMT) solvers [6]. Through Zot one can verify whether stated propertieshold for the modeled system (or parts thereof) or not; if a property does not hold, Zotproduces a counterexample that violates it.

4.1.1 An example: a lamp with a timer

As a simplest example on which to discuss the introduced concepts we consider a so-called timer-reset-lamp (TRL, [67]), i.e., a lamp with two buttons, called ON and OFF.When the ON button is pressed the lamp is lighted and it remains so for ∆ time units(t.u.) and then it goes off, unless the OFF button is pushed before the ∆ time-out expires(in which case the light goes off immediately after the push of the OFF button , even ifthis occurs before the end of the time-out period), or unless the ON button is pressedagain, before the time-out, in which case the lamp will remain lighted for more ∆ t.u.(unless the OFF button is pressed before the time-out expires, etc.). To ensure that thepressure of a button is always meaningful, it is assumed that ON and OFF cannot bepressed simultaneously.

Figure 4.1: A history for the example of the timed lamp

An example of a trace of execution of the TRL system (a so-called history) is rep-resented in Figure 4.1 , for the case ∆ = 5. The history shows typical behaviors ofthe modeled system: the lamp being off is turned on by pushing button ON and thenit turns off “spontaneously" after ∆ t.u.; then the lamp is lighted again and then turnedoff within ∆ t.u. by pressing button OFF; the lamp is kept on by pushing again buttonON before the ∆ time-out, and then it finally goes off spontaneously. The descriptivemodel of the TRL is based on following three propositional letters, with the indicatedmeaning:

2http://home.dei.polimi.it/pradella/Zot

38

http://home.dei.polimi.it/pradella/Zot

4.2. Class Diagram

• L the light is on,

• ON the button to turn it on is pressed,

• OFF the button to turn it off is pressed.

The model is made of two simple formulae. the first one states that the lamp is on (atthe current time) if and only if the ON button was pressed not more than ∆ time unitsago and since then the OFF button was never pressed. In TRIO this is formalized bythe following formula:

(D1) L⇔WithinP(ON,∆) ∧ Since(¬OFF,ON)

The second formula expresses the mutual exclusion between the pressing of the ONand OFF buttons, namely:

(D2) ¬(ON ∧OFF )

The descriptive model of the formula simply consists of the conjunction of these twoformulae, enclosed in a universal temporal quantification (an Alw operator) assertingthat they hold for all instants of the temporal domain.

(DM) Alw(D1 ∧D2) (4.1)

The descriptive model, despite its simplicity and succinctness, characterizes completelythe TRL system: starting from it the history depicted in Figure 4.1 can be generatedusing the Zot tool, or one can prove that the following (conjectured) property

(P1) Alw(¬Lasts(L,∆ + 1)) (4.2)

(i.e., the lamp will never remain on for more than ∆ time units) does not hold, bygenerating, through the Zot tool, a counterexample consisting of a history similar tothe one shown in Figure 4.1, including two push actions of the ON button at distanceless than ∆; the Zot tool can instead prove, from the descriptive model, the followingproperty

(P2) Alw(Lasts(L,∆ + 1)⇒WithinF(ON,∆ + 1)) (4.3)

(i.e., the lamp remains lighted for more than ∆ time units only if we have another pressactions of the ON button at a distance of less than ∆ t.u.).

4.2 Class Diagram

For a detailed description of the operators supported by MADES Class Diagrams pleaserefer to Section 3.2.

4.2.1 Predicates

The following elements of the class diagram are directly translated in temporal logic(see Table 4.2). For every clock c, a temporal logic predicate ClockidcTick is declared,where idc is the UML identifier of the clock. Every UML element in the model has isown identifier. The UML identifiers are used to generate the temporal logic predicates

39


of the elements. This generation mechanism ensures their uniqueness, meaning that wedo not generate the same predicate for two different UML model elements. If not differ-ently specified we will now on use idx to refer to the UML identifier of the element x inthe UML model. For every signal s we declare the temporal logic predicate Signalids .For every operation x belonging to an object y we declare the temporal logic predicateOBJidxOPidy . For every parameter z belonging to an operation y owned by an objectx, the TRIO arithmetic variable ObjidxOpParidz is declared, representing the actualvalue of the parameter. For every return value belonging to an operation y owned byan object x, the TRIO arithmetic variable ObjidxOpidyRet is declared, representing thereturn value of the operation. For every attribute y belonging to an object x, the TRIOarithmetic variable ObjidxAttridy is declared which models the value of the attributeover time.

UML ENTITY PREDICATE OR VARIABLE

Clock ClockidcTick

Signal Signalids

Operation ObjidxOPidy

Parameter ObjidxOpParidz

Attribute ObjidxAttridy

Return Value ObjidxOpidyRet

Table 4.2: TRIO predicates associated to the Class Diagram

4.2.2 Axioms

For every predicate shown in Table 4.2 we will present the corresponding axioms con-straining its behavior over time. If not differently specified from now on we will referto the temporal logic predicates using their corresponding UML element name.

Given a clock c, its clock tick occurs iff it did not tick during the last T − 1 timeunits, which implies that it ticks at times T, 2T, 3T, . . .: 3

Lasted(¬ClockidcTick, T − 1)⇔ ClockidcTick (4.4)

Objects that are linked to a clock c run on a time base that is the one defined by c. Allthe events that belong to these objects can only happen when c ticks. Given a clock c,we define the set of predicates running on this clock as Eventsc. For every object olinked to clock c, if there is a sequence diagram where o sends/receives a message, thepredicate corresponding to the message start/end event is included in set Eventsc. Forevery predicate e in Eventsc the following axiom holds, which states that event e canoccur only in those instants in which clock c ticks:

e⇒ ClockidcTick (4.5)

The elements defined in the CD, together with their associated predicates, are sharedbetween the different views. Shared predicates enable a communication mechanismwhich is described in detail in Section 4.7, thus any additional axiom related to thataspect will be presented here.

3TRIO axioms are implicitly asserted for all time instants, hence formula (4.4) is implicitly interpreted as“Always(Lasted(¬ClockidcT ick, T − 1)⇔ ClockidcT ick)”.

40

4.3. State Diagrams

4.3 State Diagrams

For a detailed description of the operators supported by MADES State Diagrams pleaserefer to Section 3.3.

4.3.1 Predicates

The following elements of the StDs are directly translated in temporal logic (see Table4.3). For every state s whose StD is owned by the class of an object o we declare threepredicates ObjidoStateidsEnter, ObjidoStateidsExit and ObjidoStateids which hold,respectively, when the object is entering or exiting the state, and when it is inside thestate. If this state has also an invariant we declare the predicateObjidoInvariantids . Forevery transition t of the same diagram we declare the predicate ObjidoTransitionidt .The same transition may have a trigger, a guard, and an action, which are mapped tothe following predicates; ObjidoTriggeridt , ObjidoGuardidt , ObjidoActionidt .

UML ENTITY TRIO PREDICATE OR VARIABLE

State ObjidoStateidsEnter,Objido

StateidsExit,

ObjidoStateids

Invariant ObjidoInvariantids

Transition ObjidoTransitionidt

Trigger ObjidoTriggeridt

Guard ObjidoGuardidt

Action ObjidoActionidt

Table 4.3: TRIO predicates associated to the State Diagram

4.3.2 Axioms

The formalization in temporal logic of StDs is fairly standard, therefore we will onlyhint at some of its features. However, it lends itself to multiple formalizations, as webriefly discuss. Given a state s owned by object o, let us define the set of its incom-ing and outgoing transitions as Incomings and Outgoings respectively. A necessarycondition to enter the state is that one of the incoming transitions holds in the previoustime instant, namely:

ObjidoStateidsEnter ⇒ (4.6)

Past

( ∨t∈Incomings

ObjidoTransitionidt , 1

)Similarly, the necessary condition to exit from a state is that one of the outgoing transi-tions holds at the current time instant, namely:

ObjidoStateidsExit⇒ (4.7)∨t∈Outgoings

ObjidoTransitionidt

41


When object o enters in state s predicate ObjidoStateids holds. If we entered the statebut we do not exited yet, we must remain in the state, which is easily formalized by thefollowing axioms:

ObjidoStateids ∧ ¬ObjidoStateidsExit (4.8)⇒ Futr(ObjidoStateids , 1)

ObjidoStateids ∧ObjidoStateidsExit (4.9)⇒ Futr(¬ObjidoStateids , 1)

Similarly, if object o is not inside the state s, unless the enter predicate holds in the nexttime instant, it will remain out of the state, which is easily formalized by the followingaxioms:

¬ObjidoStateids ∧ Futr(ObjidoStateidsEnter, 1) (4.10)⇒ Futr(ObjidoStateids , 1)

¬ObjidoStateids ∧ Futr(¬ObjidoStateidsEnter, 1) (4.11)⇒ Futr(¬ObjidoStateids , 1)

Given a transition t connecting a source state s with a destination state d, the sufficientcondition to exit from s and entering in d is that t occurs, namely:

ObjidoTransitionidt ⇒ (4.12)ObjidoStateidsExit ∧ Futr(ObjidoStateiddEnter, 1)

This axiom is not generated if t is a self-recursive transition because this is in contrastwith the definition of the enter/exit predicates given in (4.8-4.11)

If the trigger associated to t is true, then one of the outgoing transition holds. Thismeans that the trigger is not a sufficient condition for t because multiple transitions maybe ready to start at the same time instant and only one of them will be taken.

ObjidoTriggeridt ⇒ (4.13)∨k∈Outgoings

ObjidoTransitionidk

A necessary condition for the transiton is that we are in the source state, the correspond-ing guard and trigger hold.

ObjidoTransitionidt ⇒ (4.14)ObjidoStateids ∧ObjidoGuardidt ∧ObjidoTriggeridt

If the transition has not any guard or trigger the necessary condition stated in the pre-vious axiom is simplified so that the necessary condition is that we only have to be insource state of the transition.

The trigger is defined by the event associated to it. Given e the event associatedto the trigger of the transition t, the trigger predicate holds iff we are in source stateand the trigger occurs. Similarly the guard predicate holds iff the associated booleanformulae holds and we are in the source state.

42

4.4. Interation Overview Diagrams

If the transition has an action associated to it, then if the transition occurs now andwe are in the source state, the action must hold, which is formalized by the followingaxiom:

ObjidoStateids∧ObjidoTransitionidt (4.15)⇒ ObjidoActionidt

Finally, if the state has some invariant, it holds when we are inside the state, which isformalized by the following axiom:

ObjidoStateids ⇒ ObjidoInvariantids (4.16)

One thing to notice about the previous axiomatization is that we assume that one instantof time passes every time a transition is taken, so we do not allow multiple transitionsto occur at the same time instant, as some semantics of State Diagrams/Statechartsdo [26].

4.4 Interation Overview Diagrams

For a detailed description of the operators supported by MADES Interaction OverviewDiagrams please refer to Section 3.5.

4.4.1 Predicates

The following elements of the IOD are directly translated in temporal logic (see Ta-ble 4.4). For every SD x included in the IOD y, predicates IODidySDidxStart andIODidySDidxEnd are declared; these predicates are true at the beginning and at theend of the diagram execution, respectively. In addition, the IODidySDidxStop predi-cate is declared, which hold when the sequence diagram is interrupted. MADES UMLmodels may include a number of IODs. For every IOD x in the MADES design model,predicates IODidxStart and IODidxEnd are declared, representing the starting andthe ending of the computation associated with the diagram. For every decision nodex found in an interaction overview diagram, k predicates are generated, where k isthe number of the outgoing paths of the decision operator. Thus, for every outgoingpath j, predicate DecidxPathj is declared representing the fact that j has been taken.Also, a guard may be associated to this path, and the corresponding predicate will beDecidxGuardj . Fork nodes with guards are translated in a similar fashion. For everyjoin node x found in an interaction overview diagram, predicate JoinidxEnd is gen-erated. This predicate holds when all the incoming paths to the join terminate theirexecutions. For every accept event action x predicate AEActionidx is created. Finally,for every send signal action x predicate SSActionidx is created.

43



SD IODidySDidx

Start,IODidySDidx

Stop,IODidy

SDidxEnd

Initial Node IODidxStart

Final Node IODidxEnd

Decision DecidxPathj , Decidx

Guardj

Fork ForkidxPathj , Forkidx

Guardj

Join JoinidxEnd

Accept Event Action AEActionidx

Send Signal Action SSActionidx

Table 4.4: TRIO predicates associated to the IOD

4.4.2 Axioms

Given a SD x inside an IOD y with exactly one input node i we must constrain thepredicate IODidySDidxStart to define its activation condition. If i is a SD, then x isready to start when i ends. This property is formalized by the following TRIO axiom:

IODidySDidxStart⇔ Past(IODidySDidiEnd, 1

)(4.17)

If i is not a SD, the activation condition of x depends on the nature of i, and it is definedrecursively. More precisely, given a SD node x with input node Ni, the activationcondition ACx(Ni) of x is defined as follows. If Ni is a merge node, and Nh1 ...Nhk

areits input nodes, then:

ACx(Ni) = ACi(Nh1)... ∨ ACi(Nhk). (4.18)

If Ni is a fork node, Nh is its input node, and y is the path connecting fork node Ni

with x, then:

ACx(Ni) = ACi(Nh) ∧ ForkidiPathy (4.19)

IfNi is a decision node, Nh is its input node, and y is the path connecting decision nodeNi with x then:

ACx(Ni) = ACi(Nh) ∧DecidxPathy (4.20)

The decision node’s paths are mutually exclusive, thus ∀i 6= j DecidxPathi ⇒ ¬DecidxPathj .The base case of the recursive definition of ACx(Ni) occurs when Ni is a sequence di-agram SD i, an accept event action a, the initial node of the IOD y, or a join nodej. In these cases ACx(Ni) is equal, respectively, to IODidySDidiEnd, AEActionida ,IODidyStart, and JoinidjEnd.The same recursive algorithm is applied for join nodes and send signal actions. If Ni

is a join node, and Nh1 ...Nhkare its input nodes, then ACx(Ni) is equal to a predicate,

JoinidiEnd, which holds in the time instant in which the last of the input nodes ofNi toterminate its execution ends. The axiom associated to predicate JoiniEnd is therefore

44


the following:

JoiniEnd⇔∨l∈{1..k}

ACi(Nhl) ∧

∀j(j 6= l⇒ Since(¬JoiniEnd,ACi(Nhj))) (4.21)

Given a send signal action x with input node Ni, the action is executed one time unitafter Ni terminates its execution. Namely, the following axiom holds: SSActionidx ⇔Past(ACx(Ni), 1). Given an accept event action x with input node Ni associated toa shared event e, the predicate AEActionidx holds iff the event holds and since theactivation condition was true, no other accept event action occurred in the meanwhile.Therefore the following holds:

AEActionidx ⇔ e ∧ Since(¬AEActionidx , ACx(Ni)) (4.22)

For every SD x enclosed in at least one IR, let us define SDxInterrupts as the set ofinterrupts associated to the IRs enclosing SD x. More precisely, if SD x belongs to anIR associated to the interrupt event e, then e is added to SDxInterrupts. Given a SDx inside IOD y the following semantics is given to the predicate IODidySDidxStop:

IODidySDidxStop⇔

IODidyEnd∨

e∈SDxInterrupts

e (4.23)

4.5 Sequence Diagrams

For a detailed description of the operators supported by MADES Sequence Diagramsplease refer to Section 3.4.

4.5.1 Predicates

The following elements of the SDs are directly translated in temporal logic (see Table4.5). Predicates SDidxStart, SDidxEnd, and SDidxStop are true at the beginning andat the end of the diagram execution, respectively. We will discuss how these predicatesare related to the other views (IODs, StDs) in Section 4.7. In addition to these predicatesSDidx is defined, which holds when the system is inside the SD x.

For every message x found in a Sequence Diagram, two predicates are declared:MsgidxStart and MsgidxEnd. The predicates hold at the beginning and at the endof the message. Note that these two time instants may not coincide – for instance, incase of delayed messages. For every execution occurrence x found in a SD predicatesExOccidxStart ,ExOccidxEnd, and ExOccidx , which hold respectively at the begin-ning, at the end, and during the execution occurrence. For every sequence diagramvariable y found in a SD x, a TRIO arithmetic variable SDidxParidy is declared. Also,for every assignment x found in a SD a TRIO temporal logic predicate Assignmentidxis declared which holds when the assignment is performed in the diagram. Finally, forevery time constraint x found in a SD the predicate Constraintidx is declared, whichholds from the beginning till the end of the execution of the SD.

45



Sequence Diagram SDidxStart

SDidxEnd,SDidx

Stop

SDidx

Message MsgidxStart, MsgidxEnd

ExOccurrence ExOccidxStart,ExOccidx

End

ExOccidx

Parameter SDidxParidy

Assignment Assignmentidx

Time Constraint Constraintidx

Table 4.5: TRIO predicates associated to the Sequence Diagram

4.5.2 Axioms

A SD x is defined as a set of lifelines. Every lifeline is an ordered lists of events.Events on the lifeline could be messages start/end, execution occurrence start/end andassignments. Given a SD x let us define Lifelinesx as the set of lifelines belonging tox. Also, given a lifeline l ∈ Lifelinesx let us define as LifelineEvl the set of eventsbelonging to the lifeline. For every ordered pair of events i, j ∈ LifelineEvl, if i holdsat some instant, then j will follow in the future if the diagram is not stopped. This isformalized by the following axiom:

Evi ⇒ (4.24)Until(¬Evi ∧ ¬Evj, SDxStop)

∨Until(¬Evi ∧ ¬SDxStop, Evj)

whereEvi is the predicate assigned to i andEvj is the predicate assigned to j. Also, if jholds at some instant, then i was true in the past and no stop occured in the meanwhile.This is formalized by the following axiom:

Evj ⇒ (4.25)Since(¬Evj ∧ SDxStop, Evi)

The beginning and the end of a SD x are formalized as follow. Given a SD x, let usdefine FirstEventsx as the set of events starting the different lifelines in Lifelinesx.For every event s ∈ FirstEventsx axioms 6.11 and 6.12 are created where Evi =SDidxStart and Evj = s. To be precise, the start event of the sequence diagram mayoccur at the same time instant of the first message. For this reason axiom 6.11 will beslightly different in this case to admit this behavior. Also, let us define {Evh..Evk} =LastEventsx as the set of events terminating the different lifelines in Lifelinesx.Then, SD x ends when the last of the events in LastEventsidx occurs. This is formal-

46


ized by the following axiom:

SDidxEnd⇔ (4.26)Evh ∧ ∀i 6= h Since(¬SDidxEnd,Evi)

...

∨Evk ∧ ∀i 6= k Since(¬SDidxEnd,Evi)

The system is inside SD x if and only if the start event of the SD holds now, or sincethe last start event the diagram neither ended or has been stopper. Thus, the followingaxiom holds:

SDidx ⇔ (4.27)SDidxStart ∨Since(¬SDidxStop ∧ ¬SDidxEnd, SDidxStart)

The different lifelines are connected through messages. Given a message x, if it isdrawn horizontally then the start/end events must occur at the same time instant, namelyMsgidxStart ⇔ MsgidxEnd. If not, then there could be a delay. In this case axioms6.11 and 6.12 are used where Evi = MsgidxStart and Evj = MsgidxEnd. Twokind of messages are possible: synchronous and asynchronous. With an asynchronousmessage, the sender does not wait for the receiver to finish processing the message, itcontinues immediately. No additional axiom is required in this case. A synchronousmessage is used when the sender waits until the receiver has finished processing themessage, only then does the caller continue. For this reasons it is not possible to createsynchronous messages without the corresponding execution occurrences on both sides.Given i, j the execution occurrences of the sender and receiver respectively, the endof j must occur before the end of i. This is formalized with axioms 6.11 and 6.12where Evi = ExOccidjEnd and Evj = ExOccidiEnd. For every execution occur-rence i, predicate ExOccidi holds between ExOccidiStart and ExOccidiEnd. This isformalized by the following axiom:

ExOccidi ⇔ (4.28)ExOccidiStart∨Since(¬SDxStop ∧ ¬ExOccidiEnd,ExOccidiStart)

Objects which are inside an execution occurrence must be considered busy. We definethe set of execution occurrences belonging to object o as ExOccSeto. For each pair ofexecution occurrences i, j ∈ ExOccSeto the following formula holds:

ExOccidi ⇒ ¬ExOccidj (4.29)

For every assignment a of the kind v = expression we have that Assignmentida ⇒(v = expression). Notice that even if graphically it is represented as a recursivemessage, the semantics is that the assignment is istantaneous - it only takes one timeunit. To implement this kind of semantics, which includes arithmetic constraints overtime, we use the features offered by Satisfiability Modulo Theories (SMT) solvers likeZ3 [56]; these solvers, which are able to handle decidable fragments of first order logic

47


such as linear integer arithmetic, are at the core of the prototype tool used. The samesemantics used for assignments in recursive messages is applied for parameters in op-eration invocations. More precisely, given an operation with a formal parameter par,a message m instantiating this operation, and the actual parameter v issued as an ar-gument to m, the assignment is made when the message end event occurs, thus thefollowing holds; MsgidmEnd ⇒ (v = par). For every SD parameter k, we imposethe value of the parameter to remain constant from the beginning of the diagram till theend. This is formalized by the following axiom:

SDxStart⇒ (4.30)Until(k = Past(k, 1) , SDxEnd)

where k must be substituted with the corresponding TRIO arithmetic variable SDidxParidy .Given a time constraint t associated to a SD x, we have that the predicate associatedto the constraint holds when we are inside the SD. Thus the following axiom holds;SDidx ⇒ Constraintidt .

4.6 Time Constraints

The syntaxt of time constraints has been presented in Section 3.8. In the followingwe are going to present the associated semantics in terms of metric temporal logicpredicates. Given a time constraint t of the form @ev2 − @ev1 ∼ K the intuitivemeaning is that @ev2 is holds now, that @ev1 holds in the past, and that between themthere is no other @ev2. Finally, their actual correlations depends on ∼. The semanticsof time constraints slightly changes depending if consider SDs or StDs. Intuitivelythis is because time constraints associated to SDs must hold for the entire duration ofthe diagram, while time constraints associated to transitions in StDs refers to only onetime instant, the one in which the transition occurs. We will only show the axiomsfor {<=,=, >=}. The remaining cases ({<, ! =, >}) can be easily derived from theprevious ones. Given a StD and a time constraint t of the form @ev2−@ev1 ∼ K wehave the following cases:

If ∼ is equal to = and ev2 holds now, then K time units in the past ev1 must hold:

ev2 ∧ Since(¬ev2, ev1)⇒ Past(ev1, K) (4.31)

This axiom slightly changes if instead of @ev2 the user decides to simply refers to thecurrent time instant. In this case the expression becomes @now − @ev1 = K and itis translated as ¬Past(ev1, K). To avoid encumbering this presentation, we will onlyshow some examples of how the @now operator is translated.If ∼ is equal to <= and ev2 holds now, then within K time units in the past ev1 musthold:

ev2 ∧ Since(¬ev2, ev1)⇒WithinP(ev1, K) (4.32)

If ∼ is equal to >= and ev2 holds now, then for more than K time units in the past ev1cannot be true:

ev2 ∧ Since(¬ev2, ev1)⇒ Lasted(¬ev1, K) (4.33)

48

4.7. Shared Events

For SDs we should also take into consideration the fact that we cannot guarantee thatbetween ev1 and ev2 the diagram has been stopped. If ∼ equal to ==, then if ev2occurs now and we have been inside SD x for K time instants, then K time units in thepast ev1 should be true.

ev2 ∧ Since(SDidx ∧ ¬ev2, ev1)⇒ Past(ev1, K) (4.34)

If ∼ is equal to <=, then if ev2 occurs now and we have been inside SD x for K timeinstants, then within K time units in the past ev1 should be true.

ev2 ∧ Since(SDidx ∧ ¬ev2, ev1)⇒WithinP(ev1, K) (4.35)

In case we are using the @now operator the time constraint becomes @now−@ev1 <=K, which leads to the following axiom:

Since(SDidx , ev1)⇒WithinP(ev1, K) (4.36)

If ∼ is equal to >=, then if ev2 occurs now and we have been inside SD x for K timeinstants, then for those same K time instans ev1 should be false.

ev2 ∧ Since(SDidx ∧ ¬ev2, ev1)⇒ Lasted(¬ev1, K) (4.37)

4.7 Shared Events

Different diagrams may share a common set of events. Shared events allow the differentviews to communicate with each other. The MADES approach makes this communica-tion straightforward thanks to its underlying temporal logic formalism. Shared eventsinclude:

• Operation invocations.

• Sequence diagrams start/end/stop events.

• IODs start/end events

• Clock ticks.

• Signals.

This section is going to present how the temporal logic formalism handles the sharedevents, and how it is possible to extend the current MADES UML diagram set withoutmodifying the semantics presented in the previous sections.

4.7.1 Operation Invocations

Operation invocations are shared between the SDs and the StDs and the communica-tion between them can be achieved in two complementary ways: SDs and StDs cansend operation invocations using messages and actions respectively. On the other handSDs and StDs can listen to operation invocations using found messages and triggersrespectively. In the model of Figure 4.2 the SD uses a found message to wait for theopA operation invocation. The operation invocation is sent by the StD while makingthe transition from State0 to State1 which occurs non-deterministically. The StD then

49


(a) (b)

Figure 4.2: The transition from State0 to State1 of Figure 4.3(b) enables the opA found message ofFigure 4.2(a). The opB message of Figure 4.2(a) triggers the transition from State1 to State0 of

4.3(b)

uses a trigger to waiting the opB operation invocation which is sent by the message inthe SD.

Temporal logic offers a simple and straightforward way to bring all these informa-tions together, by sharing the operation predicate defined in the CD (see Section 4.2)between the SDs axiomatization and the StDs axiomatization. Given an operation xbelonging to an object y let us define ReasonsOpxObjy as the set of events that maycause the specified operation. This set is constitued by the messages in the SDs thatinstantiate this operation, namely MessagesOpxObjy, and the set of operation callsspecified in the actions of the StDs, namely OperationCallOpxObjy. According tothis definition we have that:

ReasonsOpxObjy = MessagesOpxObjy ∪OperationCallOpxObjy (4.38)

The predicate definining the operation holds if and only if any of the predicates r be-longing to the set ReasonsOpxObjy holds.

ObjidxOPidy ⇔∨

r∈ReasonsOpxObjy

r (4.39)

Triggers in the StDs and found messages in the SDs can then be linked to operationinvocations. Let us define Triggersx as the set of triggers associated to the operationx. If the operation holds now, then all the triggers are fired. Thus for every trigger tbelonging to Triggersx we have that :

Triggeridt ⇔ ObjidxOPidy (4.40)

This is consistent with the intuitive semantics that a trigger linked to an operation oc-curs if any of the other view invoke the specified operation, indipendently if this is a

50

4.7. Shared Events

message, or an operation call coming from another StD. This kind of axiomatizationalso makes easy to add new diagram types that refers to operations in the class diagram.The only thing to do is to add the predicate defined in the new diagram to the alreadyexisting reasons set of the operation. The same pattern holds for found messages inthe SDs. Let us define FoundMessagesx as the set of found messages linked to thatoperation. If the operation holds now, then all the found messages can proceed. Thusfor every found message m belonging to FoundMessagesx we have that :

MessageidmStart⇔ ObjidxOPidy (4.41)

4.7.2 Sequence Diagrams Events

Given a SD x its start event is shared with IODs, and StDs. IODs can invoke SDs bysimply linking them to activity nodes. StDs can invoke SDs by using the designatedsyntaxt in the action field of the transitions (see Section 3.7). On the other hand theIODs can listen for SDs invocations by using accept event actions. StDs can listen forSDs invocations by using the designated syntaxt in the trigger field of the transitions.

Given a SD x let us define ReasonsSDxStart as the set of events that may activatethe SD. This set is constituted by the SD start events specified in the IODs (see Table4.4), namely IODs_SDxInvocations, and by the SDs invocation specified in the ac-tions of the transitions of the StDs, namely StDs_SDxInvocations. According to thisdefinition we have that:

ReasonSDxStart = IODs_SDxInvocations ∪ StDs_SDxInvocations (4.42)

The predicate definining the start of the SD holds if and only if any of the predicates rbelonging to the set ReasonsSDx holds.

SDxStart⇔∨

r∈ReasonsSDx

r (4.43)

Triggers in the StDs and accept event actions in the IODs can then be linked to the SDstart. Let us define Triggersx as the set of triggers associated to SD x. If SD x startsnow, then all the triggers are fired. Thus for every trigger t belonging to Triggersx wehave that :

Triggeridt ⇔ SDxStart (4.44)

The same pattern holds for accept event actions in the IODs. Let us define IODsAcceptEventsx as the set of accept event actions linked to SD x. If SD x starts now,then all the accept event actions can proceed. Thus for every accept event action abelonging to IODsAccept Eventsx we have that :

AEActionida ⇔ SDxStart (4.45)

The way SD’s stop and end events work is the same as the one presented for the startevent. Figure 4.3 shows an example of communication between one IOD and one StDthrough SDs’ shared events. When the system starts both the StD and the IOD are intheir initial state. When the IOD invoke the execution of sd_A it has 5 time instantsbefore the transition of the StD occurs. If sd_A terminates before 5 time units the IOD

51


(a)

(b)

Figure 4.3: An example of communication between one IOD and one StD using SD’s shared events. TheStD and the IOD starts concurrently. After 5 time units the StD stops the execution of the sd_A SD.

reaches the end of the flow. If not, sd_A is stopped, the accept event action occurs, andsd_B is executed.

To summarize there are different syntactic constructs to share the SD’s start/end/stopevents. Given a StD with a transition t associated to an action a, it is possible to assignto a one of the SD start/stop/end events. When a is performed, the corresponding sharedevent holds, which may result in starting, stopping, or ending the SD. We may also wantto assign one of the same events to the trigger of t which then results in performing thetransition when the corresponding event holds. The IODs share the SD’s start/end/stopevents with all the included SDs. Given a SD x enclosed in an IOD, its start event holdswhen the incoming control flow is taken and the end event holds when the outgoingcontrol flow is taken. The stop event holds when the IOD reaches the final node, orthe SD is enclosed in an interruptible region and the interrupting signal holds. Finallyaccept event actions can be used to refer to the SDs’ events directly.

52

4.8. Extending the Semantics

4.7.3 Clocks and Signals

In MADES, clock types are defined in the CDs and their tick event can be used insidetemporal constraints of the SDs and the StDs, as well as in transitions (as triggers,guards or actions) in the StDs. Clock tick events are shared between the different viewswhich can listen to them in order to synchronize on a periodic behavior. Using the clocktick as a transition trigger is a common design pattern that lets specific objects changestate or perform an action synchronised with a particular clock. Figure 4.4 shows twoequivalent ways of specifying a periodic Sequence Diagram. The first one uses a StDwith a clock tick event in the trigger field. The second one uses the accept event actionoperator of the IOD together with the clock tick event.

(a) (b)

Figure 4.4: Two equivalent models defining a periodic Sequence Diagram. The StD has aself-transition triggered by a clock event whose action is the start event of the SD. The IOD is using

an accept signal action - assigned to a clock tick event - followed by the SD.

Signals, too, are defined in the CDs. They can be used in the IODs [60] as well as intransitions of a state diagram (as triggers, guards, or actions). Signals can be used asa simple mean to enable the communication between the different views; for examplea signal sent from a state diagram can be accepted by an accept signal action of aninteraction overview diagram. Given a signal s let us define Reasonss as the set ofpredicates generated by the StDs actions and the IODs send signal actions associated tos. If Reasonss is empty, no axiom is generated and the signal may occur at any pointin time. If Reasonss is not empty then the following axiom holds:

Signalids ⇔∨

r∈Reasonss

r (4.46)

4.8 Extending the Semantics

The MADES UML semantics can be easily extended with new diagrams. Each diagramis formalized separately by defining the predicates representing it as we did in Sections4.2- 4.5. Once the definition has been done, we can start thinking about what are theelements which are shared between the different views. We can do that by refining the

53


meta-model of the shared elements presented in Section 3.6. Given these premises themetric temporal logic approach provides an easy mechanism to synchronize the differ-ent events. In particular Section 4.7 suggests that there is a precise relation betweenthe different predicates belonging to the MADES UML views. A relation between twopredicates belonging to two diagram types Dx and Dy is a 3-tuple < px, py, t > wherepx and py are the predicates belonging toDx andDy respectively, while t ∈ read, writeis the type of the relation between them. We say that a predicate px reads from predi-cate py if px occurs if and only if py occurs, which is formalized by the following tuple:< px, py, read >. We say that a predicate px has a write relation with py if px is one ofthe reasons because of which py may occurr.

Figure 4.5 and 4.6 show the read and write relations between the different viewrespectively: the direction of the arrow identify the source and the target of the relation;dashed arrows identify read relations while solid arrows identify write relations; thelabel identify the type of predicates which are read or written. Read relations are easyto formalize. The source and the target predicate are connected by an if and only ifaxiom, thus px ⇔ py. In addition to that px cannot be implied by any other formulaeof the type f ⇒ p where f is a formulae belonging to the semantics of Dx. Writerelations are built as follow: the target predicate py must collect all the predicates thathave a write relation directed to him. This constitutes the Reasonspy set. Intuitivelythe Reasonspy set contains all the predicates that may cause the py predicate to be true.Once the set has been constructed the following holds, py ⇒

∨r∈Reasonspy

r.To add a new diagram Dz to MADES UML we must first define the predicates

owned by Dz that will be shared with the other views. Then we must define all therelations between the already existing predicates and the new one, using the simplemodel explained previously. Finally we must modify the translation mechanism suchthat the axioms defined previously are generated accordingly to the relations definedbetween the different views. This is an easy and powerful mechanism that does notrequire to change the semantics which is already in place in order to support additionalviews to the MADES framework.

54

4.9. Analyze partial models

Figure 4.5: Read relationship between the different views. For each arrow, the diagram at the tail readsthe predicates shared by the diagram at the head. The name of the shared predicates is shown on the

arrow itself.

Figure 4.6: Write relationship between the different views. For each arrow, the diagram at the tailwrites the predicates shared by the diagram at the head. The name of the shared predicates is shown

on the arrow itself.

4.9 Analyze partial models

The metric temporal logic approach presented in this thesis provides the possibility toverify partial models. This is obtained by providing the means to add/remove behav-ioral views seamlessy by simply avoiding their translation. Using this mechanism boththe verification effort and the complexity of the verification procedure is reduced to the

55


number of diagrams taken in consideration.Given a target property p the user can select an interesting subset of the UML model

against which the property must be verified. After the first iteration two results are pos-sible. If the property holds, the user may want to include a greater number of diagramsin order to verify that the additonal views do not interfere with the verification result.If the property does not hold, the user may first inspect only the diagrams taken in con-sideration to see if they are adequate to satisfy p. If there is an error in the consideredsubset of the model the user can fix the error and start again. If no error is found, eitherthe number of diagrams is not enough to satisfy p, i.e. we must define additional behav-ior to satisfy the property, or the considered diagrams contradict the property, thereforewe must consider to remove them from the model, or change the specification. Fol-lowing this approach drastically simplify the verification effort and provides a suitablemeans to inspect the models incrementally, gaining confidenze about their behavior,and prove properties accordingly.

The transformation mechanism presented in Sections 4.2- 4.5 does not make anyassumption about the presence/absence of the different behavioral views. The onlystructure which must be satisfied is the metamodel presented in Figure 3.1. Therefore aCD must always be defined, but on top of this the user can add/remove as many behav-ioral diagrams as he wants. Once a new diagram is added the connections defined bythe shared events in the system (see Section 4.7) are updated, to consider the behaviorsintroduced by the additional diagrams.

To exemplify what has been explained previously let’s consider the model shown inFigures 4.7-4.9. In the CD the UML engineer defines two classes - Class1 and Class2 -and one ClockType named SysClock. For each of these entities a corresponding instanti-ation is defined, namely c1,c2 and sysClock. The model is still in the exploratory phase,therefore a comment is added to notify the reader that op1() must be synchronized withthe clock sysClock. The StD of Figure 4.8 defines the behaviors of the objects belong-ing to Class1. The StD simply changes state every time the op1() operation is invokedmoving from s1 to s2 and viceversa. The TPD of Figure 4.9 shows the property to beverified. The property states that whenever we are in s1 and op1() is invoked, then ex-actly 5 time instants in the future, we will have another occurrence of op1(). The sameproperty can be expressed in plain TRIO with the following formulae:

Objidc1Stateids1 ∧Objidc1OPidop1 → Futr(Objidc1OPidop1 , 5) (4.47)

The property does not hold for the system and a counterexample is shown to the user. 4

Obviously the model was not ready to satisfy the desired property because op1() is notyet synchronized with the sysClock. The user therefore adds the SD shown in Figure4.10 to the behaviors of the system. The SD shows the detail of the interaction betweenc1 and c2 and assigns to the message instantiating op1() the timed event stereotype.The timed event stereotype defines an association between the message and the sycClocdefined in the CD. As a result the message will occur every 5 time instants.

According to what has been presented in Section 4.7, when the new SD is addedto the model, in addition to the SD’s axiomatization, the following axiom linking thedifferent views is generated:

Msgidop1m ⇔ Objidc1OPidop1 (4.48)4see Chapter 6 to see how counterexamples looks like and how they are rendered back to the user).

56

4.9. Analyze partial models

where idop1m is the UML id of the message instantiating op1(). Notice that this is donewithout modifying the rest of the semantics associated to the different behavioral views.The rest of the semantics is left unchanged and the axioms are still generated accordingto the translation rules defined in Sections 4.2 -4.5.

The user can now run again the verification procedure; this time the desired propertyholds for the system. The provided example has shown how it is possible to build andverify the MADES UML models incrementally, by first verifying the property only ona subset of the model and by including additional behaviors incrementally.

Figure 4.7: The CD of the model for the partial verification example.

Figure 4.8: The StD of the model for the partial verification example.

57


Figure 4.9: The TPD of the model for the partial verification example.

Figure 4.10: The SD of the model for the partial verification example.

58

CHAPTER5Corretto: The MADES UML Verification Tool

Corretto is the MADES UML prototype verification tool. It is built on top of a setof interoperable tools whose goal is to allow UML model designers to carry out theformal verification of their models in a user-friendly manner. Providing a user-friendlyUML verification tool is far from trivial. The verification tool should hide the manyunnecessary details about the creation of the formal representation and the enactmentof the verification phase. The tool must provide to the user the means to understand howthe model behaves according to its semantics; specify the property of interest withoutleaving the UML environment; and understand the verification results produced by theunderlying verification tool.

In this context the formal verification of UML models can divided in four phaseswhich are summarized in Figure 5.1(a):

• Modeling. During this phase the user builds the model to be verified and specifiesthe property of interest using some high-level notation.

• Transformation. During the transformation phase the high-level model is trans-lated - together with the property to be verified - into its formal representation.The formal model is hidden to the user.

• Verification. During the verification phase the required property is verified againstthe formal model. A suitable formal verification tool is required. The tool is op-erated automatically.

• Traceability. During the traceability phase the results produced by the verifica-tion tool are inspected using a high-level notation. The notation must be able tobring the verification results back to the modelling level where the user is working.

59

Chapter 5. Corretto: The MADES UML Verification Tool

After the traceability phase the user is therefore able to understand the verification re-sults and to modify the high-level model accordingly. Corretto supports all the differ-ent verification phases presented previously using both well established and prototypetools:

• Papyrus Modeling Tool. Papyrus provides an integrated and user-consumableenvironment for editing UML and related modeling languages such as SysMLand MARTE using the Eclipse Modeling Framework.

• UML2ZOT Trasformation Tool. UML2ZOT is a Java component which takesthe MADES UML model produced by Papyrus in XMI format and generates itscorresponding TRIO metric temporal logic semantics. The process is automaticand the user will not be involved.

• Zot Verification Tool. Zot is a bounded satisfiability checker which encodessatisfiability (and validity) problems for discrete-time TRIO formulae as propo-sitional satisfiability (SAT) problems, which are then checked with off-the-shelfSAT solvers. If the property specified by the user does not hold for the system,Zot returns a textual counterexample violating the property.

• Traceability Tool. The Traceability Tool reads the results produced by Zot. Ifthe property specified by the user holds for the model, the user is just notifiedthat the model satisfies the property. If the property does not hold, the textualcounterexample produced by Zot is visualized inside Papyrus. By clicking onone of the elements of the counterexample, the corresponding UML element ishighlighted.

Corretto integrates all these different tools into a unique, usable solution. It is dis-tributed by means of an Eclipse plugin. After the installation, Papyrus is enriched withall the MADES UML stereotypes to build the model and to specify the properties ofinterest (TPDs). Once the user decides to run the formal verification the UML modeland the property to be verified are exported in XMI. The UML model is thereforeread by the UML2ZOT transformation tool which produces the corresponding TRIOmetric temporal logic semantics. UML2ZOT is built on top of the Eclipse UML2 li-brary, which is an EMF-based implementation of the UML 2.x OMG metamodel forthe Eclipse platform. By exploiting the EMF-based representation of the UML modelbuilt by the user, UML2ZOT produces the TRIO model in LISP format which is pre-sented as input to the Zot model checker. After the verification procedure of Zot isfinished two cases are possible: If the property specified by the user holds, then he isjust notified of the result. If the property does not hold, a counterexample is returned.Counterexamples in Zot are simple text traces representing an execution of the systemthat violates the property. The traceability tool displays the trace inside the Papyrusenvironment by enriching the textual elements of the trace with hyperlinks to the cor-responding UML elements, providing a suitable means for the user to understand theresults. Navigating the trace resumes closely the debugging paradigm of well knowprogramming languages, an environment that should be well known to the user.

Corretto has been developed in the context of the MADES project 1. During therequirements phase the partners defined the expected functionalities of the tool while in


60

(a)

(b)

Figure 5.1: The Corretto verification workflow and tools. Figure 5.1(a) shows the abstract workflow,while Figure 5.1(b) shows the concrete tools we use.

the validation phase they provided some useful feedback on its usability. The first ver-sion of Corretto was developed as a tool-chain. The modeling phase was supportedby the Modelio CASE tool 2 while the analysis and the traceability phase were devel-oped as an Eclipse plugin. The feedback from the partners suggested the developmentof the current version of the tool presented in this thesis were all the different phasesare integrated as an Eclipse plugin for the Papyrus modeling tool.

The remaining of this chapter is organized as follows: Section 5.1 presents the Pa-pyrus UML modelling tool; Section 5.2 presents the Zot verification tool. Section 5.3presents the UML2ZOT trasformation tool; Finally Section 5.4 presents the traceabilitytool.

2http://www.modeliosoft.com/

61


5.1 Papyrus Modeling Tool

The Eclipse Modeling Project3 focuses on the evolution and promotion of model-baseddevelopment technologies within the Eclipse community by providing a unified set ofmodeling frameworks, tooling, and standards implementations. In this context Papyrus4 provides an integrated and user-consumable environment for editing UML and relatedmodeling languages such as SysML and MARTE. Papyrus also offers a very advancedsupport of UML profiles that enables users to define editors for DSLs based on theUML 2 standard. The main feature of Papyrus regarding this latter point is a set ofvery powerful customization mechanisms which can be leveraged to create user-definedPapyrus perspectives and give it the same look and feel as a "pure" DSL editor.

We decided to built on top of Papyrus for three reasons: first, it is an open-sourceproject whose development is active and supported by two companies (CEA LIST 5,Atos Integration 6). Second, thanks to the plugin extension mechanism of the Eclipsemodeling environment it’s easy to extend the functionalities provided by the IDE tosupport our own verification activities. Third, Papyrus is compatible with the other soft-ware products developed in the Eclipse Modeling Project. In particular we exploitedthe interoperability with the Eclipse UML2 library7 which is an EMF-based implemen-tation of the UML 2.x OMG metamodel for the Eclipse platform. The advantages ofthis choice will be explained in detail in Section 5.3 where the transformation tool ispresented.

Using the standard Papyrus perspective the Eclipse IDE window is divided in fourareas. On the top left the Project Explorer shows the projects in the eclipse workspace.On the bottom left the Model Explorer shows a tree based views of the UML modelbuilt by the user. While the new UML users tend to focus on the area dedicated to thediagram, the model explorer is actually the most important part of the interface sinceit shows the modeling artifact produced in the design session which will be read bythe other modeling tools, for example to automatically generate code from the model.On the right the Model Diagram area is shown where the user can build the graphicalrepresentation of its model using the standard UML diagrams supported by Papyrus.Finally, on the bottom right it is possible to modify the attributes of each modelingelement by either selecting the element on the diagram, or in the Model Explorer.

3http://www.eclipse.org/modeling/4http://www.eclipse.org/modeling/mdt/papyrus/5http://www-list.cea.fr/6http://atos.net/en-us/7http://www.eclipse.org/modeling/mdt/?project=uml2

62

5.2. Zot Verification Tool

Figure 5.2: A screenshot of the Papyrus modeling tool.

5.2 Zot Verification Tool

Zot is a Bounded Model/Satisfiability Checker that takes as input specifications writ-ten in a variety of temporal logics, and determines whether they are satisfiable or not.Through this basic mechanism, it can perform verification of user-defined propertiesfor the desired models.

Let us call S the temporal logic-based model of the system being designed. If S isfed to the Zot tool “as is", Zot will look for an execution trace of the modeled system; ifit does not find one (i.e., if the model is unsatisfiable), then the model is contradictory,hence it contains some flaw that make it unrealizable in practice. Now, suppose weintroduce a further temporal logic formula, P , which formalizes a user-defined propertyto be checked for the system. We can ask Zot to check whether the formula S ∧ ¬Pis satisfiable or not. If S ∧ ¬P is unsatisfiable, this means that there is no executiontrace that satisfies the system (i.e., S), that also satisfies ¬P , that is, that violates theproperty P . If no system trace violates property P , then the latter actually holds for thesystem. If, on the other hand, S ∧¬P is satisfiable, this means that there is at least onesystem trace that satisfies both S and ¬P ; that is, there is at least one execution traceof the system that violates the property, so the property does not hold for the system.If Zot determines that S ∧ ¬P is satisfiable, the tool produces an execution trace thatsatisfies it, i.e., a counterexample trace that is compatible with the system model butthat violates the property.

63


Zot performs the checks outlined previously by encoding temporal logic formulaeinto the input language of various solvers. In particular, Zot supports two kinds ofsolver: SAT solvers and SMT solvers. SAT solvers are capable of taking as inputformulae written in Propositional Logic, an determine whether they are satisfiable ornot. SMT solvers do the same (determine whether logic formulae are satisfiable or not),but they accept as input formulae written in logics (fragments of First-Order Logic) thatare richer than simple Propositional Logic. Over the last few years both SAT solversand SMT solvers have made great strides in terms of their performances (i.e., theirability to handle large-sized formulae in a reasonable amount of time), so that they havebecome viable engines for fully automated logic-based verification approaches such asthe one realized by Zot. In addition, most SAT/SMT solvers accept inputs written ina standard format (the DIMACS format for SAT solvers, and the SMT-LIB formal forSMT solvers), which makes them easily interchangeable. This is very useful, sincedifferent solvers implement different heuristics, and the “best" solver does not exist inabsolute terms, but only on a model-by-model case.

At its core, Zot encodes specifications written in a variety of temporal logics into theinput languages of SAT/SMT solvers. The tool supports several different encodings,which the user can choose by setting suitable options in the verification scripts. Zot isplugin-based: every encoding is realized by a plugin, and to select the encoding to beused the user selects the corresponding plugin. Figure 5.3 depicts the architecture of theZot tool. At the basis there are the third-party SAT and SMT solvers. Suitable modulesinterface Zot with the underlying solvers. Since the two kinds of solvers accept differentinputs and have different features, the interface modules are also different dependingon the solver: “sat-interface" and “zot2cnf" interface Zot with SAT solvers, while “smt-interface" does the same for SMT solvers.

The plugins implementing the different encodings define how temporal logic formu-lae are translated into the input languages of SAT/SMT solvers. The temporal logicssupported by Zot are depicted in the yellow boxes. They are:

• LTLB: propositional Linear Temporal Logic with both future and past operators,whose main temporal operators are “next" (X), “yesterday" (Y), “until" (U) and“since" (S).

• CLTLB: Constraint LTLB, which has the same temporal operators as LTLB, butwhich admits, as atomic elements, not only propositional letters, but also a limitedset of first-order constraints (e.g., “x < 3").

• TRIO: a very expressive linear temporal logic with a metric notion of time, whosebasic temporal operator is Dist, which is used to express metric constraints suchas “event e will occur at a distance of 3 time units from now".

Since both LTLB and CLTLB are subsets of the more expressive TRIO, to encodeTRIO formulae into the input languages of SAT/SMT solvers some plugins (e.g., eezotin Figure 5.3) first translate TRIO formulae into LTLB/CLTLB formulae, then theyencode the latters into the language of the corresponding solver. A through discussionof the logics supported by Zot is outside the scope of this document, we refer theinterested reader to the manual of the Zot tool 8. Zot plugins implement the primitives

8https://code.google.com/p/zot/

64


Figure 5.3: Overall architecture of Zot

that are used in Zot scripts to define the models to be analysed. Since the plugins areimplements as Lisp modules, the primitives are essentially Lisp declarations. Then, Zotscripts, which contain both the model to be analysed and the necessary commands toinvoke the desired solver, are a collection of Lisp statements. The available Zot pluginsare the following:

• eezot, which encodes LTLB formulae in the input language of SAT solvers; eezotalso translates TRIO formulae into LTLB ones, by transforming TRIO the metricoperator Dist into a series of next/yesterday operators (e.g., “event e will occur ata distance of 3 time units from now" becomes “the next instant of the next instantof the next instant event e occurs").

• meezot, which encodes TRIO formulae in the input language of SAT solvers;unlke eezot, meezot natively encodes the metric operator Dist, and it is usuallyfaster than eezot when the input model has many metric constraints.

• smteezot, which encodes LTLB formulae in the input language of SMT solvers;smteezot is akin to eezot (for example as far as the translation of the TRIO Distoperator is concerned), but it exploits the features of SMT solvers to produce amore compact encoding than eezot.

• smtmeezot, which encodes TRIO formulae in the input language of SMT solvers;

65


this plugin, which is the dual of meezot, requires an SMT solver that supports the“mod" operator (among those mentioned in Figure 5.3, only z3 has this feature).

• ae2zot, which encodes CLTLB formulae in the input language of SMT solvers;ae2zot differs from smteezot in that it supports arithmetic constraints over integernumbers such as “x < 3" (smteezot, like eezot, inly supports propositional LTLformulae). However, it is similar to smteezot in that it translates the TRIO Distoperator as a sequence of “next"/"yesterday" operators.

• ae2zot-r, which is similar to ae2zot, but it supports arithmetic constraints overreal numbers.

As shown in Figure 5.3, Zot includes also other plugins (bezot, mbezot, smtbezot)which however are not used in the context of the framework presented in this thesis.Determining which plugin (and which solver) to use is often not so clear-cut. Exper-iments carried out with the various plugins have shown that the fastest combinationplugin/solver changes from model to model. As a consequence, from a practical pointof view, after the designer has defined the MADES model to be analysed, he can: ei-ther (i) run different combinations plugin/solver on different computers (or on differentcores of the same computer) if these are available, then collect the result from the verifi-cation instance that terminates first; or (ii) try different combinations, determine whichone is the fastest, then stick with that for all subsequent analyses of the model.

5.2.1 The lamp example in Zot

In Section 4.1 we presented the lamp example in TRIO. The corresponding Zot syntaxtis the one provided in Listing 5.1. The system says that the light stays on if and only ifwe pushed the on button within 5 time instants in the past, and since that time we didnot push the off button. Moreover on and off cannot be pushed at the same time.

( a s d f : o p e r a t e ’ a s d f : load−op ’ meezot )( use−package : t r i o −u t i l s )( d e f v a r TSPACE 20)

( d e f v a r S (&&; ; D e f i n i t i o n o f LIGHT(<−>

(−P− LIGHT )(&&

( w i t h i n p (−P− ON) 5)( s i n c e ( ! ! (−P− OFF) ) (−P− ON) )

))

; ; CANNOT PUSH ON AND OFF TOGETHER( ! ! (&&

(−P− ON)(−P− OFF)

) )) ) ; ; END S

66


; ; PROPERTY( d e f v a r P ( ! ! ( l a s t s (−P− LIGHT ) 6) ) )

; ; RUN( d e f v a r t h e _ s y s t e m (&& ( Alw S ) ( ! ! ( Alw P ) ) ) )( meezot : z o t TSPACE (&& t h e _ s y s t e m ) )

Listing 5.1: A minimalistic lamp example for Zot

Given that system expressed in TRIO we want to prove (conjecture) that the light cannotstay on for more than 5 time instants. The Listing 5.2 shows the result of the verifica-tion. Our conjecture was actually false and Zot returns a counterexample in a textualformat. The counterexample is made of a number of time instants. Each time instantshows the predicate which holds at that time. So at time zero, predicate ON holds,and at time one predicates ON and LIGHT holds. As the counterexample shows oursystem does not prevent the user from pushing the on button when the light is on. Forthis reason the light can stays on for more then 5 time instants by simply pushing theon button again and again, which violates our property.

E v a l u a t i o n took :0 .104 s e c o n d s o f r e a l t ime0 .004000 s e c o n d s o f t o t a l run t ime ( 0 . 0 0 4 0 0 0 use r , 0 .000000 sys tem )3.85% CPU220 ,282 ,508 p r o c e s s o r c y c l e s27 ,520 b y t e s consed

−−−SAT−−−LOOPEX = TRUEI_LOOP = 9−−−−−− t ime 0 −−−−−−

ON−−−−−− t ime 1 −−−−−−

LIGHTON

−−−−−− t ime 2 −−−−−−LIGHT

−−−−−− t ime 3 −−−−−−LIGHT

−−−−−− t ime 4 −−−−−−LIGHT

−−−−−− t ime 5 −−−−−−LIGHT

−−−−−− t ime 6 −−−−−−LIGHT

−−−−−− t ime 7 −−−−−−OFF

−−−−−− t ime 8 −−−−−−−−−−−− t ime 9 −−−−−−∗∗LOOP∗∗

−−−−−− t ime 10 −−−−−−−−−−−− end −−−−−−E v a l u a t i o n took :

0 .184 s e c o n d s o f r e a l t ime0 .060004 s e c o n d s o f t o t a l run t ime ( 0 . 0 5 2 0 0 3 use r , 0 .008001 sys tem )

67


32.61% CPU391 ,483 ,012 p r o c e s s o r c y c l e s3 ,083 ,704 b y t e s consed

Listing 5.2: The Zot counterexample format

5.3 UML2ZOT Trasformation Tool

The UML2ZOT Trasformation Tool takes as input the XMI of the UML model andtranslates it into a LISP file containining the temporal logic axiomatization which canbe analyzed by Zot.

Model transformation is at the heart of the MDD therefore a number of maturetechnologies exists today. The Object Management Group defined a standard set oflanguages for model transformations called QVT (Query/View/Transformation) [58]that generated a number of different implementations [54]. Some well known exam-ples are the one of Jouault et al. [43] called ATL, and the one of Kolovos et al. [47]called ETL (Epsilon Transformation Language). All of them provides both a languageand a toolkit which are able to produce a set of target models from a set of sourcemodels. Three styles are generally recognized in model transformation languages [54]:declarative, imperative and hybrid, each one demonstrating particular advantages andshortcomings. Purely declarative transformation languages are generally considered tobe more suitable for scenarios where the source and target metamodels are similar toeach other in terms of structure and organization. However, such languages are chal-lenging to use in cases where significant sequential processing and complex mappingsare involved. By contrast, purely imperative transformation languages are capable ofaddressing a wider range of transformation scenarios. Nevertheless, they typically op-erate at a low level of abstraction which means that users need to manually addressissues such as tracing, resolving target elements with their source counterparts, andorchestrating the transformation execution. To address those shortcomings, hybrid lan-guages provide a declarative rule-based execution scheme as well as imperative featuresfor handling complex transformation scenarios. For the development of Corretto thedecision which has been taken was to implement the transformation procedure usinga plain Java component presented later in this section. The reasons for this were bothin the lack of expertise of the author with the state-of-the-art transformation languagesand to guarantee the interoperability with the other parts of the tool. Also since ourtransformation was relatively simple - it’s a one-to-one model transformation withoutthe need of any complex traceability requirements - we decided that keeping it simplewas the best choice. Future versions of the tool may evaluate to use different trans-formation technologies even if this is not critical at this stage. Because of this choicethe Java code implementing the transformation resembles more one of the imperativetransformation style mentioned previously.

Figure 5.4 presents the architecture of UML2ZOT. The tool is entirely written in Javaand relies on two external libraries; The first one is the Eclipse UML2 Library9 whichis used to read the XMI input file of the UML model. Since the input of the UML2ZOTtool is an XMI file different CASE tools can be used to produce the input UML model.In this thesis we experimented with Papyrus, but we can change the modeling tool as

9www.eclipse.org/uml2/

68

5.3. UML2ZOT Trasformation Tool

soon as the XMI it produces complies with the one supported by the Eclipse UML2library. The second one is the Xtext10 library which is used to parse the expressionsfound in the model (for example the one of time constraints, presented in Section 3.8).UML2ZOT in turn is divided in two sub-packages. The MADES UML package reads

Figure 5.4: Overall architecture of UML2ZOT

the UML model using the Eclipse UML2 API and exposes its API to the TRIO seman-tics package. The TRIO semantics package uses the API exposed by the MADES UMLpackage in order to produce the TRIO semantics written in LISP. It is worth notice thatthis kind of architecture makes the software extensible to new semantics. Suppose thatyou want to provide a new semantics to the MADES UML language; it is possible toreuse the MADES UML package to produce a semantics which is different from theTRIO one presented in this thesis, making the entire approach extensible.

The MADES UML package is in turn divided into a number of subpackages. Mostof the subpackages refers to the diagrams supported by the framework (see Figure 5.5).In addition to that you have other four packages. The Expressions package handles theboolean expression written in the different guards of the UML model. The Events pack-age handles the events notation presented in Section 3.7. The Time constraints packagehandles the time constraint notation presented in Section 3.8. Finally, the Propertiespackage handles the notation to express the properties using CDs. The listing presentedin 5.4 shows an example of how one of the classes included in the MADES UML pack-age looks like. It decorates the elements provided by the Eclipse UML2 library andreturns the informations needed to build the semantics. For example according to theMADES UML meta-model (see Section 3) State Diagrams exists only in the context ofa class in the CD.

10www.eclipse.org/Xtext/

69


Figure 5.5: The MADES UML package

package i t . p o l i m i . uml2zo t . madesuml . c l a s s d i a g r a m ;p u b l i c c l a s s C l a s s {

/∗∗ The d e c o r a t e d c l a s s ∗ /o rg . e c l i p s e . uml2 . uml . C l a s s u m l _ c l a s s ;

p u b l i c C l a s s ( o rg . e c l i p s e . uml2 . uml . C l a s s c ) {t h i s . u m l _ c l a s s = c ;

}

/∗∗ R e t u r n s t h e s t a t e d iagram a s s o c i a t e d t o t h i s o b j e c t ∗ /p u b l i c Set < S ta t eDiag ram > g e t S t a t e D i a g r a m s ( ) {

HashSet < S ta t eDiag ram > s t a t e m a c h i n e s = new HashSet < S ta t eDiag ram > ( );

f o r ( Element e : u m l _ c l a s s . getOwnedElements ( ) ) {i f ( e i n s t a n c e o f S t a t e M a c h i n e ) {

s t a t e m a c h i n e s . add ( new S t a t e D i a g r a m ( ( S t a t e M a c h i n e ) e ) ) ;}

}r e t u r n s t a t e m a c h i n e s ;

}

. . .

}Listing 5.3: An example of class taken from the MADES UML package

The TRIO semantics package is organized like the MADES UML package. It hasa number of subpackages, one for each supported diagram. Each class contained in

70

5.4. Traceability Tool

any of the diagrams subpackages decorates the corresponding MADES UML elementcontained in the MADES UML package providing additional methods to generate theLISP semantics associated to that element. In general the classes contained in theTRIO semantics package decorates the element of the MADES UML package with twoadditional methods; the getPredicate() method returns the predicate associated to theUML element according to the tables defined in Chapter 4; the getSemantics() methodreturns the semantics associated to the UML element.

package i t . p o l i m i . uml2zo t . s e m a n t i c s . s t a t e d i a g r a m ;p u b l i c c l a s s S T r a n s i t i o n {

p r i v a t e T r a n s i t i o n m a d e s _ t r a n s i t i o n ;

p u b l i c S T r a n s i t i o n ( T r a n s i t i o n t ) {t h i s . m a d e s _ t r a n s i t i o n = t ;

}

p u b l i c P r e d i c a t e g e t P r e d i c a t e ( O b j e c t o b j e c t ) {r e t u r n new P r e d i c a t e ( " OBJ"+ o b j e c t . getName ( ) +"_STD"+ t h i s .

m a d e s _ t r a n s i t i o n . g e t S t a t e D i a g r a m ( ) . getName ( ) +"_TRANSITION"+ t h i s . m a d e s _ t r a n s i t i o n . getUMLId ( ) ) ;

}

p u b l i c S t r i n g g e t S e m a n t i c s ( O b j e c t o b j e c t ) {S t r i n g sem = " " ;

. . .}

}Listing 5.4: An example of class taken from the TRIO semantics package

5.4 Traceability Tool

The traceability tool is operated at the end of the verification phase when verificationresults become available. Verification results often reveal unexpected behaviors that theuser did not expect at first. A deep inspection is needed in order to understand why thedesired property has been violated. Despite the importance of the verification results,most of the state-of-art tools omit the problem of finding a suitable representation inorder for the result to be understood by the end-users (see Chapter 2). This is why quiteoften an expert of the underlying formal notation is required to understand the resultsand modify the original high-level model accordingly.

In the case of Corretto, the verification tool - Zot - may return two possible re-sults; either the property holds for the model, or a counterexample is returned showingwhy the property is violated. A counterexample in Zot is a text file containing a listof time instants (see Listing 5.2). Every time instant t contains the set of the temporallogic predicates which are true at that time. The goal of the traceability tools is to linkthe predicates in the counterexample to the source UML model, in order to let the userunderstand why its property has been violated; the predicates alone mean nothing to

71


him. The simplest solution would be to provide a graphical representation for the trace,for example using a sequence diagram, but we discovered that this solution often doesnot scale, especially in the case of multi-diagram UML models, where predicates in thetrace may refer to elements belonging to any of the different views in the model. Thetraceability tool therefore provides a simple but effective solution. Instead of findinga suitable representation for the trace, the predicates are just linked back to the cor-responding UML element in the model, by means of hyperlinks in Papyrus. In thisway the user can both inspect and interpret the trace using the high-level informationsprovided by the UML elements.

For a better explanation of the tool’s usage let us consider the example propertyshown in the TPD of Figure 5.7. The diagram states a security property of the CarCollision Avoidance System (CCAS) presented in detail is Section 6.2. The CCASsystem must ensure that the car brakes automatically if the distance with the front carremains less then 2 meters for a certain amount of time. In this case we want to checkthat if the distance with the facing car remains strictly less then 2 meters for 450ms,then the CCAS system must brake. In the UML model 1 time unit is equivalent to10ms, the distance read by the CCAS has been modeled using a variable in a sequencediagram whose corresponding UML model is shown in Figure 5.6(b), and the brakingaction has been modeled as a braking state in a state machine whose correspondingUML model is shown in Figure 5.6(a). The property in the TPD states that if the valueof the distance variable remained strictly less then 2 for 45 time units, then in thosesame 45 time units the system has been inside the braking state.

Since the property does not hold for the CCAS system a counterexample is returnedbyZot and the user interacts with the traceability tool to figure out why. A screenshot ofthe traceability tool showing the counterexample to the previous property is presentedin Figure 5.8. The user interface is simple and is divided in two areas. The sourcemodel is represented on the left in the Model explorer window, whilst the output of theverification process is displayed on the right. The two areas can be navigated in full. Byselecting a predicate in the Zot output the relevant model element in the source modelis highlighted. The links between these entities are maintained by an index file whichhas been produced during the translation phase. The index file contains the mappingsbetween the UML identifiers of the model elements and their corresponding predi-cates in the Zot output. In the counterexample shown in Figure 5.8 the user clicks atthe SDSendSensorDistanceParDistance variable and the distance parameter of thesequence diagram is highlighted in the UML model explorer on the left. The other bitof information is trivial; SDSendSensorDistanceParDistance = 0 at time 0. Thevalue of the distance remains unchanged for all the subsequence time instants, until time45. At that time the user clicks on the ObjBrakeS_StDStateMachine1_StateIdlepredicate and the idle state of the BrakingSystem class of the UML model is highlightedin the UML model explorer. Therefore the distance variable remained stricly less then2 for 45 time units, but yet the BrakingSystem is still in the idle state, violating theproperty shown in Figure 5.7.

72


(a) (b)

Figure 5.6: Subset of the UML model of the Car Collision Avoidance System. On the left the statediagram of the BrakingSystem class is shown. On the right the sequence diagram fetching the

distance from the facing car is shown; the ownedParameter field containing the distance variablemodels the fetched distance.

Figure 5.7: Example property for the traceability tool.

73


Figure 5.8: Traceability navigation tool. The user inspects the counterexample at time 0; by clicking onthe predicate he discovers that the value of the distance variable is equal to zero.

74


Figure 5.9: Traceability navigation tool. The user inspects the counterexample at time 45; by clickingon the predicate he discovers that the braking system is inside the idle state.

75

CHAPTER6Experimental Evaluation

The assessment of the approach proposed in this thesis has been done through a numberof case studies coming from the industrial partners of the MADES European Project1.Two components of a RADAR systems coming from two different industrial partners,and a Car Collision Avoidance System (CCAS) have been verified using the Correttoprototype tool. Verification tools were not present before the MADES project thereforeno A/B test can be provided with respect to other equivalent verification technologies.

Before the introduction of the Corretto prototype tool there were no understand-ing about the quality of the UML models produced in the early stages of the develop-ment. A suitable implementation together with unit and integration testing were neededin order to assess the quality of the product. Now the engineers can experiment withtheir models at the early stage of the development process by building and verifyingtime properties. Models become executable and can be used not only for the documen-tation and the code generation of the artifacts, but also to assess their behavior thereforeincreasing their quality. In the long run standardized process can be built were modelverification plays a central role in the product lifecycle. UML models built by the en-gineers must complies with standardized pattern properties in order to proceed to thecode generation and implementation phase.

The rest of this chapter is organized as follows: Section 6.1 presents how the cor-rectness of the semantics has been checked for each of the different behavioral viewssupported by MADES UML. Section 6.2 presents the CCAS case study with great de-tails on the formal model produced by the UML2ZOT transformation tool. Sections 6.3and 6.4 present the case studies of two components of a Radar system which have beenmodeled and verified with the Corretto prototype tool. Finally Section 6.5 collectsthe results of the experiments and states some conclusions.


77

Chapter 6. Experimental Evaluation

6.1 Testing the Semantics

Testing the correctness of the semantics is not a trivial task. First because there is noformal semantics provided by the OMG itself, thus an equivalence test is not possible.Second because there are no standard techniques to testing axiomatizations written inlogic. Given that in order to check if the semantics works as expected or not, a numberof test cases have been defined for each diagram supported by MADES UML. The goalof each test case is to prove that the behavior of the semantics is the one expected bythe end-user, but also to build a set of test cases to be used for the regression testing ofthe semantics. To avoid burdening the presentation in this section we will not show allthe test cases that have been performed but only the most representative one.

6.1.1 Sequence Diagrams

Let’s consider the model shown in Figures 6.1-6.2. The CD of Figure 6.1 defines twoclasses - Class1, Class2 - and the corresponding objects instantiating them. Each classhas one operation. The SD of Figure 6.2 shows that two simple messages are exchangedbetween the two objects. The messages invoke the corresponding operations defined inthe CD. We may want to check if the order of the events in the SD is correct or not. Todo that we ask the model if there exist any trace where the second message is followedby the first one, which is formalized by this property:

op2⇒ Futr(¬op1, 1) (6.1)

where op1, op2 are the predicates assigned to the messages in the SD according to therules defined in Chapter 4. Running the verification we discover that the property doesnot hold for our system. Looking at the counterexample provided by the verificationtool the reason is actually trivial. Suppose that the SD starts, the first message is sent,the second message is sent, and then the SD ends. If the SD starts again then the firstmessage is sent again, just after the second one (but in the previous instance of the SD),thus violating the property. We get rid of this case by modifying our property, sayingthat if we have the second message now, and in the next time instant we are not insidethe SD, then we cannot have the op1 message:

op2 ∧ Futr(¬SDStart, 1)⇒ Futr(¬op1, 1) (6.2)

The previous formulae can also be expressed using a Time Property Diagram (TPD) asshown in Figure 6.3. To define the TPD the user must first import the MADES profiledefining the stereotypes for TPDs. Once the profile has been imported the user creates aCD representing the formulae to be proved. The root of the formulae is identified by the«property» stereotype. The «alw» stereotype states that the underneath formulae holdsfor every time instant t in the model. The left side of the implication contains a «term»refering to the message instantiating op_1 and an «event» refering to the start event ofthe SD named Interaction1 using the MADES event notation presented in Section 3.7.Once the «term» stereotype is assigned to the class, the message is selected througha suitable dialog box offered by Papyrus. The same mechanism holds for the «event»stereotype except that a text field for the event expression is provided.

78

6.1. Testing the Semantics

Figure 6.1: Testing the SD semantics: The CD of the model under test.

Figure 6.2: Testing the SD semantics: The SD of the model under test.

79


Figure 6.3: Testing the SD semantics: The TPD of the property to be tested: “ if op2() holds now and inthe next time instant we are not inside the SD, then we cannot have the op1() message”.

80


6.1.2 State Diagrams

Let’s consider the model shown in Figures 6.4-6.6. The model contains two classes,and each class is instantiated by one object. The behavior of the different classes isexpressed by means of two StDs. Both the StDs exhibit the same behavior. Everystate has an outgoing transition labeled with a time constraint as a trigger. When thetime constraint expression becomes true, the transition is taken. In this case the tran-sition is always taken 5 time instants after the object entered the state. For exampleis we consider the StD of Figure 6.4 each object belonging to Class1 first enter inc1State1; after 5 time instant the constraint @now - @c1State1.enter==5 holds, there-fore the object moves to c1State2; after other 5 time instant the constraint @now [email protected]==5 holds, therefore the object moves back to c1State1; and so on andso forth. If you consider the combined behavior of the two StDs you may notice thatwhen StDClass1 is in c1State1, StDClass2 is in c2State2. Likewise, when StDClass1 isin c1State2, StDClass2 is in c2State1. We first tried to check this intuitive property byasking Zot a random trace of the system which is shown in Listing 6.1. In the trace youcan see that both the objects switch state at time 6 and at time 12, therefore they willnever be both in c1State1 and c2State1 at the same time. To verify that this propertyalways holds for the system we define the following formulae:

c1State→ ¬c2State1 (6.3)

The same property is represented by means of a TPD in Figure 6.7. Zot is able to provein a couple of seconds that the property actually holds for the system.I_LOOP = 41−−−−−− t ime 0 −−−−−−

MADESYSTEMSTART−−−−−− t ime 1 −−−−−−

OBJ2_STDCLASS2_C2STATE2_ENTEROBJ1_STDCLASS1_C1STATE1_ENTER

−−−−−− t ime 2 −−−−−−−−−−−− t ime 3 −−−−−−−−−−−− t ime 4 −−−−−−−−−−−− t ime 5 −−−−−−−−−−−− t ime 6 −−−−−−

OBJ1_STDCLASS1_C1STATE1_EXITOBJ2_STDCLASS2_C2STATE2_EXIT

−−−−−− t ime 7 −−−−−−OBJ1_STDCLASS1_C1STATE2_ENTEROBJ2_STDCLASS2_C2STATE1_ENTER

−−−−−− t ime 8 −−−−−−−−−−−− t ime 9 −−−−−−−−−−−− t ime 10 −−−−−−−−−−−− t ime 11 −−−−−−−−−−−− t ime 12 −−−−−−

OBJ1_STDCLASS1_C1STATE2_EXITOBJ2_STDCLASS2_C2STATE1_EXIT

−−−−−− t ime 13 −−−−−−OBJ2_STDCLASS2_C2STATE2_ENTEROBJ1_STDCLASS1_C1STATE1_ENTER

−−−−−− t ime 14 −−−−−−−−−−−− t ime 15 −−−−−−

81


−−−−−− t ime 16 −−−−−−Listing 6.1: Testing the StD semantics: an execution trace of the system under test

Figure 6.4: Testing the StD semantics: The CD of the model under test.

Figure 6.5: Testing the StD semantics: The StD of Class1.

Figure 6.6: Testing the StD semantics: The StD of Class2.

82


Figure 6.7: Testing the StD semantics: The TPD of the property to be proved.

6.1.3 Interaction Overview Diagram

Let’s consider the model shown in Figures 6.8-6.9. The model contains two classes, andeach class is instantiated by one object, and one signal. In addition the model has threeSDs, and one IOD. The IOD starts with either Interaction2 or Interaction3. If theseSDs complete their execution successfully, the IOD ends. It may also occur the any ofthe two SDs is interrupted, activating the accept event action node, and consequently,the Interaction1 SD. Intuitively we may think that the IOD ends either because one ofthe two SDs on the left finished correctly, or because the Interrupt signal occurs and theInteraction1 is executed. This intuition can be formalized by the following property:

Interaction1End⇒ ¬SomP(Interaction2End ∨ Interaction3End) (6.4)

where Interaction1End,Interaction2End and Interaction3End are the predicates assignedto the end event of the SD nodes of the IOD (see Section 4.4). The previous propertycan also be expressed using the Time Property diagram shown in Figure 6.10. Zot isable to prove the property in few seconds.

Figure 6.8: Testing the IOD semantics: The CD of the model under test.

83


Figure 6.9: Testing the IOD semantics: The IOD of the model.

Figure 6.10: Testing the IOD semantics: The TPD of the property to be proved.

84

6.2. CCAS Case Study

6.2 CCAS Case Study

The car collision avoidance system, or CCAS for short detects the position of the vehi-cle on which it is installed, relative to other objects such as cars and pedestrians. Thedistance between the car and the external objects is read through an on-board proximitysensor, which is in charge of sending data to the CCAS main module every 100 msthrough the system bus. The delivery takes 20 ms, and during the data transfer the busis considered to be busy. When the distance between the car and the external objects isgreater then or equal to 2 meters the CCAS should not perform any action. When thedistance becomes strictly less than 2 meters the CCAS switches to the warning state. Ifthe CCAS remains in the warning state for more than 300 ms and the distance is stillless than 2 meters, the CCAS must brake. The warning state is introduced to avoidunstable oscillating behaviors when the distance fluctuates around the 2 meter value.The brake actuator is in charge of executing the brake command. The CCAS sendsthe brake command using the bus. The delivery takes 20 ms. When the command isreceived, the brake actuator brakes for 100 ms.

6.2.1 MADES UML Model

The CCAS is modeled with one CD (Figure 6.11), one OD (Figure 6.12), one IOD(Figure 6.13), two SDs (Figure 6.14-6.17), and two StDs (Figure 6.19-6.18). All thediagrams contribute to the final behavior of the CCAS.

Class Diagram and Object Diagram

The CD is made of four classes, one signal, and one clock type. The Radar class isin charge of sending the distance to the BUS. The BUS has two methods; the sendSen-sorDistance() method which is in charge of delivering the distance to the Controller,while the sendBrakeCommand() method is in charge of sending the brake command tothe braking system. The Controller has only the notifyDistance() method to receive thedistance sent by the Radar. The brakeInterrupt signal is defined here and will be usedin the behavioral diagrams to actually trigger the braking procedure. The RadarClockclass defines a clock type with period equal to 10. Each time unit represents 10ms,which results in a clock tick every 100ms.

For every class in the CD the system has exactly one object instantiating the class.As explained in Chapter 4, in order to verify the model the number of objects in thesystem must be finite. The clock object istantiating the clock type defined in the classdiagram is identified with the «clock» stereotype.

85


Figure 6.11: CCAS Class Diagram.

Figure 6.12: CCAS Object Diagram

Figure 6.13: CCAS Interaction Overview Diagram

86


Interaction Overview Diagram

The IOD of the system shows a good overview of how the CCAS works. When thesystem starts it immediately executes the sendSensorDistance SD, which is included inan infinite loop. When the brakeInterrupt signal occurs, the sendBrakeCommand SD isactivated. After the execution of this SD, the IOD throw away the token. This diagramsalso communicate that the system never ends its execution because no activity finalnode is present.

Sequence Diagrams

SDs are used to show the interactions within the system. The CCAS has two maincommunications going on. The first one is represented in the sendSensorDistance SD(Figure 6.14). The radar sends the distance to the bus which in turn notifies the con-troller of the new distance value. In order to pass the distance information within thediagram, a sequence diagram parameter called distance has been created whose value isconstant for the entire duration of the diagram (Figure 6.15). The sendSensorDistancemust be sent periodically, with period equal to the one specified by the RadarClockin the CD. To express this the «timedEvent» stereotype taken from the MARTE UMLprofiles is used. The stereotype provides an attribute to specify to which clock thetimed event should be linked to (see Figure 6.16). The comment profiled as a «time-Constraint» specifies that the bus takes 2 time units to deliver the message. The syntaxtof time constraints is explained in detail in Section 3.8. The sendBrakeCommand SDshows how the brake command is sent from the controller to the braking system whichis in charge of activating the brake of the car. Again a «timeConstraint» is used toexpress how much time units the bus takes to deliver the distance.

Figure 6.14: CCAS Send Sensor Distance Sequence Diagram

87


Figure 6.15: CCAS Send Sensor Distance Parameter

Figure 6.16: CCAS Send Sensor Distance Timed Event

Figure 6.17: CCAS Send Brake Command Sequence Diagram

88


State Diagrams

StDs are used to represent the internal behavior of the classes in the CD. Both theController class and the BrakingSystem class own one StD. The controller stays in thenoAction state until the received distance remains greater or equal than 2. The distanceis received through the parameter of the notifyDistance method. When the distancebecomes strictly less then 2, the controller moves to the warning state. This state isintroduced to deal with the oscillations of the distance around the value of 2. If thedistance becomes again greater then 2, the controller returns to the noAction state. Onthe other hand if the distance remains less then 2 for more then 30 time units, thecontroller executes the transition from the warning state to the braking state and triggerthe brakeInterrupt signal. The BrakingSystem starts in the idle state. When it receivesthe distance it moves to the braking state where it remains for 10 time instants. Afterthat he moves back to the idle state.

Figure 6.18: CCAS State Diagram of Controller

Figure 6.19: CCAS State Diagram of the Braking System

6.2.2 Semantics

Class Diagram and Object Diagram

In the following the axioms generated by the CD and the OD are presented. For ev-ery operation in the CD the corresponding predicate is generated according to the tablepresented in Section 4.2. For example the sendBrakeCommand operation generatesthe OBJcanid

OPsendBrakeCommandid predicate. This predicate holds when the operationis invoked. The operation may be invoked either because some message instatiating

89


this operation appears in some sequence diagram, or because some state diagram di-rectly invoke the operation through the action field of a transition. The CCAS onlyhas one message instantiating the sendBrakeCommandOperation (Figure 6.17), thusthe following axiom holds:

ObjcanidOpsendBrakeCommandid ⇔MsgsendBrakeCommandMsgid (6.5)

The brakeInterrupt signal is translated similarly. The predicate SignalbrakeInterruptid isgenerated and it is associated to all the elements that invoke the signal. For the CCASwe only have one transition in the StD controller, thus:

SignalbrakeInterruptid ⇔ ObjctrlidTransitionwarning−>brakingid (6.6)

The OD also defines a clock whose clock type is declared in the CD. For this clock thesemantics defining its clock tick is generated.

ClockradarClockidTick ⇔ Lasted(¬ClockradarClockidTick, 9) (6.7)

Interaction Overview Diagrams

The IOD of the CCAS is fairly simple. The most significative formulae includes theactivation of the two SDs, sendSensorDistance and sendBrakeCommand. The send-SensorDistance SD is invoked by the IOD when the IOD starts or the SD itself ends(self-loop). This generates the following formulae:

IODidSDsendSensorDistanceidStart⇔ (6.8)Past(IODidSDsendSensorDistanceidStart ∨ IODidEnd, 1)

The sendBrakeCommand SD is invoked by the IOD when the brakeInterrupt holds.This is easily translated in the following formulae:

IODidSDsendBrakeCommandidStart⇔ (6.9)Past(SignalbrakeInterruptid ∨ IODidEnd, 1)

Sequence Diagrams

In the following the axioms generated by the sendSensorDistance SD are presented.The sendBrakeCommand SD can be easily derived using the same pattern of formulaepresented here. SDs are characterized by three fundamental predicates: SDidStart,SDidEnd, SDidStop. The first holds when the diagram starts, the second holds whenthe diagram ends, and the third holds if the diagram is interrupted for some reason.An additional predicate is defined on top of these, which holds when the system isexecuting the SD. The system is executing the SD if the SD is started, but it does notended yet, thus the following formulae holds:

SDidStart⇔ Since(¬SDidEnd ∧ SDidStop, SDidStart) (6.10)

Each lifeline is an ordered list of events, and every event is represented by one predicate.By convention the first event of each lifeline is the SD start. For the sendSensorDistanceCCAS the first lifeline is made of the following list of events: {SDStart,MsgSendSensorDistanceStart, SDEnd}. Each of these events has one predicate associated.

90


To represent the fact that this is an ordered list with an unspecified amount of time be-tween each event, two formulae are generated for each pair of events in the list. Let’stake SDStart andMsgSendSensorDistanceStart events. The predicates associatedto them are SDsendSensorDistanceidStart and MsgsendSensorDistanceid Start. The follow-ing formulae states that if SDsendSensorDistanceidStart then MsgsendSensorDistanceid Startwill be true sometimes in the future, if the SD is not stopped in the meanwhile.

Evi ⇒ (6.11)Until(¬Evi ∧ ¬Evj, SDxStop)

∨Until(¬Evi ∧ ¬SDxStop, Evj)

where Evi = SDsendSensorDistanceidStart and Evj = MsgsendSensorDistanceidStart. No-tice that this formulae allows the possibility of having the SDStart andMsgSendSensorDistanceStart at the same time instant. For events that cannot occur at the same timeinstants - like MsgSendSensorDistanceEnd and MsgNotifyDistanceStart in thelifeline of the bus - the formulaeEvi ⇒ ¬Evj is added. Likewise, ifMsgsendSensorDistanceid

Start holds now, then somewhere in the past we had the SDsendSensorDistanceidStart

event, if the SD has not been stopped in the meanwhile.

Evj ⇒ (6.12)Since(¬Evj ∧ SDxStop, Evi)

The end event of the SD has an additional formulae associated which states that the endoccurs if and only if the last event of the different lifelines occurs. The set of events thatterminate the different lifelines is the following: {MsgSendSensorDistanceStart,MsgNotifyDistanceStart,MsgNotifyDistanceEnd}. The following formulae de-fines the end of the SD:

SDidxEnd⇔ (6.13)Ev1 ∧ ∀i ∈ {2, 3} Since(¬SDidxEnd,Evi)

Ev2 ∧ ∀i ∈ {1, 3} Since(¬SDidxEnd,Evi)

Ev3 ∧ ∀i ∈ {1, 2} Since(¬SDidxEnd,Evi)

where Ev1 = MsgSendSensorDistanceStart, Ev2 = MsgNotifyDistanceStart,and Ev3 = MsgNotifyDistanceEnd. All the parameters belonging to a SD re-mains constant during the execution of the diagram. The sendSensorDistance se-quence diagram owns one parameter called distance. The predicate associated to itis SDParamdistanceid . The formulae which entails the semantics is the following:

SDsendSensorDistanceid ⇒ (6.14)(SDParamdistanceid = Y esterday(SDParamdistanceid))

All the messages in the sendSensorDistance SD are not delayed, thus the send andreceive events holds at the same time instant. For the sendSensorDistance message wehave that the following formulae holds:

MsgsendSensorDistanceidStart⇔MsgsendSensorDistanceidEnd (6.15)

91


Moreover the assignment of the parameters is performed when the message is received.The sendSensorDistance message instantiate the corresponding operation whose pa-rameter is equal to Objcanid

OPParsendSensorDistanceid . Thus, the following formulaeholds:

MsgsendSensorDistanceidEnd⇒ (6.16)SDParamdistanceid = Objcanid

OPParsendSensorDistanceid

The sendSensorDistance SD has one time constraint associated stating that the dis-tance between the time in which the sendSensorDistance message is sent and the timein which the notifyDistance message is sent, must be equal to 2 time units. This istranslated into the following formulea:

MsgnotifyDistanceidStart⇒ Past(MsgsendSensorDistanceidStart, 1) (6.17)

State Diagrams

In the following the semantics generated by the StD of the Controller class is pre-sented. The formulae related to the other StDs can be easily derived by applying thesame pattern of formulae to the predicates of the other StDs. For every object instan-tiating the class owning the StD the tool produces the formulae related to its behaviordescribed in the StD. In other words if a class is instantiated by two objects, the samestate diagram is generated twice, one for each object. The Controller class has only oneinstace, ctrl. The semantics of the state diagrams is divided in two parts: the first de-fines the meaning of the predicates associated to each state; the second one defines themeaning of the predicates associated to the transitions, together with their correspond-ing trigger/guard/action fields. The noAction state of the Controller has three incomingtransitions: warning->noAction, noAction->noAction and braking->noAction. Each oftransition has an predicate associated, namely ObjctrlidTransitionwarning−>noActionid

,ObjctrlidTransitionnoAction−>noActionid

, andObjctrlidTransitionbraking−>noActionid. The

ctrl object enters the noAction state if the previous time instant either the warning->noAction transition, or the braking->noAction transitions occurred. The self transi-tion is not included in this set because formally we do not exit and enter again in thestate.

ObjctrlidStatenoActionidEnter ⇒ (6.18)Past(ObjctrlidTransitionwarning−>noActionid

∨ (6.19)ObjctrlidTransitionbraking−>noActionid

, 1)

Likewise, we exit the noAction state if the noAction->warning transition occurs, thusthe following formulae holds:

ObjctrlidStatenoActionidExit⇒ (6.20)

ObjctrlidTransitionnoAction−>warningid

Given these simple definitions of the enter/exit events of each state the definition of thestate itself must be provided. The definition states that if we are inside the state and noexit event holds at the current time instant, then in the next time instant we will remainin the same state. On the other hand if we are inside the state and the exit event holds at

92


the current time instant, then the next time instant we will not be anymore in this state.This is translated into the following formulae for the noAction state:

ObjctrlidStatenoActionid∧ ¬ObjctrlidStatenoActionid

Exit (6.21)⇒ ObjctrlidStatenoActionid

ObjctrlidStatenoActionid∧ObjctrlidStatenoActionid

Exit

⇒ ¬ObjctrlidStatenoActionid

The same type of axioms can be easily derived for the enter event. For each transitionof the state diagram a number of axioms are generated. The first one states that if thetransition holds now, then we must exit from the source state, and we should enter thetarget state in the next time instant. For the warning->braking transition this becomethe following:

ObjctrlidTransitionwarning−>brakingid ⇒ (6.22)ObjctrlidStatewarningidExit ∧ Futr(ObjctrlidStatebrakingidEnter, 1)

Each transition may have three optional fields: trigger, guard and action. If the triggerand the guard holds, then the transition can be fired. However it may be the case thatmultiple transitions are ready to go. In this case the choice is non-deterministic. Thefollowing formulae states that if the transition and the guards holds at the current timeinstant, one of the outgoing transitions will hold at the same time. For the warning->braking transition this is translated as follows:

ObjctrlidTransitionwarning−>brakingidTrigger∧ (6.23)ObjctrlidTransitionwarning−>brakingidGuard

⇒ ObjctrlidTransitionwarning−>brakingid ∨ObjctrlidTransitionwarning−>idleid

A necessary condition for the transiton is that we are in the source state and the corre-sponding guard and trigger hold. For the warning->braking transition this is translatedas follows:

ObjctrlidTransitionwarning−>brakingid ⇒ (6.24)ObjctrlidTransitionwarning−>brakingidTrigger∧ObjctrlidTransitionwarning−>brakingidGuard

Finally, the definition of the trigger, guard follows from their specification in the model.For the warning->braking transition we have that the trigger occurs if and only if we arein the source state and the notifyDistance operation is invoked on the object, therefore:

ObjctrlidTransitionwarning−>brakingidTrigger ⇔ (6.25)ObjctrlidStatewarningid ∧ObjctrlidOPnotifyDistanceid

The guard of the warning->braking transition holds if and only if we entered in thewarning state 30 time units ago and the distance received now is less then 2, therefore:

ObjctrlidTransitionwarning−>brakingidGuard⇔ (6.26)ObjctrlidStatewarningid ∧ObjctrlidOPParreceivedDistanceid < 2 ∧Lasted(ObjctrlidStatewarningidEnter, 30)

93


If the transition has an action associated to it, like in the case of the warning->brakingtransition, then if the transition occurs now and we are in the source state, the actionmust hold, which is formalized by the following axiom:

ObjctrlidStatewarningid ∧ObjctrlidTransitionwarning−>brakingid (6.27)⇒ SignalbrakeInterruptid

6.2.3 Property and Results

A first check that can be carried out through Zot concerns the satisfiability of the pro-duced model. This is useful to verify the consistency of the different views of themodeled system provided by the various UML diagrams. In fact, it can be the casethat different UML diagrams are inconsistent because, for example, the informationprovided in a view violates the constraints imposed by another view. To answer thisfirst question it is enough to feed Zot the formal model, then ask the tool to check itssatisfiability; in case the model is satisfiable, Zot produces a valid trace of the system;otherwise, in case of inconsistencies, Zot indicates that the model is unsatisfiable. Forthe CCAS system, the check has been performed using a time bound of 100 units, andZot reported in less than 40 seconds of real time that the system is indeed satisfiable.2

If, on the other hand, we modify the UML model such that the period of the RadarClocktype is equal to one instead of ten, the model becomes unsatisfiable. Intuitively the rea-son is that the bus takes two time units to deliver the information, thus we cannot sendthe measured distance from the ProximitySensor to the CCAS every discrete time unit.From the point of view of the UML model the information provided by the Class Dia-gram (Figure 6.11), the sendSensorDistance Sequence Diagram (Figure 6.14) wouldbe contradictory.

If the model is satisfiable we can proceed and check some user-defined properties.We start by checking that, if the distance remained less than 2 meters for 45 time units,then the system did indeed brake within those same 45 time units. We expect this timewindow to be big enough for the system to react in time because the warning state lasts30 time units and the bus delivery takes 2 time units. The property is formalized by thefollowing formula:

Lasted(ObjctrlidOPParreceivedDistanceid < 2, 45) (6.28)⇒WithinP(ObjbrakeSid

Statebrakingid , 45)

Zot determines in around 40 seconds that the property does not hold for the CCASsystem, and it produces as counterexample a trace of the system violating the property,which is summarized below. Intuitively the reason for the violation is that the CCASdoes not enter immediately into the warning state when the distance becomes less than2, but only when it receives the notifyDistance message from the bus and the distance isless than 2. Then, the time constants in property (6.28) have been changed from 45 to50 time units (i.e.,500ms), and in this case Zot was able to show in around 50 secondsthat the new property holds.

As mentioned above, a time bound of 100 units was used to perform the variouschecks with Zot. This means that the tool explored all system traces of length up to

2Using the Common Lisp compiler SBCL 1.0.45.0 on a 2.80GHz Core2 Duo laptop with 64bit Ubuntu 11.04 and 4GB of RAM.The verification engine used was the SMT-based Zot plugin introduced in [6]; the solver was z3 3.2 (http://research.microsoft.com/en-us/um/redmond/projects/z3/).

94

http://research.microsoft.com/en-us/um/redmond/projects/z3/

http://research.microsoft.com/en-us/um/redmond/projects/z3/


100 during the checks. However, we were also able to determine through Zot that 100is larger than the completeness bound for the CCAS model, hence the results of theanalyses can be generalized to traces of any length.

The diagram of Figure 6.20 shows the TPDs corresponding to the temporal logicformulae shown in 6.28. Because the property is built directly in Papyrus the user

Figure 6.20: The TPD of the property to be proved for the CCAS

does not need anymore to deal with the mappings between the UML elements and thetemporal logic predicates: the elements of the formulae are selected directly throughthe dialog boxes offered by Papyrus, and the translation from UML to temporal logicis hidden (see Figure 6.21). Figure 6.22 shows the traceability interface while the useris debugging the counterexample produces by Zot for the property stated in formulae6.28. The user is analyzing the time instant 45 where he expects to find the brakeSobject in the braking state, while instead it is still in the idle state. The user clicks thepredicate in the bottom right of the screen , where the counterexample is shown, andthe corresponding UML element is higlighted on the bottom left, in the model explorer.

Figure 6.21: The interface to select the elements in the property

95


Figure 6.22: The traceability interface. The user inspect the trace on the bottom right and check thecorresponding uml element in the bottom left of the screen.

96

6.3. TXT Case Study

6.3 TXT Case Study

Corretto has been used for the verification of the user interface (UI) of a radar system.Figure 6.23 show the various parts that compose the whole radar system. The radar in

Figure 6.23: Radar UI, Antenna and Processor

this case study is developed to operate on board an aircraft. The critical part is thatthe radar has to follow the aircraft movements (asset based on three axes values: yaw,pitch, roll and altitude, etc.) to be able to direct the antenna on the target accordingly.The radar system receives the navigation information from two computers:

• FMS is the Flight Management System, which is the on board computer that is incharge of flight management.

• AHRS is the inertial platform, a set of sensors managed by a computer that col-lects information from several sensors and provides the values related to position,velocity and other values.

Communication with FMS and AHRS is achieved by means of a specific avionic linkbased on the ARINC429 standard. ARINC429 is a specific avionic communicationmedia that consists of a serial line operating at a 100 kHz bit rate.Transmitted messages are quite simple and consist of 32 bit word data. Each data has aspecific meaning given by a part of the data (named label). A data element has a labeland each label refers to a specific meaning (velocity, position, height). The remainingpart of the word consists of the real data value. These messages are continuously sentover the link at a predefined rate.The flight parameters received by the FMS/AHRS are routed to the radar processor andantenna by the Radar UI Module depicted in Figure 6.23. When the antenna detects atarget, the data processor generates the proper map information and sends it to the UserInterface for displaying.

97


All communications of the Radar UI with the Data processor & Radar Antenna is sup-ported by an Ethernet link (TCP/IP and UDP/IP). The User Interface (UI) implementa-tion has several timing constraints that must be met:

• Flight management communication messages are timely transmitted at differentrates: i.e. several messages are 10mS rate, other at 100mS rate

• The I/O management subsystem shall transmit the flight data to the radar at 10mSrate

• The radar sends status information to the Radar UI every 100mS

• The radar sends map information to the Radar UI every second

• The UI shall check the keyboard function keys and joystick cursor at a proper rate

In order to track the target correctly, the radar shall receive the flight information atstrict intervals and at a proper rate. In fact, the movement of the antenna shall becomputed according to the flight trajectory.One design decision is that hard real time tasks are implemented in the IOInterface(I/O Management) component while the other parts are in the GUIMain (INTERFACE)component which is much less critical.The GUIMain module it is not only a GUI component but contains many parts. Allthese parts are not as critical in terms of time computation as the IOInterface. TheGUIMain component contains several sub-components (packages in UML) having dif-ferent duties. In addition to the UI software there are also: data management (naviga-tion data and radar data), equipment diagnostic, recording and playback facilities, math-ematical computation (geo-reference positioning), communication (network, RS232,RS422) and logging.The GUIMain software shall receive the navigation information and manage the timingwith respect to the radar system (antenna and processor). The Radar UI part has beendivided into two main parts:

• A typical graphical user interface management (UI), called User Interface (seeFigure 6.23)

• An I/O management layer, called I/O Management (see Figure 6.23)

The I/O management layer is in charge of the most critical parts in terms of timing. Itcommunicates with the external I/O board by means of a dual port RAM through thePCI bus. Specific Windows drivers have been developed for the I/O management layerto access such peripherals.


The goal of the MADES UML model is to capture the behavioral features of the RadarSystem described previosly. A suitable abstraction level has been agreed with the end-users in order to verify the properties of interest.Figure 6.24 shows the CD of the system. There are 5 tasks (swMainMMI, swPanelData,swRadarData, swNavData, swWeatherData) modeled as classes that retrieve their datathrough a shared resource (swEnvironment). Each task is in charge of taking some

98

6.3. TXT Case Study

data made available by the environment and display them to the on-board UI. In orderto fulfill this goal each task owns a dedicated clock. Every time a clock ticks, thecorresponding task retrieves the data from the environment and print them on the UI.All the classes in the system are instantiated by one object. The interactions between

Figure 6.24: The Radar System Class Diagram.

the tasks and the environment are modeled by means of SDs. Each SDs is in charge ofshowing the interaction of the corresponding task with the environment. Figures 6.25-6.29 shows all the interactions in the system. Finally, in order to launch the interactionsperiodically, each task owns a state diagram with only one transition. The transition issynchronized with the tick of the clock assigned to the class, and fires the SD assignedto the task. Figures 6.30 and 6.31 shows two of the 5 StDs in the system.


The property shown in Figure 6.32 has been verified against the system. The prop-erty states that if the panel_setButton() message occurs, then within 15 time units themain_panel_getButton() message must occur. Zot proved in 178 seconds that the prop-erty holds for the system. 3

3On an machine running Ubuntu 11.04 Intel(R) Xeon(R) CPU E5530 @ 2.40GHz with 24GB of RAM

99


Figure 6.25: TXT Case Study: Navigation to Environment SD

100

6.3. TXT Case Study

Figure 6.26: TXT Case Study: Main MMI to Environment SD

101


Figure 6.27: TXT Case Study: Radar to Environment SD

Figure 6.28: TXT Case Study: Panel Data to Environment SD

102

6.3. TXT Case Study

Figure 6.29: TXT Case Study: Weather to Environment SD

Figure 6.30: TXT Case Study: The Main MMI StD

Figure 6.31: TXT Case Study: The Navigation Data StD

103


Figure 6.32: TXT Case Study: The TPD of the property which has been verified against the model.

104

6.4. CASSIDIAN Case Study

6.4 CASSIDIAN Case Study

The CASSIDIAN Case Study analyzes a different component of the Radar system,namely the Radar Processor. The goal of the Radar Processor is to take the new datacoming from the antenna, process them, and finally delivery them for further usage(for example displaying the data to the Radar GUI). Compared to the previous examplethis case study is slightly bigger and exhibit a greater number of interactions betweenthe different components. A substantial use of time constraints has been made in themodel showing their effectiveness in the domain of discourse. The operations that mustbe performed on the data includes packaging, Sweep Processing, Doppler Processing,Thresholding, and finally some Post Processing. When the new data is available forprocessing, the previous transformations are executed in order and must be completedwithin 100ms.


The Radar Processor system has been modeled using one CD, one OD, one IOD, and5 SDs. Figure 6.33 shows the CD of the system. There are 5 classes taking careof the different processing steps, namely SignalPackaging, SweepProcessingHdl, Post-Processing, DopProcessing and Thresholding. Each of the previous classes is instantiedby one and only one object, whose names are respectively spm1, swp1, pp1, dop1 andthres1. When some new incoming data is received by the spm1:SignalPackaging ob-ject, the SD of Figure 6.34 is activated. The data is stored into a input queue, mod-eled using an instance of the DataFifo class, afterwards it is packaged using an in-stance of the BurstSender class, and finally is prepared for the bus using an instanceof the BusDataBox class. The entire procedure should not take more then 5 time units(i.e. 5ms) therefore the following time constraint is added: @SignalPackaging.end [email protected] <= 5 where SignalPackaging is the name of the SD and Sig-nalPackaging.start and SignalPackaging.end are the start/end events of the SD. Afterthe signal packaging procedure is terminated the sweep processing procedure starts.The swp1:SweepProcessingHdl object activates the processing chain described in theSD of Figure 6.35. First the param:ParameterStore object sends the parameters tobe used during the processing to the different elements involved in the computation,i.e. the to the sat:SaturationDetection object, to the cal:Calibration object and to thepc:PulseCompression object. When this preliminary phase is completed the data is readfrom the bus using the inBox_sph: BusDataBox object, it is passed through the com-putation chain made of saturation detection, calibration and pulse compression, andfinally the data is sent through the bus again using the outBox_sph:BusDataBox object.The entire procedure should not take more then 10 time units (i.e. 10ms) thereforethe following time constraint is added: @SweepProcessingHdl.end - @SweepProcess-ingHdl.start <= 10. The signal packaging and the sweep processing are followed bythree further sequential processing steps, the doppler processing, the data thresholdingand the post processing. The doppler processing is shown by the SD of Figure 6.35and is activated by the dop1:DopProcessing object. The data to be computed are takenfrom the dopEvtBox:DataBox and the inBox_dp:DataBox objects respectively. After-wards the doppler computation is performed using the dopAlgoStep:DopAlgo object,and finally the output data is written using the outBox_dp:DataBox object. The entire

105


procedure should not take more then 10 time units (i.e. 10ms) therefore the followingtime constraint is added: @DopProcessing.end - @DopProcessing.start <= 10. Afterthe doppler processing, the data thresholding shown in the SD of Figure 6.37 is acti-vated. The thres1:Thresholding object starts the procedure. The wrk:MultiStepWorkerobject first gathers the data from the evtBox:DataBox and the inBox_th:DataBox ob-ject, afterwards the data thresholding is calculated in three steps performed by the al-goStep1:CashCfarAlgo, algoStep2:ThresholdAlgo and algoStep3:BIAlgo objects. Fi-nally the resulting data is written using the outBox_dh:DataBox object. The entireprocedure should not take more then 10 time units (i.e. 10ms) therefore the followingtime constraint is added: @Thresholding.end - @Thresholding.start <= 10. The laststep performed by the Radar Processor system to the incoming data is the post pro-cessing procedure shown in the SD of Figure 6.38. The procedure is started by thepp1:PostProcessing object which delegates to the fpWrk:SingleStepWorker object thetask of retrieving the data from the fpEvtBox:DataBox and inBox_pp:DataBox objects.Afterwards the post processing computation is performed by the fpAlgoStep:FpAlgoobject, and the resulting data is written using the outBox_pp:DataBox object. Theentire procedure should not take more then 10 time units (i.e. 10ms) therefore the fol-lowing time constraint is added: @PostProcessing.end - @PostProcessing.start <= 10.The IOD of Figure 6.39 shows how the different SDs are connected each other. TheAntennaDataInterrupt signal used in the IOD is declared in the CD and models theoccurrence of the new data coming from the antenna that need to be processed. Theentire processing chain must be completed within a 100ms.


The property that we want to verify on the system is that the entire data transformationcannot last more than 100ms. In order to do that a Time Propery has been defined(see Figure 6.40). The property states that whenever the AntennaDataInterrupt occurs,within 100 time instants in the future the putData_out_Message occurs. Zot proved in546 seconds that the property holds for the system. 4

4On an machine running Ubuntu 11.04 Intel(R) Xeon(R) CPU E5530 @ 2.40GHz with 24GB of RAM

106


Figure 6.33: CASSIDIAN Case Study: The CD of the Radar Processor System.

Figure 6.34: CASSIDIAN Case Study: The Signal Packaging SD.

107


Figure 6.35: CASSIDIAN Case Study: The Sweep Processing SD.

Figure 6.36: CASSIDIAN Case Study: The Doppler Processing SD.

Figure 6.37: CASSIDIAN Case Study: The Data Thresholding SD.

108


Figure 6.38: CASSIDIAN Case Study: The PostProcessing SD.

Figure 6.39: CASSIDIAN Case Study: The IOD shows the transformation chain done by the RadarProcessor each time a new data is available.

109


Figure 6.40: CASSIDIAN Case Study: The Time Property Diagram saying that if theAntennaDataInterrupt occurs, then within 100 time instants the putData_out_Message occurs.

110

6.5. Lessons Learned

6.5 Lessons Learned

In this chapter we analyzed three different case studies; the CCAS, the TXT RadarGUI and the CASSIDIAN Radar Processor. The case studies all belongs to the embed-ded system domain and mainly differs between each other for the number of diagramsinvolved. Each case study has been verified against a time property expressed usingthe TPD notation. One of the goals of the Corretto prototype verification tool is toallow UML model designers to carry out the formal verification of their models in auser-friendly manner by hiding the many unnecessary details about the creation of theformal representation and the enactment of the verification phase. Corretto succededin providing an integrated environment where the user does not need to understand theunderlying formalism for the enactment of the verification phase. The combination ofan automatic translation process and the possibility to specify properties using a highlevel notation like TPDs provides the means to hide the underlying temporal logic for-malism. On the other hand the traceability tool still needs to be improved. End usersmostly get confused by the great - and somehow disorganized - amount of informationprovided in the counterexamples. Despite this, the preliminary results are encouraging.Users can map the results of the verification phase (i.e. textual counterexamples) to theUML model elements and are able to understand why the property is violated withoutthe need of analyzing the underlying metric temporal logic formulae. Future works willbe concentrated on improving the user interface to resemble the debug interface of wellknown programming languages.

The MADES UML language has been proposed as a verifiable subset of UML fortimed systems. The goals of the language are (i) to reduce the complexity of the UMLspecification, (ii) to define the models which can be formally verified, (iii) to selectan interesting subset of MARTE/UML that can be used for the verification of timedsystems. In our experiments we found out that MADES UML was definitely able tomodel the systems under analysis. In particular the integration of the different views(especially IODs and SDs) has been crucial to express the desired behaviors of thesystems. Our industrial partners also did a massive usage of time constraints for thedescription of the timed behavior of the diagrams proving the effectiveness of this con-struct inspired by the MARTE/UML profile. Despite this we believe that a number ofimprovements is still needed; for the embedded systems domain the support of UMLcomponent diagrams is definitely desirable. The Radar processor case study - originallymodelled using Component diagrams - has been translated into CDs resulting into anexplosion of the graphical connections between the elements. For larger models thismay be a problem, therefore future works will exploit the flexibility of the MADESsemantics to integrate Component Diagrams in our approach. We also needs to includea greater support for ADs - besides the one provided by the IODs -, and for hierarchicalstate machines, to broaden the verifiable set of syntactic elements and starts targetingcase studies belonging to more complex domains were a greater number of objects anda greater degree of concurrency is involved.

The verification framework proposed in this thesis must also face the well knowstate explosion problem. Right now we only analyzed fairly small models, even if webelieve that their size is already reasonable to express complex and interesting behav-iors. Table 6.1 shows the performance of Zot for the different case studies presented

111


in this thesis. The Objects, Messages and States columns displays the correspondingnumber of UML elements of the case study. The Predicates column display the numberof metric temporal logic predicates generated by Zot.

MODEL OBJECTS MESSAGES STATES PREDICATES SATISFIABILITY PROPERTY

CCAS 9 4 7 65 35s 33sTXT 16 28 10 169 395s 188s

CASSIDIAN 60 28 0 157 271s 500s

Table 6.1: The performance of Zot with the different models analyzed. The timeboud (i.e. the searchhorizon for Zot) is equal to 100.

The last two columns show the execution times for the simple satisfiability problem(i.e. the formal model is run without a property to be verified), and for the verificationof a user defined property. The CCAS case study is a fairly simple and small example,therefore the verification time is around half minute for both the satisfiability problemand the property verification. The TXT case study generates the biggest number ofpredicates, while the CASSIDIAN one takes the biggest amount of time (around 8min) to verify the desired property. The number of predicates is a measure of thecomplexity of the underlying formal model even if is not entirely representative. Forexample having a model with a smaller number of predicates does not imply that theverification time will be smaller, like in the case of the CASSIDIAN model and theTXT model. Due to the complexity of the underlying verification tools and procedures,it is quite difficult to predict if a model will require a long time to be verified or not.What makes a model a complex one - therefore increasing its verification time - is itslevel of nondeterminism, which unfortunately cannot be measured. This task is still upto the experience of the formal verification expert that looking at the model and at thegenerated semantics may guess the verification time.

If the model to be verified is too big for being analyzed, the flexibility of the se-mantics presented in this thesis provides the opportunity to verify partial models, i.e.subsets of the model that the user considers interesting for the verification of a certainproperty. By selecting only the diagrams containing the interesting behaviors, the usercan shrink down the verification performance by a considerable factor. This is whatactually happened in the case of the CASSIDIAN case study where only a portion ofthe Radar system has been selected for the verification by our industrial partners. Oncethe user select a subset of the model he can start experimenting to see how the differentparts affect the validity of a certain property, therefore trying to expand the subset untilthe verification time remains reasonable.

112

CHAPTER7Conclusions

UML is a well known and widely used design notation that relies on models to improvethe quality and maintainability of software systems. UML has gone from a relativelybasic descriptive tool, i.e. a tool that serves to document software systems, to a sophisti-cated prescriptive one, that is, a tool that can be used to specify, analyze and implementcomplex software systems. The idea of applying formal verification techniques for theanalysis of UML models is not new. However, despite the great research effort of thelast ten years, the results have been definitely below the expectations. Today we are notyet able to translate a general purpose UML model made of different views combinedto your liking into a formal representation. This is especially true if we consider theUML behavioral diagrams, such as activities, interactions and state machines. The sizeof the UML specification and the absence of a precise definition of how the differentbehavioral views must be combined are just some of the root causes of this result. Also,the vast majority of research works only concentrated on how to translate the differentUML behavioral views into the semantic domain which is most suitable to representthe diagram of choice. This - partial - formalization effort lead to a number of for-mal semantics which neglect the interdependencies with the other views of the system,making the verification of heterogeneous UML models unfeasible. To make this pictureeven more complicated we must face the problem that the formal verification of UMLmodels is still a niche activity mostly confined to academia. Building a formal modeltypically requires a good knowledge of both the problem domain and of the tool that isused for the verification. This also requires mastering techniques like abstraction andrefinement, model checking, or theorem proving that require a dedicated background.As a consequence most UML engineers will not be able to take advantage of the modernverification technologies.

Solving the previously stated problems is required if we want to spread UML formal

113

Chapter 7. Conclusions

verification at large scale, where appropriate technology and tools will be available toallow to any average engineer to use any UML model at the earliest stages of the design,verify complex properties and follow the results of this verification. The first steptowards this goal is to build a unified semantics of the different views which is modularand extendible. New diagrams may be added/removed/modified from the standard, anddomain specific UML profiles will be defined together with user defined ones. Thesemantics must be flexible enough to cope with this variability while increasing thenumber of supported diagrams. In turn this is translated into a great value for theend user who will be able to select from a multitude of diagram types, each of thememphasizing a particular aspect of the system. Second, we must build methods andtools which go beyond the simple translation of UML models to their correspondingformal semantics. A full verification framework must be able to support not only theformal verification (i.e. run the analysis) but also the comprehension of its results, whileremaining within the scope of UML as much as possible.

This thesis is a first step towards this research roadmap. With respect to the state-of-the-art tools we are now able to verify UML models made of multiple behavioral viewsand to translate them into a unified semantics based on a metric temporal logic. Werely on a significant subset of UML with a consistent and coherent interpretation calledMADES UML which includes several UML behavioral views (Sequence Diagrams,State Diagrams, Interaction Overview Diagrams) together with static ones (Class Di-agrams, Object Diagrams). The unified semantics is based on the TRIO [16] metrictemporal logic. The logic based formalization fosters: (a) decoupling, of the semanticswith respect to the predicates that represent the elements of MADES UML models toease the definition of different semantics, (b) extensibility, since adding a new diagramtype entails defining the predicates that represent its elements, and their associatedaxioms, and (c) partiality, since it supports the analysis of partial models by simplyavoiding the translation of the diagrams the user is not interested in. Moreover theframework has been designed for users with little or no background on formal verifi-cation. The users can express the properties of interest using a high-level UML likenotation called Time Property Diagrams (TPDs). TPDs are an extension of Class Di-agrams - defined by means of a suitable UML profile - to build linear temporal logicproperties. They represent an excellent compromise between usability and expressive-ness. Finally verification results can be analyzed directly on the UML model by meansof a simple traceability mechanism. If the property specified by the user does not hold,then the counterexample returned by ourZot model checker is enriched with hyperlinkshighlighting the corresponding elements in the UML model.

A number of difficulties have been found both in the definition of MADES UMLand the TRIO metric temporal logic semantics. The primary goal in the definition ofMADES UML was to build a verifiable subset of UML for timed systems. The size ofthe UML specification has hampered the definition of a subset which was expressiveenough to cope with the domain of interest but concise enough to be translated into aformal language. A certain number of interesting UML operators have been excludedfrom MADES UML to be realistic and to bring this research project to completion. Wecoped with this limitation by proposing a semantics which is extensible and that canaccomodate new UML operators as soon as they will be formalized. The UML specifi-cation is also unclear about how the different UML behavioral views can be integrated.

114

Multiple meanings can be ascribed to the models made of multiple behavioral views,but no suggestion is provided by the standard. This issue has been partially solved withthe definition in MADES UML of a set of shared events between the different views.However, different interpretations are still possible and we decided to ascribe the onesthat were best suited for our application domain, i.e. timed systems, leaving the explo-ration of the remaining ones for the future. Also the definition of the metric temporallogic semantics has not been done without difficulties. In fact, despite the expertise ofthe author in building metric temporal logic specifications, the declarative nature of thelanguage does not resemble the operational style of many of the UML behavioral dia-grams, like sequence diagrams or activity diagrams, leading to a number of technicaldifficulties that came out over time together with different axiomatization styles. Theone presented in this thesis is the result of a series of iterations that have contributedto definition of its properties: decoupling, extensibility and partiality. Also designinga framework for users with little or no background on formal verification has not beentrivial. Making the translation process of the UML models into their correspondingformal notation automatic was an essential requirement. Afterwards, the problem offinding a visualization to express the properties to be proved on the model was defi-nitely not easy to solve. The UML specification has no suggestions on this topic andthe works in literature present ad-hoc solutions where sometimes the expressiveness ofthe property is limited in favor of its usability. For example, using a sequence diagramto check wheather its trace is accepted by a set of state machines is an easy mechanismto express a property, but we drastically limit the scope of the properties we can prove.After some experiments with both SDs and StDs to express the properties we com-mitted the decision of working with a profile extension of class diagrams with TRIOoperators and for the moment we are more then satisfied of the result. A similar diffi-culty arised while working on improving the way verification results can be analyzed.Also here different solutions have been investigated; the one which is mostly used isliterature is based again on sequence diagrams, but we argue that often it does not scalegrafically and its a viable solution only when the models are made of just one type ofdiagram, e.g. state diagrams. But what if the model is made of SMs, SDs, and ADs?How the counterexample looks like? The solution provided by our traceability tool isto link the elements of the counterexample to the UML model, which is simple andindipendent from the type of views used in the model.

The result of the above mentioned efforts is the Corretto verification tool, anEclipse plugin for the verification of MADES UML models. The MADES UMLmodel is built inside the Eclipse environment using Papyrus which is enriched withthe MADES UML profile to let the user specify the property of interest using TPDs.When the user is ready to run the verification, Corretto translates the MADES UMLmodel into its corresponding metric temporal logic semantics by means of a standaloneJava application which in turn relies on theZot bounded model/satisfiability checker forTRIO. Verification results, i.e. counterexamples, can be analyzed using the Correttotraceability interface linking the elements of theZot counterexample to the correspond-ing elements in the UML model. Even if Corretto is still a prototype tool we believethis is a big step towards a push button technology for the verification of the UMLmodels. The current limitations include the limited number of compliance checks tosee if the UML model built by the user is included in MADES UML or not, and the

115

Chapter 7. Conclusions

traceability interface which is not yet as user-friendly as we want.The assessment of the framework has been done through a number of case studies

coming from the industrial partners of the MADES European Project including twocomponents of a RADAR systems and a Car Collision Avoidance System (CCAS) pre-sented in this thesis. By exploiting the features provided by Corretto end-users havebeen able to model the target systems using MADES UML and verify the properties ofinterest in a matter of minutes. End-users made an extensive usage of the novel lan-guage features proposed in MADES UML like time constraints and the events notation.The results witness the soundness of the approach and motivate further analyses.

7.1 Future Work

The above results suggest a large number of improvements and research directions.Some of them are more theoretical while other ones are more technical.

Regarding the theoretical ones one of the problems which has not been addressedin deep detail in this thesis is how to fight the classical state explosion problem whichis still hampering the exploitability of model checking when dealing with large sizedmodels. Many recent works demonstrate that is possible to exploit domain specificoptimizations to improve the verification performance on large models [4] [29]. Op-timizations in our metric temporal logic approach can be done at two different levels:the first one is to try to optimize the MADES semantics understanding what are the ax-ioms that mostly affect the performance of the verification and check if we can providelightweight alternatives by using different styles of formalization; the second one is totune how Zot encodes our TRIO models into satisfiability problems in order to exploitpossible domain-specific symmetries of the UML semantics we propose.

Another interesting theoretical question we are planning to answer is how our method-ology would work when dealing with UML models which are developed iteratively. Ateach iteration the UML model is refined adding additional diagrams detailing the high-level view described in the previous iteration. We found out that this is widely used inthe industry but it is not specifically addressed by any of the research works in the UMLverification literature. Some of our preliminary experiments demonstrates that MADESUML definitely provides some instruments to link the diagrams at the different stagesof the refinement chain, for example by using time constraints, but this needs to be fur-ther investigated. In particular MADES UML needs to be extended to support the UMLelements to model the different abstraction relationship, and the semantics should bemodified to take care of this extension; the current semantics shows how it is possibleto integrate different UML behavioral views at same level of abstraction, but nothinghas been said about the possibility of having a model where different abstraction levelsare present.

Regarding the MADES UML semantics it would be also interesting to comparethe TRIO metric temporal logic semantics we ascribed with a (possibly) equivalent onewritten using another formalism. This would be useful both to compare the flexibility ofthe metric temporal logic approach with another one, and to compare the performancesof the different model checking tools. This task is far from trivial, first because it maynot be the case that the different formal languages have the same expressive power (forexample most of them are not able to deal with the time dimension), and second because

116

7.1. Future Work

learning how to make a consistent and extensible semantics in a new formalism needsa certain degree of expertise that is not obvious. For the ones which support the timedimension we are planning to explore the IF language and tools [9], while between theones that do not support the time dimension we are planning to experiment with theNuSMV model checker [17].

A complementary set of future works are the ones related to the technical devel-opment of Corretto. Corretto is still a prototype tool and can be improved inmany directions: first, the users needs better support for the translation of the UMLmodels especially to check if the model they built is supported by MADES UML ornot. Right now the Papyrus interface supports most of the UML elements of the OMGspecification, but there is no evidence if an element is supported by MADES UML ornot rather then the documentation provided with this work. If the UML model is notsupported right now Corretto refuses to translate the model. Second, we need to im-prove the awareness of how the MADES UML semantics works. UML designers oftenmake wrong assumptions about the UML semantics by building their own on-the-flysemantics. In order to let the user play with the MADES UML semantics we aim to im-plement a simulation tool that can animate the models giving the users a way to debugand therefore understand the semantics. Currently the only way to debug the semanticsis to ask Zot random execution traces that satisfies the system specification. This canbe done by starting the verification procedure without specifying any property.

The MADES UML language itself must be enlarged iteratively to support an in-creasing number of different views starting from Component Diagrams (CpDs) andActivity Diagrams (ADs). In particular the absence of CpD is one of the most impor-tant deficiencies identified by our industrial partners. CpDs are particularly useful toavoid the explosion of the number of classes in the system by grouping the elementsinto components enriched by suitable interfaces.

Finally, regarding the evaluation of the framework, we aim at solving a great num-ber of new UML models belonging to different domains, especially the ones whereconcurrency is involved. This aspect has not been deeply covered in our case studiestherefore it needs further analysis. This may guide both the integration of the new UMLoperators from the OMG specification into MADES UML and also the extension of thecurrent semantics to deal with the new concepts.

117

Bibliography

[1] Wolfgang Ahrendt, Thomas Baar, Bernhard Beckert, Richard Bubel, Martin Giese, Wolfram Menzel, WojciechMostowski, Andreas Roth, Steffen Schlager, and Peter H Schmitt. The KeY tool Integrating object orienteddesign and formal verification. Software and Systems Modeling, pages 32–54, 2005.

[2] Charles André, Frédéric Mallet, and Robert de Simone. Modeling Time(s). In Model Driven EngineeringLanguages & Systems (MoDELS), volume 4735 of LNCS, pages 559–573, 2007.

[3] L Apvrille, J.-P. Courtiat, C Lohr, and P de Saqui-Sannes. TURTLE: a real-time UML profile supported by aformal validation toolkit. IEEE Transactions on Software Engineering, 30(7):473–487, 2004.

[4] Luciano Baresi, Carlo Ghezzi, and Luca Mottola. Loupe: Verifying Publish-Subscribe Architectures with aMagnifying Lens. IEEE Transactions on Software Engineering, 37(2):228–246, March 2011.

[5] Luciano Baresi, Angelo Morzenti, Alfredo Motta, and Matteo Rossi. From interaction overview diagrams totemporal logic. Models in Software Engineering, 6627(i):90–104, 2011.

[6] Marcello M Bersani, Achille Frigeri, Matteo Pradella, Matteo Rossi, Angelo Morzenti, and Pierluigi SanPietro. Bounded Reachability for Temporal Logic over Constraint Systems. In Temporal Representation andReasoning (TIME), 2010.

[7] T Bouabana-Tebibel. Semantics of the interaction overview diagram. In IEEE International Conference onInformation Reuse Integration (IRI), pages 278–283, 2009.

[8] Thouraya Bouabana-Tebibel. Roles at the basis of UML validation. Journal of Computing and InformationTechnology, pages 171–183, 2007.

[9] Marius Bozga, Susanne Graf, Ileana Ober, Iulian Ober, and Joseph Sifakis. The IF Toolset. In Formal Methodsfor the Design of Real-Time Systems (SFM-RT), pages 237–267, 2004.

[10] Manfred Broy and María Victoria Cengarle. UML formal semantics: lessons learned. Software and SystemsModeling, 10(4):441–446, June 2011.

[11] Manfred Broy, Michelle L Crane, Jürgen Dingel, Alan Hartman, Bernhard Rumpe, and Bran Selic. 2nd UML2 Semantics Symposium: Formal Semantics for UML. In Workshops and Symposia at MoDELS 2006, volume4364 of LNCS, pages 318–323, 2006.

[12] S Burmester, H Giese, M Hirsch, and D Schilling. Incremental Design and Formal Verification with UML/RTin the FUJABA Real-Time Tool Suite. In International Workshop on Specification and vaildation of UMLmodels for Real Time and embedded Systems (SVERTS), 2004.

[13] Sven Burmester, Holger Giese, Martin Hirsch, Daniela Schilling, and Matthias Tichy. The fujaba real-timetool suite: model-driven development of safety-critical, real-time systems. In International Conference onSoftware Engineering (ICSE), ICSE ’05, pages 670–671, 2005.

[14] Jordi Cabot, Robert Clarisó, and Daniel Riera. UMLtoCSP: a tool for the formal verification of UML/OCLmodels using constraint programming. In IEEE/ACM international conference on Automated software engi-neering (ASE), ASE ’07, pages 547–548, 2007.

[15] Victoria Cengarle and Alexander Knapp. UML 2 . 0 Interactions : Semantics and Refinement. In CriticalSystem Development with UML (CSDUML), 2004.

119

Bibliography

[16] Emanuele Ciapessoni, Alberto Coen-porisini, Ernani Crivelli, Dino Mandrioli, and Angelo Morzenti. Fromformal models to formally-based methods : an industrial experience. ACM Transactions on Software Engi-neering and Methodology (TOSEM), pages 1–30, 1999.

[17] Alessandro Cimatti, Edmund M Clarke, Enrico Giunchiglia, Fausto Giunchiglia, Marco Pistore, Marco Roveri,Roberto Sebastiani, and Armando Tacchella. NuSMV 2 : An OpenSource Tool for Symbolic Model Checking.In Computer Aided Verification (CAV), 2002.

[18] Werner Damm, Bernhard Josko, Amir Pnueli, and Angelika Votintseva. A discrete-time UML semantics forconcurrency and communication in safety-critical applications. Science of Computer Programming, 55(1-3):81–115, 2005.

[19] Werner Damm and Bernd Westphal. Live and Let Die : LSC-Based Verification of UML-Models. In FormalMethods for Components and Objects (FMCO), pages 99–135, 2003.

[20] S Demathieu, Fr Thomas, Charles Andr, S G, and Fran Terrier. First Experiments Using the UML Profile forMARTE. IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Comput-ing (ISORC), (1):50–57, May 2008.

[21] Karsten Diethers and Michaela Huhn. Vooduu: Verification of Object-Oriented Designs Using UPPAAL. InTools and Algorithms for the Construction and Analysis of Systems (TACAS), volume 2988 of LNCS, pages139–143. 2004.

[22] Dov Dori. Why significant UML change is unlikely. Communications of the ACM (CACM), 45(11):82–85,2002.

[23] Christoph Eichner, Hans Fleischhack, Roland Meyer, Ulrik Schrimpf, and Christian Stehno. Compositionalsemantics for UML 2.0 sequence diagrams using Petri nets. In International SDL Forum, pages 133–148,2005.

[24] John Erickson and Keng Siau. Theoretical and practical complexity of modeling methods. Communicationsof the ACM (CACM), 2007.

[25] Rik Eshuis. Symbolic model checking of UML activity diagrams. ACM Transactions on Software Engineeringand Methodology, 15(1):1–38, 2006.

[26] Rik Eshuis. Reconciling statechart semantics. Science of Computer Programming, 74(3):65–99, 2009.

[27] Rik Eshuis and Roel Wieringa. A Real-Time Execution Semantics for UML Activity Diagrams. In Funda-mental Approaches to Software Engineering (FASE), volume 02, pages 1–15, 2001.

[28] Rik Eshuis and Roel Wieringa. Tool Support for Verifying UML Activity Diagrams. IEEE Transactions onSoftware Engineering, 30(7):437–447, 2004.

[29] Antonio Filieri, Carlo Ghezzi, and Giordano Tamburrelli. Run-time efficient probabilistic model checking. InInternational conference on Software engineering (ICSE).

[30] Robert France and Bernhard Rumpe. Model-driven Development of Complex Software : A ResearchRoadmap. In Workshop on the Future of Software Engineering (FOSE), 2007.

[31] Robert B France, Sudipto Ghosh, and Trung Dinh-trong. Model-driven development using UML 2.0: promisesand pitfalls. Computer, (February):59–66, 2006.

[32] Gerard J. Holzmann. The Spin Model Checker: Primer and Reference Model. 2004.

[33] Martin Glinz. Problems and deficiencies of UML as a requirements specification language. In 10th Interna-tional Workshop on Software Specification, number November, 2000.

[34] Martin Gogolla, Fabian Büttner, and Mark Richters. USE: A UML-based specification environment for vali-dating UML and OCL. Science of Computer Programming, 69(1-3):27–34, December 2007.

[35] Günter Graw and Peter Herrmann. Transformation and Verification of Executable UML Models. ElectronicNotes in Theoretical Computer Science, 101:3–24, November 2004.

[36] Youcef Hammal. A Formal Semantics of UML StateCharts by Means of Timed Petri Nets. In InternationalConference on Formal Techniques for Networked and Distributed Systems (FORTE), volume 3731 of LNCS,pages 38–52. 2005.

[37] Youcef Hammal. Branching Time Semantics for UML 2.0 Sequence. In Formal Techniques for Networkedand Distributed Systems, pages 259–274, 2006.

[38] Helle Hansen, Jeroen Ketema, Bas Luttik, MohammadReza Mousavi, and Jaco van de Pol. Towards modelchecking executable UML specifications in mCRL2. Innovations in Systems and Software Engineering,6(1):83–90, 2010.

120

Bibliography

[39] Helle Hvid Hansen, Jeroen Ketema, Bas Luttik, and Mohammadreza Mousavi. Automated Verification ofExecutable UML Models. In Formal Methods for Components and Objects (FMCO), pages 1–26, 2010.

[40] David Harel. What’s the Semantics of "Semantics"? IEEE Computer, 2004.

[41] Ø ystein Haugen, Knut Eilif Husa, Ragnhild Kobro Runde, and Ketil Stø len. STAIRS towards formal designwith sequence diagrams. Software and Systems Modeling (SOSYM), 4(4):355–357, October 2005.

[42] Oystein Haugen, Eilif Husa Knut, Runde Ragnhild Kobro, Stolen Ketil, Knut Eilif Husa, and Ragnhild KobroRunde. Why Timed Sequence Diagrams Require Three-Event Semantics. In Scenarios: Models, Transforma-tions and Tools, number December, pages 1–25, 2005.

[43] Frédéric Jouault, Freddy Allilaire, Jean Bézivin, and Ivan Kurtev. ATL: A model transformation tool. Scienceof Computer Programming, 72(1-2):31–39, June 2008.

[44] Stuart Kent. Model Driven Engineering. In Integrated Formal Methods, 2002.

[45] Alan Kirshin, Andrei Dotan, Dolev Hartman. A UML Simulator Based on a Generic Model Execution Engine.In MoDELS Workshops, 2006.

[46] Alexander Knapp and Jochen Wuttke. Model checking of UML 2.0 interactions. In Workshops and Symposiaat MoDELS 2006, volume 4634 of Lecture Notes in Computer Science, pages 42–51, 2006.

[47] Dimitrios S Kolovos, Richard F Paige, and Fiona A C Polack. The Epsilon Transformation Language. InInternational Conference on Theory and Practice of Model Transformations (ICMT), pages 46–60, 2008.

[48] Sabine Kuske, Martin Gogolla, Hans-Jörg Kreowski, and Paul Ziemann. Towards an integrated graph-basedsemantics for UML. Software & Systems Modeling, 8(3):403–422, August 2008.

[49] Marcel Kyas, Harald Fecher, Frank S. de Boer, Joost Jacob, Jozef Hooman, Mark van der Zwaag, TamarahArons, and Hillel Kugler. Formalizing UML Models and OCL Constraints in PVS. Electronic Notes inTheoretical Computer Science, 115:39–47, January 2005.

[50] K Lano. A compositional semantics of UML-RSDS. Software & Systems Modeling, 8(1):85–116, August2009.

[51] Diego Latella, István Majzik, and Mieke Massink. Towards a Formal Operational Semantics Of UML State-chart. In Formal Methods for Open Object-Based Distributed Systems (FMOODS), 1999.

[52] Johan Lilius and Ivan Porres Paltor. vUML: A tool for verifying UML models. Automated Software Engineer-ing (ASE), 1999.

[53] Mass Soldal Lund and Ketil Stolen. A Fully General Operational Semantics for UML 2.0 Sequence Diagramswith Potential and Mandatory Choice. In Formal Methods (FM), pages 380–395, 2006.

[54] Tom Mens and Pieter Van Gorp. A Taxonomy of Model Transformation. Electronic Notes in TheoreticalComputer Science, 152:125–142, March 2006.

[55] Zoltán Micskei and Hélène Waeselynck. The many meanings of UML 2 Sequence Diagrams: a survey. Soft-ware and Systems Modeling (SOSYM), 10(4):489–514, 2011.

[56] Leonardo De Moura and Nikolaj Bjø rner. Z3 : An Efficient SMT Solver. In Tools and Algorithms for theConstruction and Analysis of Systems (TACAS), pages 337–340, 2008.

[57] Iulian Ober and Iulia Dragomir. OMEGA2: A new version of the profile and the tools. International Confer-ence on Engineering of Complex Computer Systems (ICECCS), 2010.

[58] Object Management Group. Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification. Tech-nical Report January, 2011.

[59] OMG. UML Profile for MARTE : Modeling and Analysis of Real-Time Embedded Systems. Technical ReportNovember, 2009.

[60] OMG. OMG Unified Modeling Language Superstructure. Technical Report August, 2011.

[61] OMG Group. Semantics of a Foundational Subset for Executable UML Models (fUML), volume 15. 2011.

[62] Richard F Paige, Phillip J Brooke, and Jonathan S Ostroff. Metamodel-based model conformance and multi-view consistency checking. ACM Transactions on Software Engineering and Methodology (TOSEM), 16(3),2007.

[63] Richard F. Paige, Dimitrios S. Kolovos, and Fiona a.C. Polack. Refinement via Consistency Checking in MDA.Electronic Notes in Theoretical Computer Science, 137(2):151–161, July 2005.

[64] Ivan Paltor and Johan Lilius. Formalising UML State Machines for Model Checking. In International Confer-ence on the Unified Modeling Language (UML), volume 1723 of LNCS, pages 430–445, 1999.

121

Bibliography

[65] Zsigmond Pap, István Majzik, András Pataricza, and András Szegi. Methods of checking general safety criteriain UML statechart specifications. Reliability Engineering & System Safety, 87(1):89–107, January 2005.

[66] Matteo Pradella, Angelo Morzenti, and Pierluigi San Pietro. The symmetry of the past and of the future:bi-infinite time in the verification of temporal properties. In Joint meeting of the European Software Engineer-ing Conference and the ACM SIGSOFT International Symposium on Foundations of Software Engineering(ESEC/SIGSOFT FSE), pages 312–320, 2007.

[67] Matteo Pradella, Angelo Morzenti, and Pierluigi San Pietro. Refining Real-Time System Specificationsthrough Bounded Model- and Satisfiability-Checking. IEEE/ACM International Conference on AutomatedSoftware Engineering, pages 119–127, September 2008.

[68] Timm Sch, Alexander Knapp, and Stephan Merz. Model Checking UML State Machines and Collaborations.Electronic Notes in Theoretical Computer Science, pages 1–13, 2001.

[69] Harald Störrle. Semantics of Interactions in UML 2.0. In IEEE Symposium on Human Centric ComputingLanguages and Environments (HCC), pages 129–136, 2003.

[70] Harald Störrle. Semantics of UML 2 . 0 Activities. In IEEE Symposium on Visual Languages and Human-Centric Computing (VLHCC), 2004.

[71] Maurice H. ter Beek, Alessandro Fantechi, Stefania Gnesi, and Franco Mazzanti. A state/event-basedmodel-checking approach for the analysis of abstract system properties. Science of Computer Programming,76(2):119–135, February 2011.

[72] Paul Baker Shiou Loh Frank Weil. Model-Driven Engineering in a Large Industrial Context - Motorola CaseStudy. In Model Driven Engineering Languages and Systems (MoDELS), 2005.

122

Date post:	06-May-2018
Category:	Documents
Upload:	hoanglien
View:	217 times
Download:	1 times

L V M DIAGRAM UML M T S - Politecnico di Milano · 1.2 Logic based-veriﬁcation of Multi-diagram...

Documents