An ASM Definition of the Dynamic OCL 2.0 Semantics [chapter]

Stephan Flake, Wolfgang Mueller
2004 Lecture Notes in Computer Science  
The recently adopted OCL 2.0 specification comes with a formal semantics that is based on set theory with a notion of an object model and system states. System states keep the runtime information relevant for the evaluation of OCL expressions. However, not all new language concepts of OCL 2.0 are already addressed in that formal semantics. We show how to overcome this by introducing new components to the object model and system states. This is the foundation for defining a dynamic semantics of
more » ... CL. In order to give precise rules that determine when the current system state has to be updated according to a change in the referred UML model, we make use of adequate mathematical means, namely Abstract State Machines (ASMs). Though our ASM specification also gives a clear definition for the evaluation of OCL constraints, it leaves sufficient flexibility for application specific implementations that have to determine when constraints are to be checked. Note that operations defined for ordered sets are basically the same as for sequences and that def-clauses are mapped to so-called OclHelper variables and operations [11, Section 7.4.4]. OclHelper variables and operations, in turn, are stereotyped attributes and operations of classifiers. Such variables and operations can be used in OCL expressions just like common attributes and operations. Thus, it only has to be ensured that no naming conflicts occur. We already integrated UML State Diagrams to OCL and defined a formal semantics for the predefined operation oclInState() [6] and also formally defined operators and operations for OCL messages [5] . These definitions are based on extensions of the work by Richters which heavily influenced the formal semantics of OCL 2.0 [13]. We introduced additional components to the object model and system states and could then give a denotational semantics by interpretation functions for the predefined OCL operations that are still missing in the formal semantics of OCL 2.0, e.g., the messagerelated operations hasReturned() and result(). This extension is also the foundation for defining a dynamic semantics of OCL, which is in the focus of this article. Note that the (extended) denotational semantics allow to evaluate OCL 2.0 expressions over given system states, but there are no precise rules that determine how system states have to be updated in relation to the execution of the referred UML model. To overcome this, we make use of adequate mathematical means for state-oriented operational definitions, namely Abstract State Machines (ASMs). ASMs were introduced by Gurevich [7]. Based on the notion of a virtual machine execution in combination with a mathematically precise notion of states and state transitions known as algebras, they provide a concise and rigorous but yet intuitive way to define system semantics. ASMs are well-established in the domain of formal specification and have already been successfully applied to define the semantics of, e.g., UML Activity Diagrams [1] and the run-to-completion step of UML State Diagrams [2] . The remainder of this article is structured as follows. The next section briefly outlines the basics of ASMs. In Section 3, we present the extensions to the object model and system states that are necessary to be able to evaluate OCL expressions that also make use of state-and message-related operations. Section 4 then presents the dynamic semantics of OCL with ASMs. In Section 5, we briefly discuss related work. Section 6 closes with a conclusion. Abstract State Machines Abstract State Machine (ASM) specifications can be understood as pseudocode over abstract data without any particular theoretical prerequisites. We here only list the basic definitions and refer to [7, 3] for a formal introduction and more details. An ASM specification comes in form of guarded function updates, called rules, of the form if Condition then < Updates> else < Updates> endif Rules are presented as nested if-then-else clauses with a set of function updates in their body. When executing the rules, the underlying ASM abstract machine executes state transitions with algebras as states. An algebra can be seen as a database of functions
doi:10.1007/978-3-540-30187-5_17 fatcat:pqxbf46sb5an7dxlbloxbpgkna