Difference between revisions of "About PlayGo"
(New page: PlayGo is a comprehensive tool for scenario-based programming, built around the language of Live Sequence Charts and its Java derivative, and the Play-in/Play-out approach. PlayGo is inte...) |
|||
| Line 7: | Line 7: | ||
== Play-In == | == 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 the way one programs a scenario-based system. | + | 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 the way one programs a scenario-based system. |
The user enters events by actually causing them to happen on the GUI; for example, by clicking buttons or entering text in display fields. Each such GUI operation is immediately and automatically reflected in the LSC, which is generated on the fly, and in the continuously accumulating underlying model. As part of the play-in process, instances and operations can be added to the LSC. An instance can represent a concrete GUI object or can stand for a set of GUI objects that participate in the scenario. A special type of instance represents the user or the environment. Operations represent method calls between the participating objects. In addition, LSCs may contain conditions, assignments and structural constructs (e.g. loops). | The user enters events by actually causing them to happen on the GUI; for example, by clicking buttons or entering text in display fields. Each such GUI operation is immediately and automatically reflected in the LSC, which is generated on the fly, and in the continuously accumulating underlying model. As part of the play-in process, instances and operations can be added to the LSC. An instance can represent a concrete GUI object or can stand for a set of GUI objects that participate in the scenario. A special type of instance represents the user or the environment. Operations represent method calls between the participating objects. In addition, LSCs may contain conditions, assignments and structural constructs (e.g. loops). | ||
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. | 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. | ||
| Line 15: | Line 15: | ||
== Play-Out == | == Play-Out == | ||
| − | Play-out is the method introduced in Come, Let's Play for executing LSC specifications. Thus, play-out is the mean 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 follow 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 which event to execute based on some strategy. In the "naïve" play-out technique, these choices are made nondeterministically, and could 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. | + | Play-out is the method introduced in Come, Let's Play for executing LSC specifications. Thus, play-out is the mean 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 follow 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 which event to execute based on some strategy. In the "naïve" play-out technique, these choices are made nondeterministically, and could 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 only, 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. | The current version of PlayGo implements naïve play-out only, 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 | Watch a Play-Out demo | ||
| − | + | == Debug == | |
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 with 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 be used as input for the Tracer tool. | 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 with 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 be used as input for the Tracer tool. | ||
| Line 26: | Line 26: | ||
Play-in is implemented on top of a user-defined GWT-based web application. Thus, the resulting target system can be shared via the internet. | Play-in is implemented on top of a user-defined GWT-based web application. Thus, the resulting target system can be shared via the internet. | ||
| − | = = | + | ============================================== |
Additional links and papers on the underlying ideas, as well as on current relevant research, can be found on David Harel's website | Additional links and papers on the underlying ideas, as well as on current relevant research, can be found on David Harel's website | ||
Revision as of 11:44, 3 September 2010
PlayGo is a comprehensive tool for scenario-based programming, built around the language of Live Sequence Charts and its Java derivative, and the Play-in/Play-out approach.
PlayGo is intended to constitute extensive support to the vision of Liberating Programming.
Contents
Live Sequence Charts (LSC)
Live Sequence Charts is a visual language that extends classical message sequence charts with modalities and modularity, thus enabling intuitive and incremental specification of reactive systems. A full description of the language is given in the book Come, Let's Play.
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 the way one programs a scenario-based system. The user enters events by actually causing them to happen on the GUI; for example, by clicking buttons or entering text in display fields. Each such GUI operation is immediately and automatically reflected in the LSC, which is generated on the fly, and in the continuously accumulating underlying model. As part of the play-in process, instances and operations can be added to the LSC. An instance can represent a concrete GUI object or can stand for a set of GUI objects that participate in the scenario. A special type of instance represents the user or the environment. Operations represent method calls between the participating objects. In addition, LSCs may contain conditions, assignments and structural constructs (e.g. loops). 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 a 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 mean 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 follow 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 which event to execute based on some strategy. In the "naïve" play-out technique, these choices are made nondeterministically, and could 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 only, 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
Debug
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 with 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 be used as input for the Tracer tool.
Implementation
PlayGo is really a fully-fledged IDE, implemented as a set of Eclipse plugins, and packaged as an Eclipse product. The decision to choose Eclipse as the core infrastructure of PlayGo stems from Eclipse's strong architecture and its adaptation of existing standards (such as UML). Eclipse architecture dictates openness, standard ways to implement extensions and to integrate with other software modules defined as Eclipse plugins. Furthermore, we believe that the Eclipse approach to building IDEs, and the set of tools it provides, fit the vision and principles underlying PlayGo. PlayGo uses Eclipse UML2Tools plugin as its UML library, and extends it with an infrastructure library that provides an intuitive and generic mechanism for extending UML2 elements. This generic infrastructure hides the complexity of UML profiles from the developer, and is used in PlayGo for defining the UML-compliant variant of LSCs, which is the source for our S2A compiler. Most of the work is done by interface declarations, so the code that the developer is required to produce is minimal. Play-in is implemented on top of a user-defined GWT-based web application. Thus, the resulting target system can be shared via the internet.
==================================
Additional links and papers on the underlying ideas, as well as on current relevant research, can be found on David Harel's website
