In this paper we presented an Unified Coordination Language (UnCL) that is based on a separation of concerns between coordination and computation. UnCL provides a general language for coordination given in UML that can be used both for simulation and coordination of an application at run-time. We discussed a precise semantics of UnCL state machines, the UnCL execution platform, and how to use an executable extension of XML specifications within this platform. Finally, we discussed the possibility of incorporating MoCha into UnCL.
UnCL relates to other coordination languages like Linda [CG90], JavaS- paces[EFA90], and MANIFOLD [Arb96]. For the majority of these models UML interfaces are made. However, as far as we know, UnCL is the first coordination language that fully integrates with UML. Besides modeling co- ordination a UnCL UML-specification can also coordinate an application in runtime. UnCL + MoCha relates to Reo[Arb04], an exogenous coordination language where complex channel connections are compositionally build out of simpler ones.
Other related work on coordination modeling are SOCCA [EG94] and CSP-OZ [MORW04]. SOCCA is an object-oriented specification language supporting the arbitrarily fine-grained synchronization of processes. Despite the fact that SOCCA is related to UML it is a separate language and not an extension like UnCL. CSP-OZ is an integrated formal method combining the process algebra CSP with the specification language Object-Z. It provides the means for putting special information (tags) in UML class diagrams. The full CSP-OZ specification is obtained after compiling these class diagrams, unlike UnCL where the specification is fully given in UML. Both CSP-OZ and UnCL + MoCha use channels as the coordination mechanisms. However, CSP-OZ channels are static while UnCL + MoCha channels are dynamic. This enables UnCL to specify dynamic reconfigurable coordination patterns. In our approach we abstract away from a particular scheduling algorithm. This gives us the advantage to make such an algorithm a parameter of an UnCL model. This is different from other work like [vdB01], [LMM99], and [PL99] where scheduling is already integrated into the semantics, making it more difficult to change the already present scheduling algorithm (if desired). Instead of using RML for the UnCL transformation rules we could have used other tools for XML transformations, like XSLT [Cla]. We chose RML because it was developed with more complex matching patterns in mind: The
6.5. CONCLUSIONS AND RELATED WORK 141 XML wild-cards defined with RML can be distributed over several places in the input. Such a distributed matching pattern is hard to define with XSLT, because XSLT templates are path oriented instead of pattern oriented.
We have successfully used the UnCL architecture in project OMEGA IST- 2001-33522, sponsored by the European Commission, where we formalized the OMEGA subset of UML and will apply it to industrial case studies. A first test case is demonstrated on-line at [Jacb].
Chapter 7
ATL Applied to the Tableau
Method
Author: Joost Jacob
7.1
Introduction
We have created a transformation language called ATL1 that can be used
to define facts and rules in a convenient way that is also suitable for non– programmers. We show how it can be used in a semantic tableau method to generate proofs, where the facts define axioms and the rules define theories. To do this, we create executable functions from ATL rules and these func- tions are then used in the implementation of a tool for the semantic tableau method. The tableau method we use is extended with equivalence classes in order to provide automatic unification. The resulting proof system is pow- erful but still transparant and easy to use since the axioms and theories are defined in the user’s own notation. Although full automationispossible, the prime goal of the proof system is not sophisticated automation of proof, but rather to make it convenient for the user to define axioms and theorems and to help with routine unification of equalities, in order to arrive at a kind of proofs where the emphasis is on elegance and where a high level of abstraction
1
ATL stands for ASCII Transformation Language, intended for manipulations of sym- bols that can be formed with an ASCII keyboard. The ASCII aspect is now outdated since also Unicode is supported, but the name stuck.
is encouraged. Such proofs can generally not be created automatically, the human contribution in the design of the proof is very significant. There is a growing demand for such proofs, because they are often easier to understand and thus more convincing2 than fully automatically generated versions, and
because they often help understand the subject matter better.
To demonstrate the above, and to provide a good motivation for the work in this paper, we follow an example that we encountered in the OMEGA[OME] project where we proof a property of a software model. Soft- ware is often incorrect and using a well–known prover like PVS [ORR+96],
as we did in OMEGA, only works well for a correct model. What to do if it is not correct? The tableau method, looking for a contradiction, seemed especially suitable for, abstract, high–level, software model verification.
We did investigate literature and the internet to see if we could find a tableau tool that we could use but we were unsuccessful. Our requirements for such a tool were that it would not have a steep learning curve, without for example having to learn a functional programming language like with ACL2 [KMM00], and we wished to be free in syntax notation and the tool should be preferably independent of an operating system, versioning problems, or software libraries. That is the reason we started this work. We have created a web–application, wherein the user can define rules in ATL, that can be used to derive the proof mentioned above. The development of ATL did help considerably to make it possible to create the web–application on schedule and in time and to make it easy to use. The tool also uses the Python [vR95] programming language that generates HTML for presenting the user with forms to fill in and that performs various bookkeeping tasks and is also used for the implementation of unification. We have plans to develop a scripting language that can be combined with ATL, or is an extension, to replace some of the Python software. An ATL interpreter is already available that could intheoryalready -do this, but we need to develop a very high–level language so the user can more easily define for instance proof search strategies. As it is now, the tool takes one derivation step at a time and the user is the scheduler: the user has to click on a button with a rule–name to choose a step. The web–application and the ATL tools are publicly accessible from the URL given in Sect. 7.3. In the web–application the user can derive a proof in the sandbox, or a new project can be started with new notation, new axioms and new theories.
2