Read the Instructions.
If your MP model is a homework assignment or for a class project, read the assignment instructions carefully. If, for example, the assignment requires you to demonstrate all event patterns, make sure you have all event patterns in your submission. Attention to details is the foundation of modeling business.
Beware of Copy/Paste Errors.
Sometimes it makes sense to copy/paste from, or directly edit, an existing MP model to create a new MP model, rather than start a new MP model from scratch. In this case, make sure that you remove all irrelevant comments from the new model. Wrong comments are dangerous!
Provide an Accurate Model Introduction.
Always begin every model with some introductory comments. Include at least the model name, author, date, and a short description of the task.
created 2017-04-14 by J.Doe
Provide a brief description of the model purpose, and how to use it.
Also include any interesting analysis highlights or results.
MP is case sensitive. In all cases, use an underscore to separate words of the phrase. This is not required by MP, but is strongly suggested. Use of CamelCase is not recommended.
Application of these conventions may seem like a waste of time at first, but it is not. Standard conventions greatly increase the speed of comprehension and provide structure to minimize ambiguity in natural language. Whatever the naming conventions you use, consistency is paramount.
MP keywords are UPPERCASE in most instances with a few exceptions. (Refer to keywords listing in Section 7 of the MP manual). Therefore usage of ALL_CAPS is not recommended in order to avoid confusion.
Most events in a model are usually activities, but some high level (composite) events can be equated with components, processes, states, and even time phases.
One can use good language grammar to help a reader decipher which type of these event types you are representing:
- Choose a noun-oriented name for an event that represents a thing, component, object, system, person, or organization (e.g., Operations_Team, UAV). Use title case for capitalization.
- Choose an imperative present-tense verb or verb phrase for an event name that represents an activity (e.g., Provide_command, Analyze_object). Use sentence case for capitalization.
- You may choose an indicative past-tense verb or verb phrase to represent zero-duration or instantaneous events (e.g., Authorization_received, Object_detected). Use sentence case for capitalization.
- Choose an indicative present continuous verb or verb phrase for an event name that represents a state (e.g., Conducting_Maintenance, Powering_Up). Use title case for capitalization.
- Choose a process-oriented phrase for an event name that represents a process or time phase (e.g., Mission_Preparation, On_Station). Use title case for capitalization.
Composite events, such as a root event, are often named for the component that embodies the event pattern listed on the right hand side of its grammar rule. Composite events may also be named for high level processes that contain a sequence of events, or for time phases that contain a sequence of events.
One Event Per Line (in General).
Try to write one event per line. Very long lines can be continued (there is no special line continuation character).
Use Indentation and Blank Lines.
Use indentation and blank lines to make the MP code more readable, and to help readers follow the top to bottom stream of events. This practice will become very critical when the size of the MP model starts to grow. Indent composite event patterns, like alternative, iteration, set, to show the hierarchy. Use blank lines to separate composite event definitions.
Use Commas inside Set Patterns for Concurrency.
Use commas in the event set patterns if you want to make events concurrent. Commas are syntactically significant. Refer to Section 5.8 of the MP Guide.