Formal Verification of Tokeneer Behaviours Modelled in fUML Using CSP

Much research work has been done on formalizing UML diagrams, but less has focused on using this formalization to analyze the dynamic behaviours between formalized components. In this paper we propose using a subset of fUML (Foundational Subset for Executable UML) as a semi-formal language, and formalizing it to the process algebraic specification language CSP, to make use of FDR as a model checker. Our formalization includes modelling the asynchronous communication framework used within fUML. This allows different interpretations of the communications model to be evaluated. To illustrate the approach, we use the modelling of the Tokeneer ID Station specifications into fUML, and formalize them in CSP to check if the model is deadlock free

An Automatically Verified Prototype of the Tokeneer ID Station Specification

The Tokeneer project was an initiative set forth by the National Security Agency (NSA, USA) to be used as a demonstration that developing highly secure systems can be made by applying rigorous methods in a cost effective manner. Altran Praxis (UK) was selected by NSA to carry out the development of the Tokeneer ID Station. The company wrote a Z specification later implemented in the SPARK Ada programming language, which was verified using the SPARK Examiner toolset. In this paper, we show that the Z specification can be easily and naturally encoded in the {log} set constraint language, thus generating a functional prototype. Furthermore, we show that {log}'s automated proving capabilities can discharge all the proof obligations concerning state invariants as well as important security properties. As a consequence, the prototype can be regarded as correct with respect to the verified properties. This provides empirical evidence that Z users can use {log} to generate correct prototypes from their Z specifications. In turn, these prototypes enable or simplify some verificatio activities discussed in the paper

Lightweight and static verification of UML executable models

Executable models play a key role in many development methods (such as MDD and MDA) by facilitating the immediate simulation/implementation of the software system under development. This is possible because executable models include a fine-grained specification of the system behaviour using an action language. Executable models are not a new concept but are now experiencing a comeback. As a relevant example, the OMG has recently published the first version of the “Foundational Subset for Executable UML Models” (fUML) standard, an executable subset of the UML that can be used to define, in an operational style, the structural and behavioural semantics of systems. The OMG has also published a beta version of the “Action Language for fUML” (Alf) standard, a concrete syntax conforming to the fUML abstract syntax, that provides the constructs and textual notation to specify the fine-grained behaviour of systems. The OMG support to executable models is substantially raising the interest of software companies for this topic. Given the increasing importance of executable models and the impact of their correctness on the final quality of software systems derived from them, the existence of methods to verify the correctness of executable models is becoming crucial. Otherwise, the quality of the executable models (and in turn the quality of the final system generated from them) will be compromised. Despite the number of research works targetting the verification of software models, their computational cost and poor feedback makes them difficult to integrate in current software development processes. Therefore, there is the need for efficient and useful methods to check the correctness of executable models and tools integrated to the modelling tools used by designers. In this thesis we propose a verification framework to help the designers to improve the quality of their executable models. Our framework is composed of a set of lightweight static methods, i.e. methods that do not require to execute the model in order to check the desired property. These methods are able to check several properties over the behavioural part of an executable model (for instance, over the set of operations that compose a behavioural executable model) such as syntactic correctness (i.e. all the operations in the behavioural model conform to the syntax of the language in which it is described), non-redundancy (i.e. there is no another operation with exactly the same behaviour), executability (i.e. after the execution of an operation, the reached system state is -in case of strong executability- or may be -in case of weak executability- consistent with the structural model and its integrity constraints) and completeness (i.e. all possible changes on the system state can be performed through the execution of the operations defined in the executable model). For incorrect models, the methods that compose our verification framework return a meaningful feedback that helps repairing the detected inconsistencies