Difference between revisions of "PlayGo Examples"
|Line 42:||Line 42:|
Revision as of 09:49, 28 February 2013
The memory game is a simple application containing a single LSC that specifies the behavior of a memory game.
The memory game UI is based on GWT.
The memory game application demonstrates the following features:
- Symbolic Instances: memoryCard1 and memoryCard2 lifelines are symbolic: their lifeline head is dashed to visualize just that. The memory game contains 12 cards. During play-out, the clicked cards will dynamically be bound to specific card lifelines. The memory panel is represented by a static lifeline (there is a single panel in the game). This panel will be statically bound to the panel lifeline during play-out.
- Live copy: A second flipUp (the second time a user clicks on a card) opens another live copy of the LSC.
- Enable Events: After a second flipUp, the beep event is enabled in the first live copy but is not enabled in the second live copy. The second live copy expects another flipUp, and when this event does not occur (instead a beep event occurs) the live copy is violated and is closed.
The memory game application is included in the workspace provided with the PlayGo download.
The baby monitor application includes 14 LSCs, each of which includes 3-4 lifelines. The specification demonstrates various features of PlayGo and the underlying language.
Most of the LSCs were created by natural language play-in, and others by basic play-in.
To see the system's requirements in controlled English click here.
The Baby Monitor application is included in the workspace provided with the PlayGo download.
The water tap is a simple application containing three LSCs that describe a specific water tap behavior by which a sink is filled with lukewarm water.
The water tap application demonstrates the following concepts:
- Modularity - each LSC is self standing and is responsible for a certain aspect of the application's behavior.
- Incremental development - due to modularity, a system can be developed incrementally. Adding a new behavior affects the complete system behavior but does not require changes to existing LSCs or existing code.
- Enabled Events: The Interleave LSC shows how after the 'addHot' event occurs, only the 'addCold' event is enabled; Until 'addCold' occurs, 'addHot' is not allowed to occur, thus will wait for its turn.
- Loops are demonstrated here, bounded by a fixed limit (e.g., 5 times in the addHotFiveTimes LSC) or unbounded (in the Interleave LSC).