Pamela's 2nd Merge Request - FIXED

Example01_SimpleMessageFlow_EventCoordination.mp

-/* Example 01. Model of [Simple_Message_Flow]
+/* Example 01. Model of Simple Message Flow
 	 
 Event grammar rules for each root define derivations for event traces,
 in this case a simple sequence of zero or more events for each root.
@@ -8,8 +8,8 @@ a modified event trace, merging behaviors of Sender and Receiver
 and adding the PRECEDES relation for the selected send/receive pairs.
 The coordination operation behaves as a "cross-cutting" derivation rule.
 
-Run for scopes 1 and up. The "Sequence" or "Swim Lanes" layouts are 
-the most appropriate for browsing traces here.
+Instructions: Run for Scopes 1 and up. Viewing of traces also includes a
+"Swim Lanes" option.
 
 ==========================================================*/
 

Example01a_UnreliableMessageFlow_VirtualEvents.mp

-/* Example 01a. Model of [Unreliable_Message_Flow]
+/* Example 01a. Model of Unreliable Message Flow
 
 We may want to specify behaviors when some messages get lost in the transition. 
 It can be done using ‘virtual’ events.
 
-run for scopes 1 and up.
+Instructions: Run for Scopes 1 and up. Viewing of traces also includes a "Swim 
+Lanes" option.
 
 ==========================================================*/
 

Example02_DataFlow_EventSharing.mp

-/* Example 02. Model of [Data_Flow]
+/* Example 02. Model of Data Flow
 	
 data items as behaviors
 
@@ -18,10 +18,10 @@ only event traces where corresponding event sharing is implemented.
 
 Event traces specified by the schema represent system’s emergent behavior, 
 where behaviors of subsystems are influenced by the coordination.
-This is a toy example of System_of_Systems emerging behavior modeling. 
+This is a toy example of System of Systems emerging behavior modeling.
 
-Run for scopes 1 and up. The "Sequence" or "Swim Lanes" layouts are 
-the most appropriate for browsing traces here. 
+Instructions: Run for Scopes 1 and up. Viewing of traces also includes a 
+"Swim Lanes" option.
 
 ==========================================================*/
 

Example03_ATMWithdrawal_BehaviorOfEnvironment.mp

-/* Example 03. Model of [ATM_Withdrawal]
+/* Example 03. Model of ATM Withdrawal
 	
 Integrated system and environment behaviors
 	
@@ -17,15 +17,13 @@ among events in different components.
 The event traces produced from a model partitioned using this separation of concerns 
 include all combinations of event selections allowed by the model.
 
-Run for scopes 1 and up. 
-
-The "Sequence" or "Swim Lanes" layouts are the most appropriate for browsing traces here. 
-The "Sequence" mode yields views very similar to the UML or SysML Sequence Diagrams. 
-
 By selecting a representative enough trace (containing all events and interactions of interest,
 like traces 2 or 3 for scope 1), and then collapsing root event, it becomes possible 
 to view a traditional "box-and-arrow" architecture diagram, i.e. to visualize an architecture view.
 
+Instructions: Run for Scopes 1 and up. "Sequence" mode yields views very similar to the UML or SysML 
+Sequence Diagrams. Viewing of traces also includes a "Swim Lanes" option.
+
 ==========================================================*/
 
 SCHEMA ATM_Withdrawal

Example04_StackBehavior_EnsureCondition.mp

-/* Example04_StackBehavior_EnsureCondition.mp
+/* Example 04. Model of Stack Behavior
 
 	The event trace is a set of events and the Boolean expressions
 in MP can embrace the traditional predicate calculus notation. A set
@@ -27,12 +27,16 @@ and demonstrates an example of combining imperative (event grammar)
 and declarative (Boolean expressions) constructs for behavior
 specification.
 
-*/
-SCHEMA Stack_behavior
+Instructions: Run for Scopes 1 and up. Viewing of traces also 
+includes a "Swim Lanes" option.
+
+==========================================================*/
+
+SCHEMA Stack_Behavior
 
 ROOT Stack: (* ( push | pop ) *)
 BUILD {
 /* If an element is retrieved, it should have been stored before */
 ENSURE FOREACH $x: pop FROM Stack
 ( #pop BEFORE $x < #push BEFORE $x );
-};
\ No newline at end of file
+};

Example04a_StackBehavior_UserDefinedRelations.mp

-/* Example4a_Queue_behavior.mp 
+/* Example 04a. Model of Stack Behavior
 
-run for scopes 1, 2, 3, and up.
-*/
+The event trace is a set of events and the Boolean expression constructs in MP 
+can support the traditional first order predicate calculus notation. 
 
-/* This rule specifies the behavior of a queue in terms of queue operations 
-enqueue and dequeue. It is assumed that initially Queue is empty. 
+A set of behaviors (event traces) may be defined by the event
+grammar rules, composition operations, and some additional constraints – 
+ENSURE conditions.
+
+This rule specifies the behavior of a stack in terms of stack operations 
+push and pop. It is assumed that initially Stack is empty. 
 The BUILD block associated with a root or composite event 
 contains composition operations performed when event trace segment 
 representing the behavior of that root or composite is generated. 
 
 The ENSURE Boolean expression provides a condition that each valid trace 
 should satisfy. The domain of the universal quantifier is the set of all 
-dequeue events inside Queue trace. 
+pop events inside Stack trace. The FROM Stack part is optional, by default it is 
+assumed to be FROM THIS.
 
-The function #dequeue BEFORE $x yields the number of dequeue events preceding $x. 
+The function #pop BEFORE $x yields the number of pop events preceding $x. 
 The set of valid event traces specified by this schema contains only traces 
 that satisfy the constraint. This example presents a filtering operation 
 as yet another kind of behavior composition, and demonstrates an
 example of combining imperative (event grammar) and declarative 
-(Boolean expressions) constructs for behavior specification.            */
-
-SCHEMA Queue_Behavior
-
-ROOT Queue: (* ( enqueue | dequeue ) *)
-	BUILD { 
-        /* if an element is retrieved, it should have been stored before,
-            this constraint is identical to Stack behavior constraint. */
-        ENSURE FOREACH $x: dequeue 
-				( #dequeue BEFORE $x < #enqueue BEFORE $x );
-
-     /* The following composition operation establishes enqueue/dequeue pairs
-     	in the Queue behavior. For each 'dequeue' the earliest in time 
-     	preceding 'enqueue' is selected, unless it has been already 
-        consumed by another 'dequeue' */
-     
-	COORDINATE  $get: dequeue 
-		DO COORDINATE $put: enqueue 
-                            SUCH THAT $put BEFORE $get 
-			DO 	IF NOT ( EXISTS $g: dequeue $put Paired_with $g OR
-						 EXISTS $p: enqueue $p Paired_with $get 	 )
-				THEN ADD $put Paired_with $get; FI;
-			OD;
-		OD;
-    };/* end BUILD for Queue */
+(Boolean expressions) constructs for behavior specification.
+
+Instructions: Run for Scopes 1 and up. Viewing of traces also includes a 
+"Swim Lanes" option.
+
+==========================================================*/
+
+SCHEMA Stack_Behavior
+
+ROOT Stack: (* ( push | pop ) *)
+		BUILD { 
+            /* if an element is retrieved, it should have been stored before */
+            ENSURE FOREACH $x: pop FROM Stack
+					( #pop BEFORE $x < #push BEFORE $x );
+
+        /* The following composition operation establishes push/pop pairs
+            in the Stack behavior. For each 'pop' the closest in time 
+            preceding 'push' is selected, unless it has been already 
+            consumed by another 'pop' */
+
+            COORDINATE  $get: pop 
+                DO COORDINATE <REVERSE> $put: push 
+                                        SUCH THAT $put BEFORE $get 
+                    DO 	IF 	NOT ( EXISTS $g: pop $put Paired_with $g OR
+                                  EXISTS $p: push $p Paired_with $get 	)
+                        THEN ADD $put Paired_with $get; FI;
+                    OD;
+                OD;
+        };/* end BUILD for Stack */
+

Example04b_QueueBehavior_UserDefinedRelations.mp

-/* Example 04b. Model of [Queue_Behavior]
+/* Example 04b. Model of Queue Behavior
 
-The event trace is a set of events and the Boolean expression constructs in MP 
-can support the traditional first order predicate calculus notation. 
-
-A set of behaviors (event traces) may be defined by the event
-grammar rules, composition operations, and some additional constraints – 
-ENSURE conditions.
-
-run for scopes 1, 2, 3, and up.
-
-This rule specifies the behavior of a stack in terms of stack operations 
-push and pop. It is assumed that initially Stack is empty. 
+This rule specifies the behavior of a queue in terms of queue operations 
+enqueue and dequeue. It is assumed that initially Queue is empty. 
 The BUILD block associated with a root or composite event 
 contains composition operations performed when event trace segment 
 representing the behavior of that root or composite is generated. 
 
 The ENSURE Boolean expression provides a condition that each valid trace 
 should satisfy. The domain of the universal quantifier is the set of all 
-pop events inside Stack trace. The FROM Stack part is optional, by default it is 
-assumed to be FROM THIS.
+dequeue events inside Queue trace. 
 
-The function #pop BEFORE $x yields the number of pop events preceding $x. 
+The function #dequeue BEFORE $x yields the number of dequeue events preceding $x. 
 The set of valid event traces specified by this schema contains only traces 
 that satisfy the constraint. This example presents a filtering operation 
 as yet another kind of behavior composition, and demonstrates an
 example of combining imperative (event grammar) and declarative 
 (Boolean expressions) constructs for behavior specification.
 
+Instructions: Run for Scopes 1 and up. Viewing of traces also includes a "Swim 
+Lanes" option.
+
 ==========================================================*/
 
-SCHEMA Stack_Behavior
-
-ROOT Stack: (* ( push | pop ) *)
-		BUILD { 
-            /* if an element is retrieved, it should have been stored before */
-            ENSURE FOREACH $x: pop FROM Stack
-					( #pop BEFORE $x < #push BEFORE $x );
-
-        /* The following composition operation establishes push/pop pairs
-            in the Stack behavior. For each 'pop' the closest in time 
-            preceding 'push' is selected, unless it has been already 
-            consumed by another 'pop' */
-
-            COORDINATE  $get: pop 
-                DO COORDINATE <REVERSE> $put: push 
-                                        SUCH THAT $put BEFORE $get 
-                    DO 	IF 	NOT ( EXISTS $g: pop $put Paired_with $g OR
-                                  EXISTS $p: push $p Paired_with $get 	)
-                        THEN ADD $put Paired_with $get; FI;
-                    OD;
-                OD;
-        };/* end BUILD for Stack */
+SCHEMA Queue_Behavior
+
+ROOT Queue: (* ( enqueue | dequeue ) *)
+	BUILD { 
+        /* if an element is retrieved, it should have been stored before,
+            this constraint is identical to Stack behavior constraint. */
+        ENSURE FOREACH $x: dequeue 
+				( #dequeue BEFORE $x < #enqueue BEFORE $x );
+
+     /* The following composition operation establishes enqueue/dequeue pairs
+     	in the Queue behavior. For each 'dequeue' the earliest in time 
+     	preceding 'enqueue' is selected, unless it has been already 
+        consumed by another 'dequeue' */
+     
+	COORDINATE  $get: dequeue 
+		DO COORDINATE $put: enqueue 
+                            SUCH THAT $put BEFORE $get 
+			DO 	IF NOT ( EXISTS $g: dequeue $put Paired_with $g OR
+						 EXISTS $p: enqueue $p Paired_with $get 	 )
+				THEN ADD $put Paired_with $get; FI;
+			OD;
+		OD;
+    };/* end BUILD for Queue */
+

Example05_CarRace_NestedComposition.mp

-/* Example 05. Model of [Car_Race]
+/* Example 05. Model of Car Race
 
 more coordination patterns:
 -	ordering of selected events in concurrent threads
 	can be modeled by coordinating them with event sequence;
 	
 -	one-many coordination.
-    
-Run for scopes 1 and up. The "Sequence" or "Swim Lanes" 
-layouts are the most appropriate for browsing traces here. 
+
+Instructions: Run for Scopes 1 and up. Viewing of traces also 
+includes a "Swim Lanes" option.
 
 ==========================================================*/
 

Example06_UnreliableChannel_AssertionChecking.mp

-/* Example 06. Model of [Unreliable_Channel]
+/* Example 06. Model of Unreliable Channel
 
 	Assertion checking, Communicating via unreliable channel.
 
@@ -20,6 +20,9 @@
     if the property should always hold, it makes sense to convert it 
     into the ENSURE condition.
 
+	Instructions: Run for Scopes 1 and up. Viewing of traces also 
+	includes a "Swim Lanes" option.
+
 ==========================================================*/
 
 SCHEMA Unreliable_Channel

Example07_UnconstrainedStack_TraceAnnotation.mp

-/* Example 07. Model of [Unconstrained_Stack]
+/* Example 07. Model of Unconstrained Stack
 
 Trace annotation techniques 
 
@@ -17,6 +17,9 @@ might  violate certain property, and how to annotate these particular
 events in the trace with additional messages. Programmers will recognize 
 the use of debugging print statements for traditional program testing/debugging.
 
+Instructions: Run for Scopes 1 and up. Viewing of traces also includes a 
+"Swim Lanes" option.
+
 ==========================================================*/
 
 SCHEMA Unconstrained_Stack

Example08_EmployeeEmployer_CoordinationAcrossHierarchyLevels.mp

-/* Example 08. Model of [Employee_Employer]
+/* Example 08. Model of Employee Employer
 
 The web site http://www.infoq.com/articles/bpelbpm 
 “Why BPEL is not the holy grail for BPM “ 
@@ -18,11 +18,9 @@ from the human resource database. When both the computer and the
 medical check have been performed, the employee is ready to work. 
 Of course, you may want to model this simple process differently, 
 but the point here is that you cannot define a structured 
-parallel workflow [in BPEL] that is equivalent to this one ..." 
-	
-	Run for scope 1. The "Sequence" or "Swim Lanes" 
-	layouts are the most appropriate for browsing traces here.
-	Some box reshuffling may be needed to improve the trace layout. 
+parallel workflow [in BPEL] that is equivalent to this one ..."
+
+Instructions: Run for Scopes 1 and up. Viewing of traces also includes a "Swim Lanes" option. Some box reshuffling may be needed to improve the trace layout.
 
 ==========================================================*/
 

Example09_PipeFilter_TraceAnnotationQueries.mp

-/*  Example 09. Model of [Pipe_Filter]
+/*  Example 09. Model of Pipe Filter
     
     pipe/filter architecture model with 2 filters
 
@@ -8,6 +8,9 @@
         3) received message can stay in the Filter for while, 
         	before being sent (if at all).
 
+    Instructions: Run for Scopes 1, 2, 3, and 4. Viewing of traces also includes a "Swim Lanes" option.
+	                                Scope     4: 959 traces in approx. 6.1 sec.
+
 ==========================================================*/
 
 SCHEMA Pipe_Filter

Example10_PublishSubscribe_EventReshuffling.mp

-/* Example 10. Model of [Publish_Subscribe]
+/* Example 10. Model of Publish Subscribe
 
 	Publisher sends a notification to all active Subscribers 
-    when new information is available. 
-    
-	 scope 1, 1 trace in less than 1 sec.
-	 scope 2, 51 traces in less than 1 sec.
-	 scope 3  3813 traces in approx. 5 min.
+    when new information is available.
+
+	Instructions: Run for Scopes 1, 2, and 3. Viewing of traces also includes a "Swim Lanes" option.
+									Scope  3: 3813 traces in approx. 7.4 min.
 
 ==========================================================*/
 

Example11_RingTopology_UserDefinedRelations.mp

-/* Example 11. Model of [Ring_Topology]
+/* Example 11. Model of Ring Topology
     
     ring topology
     an example of user-defined relation use
 
     The following is a model of network ring, 
     where each node interacts with its left and right neighbors only.
+
+    Instructions: Run for Scopes 1, 2, and 3. Viewing of traces also includes a "Swim Lanes" option.
+									Scope  3: 1570 traces in approx. 31 sec.
     
 ==========================================================*/
 

Example12_CardiacArrestWorkflow_VirtualEvents.mp

-/* Example 12. Model of [Cardiac_Arrest_Workflow]
+/* Example 12. Model of Cardiac Arrest Workflow
 
 the web site
 http://workflowpatterns.com/patterns/control/index.php
@@ -12,7 +12,7 @@ run in parallel. Once the first of these has completed, the triage task
 is commenced. Completion of the other task is ignored and does not result 
 in a second instance of the triage task.
 
-run for scope 1
+Instructions: Run for Scope 1. Viewing of traces also includes a "Swim Lanes" option.
 
 ==========================================================*/
 

Example13_ConsumersSuppliers_DependencyTracking.mp

-/* Example 13. Model of [Consumers_Suppliers]
+/* Example 13. Model of Consumers Suppliers
 
 Asynchronous coordination and dependency definition example.
 
 user-defined relation related_to connects events within each 
 single Request_delivery -> Consume chain
 
-on Gryphon:
-	scope 1, 2   traces, in less than 1 sec.
-  	scope 2, 670 traces, approx. time 2.5 min.
+Instructions: Run for Scopes 1 and 2. Viewing of traces also includes a "Swim Lanes" option.
+  							 Scope 2: 110 traces in approx. 38 sec.
 
 ==========================================================*/
 

Example14_ShoppingSpree_NumberAttributes.mp

-/* Example 14. Model of [Shopping_Spree]
+/* Example 14. Model of Shopping Spree
+
+Instructions: Run for Scopes 1 and up. Viewing of traces also includes a "Swim Lanes" option.
 
 ==========================================================*/
 

Example15_BackpackWeight_IntervalAttributes.mp

-/* Example 15. Model of [Backpack_Weight]
+/* Example 15. Model of Backpack Weight
 
     Use of interval attributes.
     
@@ -6,9 +6,10 @@
     the total weight of 30 units. 
     There may be several instances of the same item.
 
-    run for scopes 1 and up
+    Instructions: Run for Scopes 1 and up. Viewing of traces also includes a "Swim Lanes" option.
 
 ==========================================================*/
+
 SCHEMA Backpack_Weight
 
 ATTRIBUTES{ interval weight; };

Example16_StackBehavior_ProbabilityCalculationsType1.mp

-/* Example16_StackBehavior_ProbabilityCalculationsType1.mp
+/* Example 16. Model of Stack Behavior
 
 	Here is a simple stack behavior model. Valid behaviors don’t permit
 a scenario when Pop operation is applied to the empty stack. For the
@@ -13,10 +13,13 @@ impossible in a real stack, so they are cut from the model.
 
 By removing some scenarios, the remaining probabilities change.
 
-*/
+Instructions: Run for Scopes 1 and up. Viewing of traces also includes a "Swim Lanes" option.
+
+==========================================================*/
+
 SCHEMA Stack_Behavior
 
 ROOT Stack: (* (<<0.75>> Push | <<0.25>> Pop ) *)
 BUILD { /* If an element is retrieved, it should have been stored before */
 ENSURE FOREACH $x: Pop FROM Stack
-( #Pop BEFORE $x < #Push BEFORE $x ); };
\ No newline at end of file
+( #Pop BEFORE $x < #Push BEFORE $x ); };

Example17_SharedEvents_ProbabilityCalculationsType1.mp

-/* Example17_SharedEvents_ProbabilityCalculationsType1.mp
+/* Example 17. Model of Shared Events
 
 	A simple example of shared events. If one root has a, the other root
 also has a. If neither root has a, then root 1 must have b, and root 2
 must have c. Additionally, probabilities show how "SHARE ALL" increases
 the chances of the shared event.
 
-*/
+Instructions: Run for Scope 1. Viewing of traces also includes a "Swim Lanes" option.
+
+==========================================================*/
+
 SCHEMA Shared_Events
 
 ROOT R1: (<<0.6>> a | b);
 ROOT R2: (<<0.8>> a | c);
-R1, R2 SHARE ALL a;
\ No newline at end of file
+R1, R2 SHARE ALL a;