|
|
| (6 intermediate revisions by one user not shown) |
| Line 1: |
Line 1: |
| − | 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 an IDE for behavioral, scenario-based, programming, built around the language of [[live sequence charts| ''live sequence charts'' (LSC)]] and its Java derivative, and the play-in/play-out methods for programming and execution. |
| | | | |
| − | PlayGo is intended to constitute extensive support to the vision of [http://www.wisdom.weizmann.ac.il/~harel/papers/LiberatingProgramming.pdf Liberating Programming]. | + | PlayGo is intended to provide extensive support for the vision of [http://www.wisdom.weizmann.ac.il/~harel/papers/LiberatingProgramming.pdf "liberating programming"] |
| | | | |
| − | == Live Sequence Charts (LSC) ==
| + | [[Language & Concepts | More about the underlying language and concepts...]] |
| − | [http://www.wisdom.weizmann.ac.il/~harel/ 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 [http://www.wisdom.weizmann.ac.il/~playbook/ Come, Let's Play]. | + | |
| | | | |
| − | == Play-In == | + | == Implementation Overview == |
| − | 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.
| + | PlayGo is an IDE, implemented as a set of Eclipse plugins, and packaged as an Eclipse product. There is not need to install Eclipse prior to installing PlayGo. Additionally, PlayGo installation does not conflict with other Eclipse installations you may have on your computer. |
| − | 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.
| + | PlayGo uses [http://www.eclipse.org/modeling/mdt/?project=uml2#uml2 Eclipse UML2 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 language 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-Out ==
| + | Play-in is carried out on top of a user-defined UI (implemented in [http://download.oracle.com/javase/6/docs/technotes/guides/swing/ Java Swing] or a [http://code.google.com/webtoolkit/ GWT-based web application]). <br>Play-out is carried out by generated [http://www.eclipse.org/aspectj/ AspectJ] code (the target language of the [http://www.weizmann.ac.il/mediawiki/playgo/index.php/The_LSC_Compiler S2A compiler]) and related built-in play-out strategies, implemented in Java. Thus, the resulting target system, i.e., the application that one can develop using PlayGo, is built using standard technologies, can run on standard platforms, and can be shared via the Internet. |
| − | 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 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 [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 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 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 [http://www.wisdom.weizmann.ac.il/~maozs/tracer/ 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 [http://www.eclipse.org/modeling/mdt/?project=uml2tools 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 [http://code.google.com/webtoolkit/ GWT-based web application]. Thus, the resulting target system can be shared via the internet.
| + | |
| | | | |
| | == Additional Information == | | == Additional Information == |
| − | Additional links and papers on the underlying languages and ideas, as well as on current relevant research, can be found on [http://www.wisdom.weizmann.ac.il/~harel David Harel website] | + | Additional links and papers on the underlying languages and ideas, as well as on current relevant research, can be found on [http://www.wisdom.weizmann.ac.il/~harel David Harel's website] |
PlayGo is an IDE for behavioral, scenario-based, programming, built around the language of live sequence charts (LSC) and its Java derivative, and the play-in/play-out methods for programming and execution.
PlayGo is an IDE, implemented as a set of Eclipse plugins, and packaged as an Eclipse product. There is not need to install Eclipse prior to installing PlayGo. Additionally, PlayGo installation does not conflict with other Eclipse installations you may have on your computer.
Additional links and papers on the underlying languages and ideas, as well as on current relevant research, can be found on David Harel's website
