Merge branch 'Pamela_Branch_3' into 'Pamela_Branch_2'

3 into 2

See merge request !37

models/Application_examples/Aspect_Oriented_Paradigm.mp

@@ -27,16 +27,17 @@ after each method call as an advice. The corresponding
 MP model may look like the following.
 
 References:
-"Example 2: Modeling Aspect-Oriented Paradigm" from Auguston, 
-	M. "Monterey Phoenix System and Software Architecture and 
-	Workflow Modeling Language Manual" (Version 4). 2020. 
-	Available online: 
+"Example 2: Modeling Aspect-Oriented Paradigm" from 
+	Auguston, M. "Monterey Phoenix System and Software 
+	Architecture and Workflow Modeling Language Manual" 
+	(Version 4). 2020. Available online: 
 	https://wiki.nps.edu/display/MP/Documentation
 
-Kiczales, G., J. Lamping, A. Mehdbekar, C. Maeda, C.V. Lopes, 
-	J. Loingtier, J. Irwin. "Aspect-Oriented Programming", 
-	Proceedings of the European Conference on Object-Oriented 
-	Programming (ECOOP), Springer-Verlag LNCS 1241. June 1997.
+Kiczales, G., J. Lamping, A. Mehdbekar, C. Maeda, 
+	C.V. Lopes, J. Loingtier, J. Irwin. "Aspect-Oriented 
+	Programming", Proceedings of the European Conference 
+	on Object-Oriented Programming (ECOOP), Springer-Verlag 
+	LNCS 1241. June 1997.
 
 Search terms: behavior, aspect-oriented paradigm; 
 coordination, event

models/Application_examples/Authentication.mp

 /* Model of Authentication
 
 Created by Kristin Giammarco on the 16th of May, 2017.
-Modified by Kristin Giammarco on the 7th of August, 2017 to add capitalization to state events.
-Modified by Kristin Giammarco on the 7th of August, 2017 to add ENSURE constraints.
+Modified by Kristin Giammarco on the 7th of August, 2017 
+	to add capitalization to state events.
+Modified by Kristin Giammarco on the 7th of August, 2017 
+	to add ENSURE constraints.
 Edited by Keane Reynolds in July, 2021.
 Edited by Pamela Dyer in July and August, 2021.
 
-Purpose: To demonstrate how to reject unwanted behaviors with ENSURE 
-constraints.
+Purpose: To demonstrate how to reject unwanted behaviors 
+with ENSURE constraints.
 
-Description: This model demonstrates how to correctly model a simple user authentication 
-system with ENSURE statements. ENSURE statements in this model are 
-used to lock the account if 3 or more incorrect passwords are input, 
-and guarantee that the account will not be locked if a correct password 
-is input within the maximum number of attempts. This provides a maximum 
-and prevents unwanted traces (ex. correct password leading to lock 
-account), demonstrating how users can remove unwanted traces in their 
-models using ENSURE.
+Description: This model demonstrates how to correctly model 
+a simple user authentication system with ENSURE statements. 
+ENSURE statements in this model are used to lock the account 
+if 3 or more incorrect passwords are input, and guarantee 
+that the account will not be locked if a correct password is 
+input within the maximum number of attempts. This provides a 
+maximum and prevents unwanted traces (ex. correct password 
+leading to lock account), demonstrating how users can remove 
+unwanted traces in their models using ENSURE.
 
 References:
 
-Search terms: behavior, authentication system; coordination, event; ENSURE condition; event sharing
+Search terms: behavior, authentication system; 
+coordination, event; ENSURE condition; event sharing
 
 Instructions: Run for Scopes 1, 2, and 3.
 	Scope 1: 2 traces in less than 1 sec.

models/Application_examples/Autonomous_Car.mp

@@ -4,19 +4,23 @@ Created by Gregory Kaminski in November, 2015.
 Edited by Keane Reynolds in July, 2021.
 Edited by Pamela Dyer in July and August, 2021.
 
-Purpose: To illustrate the use of COORDINATE statements to improve the quality of trace analysis.
-
-Description: This is a model of an autonomous car that was used to support a failure mode 
-analysis of autonomous automobile technology (student project). It applies COORDINATE statements to link the content under the 
-roots "Car" and "User" together. This is important as, without the 
-COORDINATE statements, the events under each root are random and 
-confusing, making understanding the traces much more difficult.
-Users should keep this in mind and use COORDINATE statements in their 
-models to improve clarity.
+Purpose: To illustrate the use of COORDINATE statements 
+to improve the quality of trace analysis.
+
+Description: This is a model of an autonomous car that 
+was used to support a failure mode analysis of autonomous 
+automobile technology (student project). It applies 
+COORDINATE statements to link the content under the roots 
+"Car" and "User" together. This is important as, without 
+the COORDINATE statements, the events under each root are 
+random and confusing, making understanding the traces much 
+more difficult. Users should keep this in mind and use 
+COORDINATE statements in their models to improve clarity.
 
 References:
 
-Search terms: behavior, autonomous car; autonomous; failure mode analysis; coordination, event
+Search terms: behavior, autonomous car; autonomous; 
+failure mode analysis; coordination, event
 
 Instructions: Run for Scope 1.
 	Scope 1: 8 traces in less than 1 sec.

models/Application_examples/Beginner_Use_of_MP.mp

@@ -4,35 +4,43 @@ Created by Kristin Giammarco on the 8th of February, 2021.
 Edited by Keane Reynolds in July, 2021.
 Edited by Pamela Dyer in July and August, 2021.
 
-Purpose: To use traces to provide a simple example of how to use MP-Firebird as a 
-beginner.
-
-Description: This model provides an orientation for those just getting started using 
-MP-Firebird.  This text editor pane allows you to compose and edit code 
-in the high-level MP language.  Press the Run button to generate event 
-traces from the code, then inspect the results in the center pane. Use 
-the far right pane to navigate the resulting traces.  Use the scope slider 
-bar next to the Run button to control the number of loop iterations.
-This model incorporates COORDINATE, ENSURE, and IF-THEN-ELSE statements, so beginner 
-users will want to look at the whole model to learn about all of these 
-statements, while more experienced users can skip to the parts that are 
-more relevant to their specific goals. See the instructions section for additional advice.
-
-ROOT A: B C;	A is a root event that includes events B followed by C
-( B | C )		Alternative events B or C (but not both together in the 
-				same trace)
+Purpose: To use traces to provide a simple example of 
+how to use MP-Firebird as a beginner.
+
+Description: This model provides an orientation for those 
+just getting started using MP-Firebird. This text editor 
+pane allows you to compose and edit code in the high-level 
+MP language. Press the Run button to generate event traces 
+from the code, then inspect the results in the center pane. 
+Use the far right pane to navigate the resulting traces. 
+Use the scope slider bar next to the Run button to control 
+the number of loop iterations. This model incorporates 
+COORDINATE, ENSURE, and IF-THEN-ELSE statements, so 
+beginner users will want to look at the whole model to 
+learn about all of these statements, while more 
+experienced users can skip to the parts that are more 
+relevant to their specific goals. See the instructions 
+section for additional advice.
+
+ROOT A: B C;	A is a root event that includes events 
+				B followed by C
+( B | C )		Alternative events B or C (but not both 
+				together in the same trace)
 (* B *) 		iterate B zero or more times
 { B , C } 		B and C are unordered
 
 References:
 
-Search terms: beginner use of MP; use of MP-Firebird; trace annotation; SAY statement
+Search terms: beginner use of MP; use of MP-Firebird; 
+trace annotation; SAY statement
 
-Instructions: Run for Scopes 1 and up. You may also make changes to this model and run it with your changes. 
-Save your model using the EXPORT button ("Code" exports a .mp text file 
-of the contents of the text editor, and "Code and Event Trace" exports 
-the contents of the text editor plus the graphs and any changes you made 
-to the graph element positions).
+Instructions: Run for Scopes 1 and up. You may also make 
+changes to this model and run it with your changes. Save 
+your model using the EXPORT button ("Code" exports a .mp 
+text file of the contents of the text editor, and "Code 
+and Event Trace" exports the contents of the text editor 
+plus the graphs and any changes you made to the graph 
+element positions).
 	Scope 1: 2 traces in less than 1 sec.
 	Scope 2: 3 traces in less than 1 sec.
 	Scope 3: 4 traces in less than 1 sec.

models/Application_examples/CargoScreening.mp

 /* Model of Cargo Screening
 
-Draft written by Mikhail Auguston on the 6th of May, 2011 (NPS, Monterey, CA).
+Draft written by Mikhail Auguston on the 6th of May, 2011 
+	(NPS, Monterey, CA).
 Edited by Keane Reynolds in July, 2021.
 Edited by Pamela Dyer in July and August, 2021.
 
-Purpose: To illustrate a model using a single long chain of logic, 
-in this case outlining a cargo screening process.
+Purpose: To illustrate a model using a single long chain of 
+logic, in this case outlining a cargo screening process.
 
-Description: This model demonstrates using composite statements under roots to make a long chain of 
-logic. This makes sense for models where 1 individual or machine is doing many tasks.
-Users should remember that multiple roots should be used if multiple people or objects 
-are performing these actions, but use composite statements when one action leads to 
-several more.
+Description: This model demonstrates using composite 
+statements under roots to make a long chain of logic. This 
+makes sense for models where 1 individual or machine is 
+doing many tasks. Users should remember that multiple roots 
+should be used if multiple people or objects are performing 
+these actions, but use composite statements when one action 
+leads to several more.
 
-An error that was found was that the original flowchart does not specify what happens if 
-selection_has_not_been_accepted, I've added PhysicalExamination
-and AnomalyResolution as a follow-up, but this scenario should be approved by the customer.
+An error that was found was that the original flowchart does 
+not specify what happens if selection_has_not_been_accepted, 
+I've added PhysicalExamination and AnomalyResolution as a 
+follow-up, but this scenario should be approved by 
+the customer.
 
 MP-Firebird may be used at least for the following:
 - generate all possible scenarios and inspect them manually, 
-	this way it becomes possible to find out the deficiency pointed out above
--  typical assertion that may be verified: "if the cargo has been loaded, 
-	was it always preceded by ThreatIsNotFound or No_high_risk_cargo_selected events?"
-- typical query may be: "show all scenarios when Loading event does not happen"
+	this way it becomes possible to find out the deficiency 
+	pointed out above
+-  typical assertion that may be verified: "if the cargo has 
+	been loaded, was it always preceded by ThreatIsNotFound 
+	or No_high_risk_cargo_selected events?"
+- typical query may be: "show all scenarios when Loading 
+	event does not happen"
 
 References:
 Skinner, Richard. "CBP's Container Security Initiative Has 
-Proactive Management and Oversight but Future Direction Is Uncertain (OIG-10-52)." 
-Office of Inspector General, Department of Homeland Security. February 3, 2010.
+Proactive Management and Oversight but Future Direction Is 
+Uncertain (OIG-10-52)." Office of Inspector General, 
+Department of Homeland Security. February 3, 2010.
 https://www.oig.dhs.gov/assets/Mgmt/OIG_10-52_Feb10.pdf
 
 
@@ -35,10 +44,12 @@ https://www.oig.dhs.gov/assets/Mgmt/OIG_10-52_Feb10.pdf
 Department of Homeland Security 
 Office of Inspector General 
 CBP's Container Security Initiative Has 
-Proactive Management and Oversight but Future Direction Is Uncertain 
-OIG-10-52 February 2010
+Proactive Management and Oversight but Future Direction 
+Is Uncertain OIG-10-52 February 2010
+********
 
-Search terms: behavior, cargo screening process; graph, flowchart
+Search terms: behavior, cargo screening process; 
+graph, flowchart
 
 Instructions: Run for Scope 1.
 	Scope 1: 6 traces in less than 1 sec.

models/Application_examples/Commercial_Flight

@@ -4,19 +4,24 @@ Created by Mikhail Auguston on the 27th of November, 2013.
 Edited by Keane Reynolds in July, 2021.
 Edited by Pamela Dyer in July and August, 2021.
 
-Purpose: To show a system with many roots performing multiple actions, using COORDINATE and SHARE ALL statements 
+Purpose: To show a system with many roots performing 
+multiple actions, using COORDINATE and SHARE ALL statements 
 to make a complex web of actions linked together.
 
-Description: This model demonstrates the interlacing of root events as Phases 
-and as Actors, in order to model a commercial flight. While complicated, users who take 
-the time to understand this model can learn about how to use SHARE ALL to 
-improve their models, and when to use COORDINATE instead. In addition, the commented out code at the bottom represents
-a simulation of COORDINATE statements with SHARE ALL statements before
-COORDINATE statements were implemented in the early MP tools.
+Description: This model demonstrates the interlacing of 
+root events as Phases and as Actors, in order to model a 
+commercial flight. While complicated, users who take the 
+time to understand this model can learn about how to use 
+SHARE ALL to improve their models, and when to use 
+COORDINATE instead. In addition, the commented out code at 
+the bottom represents a simulation of COORDINATE statements 
+with SHARE ALL statements before COORDINATE statements were 
+implemented in the early MP tools.
 
 References:
 
-Search terms: behavior, commercial flight; event sharing; coordination, event
+Search terms: behavior, commercial flight; event sharing; 
+coordination, event
 
 Instructions: Run for Scope 1.
 	Scope 1: 2 traces in less than 1 sec.

models/Application_examples/Cycle_Pattern.mp

@@ -4,14 +4,14 @@ Created by Kristin Giammarco on the 10th of March, 2018.
 Edited by Keane Reynolds in July, 2021.
 Edited by Pamela Dyer in July and August, 2021.
 
-Purpose: To illustrate a cycle as a form of pattern that 
-can be modeled in MP, and to show how commentary can be 
-added to the traces.
-
-Description: The model below describes a cycle in terms of a 
-series of one or more steps, each step either 
-moving the system "forward" or "backward" as the 
-process unfolds.  "Forward" and "backward" are 
+Purpose: To illustrate a cycle as a form of pattern 
+that can be modeled in MP, and to show how commentary 
+can be added to the traces.
+
+Description: The model below describes a cycle 
+in terms of a series of one or more steps, each step 
+either moving the system "forward" or "backward" as 
+the process unfolds. "Forward" and "backward" are 
 generic terms that may be substituted with synonyms 
 such as "up" and "down," "in" and "out", "over" 
 and "under", "increase" and "decrease", etc., or 
@@ -29,8 +29,9 @@ model when looking to use SAY or IF statements to
 add the story to their traces.
 
 References:
-Giammarco, Kristin, and Len Troncale. "Modeling Isomorphic Systems Processes Using 
-Monterey Phoenix." Systems 6, no. 2 (2018): 18.
+Giammarco, Kristin, and Len Troncale. "Modeling 
+Isomorphic Systems Processes Using Monterey Phoenix." 
+Systems 6, no. 2 (2018): 18.
 https://doi.org/10.3390/systems6020018
 https://www.mdpi.com/2079-8954/6/2/18
 
@@ -38,11 +39,13 @@ https://www.mdpi.com/2079-8954/6/2/18
 **** Remove this part ****
 Cycle_ISP Model for Systems Journal Article
 Available at https://www.mdpi.com/2079-8954/6/2/18
+********
 
-Search terms: behavior, cycle pattern; ENSURE condition; IF statement; SAY statement; isomorphism
+Search terms: behavior, cycle pattern; ENSURE condition; 
+IF statement; SAY statement; isomorphism
 
-Instructions: Run for Scopes 2 and 3. (Scope 1 generates zero traces because
-of the ENSURE constraint.)
+Instructions: Run for Scopes 2 and 3. (Scope 1 generates 
+zero traces because of the ENSURE constraint.)
 	Scope 1: 0 traces in less than 1 sec.
 	Scope 2: 40 traces in less than 1 sec.
 	Scope 3: 2952 traces in approx. 2.9 sec.

models/Application_examples/Dining_Philosophers.mp

@@ -8,48 +8,58 @@ Purpose: To illustrate the extensive logic and problem
 solving capabilities of MP, using the dining philosophers 
 problem as the topic.
 
-Description: This model demonstrates using COORDINATE, ENSURE, and IF statements 
-to come up with an answer to a sort of riddle. The logic and problem 
-solving potential of Monterey Phoenix is showcased through its ability 
-to come up with exhaustive solutions to multiple variations of a complex 
+Description: This model demonstrates using COORDINATE, ENSURE, 
+and IF statements to come up with an answer to a sort of 
+riddle. The logic and problem solving potential of Monterey 
+Phoenix is showcased through its ability to come up with 
+exhaustive solutions to multiple variations of a complex 
 puzzle with some code and constraints.
 
-Five silent philosophers sit at a table around a bowl of spaghetti. 
-A fork is placed between each pair of adjacent philosophers. 
-It was originally formulated in 1965 by Edsger Dijkstra.
-
-Each philosopher must alternately think and eat. However, a philosopher 
-can only eat spaghetti when he has both left and right forks. 
-Each fork can be held by one philosopher only and so a philosopher can use 
-the fork only if it's not being used by another philosopher. 
-After he finishes eating, he needs to put down both forks so they become 
-available to others. A philosopher can grab the fork on his right or 
-the one on his left as they become available, but can't start eating 
-before getting both of them.
-
-Eating is not limited by the amount of spaghetti left: assume an infinite 
-supply. The problem is how to design a discipline of behavior (a concurrent 
-algorithm) such that each philosopher won't starve; i.e., can forever 
-continue to alternate between eating and thinking assuming that any 
+Five silent philosophers sit at a table around a bowl of 
+spaghetti. A fork is placed between each pair of adjacent 
+philosophers. It was originally formulated in 1965 by 
+Edsger Dijkstra.
+
+Each philosopher must alternately think and eat. However, a 
+philosopher can only eat spaghetti when he has both left and 
+right forks. Each fork can be held by one philosopher only 
+and so a philosopher can use the fork only if it's not being 
+used by another philosopher. After he finishes eating, he 
+needs to put down both forks so they become available to 
+others. A philosopher can grab the fork on his right or the 
+one on his left as they become available, but can't start 
+eating before getting both of them.
+
+Eating is not limited by the amount of spaghetti left: assume 
+an infinite supply. The problem is how to design a discipline 
+of behavior (a concurrent algorithm) such that each 
+philosopher won't starve; i.e., can forever continue to 
+alternate between eating and thinking assuming that any 
 philosopher cannot know when others may want to eat or think.
 
 This MP model provides abstract specification of correct 
 behaviors, but does not provide implementation details. 
-Since MP supports automated use case extraction, this model may be used 
-as a source of test cases for testing the implementation.
+Since MP supports automated use case extraction, this model 
+may be used as a source of test cases for testing 
+the implementation.
 
 References:
-"Dining philosophers problem." Wikipedia. Wikimedia Foundation, August 6, 2021.
+"Dining philosophers problem." Wikipedia. Wikimedia 
+Foundation, August 6, 2021.
 https://en.wikipedia.org/wiki/Dining_philosophers_problem
 
 
 **** Remove this part ****
 Explanation of the problem from Wikipedia: http://en.wikipedia.org/wiki/Dining_philosophers_problem
+********
 
-Search terms: behavior, dining philosophers; riddles; behavior, ring topology; event reshuffling; BUILD block; isomorphism
+Search terms: behavior, dining philosophers; riddles; 
+behavior, ring topology; event reshuffling; BUILD block; 
+isomorphism
 
-Instructions: Run for Scope 1. This will generate zero traces because
-a philosopher cannot eat with a single fork. Then run for Scopes 2 and up.
+Instructions: Run for Scope 1. This will generate zero 
+traces because a philosopher cannot eat with a single fork. 
+Then run for Scopes 2 and up.
     Scope 1: 0 traces in less than 1 sec.
     Scope 2: 2 traces in less than 1 sec.
     Scope 3: 6 traces in less than 1 sec.

models/Application_examples/Elevator.mp

@@ -4,11 +4,12 @@ Created by Kristin Giammarco circa 2011.
 Edited by Keane Reynolds in July, 2021.
 Edited by Pamela Dyer in July and August, 2021.
 
-Purpose: To demonstrate how under-constraining a model can be beneficial, 
-because it can lead to emergent behavior showing up in the traces.
+Purpose: To demonstrate how under-constraining a model 
+can be beneficial, because it can lead to emergent behavior 
+showing up in the traces.
 
-Description: This demonstrates the modeling of situations and consequential events
-in MP.  The pattern is:
+Description: This demonstrates the modeling of situations 
+and consequential events in MP. The pattern is:
 
 ( 	SituationA do_one_thing 	| 
 	SituationB do_another_thing )
@@ -18,17 +19,19 @@ in the case of this model,
 ( 	Elevator_works_fine Get_Off |
     Emergency_Situation Call_for_help )
 
-Ultimately, this is a simple model of an emergency scenario involving an 
-elevator with very few constraints. This allows 
-for more variance, which leads to emergent behavior. Users should use 
-this as an example of how under-constraining your model can be beneficial. 
-Constraints should only be limited to necessity, or to remove traces that 
-no longer need to be considered. When in doubt, add a constraint, and then 
-comment it out. Bring it back later if needed.
+Ultimately, this is a simple model of an emergency scenario 
+involving an elevator with very few constraints. This 
+allows for more variance, which leads to emergent behavior. 
+Users should use this as an example of how under-constraining 
+your model can be beneficial. Constraints should only be 
+limited to necessity, or to remove traces that no longer 
+need to be considered. When in doubt, add a constraint, and 
+then comment it out. Bring it back later if needed.
 
 References:
 
-Search terms: behavior, elevator; event sharing; coordination, event; behavior, emergent
+Search terms: behavior, elevator; event sharing; 
+coordination, event; behavior, emergent
 
 Instructions: Run for Scope 1.
 	Scope 1: 3 traces in less than 1 sec.

models/Application_examples/FindAdvisor.mp

@@ -4,25 +4,32 @@ Created by Kristin Giammarco.
 Edited by Keane Reynolds in July, 2021.
 Edited by Pamela Dyer in July and August, 2021.
 
-Purpose: To show that human interaction and organizational processes can be modeled as well as technological
-system and subsystem interactions.
-
-Description: Alternate behaviors for humans are described in
-terms of possible decisions they could make. In this example, the process of a student finding an advisor for a potentially 
-MP-related research topic is modeled. To do so, it only uses
-roots, composites, "or" blocks, and COORDINATE statements. Users should inspect this 
-model when considering the process of finding a mentor, or looking to learn how to 
-use COORDINATE statements to make a model. Because the same modeling approach can be used for human systems and technological systems, 
-it becomes possible to have integrated behavior models containing both humans and 
+Purpose: To show that human interaction and organizational 
+processes can be modeled as well as technological system 
+and subsystem interactions.
+
+Description: Alternate behaviors for humans are described 
+in terms of possible decisions they could make. In this 
+example, the process of a student finding an advisor for a 
+potentially MP-related research topic is modeled. To do so, 
+it only uses roots, composites, "or" blocks, and COORDINATE 
+statements. Users should inspect this model when considering 
+the process of finding a mentor, or looking to learn how to 
+use COORDINATE statements to make a model. Because the same 
+modeling approach can be used for human systems and 
+technological systems, it becomes possible to have 
+integrated behavior models containing both humans and 
 technology to study the possible interactions among them.
 
 References:
 
-Search terms: behavior, finding advisor; human interactions modeling; behavior, human systems
+Search terms: behavior, finding advisor; 
+human interactions modeling; behavior, human systems
 
-Instructions: Run for Scope 1 (there is no iteration in this example, so increasing the scope will not 
-produce more scenarios). "Sequence" mode yields views very similar to the UML or SysML 
-Sequence Diagrams.
+Instructions: Run for Scope 1 (there is no iteration in 
+this example, so increasing the scope will not produce more 
+scenarios). "Sequence" mode yields views very similar to 
+the UML or SysML Sequence Diagrams.
 	Scope 1: 3 traces in less than 1 sec.
 
 ==========================================================*/

models/Application_examples/First_Responder.mp

@@ -4,26 +4,31 @@ Created by Jordan Bryant in May, 2016.
 Edited by Keane Reynolds in July, 2021.
 Edited by Pamela Dyer in July and August, 2021.
 
-Purpose: To demonstrate a first responder scenario involving the administation of a rescue 
-medication (Narcan) to an overdose victim by a First Responder or a 
-Bystander.
-
-Description: This model demonstrates the administration of Narcan by bystanders 
-in order to determine the possible consequences of allowing or even 
-encouraging bystanders to administer medication in an overdose scenario. 
-The model accomplishes this using "or" blocks and COORDINATE statements. 
-Users may find this model useful when looking into COORDINATE statements, 
-or scenarios with bystanders who could possibly become involved in whatever 
-process is being modeled.
+Purpose: To demonstrate a first responder scenario 
+involving the administation of a rescue medication (Narcan) 
+to an overdose victim by a First Responder or a Bystander.
+
+Description: This model demonstrates the administration of 
+Narcan by bystanders in order to determine the possible 
+consequences of allowing or even encouraging bystanders to 
+administer medication in an overdose scenario. The model 
+accomplishes this using "or" blocks and COORDINATE 
+statements. Users may find this model useful when looking 
+into COORDINATE statements, or scenarios with bystanders 
+who could possibly become involved in whatever process 
+is being modeled.
 
 References:
 
-Search terms: behavior, first responder; behavior, bystander; behavior, unexpected; behavior, emergent
+Search terms: behavior, first responder; 
+behavior, bystander; behavior, unexpected; 
+behavior, emergent
 
-Instructions: Run for Scope 1. The model was developed to compare response times, but unexpected 
-scenarios emerged that were previously not considered.  Trace 6 and others
-show a double administration of Narcan by both the bystander and the first 
-responder.
+Instructions: Run for Scope 1. The model was developed to 
+compare response times, but unexpected scenarios emerged 
+that were previously not considered. Trace 6 and others 
+show a double administration of Narcan by both the 
+bystander and the first responder.
 	Scope 1: 8 traces in less than 1 sec.
 
 ==========================================================*/

models/Application_examples/Knapsack_Weight_Limit.mp

@@ -8,30 +8,36 @@ Purpose: To illustrate the process of searching for all
 optimal solutions in a certain scope, with a limit set 
 for the weight of the knapsack.
 
-Description: This is a case of well-known Knapsack Dynamic Programming Problem.
-In general it is NP-hard and NP-complete 
-with respect to the number N of items and to the weight limit W.
-It has been proven that the computational complexity is O(N * W)
-
-This example demonstrates MP template for performing "brute force" search
-for all optimal solutions within the given scope 
-(certainly not the optimal performance, but is acceptable for relatively 
-small N,in particular, it stabilizes at scope 4).
-
-Ultimately, this model demonstrates using GLOBAL limits to exhaustively calculate all 
-the combinations of items that can be put into a bag to not exceed the weight 
-limit. Users can reference this model to learn about solving logic problems 
-with MP constraints.
+Description: This is a case of well-known Knapsack Dynamic 
+Programming Problem. In general it is NP-hard and 
+NP-complete with respect to the number N of items and to 
+the weight limit W. It has been proven that the 
+computational complexity is O(N * W)
+
+This example demonstrates MP template for performing 
+"brute force" search for all optimal solutions within the 
+given scope (certainly not the optimal performance, but is 
+acceptable for relatively small N, in particular, it 
+stabilizes at scope 4).
+
+Ultimately, this model demonstrates using GLOBAL limits to 
+exhaustively calculate all the combinations of items that 
+can be put into a bag to not exceed the weight limit. 
+Users can reference this model to learn about solving 
+logic problems with MP constraints.
 
 References:
-"Knapsack problem." Wikipedia. Wikimedia Foundation, August 26, 2021.
+"Knapsack problem." Wikipedia. Wikimedia Foundation, 
+August 26, 2021.
 https://en.wikipedia.org/wiki/Knapsack_problem
 
 
 **** Remove this part ****
 Information on computational complexity from Wikipedia at https://en.wikipedia.org/wiki/Knapsack_problem 
+********
 
-Search terms: event attribute, number; optimization, weight; BUILD block; WITHIN command; report, global
+Search terms: event attribute, number; optimization, weight; 
+BUILD block; WITHIN command; report, global
 
 Instructions: Run for Scopes 1 and up.
     Scope 1: 4 traces in less than 1 sec.

models/Application_examples/MP_Architecture_Specification.mp

@@ -7,8 +7,8 @@ Edited by Pamela Dyer in July and August, 2021.
 Purpose: To illustrate an architecture model surrounding 
 the MP compiler/trace generator process.
 
-Description: This model demonstrates how a user might use an MP 
-IDE to develop an MP model. This model contains many 
+Description: This model demonstrates how a user might use 
+an MP IDE to develop an MP model. This model contains many 
 types of interactions and goes through the process of 
 making a model, so beginner and intermediate users may 
 find this model helpful for learning about the modeling 
@@ -17,7 +17,9 @@ SHARE ALL, SAY, GRAPH, etc.) can create relationships.
 
 References:
 
-Search terms: architecture; trace annotation; behavior, compiler; behavior, parser; graph, component diagram; report, global; isomorphism
+Search terms: architecture; trace annotation; 
+behavior, compiler; behavior, parser; 
+graph, component diagram; report, global; isomorphism
 
 Instructions: Run for Scopes 1 and 2.
 	Scope 1: 16 traces in less than 1 sec.

models/Application_examples/Manufacturing_Process.mp

@@ -4,22 +4,30 @@ Created by John Palmer in August, 2014.
 Edited by Keane Reynolds in July, 2021.
 Edited by Pamela Dyer in July and August, 2021.
 
-Purpose: To demonstrate a model of a system manufacturing process, 
-while taking advantage of being able to use local scopes.
-
-Description: This model demonstrates application of Monterey Phoenix Modeling to Manufacturing Product Systems.
-This is an example pre-dating MP-Firebird application that was used to generate scenarios
-for separately estimating probability, time, and cost of each of these scenarios.
-MP version 4 may be used to conduct such analysis with its native capabilities.
-
-Ultimately, this model demonstrates a manufacturing system made from only standard ROOT 
-statements, "or" blocks, SHARE ALL statements, iteration, and scope limits. 
-This manufacturing system has several actors simultaniously performing jobs, 
-so users may look to this model for a simple way of designing a system.
+Purpose: To demonstrate a model of a system manufacturing 
+process, while taking advantage of being able to use 
+local scopes.
+
+Description: This model demonstrates application of Monterey 
+Phoenix Modeling to Manufacturing Product Systems. This is 
+an example pre-dating MP-Firebird application that was used 
+to generate scenarios for separately estimating probability, 
+time, and cost of each of these scenarios. MP version 4 
+may be used to conduct such analysis with its 
+native capabilities.
+
+Ultimately, this model demonstrates a manufacturing system 
+made from only standard ROOT statements, "or" blocks, 
+SHARE ALL statements, iteration, and scope limits. This 
+manufacturing system has several actors simultaniously 
+performing jobs, so users may look to this model for 
+a simple way of designing a system.
 
 References:
 
-Search terms: behavior, manufacturing process; manufacturing system; event sharing; probability analysis; nested iteration
+Search terms: behavior, manufacturing process; 
+manufacturing system; event sharing; probability analysis; 
+nested iteration
 
 Instructions: Run for Scope 1.
 	Scope 1: 8 traces in approx. 1.4 min.

models/Application_examples/Martian_Lander.mp

 /* Model of Martian Lander
 
 MP model written by Mikhail Auguston following example 1 
-and Appendix B from (Jahanian and Mok 1986).
+	and Appendix B from (Jahanian and Mok 1986).
 Edited by Keane Reynolds in July, 2021.
 Edited by Pamela Dyer in July and August, 2021.
 
 Purpose: To illustrate a landing system for a Martian Lander, 
 which is an example of real-time system behavior modeling.
 
-Description: The landing system operates in one of two modes: normal or emergency. 
-When the system is turned on (an external event), it operates in the 
-normal mode. While in the normal landing mode, the pilot can control 
-acceleration, velocity, and position by adjusting the downward thrust 
-generated by the rocket motor, thus bringing the space vehicle to a 
-safe landing. This task is continually performed in two phases.
-
-In phase 1, an I/O device is started to read the acceleration set 
-by the pilot, and a hardware timer is started which generates a timer 
-interrupt (i.e., external event TMRINT) after 100 ms. In phase 2, 
-when the I/O operation is completed (i.e., external event IOINT), 
-the motor thrust is adjusted appropriately. However, if for some 
-reason the I/O operation is not done within 100 ms, the timer interrupt 
-initiates the emergency landing mode. While in the emergency mode, 
-the altitude and velocity is periodically sampled and a retro-rocket 
-is automatically fired to bring the vehicle to a safe landing.
+Description: The landing system operates in one of two modes: 
+normal or emergency. When the system is turned on (an external 
+event), it operates in the normal mode. While in the normal 
+landing mode, the pilot can control acceleration, velocity, 
+and position by adjusting the downward thrust generated by 
+the rocket motor, thus bringing the space vehicle to a safe 
+landing. This task is continually performed in two phases.
+
+In phase 1, an I/O device is started to read the acceleration 
+set by the pilot, and a hardware timer is started which 
+generates a timer interrupt (i.e., external event TMRINT) 
+after 100 ms. In phase 2, when the I/O operation is completed 
+(i.e., external event IOINT), the motor thrust is adjusted 
+appropriately. However, if for some reason the I/O operation 
+is not done within 100 ms, the timer interrupt initiates the 
+emergency landing mode. While in the emergency mode, the 
+altitude and velocity is periodically sampled and a 
+retro-rocket is automatically fired to bring the vehicle 
+to a safe landing.
 
 Events and actions:
 RACC    Starts IO device to read acceleration
-STMR    Start hardware watchdog timer, this model has two timers
+STMR    Start hardware watchdog timer, this model has 
+			two timers
 ADJM    Adjust motor thrust
 TDP     Transmit info to display panel
 IEM     Initiate emergency mode 
@@ -38,7 +42,8 @@ CKDT    Check input data for consistency
 RRM     Retro-rocket module
 START   Systems start up,
 IOINT   I/O device signals completion
-TMRINT  Timer Interrupt, occurs at least 100 ms after start of STMR
+TMRINT  Timer Interrupt, occurs at least 100 ms after 
+			start of STMR
 
 Action Time in ms
 RACC 	10
@@ -52,12 +57,13 @@ IALT 	20
 CKDT 	10
 RRM 	10
 
-In summary, this model demonstrates the use of COORDINATE statements to model 
-the relationships of an unlikely and unfamiliar situation, and then 
-make the situation easier to understand using charts and "comments" 
-from SAY statements. Users can reference this model for advice on 
-COORDINATE statements and using MP to add graphs and commentary to 
-traces automatically.
+In summary, this model demonstrates the use of COORDINATE 
+statements to model the relationships of an unlikely and 
+unfamiliar situation, and then make the situation easier 
+to understand using charts and "comments" from 
+SAY statements. Users can reference this model for advice 
+on COORDINATE statements and using MP to add graphs and 
+commentary to traces automatically.
 
 References:
 Jahanian, Farnam, and Aloysius Ka-Lau Mok. "Safety Analysis 
@@ -73,8 +79,12 @@ Farnam Jahanian, Aloysius Ka-Lau Mok
 "Safety analysis of timing properties in real-time systems",
 IEEE Transactions on Software Engineering
 Year: 1986, Volume SE-12, Issue 9, pp.890-904
+********
 
-Search terms: Martian Lander system; behavior, landing system; event attribute, timing; trace annotation; table; graph, Gantt chart; graph, bar chart
+Search terms: Martian Lander system; 
+behavior, landing system; event attribute, timing; 
+trace annotation; table; graph, Gantt chart; 
+graph, bar chart
 
 Instructions: Run for Scopes 1 and up.
 	Scope 1: 3 traces in less than 1 sec.

models/Application_examples/Prisoners_Dilemma.mp

@@ -10,36 +10,39 @@ game scenario.
 Description: Users looking to model exhaustive logical 
 game scenarios may want to use this model as an example.
 
-In this case, the classic model is the output in the traces
+In this case, the classic model is the output in the traces 
 of the model with the payouts as documented in (Straffin 1993).
 
-Different in this MP model is how the payouts
-are computed.  Most models just assume the final
-amount of payouts for the matrix game. 
+Different in this MP model is how the payouts 
+are computed. Most models just assume the final 
+amount of payouts for the matrix game.
 
-Here the payout for Alice, and Bob respectively,
+Here the payout for Alice, and Bob respectively, 
 is computed from 
-"Alice's view of the payoff for each possible event independently of Bob's view"
+"Alice's view of the payoff for each possible event 
+independently of Bob's view"
 
 This is represented by the columns in the tables below. 
-A simple arithmetic derivation from those columns is computed to have the 
-trace generation output each matrix element of the game as 
-a separate trace in the MP output. 
+A simple arithmetic derivation from those columns is 
+computed to have the trace generation output each matrix 
+element of the game as a separate trace in the MP output.
 
-Future work is to include other obvious matrices readily constructed 
-from this to be generated as part of the trace generation.
+Future work is to include other obvious matrices readily 
+constructed from this to be generated as part of the 
+trace generation.
 
 This would represent something like a class of matrix games 
 to be constructed by the schema, one of which would be 
 the classic two person prisoners dilemma.
 
-Notice that this code is almost exactly like
-MP native Example 23 -- number attributes.
-That example is about a buyer purchasing different products
+Notice that this code is almost exactly like 
+MP native Example 23 -- number attributes. 
+That example is about a buyer purchasing different products 
 from different stores.
 
-A related version of the prisoners dilemma to shopping is
-documented at the Wikipedia article cited below. "The donation game."
+A related version of the prisoners dilemma to shopping is 
+documented at the Wikipedia article cited below. 
+"The donation game."
 
 This model is only meant to be run at Scope 1.
 
@@ -53,8 +56,9 @@ the payoff for Bob when he confesses            = 1.
 the payoff for Bob when Alice does not confess  = 2.
 in all other circumstances the payoff for Bob   = 0.
 
-To map it to classic values to show negative payoffs -- that is a sort of normalizing. 
-The total payoff is computed from the assignments above and then subtracting 2.
+To map it to classic values to show negative payoffs -- that 
+is a sort of normalizing. The total payoff is computed from 
+the assignments above and then subtracting 2.
 
 References:
 Straffin, Philip D. "12. The Prisoner's Dilemma." in Game 
@@ -76,12 +80,13 @@ Kuhn, Steven. "Prisoner’s Dilemma." The Stanford
 Mathematical Association of America 1993
 isbn: 0-88385-637-9
 Chapter 12, page 73.
-
 https://en.wikipedia.org/wiki/Prisoner%27s_dilemma
-
 https://plato.stanford.edu/entries/prisoner-dilemma/#Symm2t2PDOrdiPayo
+********
 
-Search terms: behavior, prisoners dilemma; behavior, matrix game; event attribute, number; BUILD block; SAY statement; isomorphism
+Search terms: behavior, prisoners dilemma; 
+behavior, matrix game; event attribute, number; 
+BUILD block; SAY statement; isomorphism
 
 Instructions: Run for Scope 1.
 	Scope 1: 4 traces in less than 1 sec.

models/Application_examples/Railroad_Crossing_Safety.mp

@@ -7,16 +7,20 @@ Edited by Pamela Dyer in July and August, 2021.
 Purpose: To illustrate timing attribute use in MP, here 
 for displaying a railroad crossing scenario.
 
-Description: This model demonstrates using BUILD statements to add time to a model of car 
-and train interactions at a railroad crossing, in which time is a defining 
-factor of many events. Users should look to this model when in need of an 
-example of using BUILD statements to add time, COORDINATE constraint usage, 
-CHECK statements used to catch unwanted behavior, and SAY statement comments to 
-improve a model's clarity.
-
-The original railroad crossing example was from (Heitmeyer and Mandrioli 1996).
-The system operates a gate at a railroad crossing. A sensor determines when 
-each train enters and exits the crossing’s region. The main safety requirement is: if a train is in the crossing region, 
+Description: This model demonstrates using BUILD statements 
+to add time to a model of car and train interactions at a 
+railroad crossing, in which time is a defining factor of 
+many events. Users should look to this model when in need 
+of an example of using BUILD statements to add time, 
+COORDINATE constraint usage, CHECK statements used to catch 
+unwanted behavior, and SAY statement comments to improve 
+a model's clarity.
+
+The original railroad crossing example was from (Heitmeyer 
+and Mandrioli 1996). The system operates a gate at a 
+railroad crossing. A sensor determines when each train 
+enters and exits the crossing’s region. The main safety 
+requirement is: if a train is in the crossing region, 
 then gate must be down.
 
 References:
@@ -24,7 +28,8 @@ Heitmeyer, Constance, and Dino Mandrioli. Formal Methods
 for Real-Time Computing. New York, NY: John Wiley & Sons, 
 Inc., 1996.
 
-Search terms: behavior, railroad crossing; safety requirement; failure mode; event attribute, timing
+Search terms: behavior, railroad crossing; 
+safety requirement; failure mode; event attribute, timing
 
 Instructions: Run for Scopes 1 and up.
 	Scope 1: 1 trace in less than 1 sec.

models/Application_examples/Replay_Attack.mp

@@ -7,14 +7,15 @@ Edited by Pamela Dyer in July and August, 2021.
 Purpose: To illustrate MP modeling of a replay attack 
 involving data transmission.
 
-Description: This model demonstrates using COORDINATE statements 
-to form relationships in a communication system with 
-a 3rd party listening in. Users should use this model 
+Description: This model demonstrates using COORDINATE 
+statements to form relationships in a communication system 
+with a 3rd party listening in. Users should use this model 
 as an example of possible 3rd parties in other systems, 
 and using COORDINATE statements to form relationships.
 
 References:
-"Replay attack." Wikipedia. Wikimedia Foundation, July 1, 2021.
+"Replay attack." Wikipedia. Wikimedia Foundation, 
+July 1, 2021.
 https://en.wikipedia.org/wiki/Replay_attack
 
 
@@ -22,8 +23,10 @@ https://en.wikipedia.org/wiki/Replay_attack
 The description of Replay Attack
 is available at 
 https://en.wikipedia.org/wiki/Replay_attack
+********
 
-Search terms: behavior, replay attack; message eavesdropping; coordination, event
+Search terms: behavior, replay attack; 
+message eavesdropping; coordination, event
 
 Instructions: Run for Scopes 1 and up.
 	Scope 1: 2 traces in less than 1 sec.

models/Application_examples/Small_Package_Delivery.mp

 /* Model of Small Package Delivery
 
 Non-combatant Scenario 1 authored by Nataki Roberts (Engility).
-MP model authored by Kristin Giammarco (NPS) and David Shifflett (NPS).
+MP model authored by Kristin Giammarco (NPS) and 
+    David Shifflett (NPS).
 Edited by Keane Reynolds in July, 2021.
 Edited by Pamela Dyer in July and August, 2021.
 
-Purpose: To illustrate the impacts of overloading constraints 
-in a model in MP, by means of a complex emergency situation 
-out at sea.
-
-Description: This model demonstrates overusing COORDINATE and ENSURE statements to 
-create a model of a complex emergency situation that has been 
-overconstrained to the point that intended behavior has also been 
-constrained out. Users should consider this model a demonstration of how 
-building a complex scenario without frequently running the model can 
-make finding parts of the model overloaded with constraints difficult.
-
-Taken from use case description in the Skyzer IM20 Mission Model 
-(Non-Combatant Operations Scenario):
-
-"Family traveling from PR to Florida in a 1984 Catalina 36 have an
-emergency out on sea. A 40 year old father is diabetic and has ran [sic]
-out of insulin and because he is the main sail operator, the family is
-suck [sic] at sea until medical attention can arrived [sic]. The major
-problem is that the USCG Cutter is four hours out on another mission, from
-the last known location point of the sailboat last communication
-beacon. But the there is a Navy ship in closer proximity with UAV
-capabilities. The USS Fitzgerald is 75 nm from that last know location
-point and has the needed medical supplies. USS Fitzgerald also has
-UAV capabilities to transport the supplies in the required time line.
-This Navy capability can provide the needed supplies within the
-required time line without risk of placing the patient at risk of a
-diabetic coma. The Navy’s UAV can fly out to the sailboat and drop
-off the medical supplies until the USCG can arrived to transport
+Purpose: To illustrate the impacts of overloading 
+constraints in a model in MP, by means of a complex 
+emergency situation out at sea.
+
+Description: This model demonstrates overusing COORDINATE 
+and ENSURE statements to create a model of a complex 
+emergency situation that has been overconstrained to the 
+point that intended behavior has also been constrained 
+out. Users should consider this model a demonstration of 
+how building a complex scenario without frequently 
+running the model can make finding parts of the model 
+overloaded with constraints difficult.
+
+Taken from use case description in the Skyzer IM20 Mission 
+Model (Non-Combatant Operations Scenario):
+
+"Family traveling from PR to Florida in a 1984 Catalina 36 
+have an emergency out on sea. A 40 year old father is 
+diabetic and has ran [sic] out of insulin and because he 
+is the main sail operator, the family is suck [sic] at sea 
+until medical attention can arrived [sic]. The major 
+problem is that the USCG Cutter is four hours out on 
+another mission, from the last known location point of the 
+sailboat last communication beacon. But the there is a 
+Navy ship in closer proximity with UAV capabilities. The 
+USS Fitzgerald is 75 nm from that last know location point 
+and has the needed medical supplies. USS Fitzgerald also 
+has UAV capabilities to transport the supplies in the 
+required time line. This Navy capability can provide the 
+needed supplies within the required time line without risk 
+of placing the patient at risk of a diabetic coma. The 
+Navy’s UAV can fly out to the sailboat and drop off the 
+medical supplies until the USCG can arrived to transport 
 the family to safety.
-Depends on: range, sea states, weather, visibility, day, Night. Is it
-raining? Hailing?"
+Depends on: range, sea states, weather, visibility, day, 
+Night. Is it raining? Hailing?"
 
 References:
 "Skyzer IM20 Mission Model (Non-Combatant Operations 
@@ -45,17 +51,22 @@ Specifications." Final Technical Report SERC-2018-TR-116;
 Systems Engineering Research Center: Hoboken, NJ, 
 USA, 2018.
 
-Search terms: small package delivery; autonomous; ENSURE condition; probability, Type 1
+Search terms: small package delivery; autonomous; 
+ENSURE condition; probability, Type 1
 
 Instructions: Run for Scope 1.
     Scope 1: 2 traces in less than 1 sec.
-This model shows only two scenarios due to overloading constraints
-(constraints that suppress entire branches of execution that a user
-intended to permit). Commenting everything out except the SCHEMA definition and the Air_Vehicle 
-root, and running that model subset at Scope 1, there are 6 event traces that can be seen.
-Two of these are unexpected. In Trace 5, there is no vessel in sight but the Air_Vehicle still
-drops the payload and the payload is on target. In Trace 6, there is no vessel in sight but
-the Air_Vehicle still drops the payload and the payload misses the target.
+This model shows only two scenarios due to overloading 
+constraints (constraints that suppress entire branches of 
+execution that a user intended to permit). Commenting 
+everything out except the SCHEMA definition and the 
+Air_Vehicle root, and running that model subset at Scope 1, 
+there are 6 event traces that can be seen. Two of these are 
+unexpected. In Trace 5, there is no vessel in sight but the 
+Air_Vehicle still drops the payload and the payload is on 
+target. In Trace 6, there is no vessel in sight but the 
+Air_Vehicle still drops the payload and the payload misses 
+the target.
 
 ==========================================================*/
 

models/Application_examples/Spent_Fuel_Cooling_and_Cleanup.mp

 /* Model of Spent Fuel Cooling and Cleanup
 
 Created by Kristin Giammarco on the 4th of May, 2020.
-Modified by Kristin Giammarco with Douglas VanBossuyt on the 8th of May, 2020.
-Modified by Kristin Giammarco with Douglas VanBossuyt on the 13th of May, 2020.
+Modified by Kristin Giammarco with Douglas VanBossuyt 
+	on the 8th of May, 2020.
+Modified by Kristin Giammarco with Douglas VanBossuyt 
+	on the 13th of May, 2020.
 Edited by Keane Reynolds in July, 2021.
 Edited by Pamela Dyer in July and August, 2021.
 
@@ -10,15 +12,17 @@ Purpose: To illustrate the modeling of a complex cooling
 and purification system, specifically a spent nuclear fuel 
 cooling pool in this particular case.
 
-Description: This model demonstrates identifying the components of 
-and interactions among a spent nuclear fuel cooling 
-pool and its environment. Users may use this model to 
-learn about interactions in a system and using COORDINATE 
-statements to make comments on relationships.
+Description: This model demonstrates identifying the 
+components of and interactions among a spent nuclear fuel 
+cooling pool and its environment. Users may use this model 
+to learn about interactions in a system and using 
+COORDINATE statements to make comments on relationships.
 
 References:
 
-Search terms: behavior, nuclear fuel cooling; coordination, event; heat exchanger; purification subsystem
+Search terms: behavior, nuclear fuel cooling; 
+coordination, event; heat exchanger; 
+purification subsystem
 
 Instructions: Run for Scope 1.
 	Scope 1: 6 traces in approx. 1.4 sec.