Difference between revisions of "Language & Concepts"

Revision as of 07:28, 25 November 2013

Live Sequence Charts (LSC)

Figure 1: An LSC describing the basic move of a memory game. Note the red and blue elements in the diagram, indicating hot and cold LSC messages and conditions.

PlayGo is built around the language of live sequence charts (LSC) and its Java derivative. LSC is a visual language that extends classical message sequence charts mainly with a universal interpretation and must/may and monitor/execute modalities. A full description of the language is given in the book D. Harel and R. Marelly, Come, Let's Play: Scenario-Based Programming Using LSCs and the Play-Engine.

Objects in LSCs are represented by vertical lines, called lifeline. A lifeline can represent a concrete object or can stand for a set of objects that participate in the scenario. A special type of lifeline represents the user or the environment.

Messages in LSCs are represented by horizontal arrows between the participating lifelines. Conditional guards, showing up as elongated hexagons, specify statements that are to be true when reached. In addition LSCs may contain assignments and structural constructs (e.g. loops).

The overall effect of a chart is to specify a scenario of behavior, consisting of messages flowing between objects and things having to be true along the way.

LSCReference

Play-In

Play-in is the process introduced in Come, Let's Play for creating (specifying) scenarios by directly manipulating objects in the GUI of the system under development. Thus, play-in is the means for programming a scenario-based system. The user enters events by actually causing them to happen on the GUI; for example, by clicking buttons, selecting menu entries, or entering text in display fields. Each such GUI operation is immediately and automatically added to the LSC, which is generated on the fly, and in the continuously accumulating underlying model.

Technically, PlayGo enables play-in on top of a user-defined GUI application. In the current version of PlayGo, the GUI application is prepared outside the actual tool, and before starting the play-in process the GUI is fed into PlayGo. Currently PlayGo supports GWTbased web applications. We plan to support additional technologies in the future.
Watch a Play-In demo

The LSCs generated from the play-in process can be manipulated in the graphical editor, by changing the values of properties, either from the special properties view or programmatically, by using the LSC Generic Infrastructure API provided as part of PlayGo.

Play-Out

Play-out is the method introduced in Come, Let's Play for executing LSC specifications. Thus, play-out is the means for running a scenario-based program. Every execution of an operation is considered a step. Following a user action, the system executes a superstep - a sequence of the steps that follows the user action, and which terminates either at a stable situation where the next event is a user action, or when the entire execution terminates.

During play-out, the current state of each LSC is represented by a cut. Given the scenario-based nature of the specification, a cut may induce multiple events to be simultaneously enabled for execution. In this case, the play-out mechanism chooses the event to execute based on some strategy. In the "naïve" play-out technique, such choices are made nondeterministically, and may lead to violations. In the smarter play-out algorithms, the next step is carefully computed, using model checking or planning, in order to help avoid violations.

The current version of PlayGo implements naïve play-out, and does so via compilation. PlayGo uses a variant of the S2A Compiler, which transforms LSCs into AspectJ code. During compilation, each LSC is statically analyzed, and is translated into a scenario aspect that simulates an automaton whose states represent cuts and whose transitions are triggered by aspect pointcuts. Scenario aspects are locally responsible for listening out for relevant events and advancing the cut state accordingly. The compilation scheme generates a coordinator, implemented as a separate aspect, which observes the cut state changes of all active scenario aspects, chooses a method, and executes it. Also, S2A follows the "strategy" design pattern to enable integration of various strategies. Watch a Play-Out demo

Debugging

PlayGo provides unique debugging capabilities, especially tailored for scenario-based execution, which include built-in step and superstep modes. Breakpoints are defined at the model level, visually, on the charts themselves. The debugger uses cut state information collected from the generated scenario aspects to display the LSC cuts. This model-level debugging is integrated into the standard code level debugging, allowing the user work interchangeably on both levels of abstraction. During execution, PlayGo can generate model-based traces, which can then be used as input for the Tracer tool.

Figure 2: During a debug session, the current cut is displayed and LSCs locations can be highlighted. Note the play-out view at the bottom which shows a trace of the latest super step.



Figure 3: The red circle on the 'beep' message indicates a user-defined breakpoint

System Model

The system model is a centralized view from which one can observe and manage the object instances participating in the LSCs.

The system model provides details on the classes and instances that participate in the LSCs. It consists of three parts: classes, instances, including details on each (such as its type - the class it represents), and types, which can be used when defining properties of classes and instances (e.g., a state type that may have the values 'ON' and 'OFF').

Figure 4: System Model during play-out session. Note the real-time values of the object's properties (e.g. the value of isUp property of object memortCard0 is now set to true)

When creating a system model or modifying it, Java code is generated. This is the code that participates in play-out. One can play in scenarios from the system model, and trigger events from it during play-out. During play-out the system model objects are "linked" to the real application objects, thus showing real runtime values of object's properties.

PlayGo provides various ways for creating the system model: manually create a new system model from the system model view, import the system model from an existing running application and import the system model from a set of LSCs.

Additional Information

Additional links and papers on the underlying languages and ideas, as well as on on-going relevant research, can be found on David Harel's website