Action Languages K268 SENG2100 Pat Browne

Executable UML An action, broadly, is some computation, such as executing a function, sending a signal, reading or writing data, and iterating over a set. Until recently, the actions defined for the UML are little more than placeholders (un-interpreted strings and graphical symbols). The modeller can indicate a few critical properties, such as sending a signal and invoking a function, but then must resort to writing code, because only a few special-purpose actions are defined. To be useful as more than a tool for sketching software structure, the UML repertoire of actions should be extended to be able to specify computation, making UML an executable specification language.

Executable UML The UML, as extended by action semantics, however, should not be taken to be a new programming language, or as a graphical programming language. There are already many programming languages that can be used with UML, or could be formally integrated with it, and the world doesn’t need yet another programming language. Rather, the action semantics provides for the specification of systems in sufficient detail that they can be executed, and the action semantics should provide just enough semantics to enable the specification of computation.

Executable UML A standard action semantics enables interchange of complete specifications in UML. Because the semantics are independent from the syntax, users can develop models using their own favourite syntax or language. Moreover, the definition of a standard syntax, being a matter of taste, is likely to be a lengthy and contentious process. Defining the semantics first also allows multiple conforming syntaxes to be developed onto a solid base. The action semantics defines primitive, simple constructs.

Executable UML The action semantics defines primitive, simple constructs. A particular action language could implement each semantic construct one-to-one, or it could define higher-level, composite constructs to offer the modeller both power and convenience. These higher-level constructs do not need to be defined as a part of the semantics, because they already exist as composites of primitives.

Executable UML The semantic primitives are defined to enable the construction of multiple execution engines, each with potentially different organizations. Hence, a model compiler builder can optimize the structure of the software to meet specific performance requirements, so long as the semantic behaviour of the specification and the implementation remain the same. This then requires a mapping from the structure of the specification to the structure of the implementation.

Executable UML Recent additions to the UML include action semantics, which facilitate the development of Action Languages (AL). AL animates UML models. In particular statecharts and interaction diagrams can be run by: 1) creating objects with the keyword create. 2) sending messages with the keyword generate.

Executable UML The action language is executable and allow us to describe the actions an object performs when receiving a stimulus. AL incluide the following functions: – Sequential Logic – Access to the data described by the Class Diagram – Access to the data supplied by signals initiating actions – The ability to generate signals – Access to timers – Access to synchronous operations provided by classes and objects – Access to operations provided by other domains – Tests and Transformations

Action Semantics for UML from OMG The UML is a rich and powerful language that can be used for problem conceptualization, software system specification, as well as implementation. The UML also covers a wide range of issues from use cases and scenarios, to state behaviour and operation declaration. However, the UML currently uses un-interpreted strings to capture much of the description of the behaviour of actions and operations. To provide for sharing of semantics of action and operation behaviour between UML modellers and UML tools, there needs to be a way to define this behaviour in a well-defined, interoperable form.

Action Semantics for UML from OMG Action Semantics are mapped to a syntax, and are combined with the UML. The aim is that the UML shall constitute a computationally complete language. This language is targeted at system analysis and behaviour description, and is not envisioned to be language suitable for system deployment.

Why Software-Platform-Independent Action Specifications? Model precision and level of implementation detail are two separate things. Software- platform-independent action specifications, in conjunction with the UML, can completely specify a computing problem without actually programming it.

Why Software-Platform-Independent Action Specifications? Such action specifications can be used to build complete and precise models that specify problems at a higher level of abstraction than a programming language or a graphical programming system. Such action specifications can support formal proofs of correctness of a problem specification.

Execution Model A new, separate UML execution model defines the state of a run-time system and relates it to the action specification. Users do not use the execution model directly to specify run-time systems. Run- time systems are created from the system model by execution semantics engines in accordance with the execution semantics rules. The execution model includes objects, links, and their attributes, as well as the run-time structure of active objects, activations, and tokens (the mechanisms that make execution work).

Executable UML Action Languagea (AL) are like OCL in that they can be used represent constraints. However OCL consists of pure expression that cannot affect the state of an object whereas AL can create objects and send messages to objects, hence permitting a greater range of modelling and testing. OCL is an expression language. It no side effects, this means that the state of the system will never change because of an OCL expression, even though an OCL expression can be used to specify a state change, e.g. in a post-condition.

Executable UML A constraint is a restriction on one or more values of an OO model. OCL is not a programming language, so it is not possible to write program logic or flow control in OCL. OCL is a typed language, so each OCL expression has a type. OCL facilitates some degree of 'executable specification' but AL takes this a stage further.

Executable UML Action languages can be used for testing dynamics of system object creation, sequence diagram, state charts. Constraints can also be written in an action language.

Executable UML Issues Action languages and OCL may make the lines between analysis, design, and implementation more fuzzy. Should UML be making a shift from a property-description language to an executable language, used mainly for programming? There may be a need for a non-executable as well as an executable version in the UML language. Both may co-exist and be used where appropriate.

Executable UML Issues If analyst/designer gets too involved in low level detail the following problems can arise: Efficient specifications: focus on efficiency rather than accuracy of specification.

Executable UML Issues The Problem of Over-Specification: If low-level details need to be specified then Java is a reasonable way to do it. A common mistake is to include more details than are necessary, spelling out unimportant details. This has been described as writing Java in pictures. This is well-known as the problem surely become worse if the tools are going to head towards being high-level programming language compilers.

Executable UML Issues Focus on the target language: When using code generators that map UML to a target language, the semantics of the target language as well as its notational capabilities tend to become visible on the UML level. For example, missing multiple inheritance in Java may restrict executable UML to single inheritance as well.

Why Not Just Use OCL? OCL is intended for expressing constraints, that is, relationships within a particular snapshot of a system. While OCL allows a modeller to specify conditions on changes to the instance model, these specifications are not executable, which is what actions are all about. OCL is not an action language.

Project Technology xUML Executable UML is a profile of the Unified Modelling Language with defined semantics for both the components and the interactions between them during execution.

Project Technology xUML The UML was originally designed to sketch the structure of object-oriented software systems. Consequently, it contains elements designed to map closely to software concepts such as class, task, parameter and so on. Given this sketch of the software, a designer/programmer can then fill in the details in the selected programming language to complete the system. In this view, there is little purpose in defining the details of actions closely- they might just as well be programmed directly.

Project Technology xUML There are many executable profiles that could be defined to select a set of meaningful components and how they interact during execution. For example, a object can invoke methods of other objects, which in turn invoke more methods, all in a completely synchronous environment. Only one thing happens at a time (the currently executing method) and the concept of a state machine is useful only as way to state constraints on the order of method execution.

Project Technology xUML The first profile defined for executable UML is one based on statecharts and asynchronous, distributed behaviour. Each object has a state machine that executes independently of all others. It is in just one state at a time, possibly executing many actions. It can invoke data access methods (that do not change state) synchronously, and it can send asynchronous signal events to communicate and synchronize with other independently executing state charts.

Project Technology xUML Both these elements and the interactions between them have a precise definition at run-time- sufficiently well-defined, in fact, to be executable, and translatable into multiple possible implementations. A model built in executable UML is therefore independent of software organization and implementation decisions: It is software-platform independent.

Why Don't We Just Use A Programming Language? A programming language such as Java provides both too much and too little. It provides too much because it allows the modeller access to implementation concepts (pointers or specifically allowable implementations of associations), yet it provides too little because a programming language does not understand UML concepts such as state or attribute typing, nor how the concepts fit together. Programming languages also over-specify sequencing.

How Does ALs Relate to Activity Diagrams? Actions can be used in activity graphs in the same way they are used in state machines. Each action state in an activity graph has an entry action specifying what is to be done at that step.

Java provides both too much and too little. It provides too much because it allows the modeller access to implementation concepts (pointers or specifically allowable implementations of associations), yet it provides too little because a programming language does not understand UML concepts such as state or attribute typing, nor how the concepts fit together. Programming languages also over-specify sequencing. Why not use Java or Prototypes

Can only test or check models: OCL is an expression language. It no side effects, this means that the state of the system will never change because of an OCL expression, even though an OCL expression can be used to specify a state change, e.g. in a post-condition. A constraint is a restriction on one or more values of an OO model. OCL is not a programming language, so it is not possible to write program logic or flow control in OCL. OCL is a typed language, so each OCL expression has a type. OCL facilitates the concept of an executable specification. Why not use OCL?

OCL is intended for expressing constraints, that is, relationships within a particular snapshot of a system. While OCL allows a modeler to specify conditions on changes to the instance model, these specifications are not executable, which is what actions are all about. OCL is not an action language. Why not use OCL?

The create object statements: create object instance myDog of Dog; The navigation expressions: select one owner related by myDog->DogOwner[R1] The generate statement sends a message to an object: generate D1:bark to myDog; Bridgepoint (BP) Executable UML

tion? The BP create objects of a subclass/superclass: create object instance shipClerk of ShippingClerk; The BP compound generalization: create object instance newBook of (BookProduct, SpecialOrderProduct); Bridgepoint (BP) Executable UML

BP reclassification by deleting the old subclass and creating the new one.: reclassify theClerk as OffDutyClerk; Use relate link objects: relate newBook to newAuthor across R2 creating newAuthorship; Use select to select the link object that relates two association end objects by selecting with identifier and referential attribute values. select theAuthorship that relates theBook to theAuthor across R2; Bridgepoint (BP) Executable UML

Restaurant System

Kennedy Carter Executable UML 1.reservation1 = create Reservation with table = “Table1”, date = “today”, time = “20:00” 2.reservation2 = create Reservation with table = “Table2”, date = “today”, time =”20:00” 3.restaurant = create unique Restaurant with booking = {reservation1, reservation2} 4.link restaurant R1 reservation1 5.link restaurant R1 reservation2 6.aBookingToday = find-one Restaurant where restaurant.booking.time = “20:00” 7.{bookingsToday} = find Restaurant where restaurant.booking.time = “today” 8.generate RG1:setArrivalTime(“20:00”) to aBookingToday 1)Two Reservations objects are constructed with three attribute values set, all inherited from Booking (table assumed by association). 2) A single restaurant object is created, there should be only one in the system (It has one attribute booking (by association with Booking) which is assigned to the set of Reservation objects. 3) Two associations are instantiated between the reservation objects and the restaurant. These are independent of the attribute assignment. 4) A single booking object is assigned to aBookingToday 5) A set of objects are assigned to a collection variable, by default a Bag. 6) A single setter message is sent to aBookingToday

Two Reservations objects are constructed with three attribute values set, all inherited from Booking (table by association). A single restaurant object is created, there should be only one in the system (from u. It has one attribute booking (by association with Booking) which is assigned to the set of Reservation objects, (through inheritance) Two associations are instantiated between the reservation objects and the restaurant. This is independent of the attribute assignment. A single message is sent to Kennedy Carter Executable UML

ALs summary Unlike conventional languages, there is no concept of a “main” function or routine where execution starts. Rather, ASL is executed in the context of a number of interacting state machines, all of which are considered to be executing concurrently and in the context of synchronous call stacks invoked from these state machines or directly from outside the system. Any state machine, on receipt of a signal (from another state machine or from outside the system) may respond by changing state. On entry to the new state, a block of processing is performed. This processing can, in principle1 execute at the same time as processing associated with another state machine.

ALs summary AL animates UML models. In particular statecharts and interaction diagrams can be run: –1) creating objects. –2) sending messages. The action language is executable and allow us to describe the actions an object performs when receiving a stimulus.

ALs summary AL features: –Sequential Logic –Access to the data described by the Class Diagram –Access to the data supplied by signals initiating actions –The ability to generate signals –Access to timers –Access to synchronous operations provided by classes and objects –Access to operations provided by other domains –Tests and Transformations

ALs summary Because ALs can create objects and send messages to objects, they permit a range of model prototyping and testing ALs can be used during analysis and design to specify and test (or check) general purpose constraints and other modeling needs. Half a mark for each of the following: To specify invariants on classes, attributes, associations and types in a class model; To specify type invariants for stereotypes; To describe pre- and post-conditions on use-cases, operations and methods; To describe guards; A transition in a state transition diagram can be coupled to an action. This action is a procedural expression that is executed when the transaction fires and it targeted at a specific object or at a set of objects. As a navigation language. This can help express constraints on loops in class diagrams. To specify constraints on operations. A message in a sequence or collaboration diagram can have an attached condition that specifies in what circumstances the message is sent. To express parameters. For example, messages in collaboration and sequence diagram can take parameters. To represent derived associations.

ALs and OCL summary In the UML context, the semantics of actions can be specified in one of two ways: –declarative, e.g. using OCL pre- and postconditions –operational, e.g. using action specification language statements Hence OCL can specify constraints about objects, but not perform operations on objects. Declarative specifications are good for testing and verifying, because pre- and postconditions can be tested and used to prove correctness. Declarative statements can cover all instances, associations, guards, navigations, multiplicities, etc. Declarative specifications facilitate the implementation of design by contract.. Declarative specifications are not particularly suitable to create executable models, because the execution of OCL expressions is ambiguous. ASL (Action Specification Language ) is designed to fill the semantic gap in UML and conforms to the UML Action Semantics Request for Proposal issued by the OMG. It supports platform independently action specifications for UML models and provides easy-to-understand operations on UML classes, objects and associations (which is not the case in usual programming languages). ASL useful for real-time embedded system, with high concurrency and timers/triggers required. ASL can directly model behavior whereas OCL can only model constraints about behavior.