Difference between revisions of "Language & Concepts"
(→Live Sequence Charts (LSC)) |
|||
| (9 intermediate revisions by one user not shown) | |||
| Line 2: | Line 2: | ||
[[Image:LSCExample.png | frame | <span style="color: rgb(0, 128, 128);"><span style="font-family: Tahoma;">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.</span> </span>]] | [[Image:LSCExample.png | frame | <span style="color: rgb(0, 128, 128);"><span style="font-family: Tahoma;">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.</span> </span>]] | ||
| − | PlayGo is | + | PlayGo is a development environment for the language of [http://www.wisdom.weizmann.ac.il/~harel/ 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 | + | 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 [http://www.wisdom.weizmann.ac.il/~playbook/Updates/ComeLetsPlay.pdf D. Harel and R. Marelly, Come, Let's Play: Scenario-Based Programming Using LSCs and the Play-Engine]. A language reference for the Java derivative implemented in PlayGo can be found [[Media:LSC Language Reference PlayGo.pdf | here]]. |
| − | + | An LSC system consists of scenarios, each of which describes a facet of the system’s behavior. Every scenario is described in a live sequence chart (an LSC). The overall system behavior is the result of concurrent execution of all LSCs. | |
| − | + | Objects in LSCs are represented by vertical lines, called lifelines. A lifeline can represent a concrete object or can denote a set of objects that participate in the scenario. Special kinds of lifelines represents the user and the environment. | |
| − | + | Messages in LSCs are represented by horizontal arrows between the participating lifelines. Messages can be tagged as to whether they must occur or may occur (hot vs. cold) and whether they are to be executed at that point of the scenario or only waited for (execute vs. monitor). | |
| − | + | Conditional guards, shown as elongated hexagons, specify statements that are to be true when reached. In addition LSCs may contain assignments and structural constructs (e.g., loops). | |
| + | LSCs can also specify forbidden behavior. | ||
| + | |||
| + | As stated above, the overall system behavior emerges from the simultaneous execution of all LSCs, complying with all constraints of what must, may or must not be executed at any given point in time. | ||
== Play-In == | == Play-In == | ||
Play-in is the process introduced in [http://www.wisdom.weizmann.ac.il/~playbook/ 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. | Play-in is the process introduced in [http://www.wisdom.weizmann.ac.il/~playbook/ 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. | ||
| Line 24: | Line 27: | ||
== Play-Out == | == Play-Out == | ||
| − | Play-out is the method introduced in [http://www.wisdom.weizmann.ac.il/~playbook/ 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. <br><br>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. <br><br> | + | Play-out is the method introduced in [http://www.wisdom.weizmann.ac.il/~playbook/ ''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. <br><br>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. <br><br>PlayGo implements play-out via compilation. It uses a variant of the [http://www.wisdom.weizmann.ac.il/~maozs/s2a/ 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 [[PlayGo Feature List#Play-out_strategies|strategies]]. [[PlayGo Demos#Play-Out|Watch a Play-Out demo]] |
== Debugging == | == Debugging == | ||
| Line 42: | Line 45: | ||
The system model is a centralized view from which one can observe and manage the object instances participating in the LSCs. | 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 | + | The system model provides details on the classes and objects that participate in the LSCs. It consists of three parts: classes, objects, including details on each (such as its type - the class it represents), and types, which can be used when defining properties of classes and objects (e.g., a state type that may have the values 'ON' and 'OFF'). |
[[Image:SystemModel.png|800px | System Model]] | [[Image:SystemModel.png|800px | System Model]] | ||
| Line 53: | Line 56: | ||
During play-out the system model objects are "linked" to the real application objects, thus showing real runtime values of object's properties. | During play-out the system model objects are "linked" to the real application objects, thus showing real runtime values of object's properties. | ||
| − | PlayGo | + | With PlayGo you can create the system model either manually by creating a new system model from the system model view or by importing the system model from a set of LSCs. |
| − | == Additional Information == | + | To learn how to create a system model, click [[How_to_create_a_system_model | here]]. |
| + | |||
| + | == Language Reference and Additional Information == | ||
Additional links and papers on the underlying languages and ideas, as well as on on-going relevant research, can be found on [http://www.wisdom.weizmann.ac.il/~harel David Harel's website] | Additional links and papers on the underlying languages and ideas, as well as on on-going relevant research, can be found on [http://www.wisdom.weizmann.ac.il/~harel David Harel's website] | ||
| + | |||
| + | An LSC Language reference is available for download [[Media:LSC Language Reference PlayGo.pdf | here]]. | ||
Latest revision as of 11:02, 23 September 2014
Contents
Live Sequence Charts (LSC)
PlayGo is a development environment for 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. A language reference for the Java derivative implemented in PlayGo can be found here.
An LSC system consists of scenarios, each of which describes a facet of the system’s behavior. Every scenario is described in a live sequence chart (an LSC). The overall system behavior is the result of concurrent execution of all LSCs.
Objects in LSCs are represented by vertical lines, called lifelines. A lifeline can represent a concrete object or can denote a set of objects that participate in the scenario. Special kinds of lifelines represents the user and the environment.
Messages in LSCs are represented by horizontal arrows between the participating lifelines. Messages can be tagged as to whether they must occur or may occur (hot vs. cold) and whether they are to be executed at that point of the scenario or only waited for (execute vs. monitor).
Conditional guards, shown as elongated hexagons, specify statements that are to be true when reached. In addition LSCs may contain assignments and structural constructs (e.g., loops).
LSCs can also specify forbidden behavior.
As stated above, the overall system behavior emerges from the simultaneous execution of all LSCs, complying with all constraints of what must, may or must not be executed at any given point in time.
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.
PlayGo implements play-out via compilation. It 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 objects that participate in the LSCs. It consists of three parts: classes, objects, including details on each (such as its type - the class it represents), and types, which can be used when defining properties of classes and objects (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.
With PlayGo you can create the system model either manually by creating a new system model from the system model view or by importing the system model from a set of LSCs.
To learn how to create a system model, click here.
Language Reference and 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
An LSC Language reference is available for download here.
