Difference between revisions of "PlayGo Examples"

Revision as of 12:03, 25 February 2014 (view source) Smadar (Talk | contribs) (→‎Water Tap) ← Older edit		Revision as of 12:10, 25 February 2014 (view source) Smadar (Talk | contribs) (→‎Phone) Newer edit →
Line 64:		Line 64:
	[[Image:SampleLSC.png]][[Image:PhoneGUI.png|200px]]<br><br>		[[Image:SampleLSC.png]][[Image:PhoneGUI.png|200px]]<br><br>
−	The project describes and implements a cell phone, including some common cell phone features, such as quick dial, lock and more. This project has been implemented using [[PlayGo Features List#Natural_Language_Play-in|NL play-in]]. Therefore, the example includes the controlled natural language to create each of the LSCs. <br> Details can be found [[Phone Specification|here]].	+	The project describes and implements a cell phone, including some common cell phone features, such as quick dial, lock and more. This project has been implemented using [[PlayGo_Feature_List#Natural_language_play-in|NL play-in]]. Therefore, the example includes the controlled natural language to create each of the LSCs. <br> Details can be found [[Phone Specification|here]].
	=== Wristwatch  ===		=== Wristwatch  ===

---

Revision as of 12:10, 25 February 2014

Applications

Memory Game

The memory game is a simple application containing a single LSC that specifies the behavior of a memory game. The memory game UI is written in Java Swing.
The memory game application demonstrates the following features:

• Symbolic Instances: card and anotherCard lifelines are symbolic: their lifeline head is dashed to visualize just that. The memory game contains 16 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 click (the second time a user clicks on a card) opens another live copy of the LSC.
• Enable Events: After a second click, 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 click, and when this event does not occur (instead a beep event occurs) the live copy is violated and is closed.

Download the Memory Game Example

Below are downloads of the memory game final application, as well as of the LSC project that can be opened and modified in PlayGo.

Memory game final application (runnable jar)

Runnable Memory Game with Swing GUI

To run the memory game, simply extract the downloaded zip and double click the jar file.

Memory Game LSC project

The Memory Game LSC Project (for development purposes)

Installation Instructions

1. Extract the downloaded zip.
2. Download PlayGo.
3. Import the downloaded project to your workspace:
   1. From the File menu choose Import-->General-->Existing Projects into Workspace.
   2. Click the 'Next' button.
   3. When prompted, select the directory to which you extracted the downloaded memory game example.
   4. Click finish.
4. The memory game example project is now part of your workspace. You can start playing with it. For details refer to how to play out.

Baby Monitor

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 NL 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.

• Getting Started with PlayGo
• PlayGo HowTo

Water Tap

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).

Download Water Tap application
Instructions for playing with the Water Tap application

Phone

The project describes and implements a cell phone, including some common cell phone features, such as quick dial, lock and more. This project has been implemented using NL play-in. Therefore, the example includes the controlled natural language to create each of the LSCs.
Details can be found here.

Wristwatch

The wristwatch application includes 20 LSCs, defining its behavior and demonstrating the use in NL play-in.
Details about the specification and downloads can be found here.

LSC Design Patterns

After A occurs, B must occur, unless exception C occurs

We want to specify the requirement: if event A occurs then event B must occur, unless event C occurs; meaning, if A occurs, either B or C must occur.

LSC has a hot monitor idiom (so we can specify that if A occurred B must occur), but there is no idiom for hot monitoring one event from a list of events; e.g., hot monitor of either B or C.

To specify hot monitor of event B or event C, we offer the following design pattern (see text explanation below):

Explanation:

1. As long as A occurred and neither B not C occurred, LSC1 remains open in a cold cut, waiting for either C or B to occur and LSC2 remains open in a hot cut, indicating that the system as a whole is in hot global cut; i.e., the system must not stay in this state forever.
2. If A occurred and then B occurred, LSC1 reaches a cold false condition (named Exit) and therefore closes with a cold violation. This enables the LSC1Done event (no longer leads to the false violation in LSC1, since LSC1 closed), allowing LSC2 to complete.
3. If A occurred and then C occurred, similarly to the previous case, LSC1 reaches a cold false condition (named Exit) and therefore closes with a cold violation. This enables the LSC1Done event (no longer leads to the false violation in LSC1, since LSC1 closed), allowing LSC2 to complete.
4. The LSCs below describe test cases / simulated environment behavior that we experimented with, and which highlight the overall behavior.
   
   

The following LSCs describe valid behavior:

The following LSC describes an invalid behavior, in which only A occurs and neither B not C occur (in which case, the system will remain in a hot cut):

Download this design pattern
Instructions for playing with this specification