thumb|320px|Graphical contents OPL: an example of the OPM language

Object process methodology (OPM) is a conceptual modeling language and methodology for capturing knowledge and designing systems, specified as ISO/PAS 19450. Based on a minimal universal ontology of stateful objects and processes that transform them, OPM can be used to formally specify the function, structure, and behavior of artificial and natural systems in a large variety of domains.

OPM was conceived and developed by Dov Dori. The ideas underlying OPM were published for the first time in 1995. Since then, OPM has evolved and developed.

In 2002, the first book on OPM

History

Around that time, in 1991, Dov Dori, who then joined Technion – Israel Institute of Technology as faculty said in his 2016 book Model-Based Systems Engineering with OPM and SysML that he:

Dori published the first paper on OPM in 1995. and OPM has since been applied in many domains.

In August 2014, the ISO adopted OPM as ISO/PAS 19450.

Design

alt=Opm methodology phases|thumb|OPM methodology phases

Object-Process Methodology (OPM) is a systems modeling paradigm that integrates two aspects inherent in any system: its structure and its behavior. Structure is represented via objects and structural relations among them, such as aggregation-participation (whole-part relation) and generalization-specialization ("is-a" relation). Behavior is represented by processes and how they transform objects: How they create or consume objects, or how they change the states of an object.

Modeling

OPM consists of object process diagramׂs (OPD) and a corresponding set of sentences in a subset of English, called Object Process Language (OPL). OPL is generated automatically by OPCAT,

; Object process diagram (OPD)

OPD is the one and only kind of diagram of OPM. This uniqueness of diagram kind is a major contributor to OPM's simplicity, and it is in sharp contrast to UML, which has 14 kinds of diagrams, and to SysML, which has nine such kinds. An OPD graphically describes objects, processes and links among them. Links can be structural and procedural. Structural links connect objects to objects or processes to processes, expressing the static system aspect—how the system is structured. Procedural links connect objects to processes, expressing the dynamic system aspect—how the system changes over time. The entire system is represented by a set of hierarchically organized OPDs, such that the root OPD, called the systems diagram (SD), specifies the "bird's eye" view of the system, and lower-level OPDs specify the system in increasing levels of detail. All the OPDs in the system's OPD set are "aware" of each other, with each showing the system, or part of it, at some level of detail. The entire system is specified in its entirety by the union of the details (model facts) appearing in all the OPDs.

; Object process language (OPL)

Each OPD construct (i.e., two or more things connected by one or more links) is translated to a sentence in OPL—a subset of natural English. The power of OPL lies in the fact that it is readable by humans but also interpretable by computers. These are the stages where the most important design decisions are made. The graphics-text bimodality of OPM makes it suitable to jointly model requirements by a team that involves both the customer or his domain expert on one hand, and the system architect, modelers, and designers on the other hand.</blockquote>

Basics

thumb|upright=1.5|OPM entities: object, object state and process

OPM has two main parts: the language and the methodology. The language is bimodal—it is expressed in two complementary ways (modalities): the visual, graphical part—a set of one or more object-process diagrams (OPDs), and a corresponding textual part—a set of sentences in object-process language (OPL), which is a subset of English.

The top-level OPD is the system diagram (SD), which provides the context for the system's function. For man-made systems this function is expected to benefit a person or a group of people—the beneficiary. The function is the main process in SD, which also contains the objects involved in this process: the beneficiary, the operand (the object upon which the process operates), and possibly the attribute whose value the process changes.

OPM graphical elements are divided into entities, expressed as closed shapes, and relations, expressed as links that connect entities.

Entities

Entities are the building blocks of OPM. They include objects and processes, collectively called things, and object states.

; Object : Associations among objects constitute the object structure of the system being modeled. In OPL text, the object name shall appear in bold face with capitalization of each word.

; Object state : An object state is a particular situation classification of an object at some point during its lifetime. At every point in time, the object is in one of its states or in transition between two of its states—from its input state to its output state.

; Process : A process is an expression of the pattern of transformation of objects in the system. A process does not exist in isolation; it is always associated with and occurs or happens to one or more objects. A process transforms objects by creating them, consuming them, or changing their state. Thus, processes complement objects by providing the dynamic, behavioral aspect of the system. In OPL text, the process name shall appear in bold face with capitalization of each word.

thumb|upright=1.5|OPM structural links

thumb|upright=1.5|OPM procedural links

; Structural link : A structural links defines a structural relation. A structural relation shall specify an association that persists in the system for at least some interval of time.

; Procedural link : A procedural link defines procedural relation. A procedural relation shall specify how the system operates to attain its function, designating time dependent or conditional triggering of processes, which transform objects.

; Event and condition : The Event-Condition-Action paradigm provides the OPM operational semantics and flow of control. An event is a point in time at which an object is created (or appears to be created from the system's perspective) or an object enters a specified state. At runtime, this process triggering initiates evaluation of the process precondition. Thus, starting a process execution has two prerequisites: (1) a triggering event, and (2) satisfaction of a precondition.

Once the event triggers a process, the event ceases to exist.

Syntax and semantics

Things

Objects and processes are symmetric in many regards and have much in common in terms of relations, such as aggregation, generalization, and characterization.

To apply OPM in a useful manner, the modeler has to make the essential distinction between objects and processes, as a prerequisite for successful system analysis and design. By default, a noun shall identify an object.

Thing generic attributes

OPM things have three generic attributes:

  1. Perseverance
  2. Essence
  3. Affiliation

OPM thing generic attributes have the following default values:

  1. The default value of the Affiliation generic attribute of a thing is systemic.
  2. System essence shall be the primary essence of the system. Like thing essence, its values are informatical and physical. Information systems, in which the majority of things are informatical, shall be primarily informatical, while systems in which the majority of things are physical shall be primarily physical.
  3. The default value of the Essence generic attribute of a thing in a primarily informatical [physical] system shall be informatical [physical].

Object states

thumb|upright=1.5|OPM things and object states

; Stateful and stateless objects : Dov Dori explains in Model-Based Systems Engineering with OPM and SysML that "An object state is a possible situation in which an object may exist. An object state has meaning only in the context of the object to which it belongs." A stateless object shall be an object that has no specification of states. A stateful object shall be an object for which a set of permissible states are specified. In a runtime model, at any point in time, any stateful object instance is at a particular permissible state or in transition between two states.

; Attribute values : An attribute is an object that characterizes a thing. An attribute value is a specialization of state in the sense that a value is a state of an attribute: an object has an attribute, which is a different object, to which that value is assigned for some period of time during the existence of the object exhibiting that attribute.

; Object state representation : A state is graphically defined by a labelled, rounded-corner rectangle placed inside the owning object. It can not live without an object. In OPL text, the state name shall appear in bold face without capitalization.

; Initial, default, and final states

; Initial, final, and default state representation : A state that is initial is graphically defined by a state representation with thick contour. A state that is final is graphically defined by a state representation with double contour. A state that is default is graphically defined by a state representation with an open arrow pointing diagonally from the left. The corresponding OPL sentences shall include explicit indicators for an initial, final or default state.

thumb|upright=1.5|OPM Transforming Links

A procedural link is one of three kinds:

  1. Transforming link, which connects a transformer (an object that the process transforms) or its state with a process to model object transformation, namely generation, consumption, or state change of that object as a result of the process execution.
  2. Enabling link, which connects an enabler (an object that enables the process occurrence but is not transformed by that process) or its state, to a process, which enables the occurrence of that process.
  3. Control link, which is a procedural (transforming or enabling) link with a control modifier—the letter e (for event) or c (for condition), which adds semantics of a control element. The letter e signifies an event for triggering the linked process, while the letter c signifies a condition for execution of the linked process, or connection of two processes denoting invocation, or exception.

; Procedural link uniqueness OPM principle :A process needs to transform at least one object. Hence, a process shall be connected via a transforming link to at least one object or object state. At any particular extent of abstraction, an object or any one of its states shall have exactly one role as a model element with respect to a process to which it links: the object may be a transformee or an enabler. Additionally, it can be a trigger for an event (if it has the control modifier e), or a conditioning object (if it has the control modifier c), or both.

; State-specified procedural links : A state-specified procedural link is a detailed version of its procedural link counterpart in that rather than connecting a process to an object, it connects a process to a specific state of that object.thumb|upright=1.5|OPM enabling links

; Transforming links : The three kinds of transforming links are:

  1. Consumption link: Graphically, an arrow with a closed arrowhead pointing from the consumee to the consuming process defines the consumption link. By assumption, the consumed object disappears as soon as the process begins execution. The syntax of a consumption link OPL sentence is: Processing consumes Consumee.
  2. Effect link: A transforming link specifying that the linked process affects the linked object, which is the affectee, i.e., the process causes some unspecified change in the state of the affectee. Graphically, a bidirectional arrow with two closed arrowheads, one pointing in each direction between the affecting process and the affected object, shall define the effect link. The syntax of an effect link OPL sentence is: Processing affects Affectee.
  3. Result link: Graphically, an arrow with a closed arrowhead pointing from the creating process to the resultee shall define a result link. The syntax of a result link OPL sentence is: Processing yields Resultee.

thumb|upright=1.5|OPM state-specified transforming links

; Enabling links : An enabling link is a procedural link specifying an enabler for a process—an object that must be present for that process to occur, but the existence and state of that object after the process is complete are the same as just before the process began. The two kinds of enabling links are:

  1. Agent and agent link: A human or a group of humans capable of intelligent decision-making, who enable a process by interacting with the system to enable or control the process throughout execution. Graphically, a line with a filled circle ("black lollipop") at the terminal end extending from the agent object to the process it enables defines an agent link. The syntax of an agent link OPL sentence is: Agent handles Processing.
  2. Instrument and instrument link: An inanimate or otherwise non-decision-making enabler of a process that cannot start or take place without the existence and availability of the instrument.

; State-specified transforming links :

  1. State-specified consumption link: A consumption link that originates from a particular state of the consumee, meaning that the consumee must be in that state for it to be consumed by the process to which it is linked. Graphically, an arrow with a closed arrowhead pointing from the particular object state to the process, which consumes the object, defines the state-specified consumption link.
  2. State-specified result link: A result link that terminates at a specific state of the resultee, meaning that the resultee shall be in that resultant state upon its construction. Graphically, an arrow with a closed arrowhead pointing from the process to the particular object state defines the state-specified result link. The syntax OPL sentence is: Process yields qualified-state Object.
  3. State-specified effect links:
  4. Input and output effect links- An input link is the link from the object's input state to the transforming process, while the output link is the link from the transforming process to the object's output state.
  5. Input-output-specified effect link: A pair of effect links, where the input link originates from a particular state of the affectee and the output link originates from that process and terminates at the output state of the same affectee. Graphically, a pair of arrows with a closed arrowhead from the input state of the affectee to the affecting process and a similar arrow from that process to the state of the affectee at process terminates defines the input-output-specified effect link. The syntax OPL sentence is: Process changes Object from input-state to output-state.
  6. Input-specified effect link: A pair of effect links, where the input link originates from a particular state of the affectee and the output link originates from that process and terminates at the affectee without specifying a particular state. Graphically, a pair of arrows consisting of an arrow with a closed arrowhead from a particular state—the input state—of the affectee to the process, and a similar arrow from that process to the affectee but not to any one of its states defines the input-specified effect link. The syntax OPL sentence is: Process changes Object from input-state.
  7. Output-specified effect link: A pair of effect links, where the input (source) link originates from an affectee, and the output link originates from the process and terminates at the output (destination, resultant) state of the same affectee. Graphically, a pair of arrows consisting of an arrow with a closed arrowhead from the affectee, but not from any one of its states, to the affecting process, and a similar arrow from that process to a particular state of that affectee— the output state— defines the output-specified effect link.

thumb|upright=1.5|OPM basic transforming event links

; State-specified enabling links : Originate from a specific qualifying state and terminate at a process, meaning that the process may occur if and only if the object exists at the state from which the link originates.

  1. State-specified agent link: Graphically, a line with a filled circle ("black lollipop") at the terminal end extending from the qualifying state of the agent object to the process it enables defines a state-specified agent link. The syntax OPL sentence is: Qualifying-state Agent handles Processing.
  2. State-specified instrument link: An instrument link that originates from a specific qualifying state of the instrument. Graphically, a line with an empty circle ("white lollipop") at the terminal end extending from the qualifying state of the instrument object to the process it enables defines a state-specified instrument link. The syntax OPL sentence is: Processing requires qualifying-state instrument.

Event-Condition-Action control

; Preprocess object set and process precondition : In order for an OPM process to start executing once it has been triggered, it needs a set of objects comprising one or more consumes, some possibly at specific states, and/or affects, collectively called the preprocess object set. At instance-level execution, each consume B in the pre-process object set of process P shall be consumed and stop to exist at the beginning of the lowest level sub-process of P which consumes B. Each affected (an object whose state changes) B in the preprocess object set of process P shall exit from its input state at the beginning of the lowest level sub-process of P.

thumb|upright=1.5|OPM basic enabling event links

; Post-process object set and process post-condition : A set of objects, comprising one or more results, some possibly at given states, and/or affects, collectively called the post-process object set, shall result from executing a process and carrying out the transformations associated with its execution. Each resulted B in the post process object set of process P shall be created and start to exist at the end of the lowest level sub process of P which yields B. Each affected B in the post-process object set of process P shall enter its output state at the end of the lowest level sub-process of P.

An event link and a condition link express an event and a condition, respectively. Control links occur either between an object and a process or between two processes.

; Event links : Triggering a process initiates an attempt to execute the process, but it does not guarantee success of this attempt. The triggering event forces an evaluation of the process' precondition for satisfaction, which, if and only if satisfied, allows process execution to proceed and the process becomes active. Regardless of whether the precondition is satisfied or not, the event will be lost. If the precondition is not satisfied, process execution will not occur until another event activates the process and a successful precondition evaluation allows the process to execute.

  1. Basic transforming event links: A consumption event link is a link between an object and a process, which an instance of the object activates.
  2. Consumption event link: Graphically, an arrow with a closed arrowhead pointing from the object to the process with the small letter e (for event). The syntax of a consumption event link OPL sentence is: Object triggers Process, which consumes Object.
  3. Effect event link: Graphically, a bidirectional arrow with closed arrowheads at each end between the object and the process with a small letter e (for event). The syntax of an effect event link OPL sentence is: Object triggers Process, which affects Object.
  1. Basic enabling event links:
  2. Agent event link: An agent event link is an enabling link from an agent object to the process that it activates and enables. Graphically, a line with a filled circle ("black lollipop") at the terminal end extending from an agent object to the process it activates and enables with a small letter e (for event). The syntax of an agent event link OPL sentence is: Agent triggers and handles Process.
  3. Instrument event link: Graphically, a line with an empty circle ("white lollipop') at the terminal end extending from the instrument object to the process it activates and enables with a small letter e (for event). The syntax of an instrument event link OPL sentence is: Instrument triggers Process, which requires Instrument.
  4. State-specified transforming event links:
  5. State-specified consumption event link: A state-specified consumption event link is a consumption link that originates from a specific state of an object and terminates at a process, which an instance of the object activates. Graphically, an arrow with a closed arrowhead pointing from the object state to the process with the small letter e (for event). The syntax of a state-specified consumption event link OPL sentence is: Specified-state Object triggers Process, which consumes Object.
  6. Input-output-specified effect event link: An input-output-specified effect event link is an input-output-specified effect link with the additional meaning of activating the affecting process when the object enters the specified input state. Graphically, the input-output-specified effect link with a small letter e (for event). The syntax of an input-output specified effect event link OPL sentence is: Input-state Object triggers Process, which changes Object from input-state to output-state.
  7. Input-specified effect event link: An input-specified effect event link is an input-specified effect link with the additional meaning of activating the affecting process when the object enters the specified input state. Graphically, the input-specified effect link with a small letter e (for event. The syntax of an input-specified effect event link OPL sentence is: Input-state Object triggers Process, which changes Object from input-state.
  8. Output-specified effect event link: An output-specified effect event link is an output-specified effect link with the additional meaning of activating the affecting process when the object comes into existence. Graphically, the output-specified effect link with a small letter e (for event). The syntax of an output-specified effect event link OPL sentence is: Object in any state triggers Process, which changes Object to destination-state
  9. State-specified agent event link:
  10. State-specified agent event link: A state-specified agent event link is a state-specified agent link with the additional meaning of activating the process when the agent enters the specified state. Graphically, the state-specified agent link with a small letter e (for event). The syntax of a state-specified agent event link OPL sentence is: Qualifying-state Agent triggers and handles Processing".
  11. State-specified instrument event link: A state-specified instrument event link is a state-specified instrument link with the additional meaning of activating the process when the instrument enters the specified state. Graphically, the state-specified instrument link with a small letter e (for event). The syntax of a state-specified instrument event link OPL sentence is: Qualifying-state Instrument triggers Processing, which requires qualifying-state Instrument."

; Invocation links

  1. Process invocation
  2. Self-invocation link
  3. Implicit invocation link: Implicit invocation occurs upon sub-process termination within the context of an in-zoomed process, at which time the sub-process invokes the one(s) immediately below it. Graphically, there is no link between the invoking and the invoked sub-processes; their relative heights within the in-zoom context of their ancestor process implies this semantics.

; Condition links : A condition link is a procedural link between a source object or object state and a destination process that provides a bypass mechanism.

  1. Condition consumption link: A condition consumption link is a condition link from an object to a process, meaning that if in run-time an object instance exists, then the process precondition is satisfied, the process executes and consumes the object instance. Graphically, an arrow with a closed arrowhead pointing from the object to the process with the small letter c (for condition) near the arrowhead shall denote a condition consumption link.
  2. Condition effect link: However, if that object instance does not exist, then the process precondition evaluation fails and the control skips the process. Graphically, a bidirectional arrow with two closed arrowheads, one pointing in each direction between the affected object and the affecting process, with the small letter c (for condition) near the process end of the arrow.
  3. Condition agent link: Graphically, a line with a filled circle ('black lollipop") at the terminal end extending from an agent object to the process it enables, with the small letter c (for condition) near the process end. The syntax of the condition agent link OPL sentence is: Agent handles Process if Agent exists, else Process is skipped.
  4. Condition instrument link: Graphically, a line with an empty circle ("white lollipop") at the terminal end, extending from an instrument object to the process it enables, with the small letter c (for condition) near the process end, shall denote a condition instrument link. The syntax of the condition instrument link OPL sentence shall be: Process occurs if Instrument exists, else Process is skipped.
  5. Condition state-specified consumption link: A condition state-specified consumption link is a condition consumption link that originates from a specified state of an object and terminates at a process, meaning that if an object instance exists in the specified state and the rest of the process precondition is satisfied, then the process executes and consumes the object instance. Graphically, an arrow with a closed arrowhead pointing from the object qualifying state to the process with the small letter c (for condition) near the arrowhead.
  6. Condition input-output-specified effect link: A condition input-output-specified effect link is an input-output specified effect link with the additional meaning that if at run-time an object instance exists and it is in the process input state (and assuming that the rest of the process precondition is satisfied), then the process executes and affects the object instance. Graphically, the condition input-output-specified effect link with the small letter c (for condition) near the arrowhead of the input. The syntax of the condition input-output-specified effect link OPL sentence is: Process occurs if Object is input-state, in which case Process changes Object from input-state to output-state, otherwise Process is skipped.
  7. Condition input-specified effect link: A condition input specified effect link is an input-specified effect link with the additional meaning that if at run-time an object instance exists in the specified input state and the rest of the process precondition is satisfied, then the process executes and affects the object instance by changing its state from its input state to an unspecified state. However, if that object instance does not exist at the input state, then the process precondition evaluation fails and the control skips the process. Graphically, the condition input-specified effect link with the small letter c (for condition) near the arrowhead of the input link. The syntax of a condition input-specified effect link OPL sentence is: Process occurs if Object is input state, in which case Process changes Object from input-state, otherwise Process is skipped.
  8. Condition output-specified effect link: A condition output-specified effect link is an output-specified effect link with the additional meaning that if at run-time an object instance exists and the rest of the process precondition is satisfied, then the process executes and affects the object instance by changing its state to the specified output-state. However, if that object instance does not exist, then the process precondition evaluation fails and the control skips the process. Graphically, the condition output-specified effect link with the small letter c (for condition) near the arrowhead of the input link. The syntax of the condition output-specified effect OPL sentence is: Process occurs if Object exists, in which case Process changes Object to output-state, otherwise Process is skipped.
  9. Condition state-specified agent link: The syntax of the condition state-specified agent link OPL sentence is: Agent handles Process if Agent is qualifying-state, else Process is skipped.
  10. Condition state-specified instrument link

More information and examples can be found in Model-Based Systems Engineering with OPM and SysML, Chapter 13 "The Dynamic System Aspect". As suggested by the name of the software, it will be a cloud-based application, and will enable users to create OPM models using a web-based application.

Standardization

ISO—the International Organization for Standardization—is an independent, non-governmental international organization with a membership of 162 national standards bodies, which develops voluntary, consensus-based, market relevant International Standards that support innovation and provide solutions to global challenges. These standards provide world-class specifications for products, services and systems, to ensure quality, safety and efficiency.

ISO and OPM

In June 2008, Richard Martin approached Dov Dori after his presentation at the INCOSE International Symposium in Utrecht, the Netherlands, to inquire about the possibility of creating an International Standard for OPM.

The OPM Study Group began its work in October 2010 and issued an interim report for the 2011 SC5 Plenary. The report included several uses of OPM to model existing SC5 standards and led to an initial motivation for the standardization of OPM with the realization that being text-based, ISO standards are prone to suffer from inconsistencies and incomplete information. This deficiency could be significantly reduced if the standards were model-based rather than text-based, and OPM offered a useful underlying modeling paradigm for this purpose.

A final OPM Study Group Report and a draft for a metamodel for model-based standards authoring document were delivered at the 2012 SC5 Plenary. As the OPM Study Group effort progressed, it became obvious that OPM could also serve as a solid and comprehensive basis for model-based systems engineering (MBSE) and for modeling both natural and man-made systems.

ISO 19450 Document

TC184/SC5/WG1 participants received the first draft of the OPM PAS in September 2011 with 16 pages, 2 annexes and a bibliography for a total of 25 pages. Most of the content simply identified sub-clause headings and space holder graphics. By the 2012 SC5 Plenary, the PAS draft included 10 full clauses describing OPM features and 6 annexes totaling 86 pages. One annex was an EBNF (Extended Backus-Naur Form, used to formally specify context free languages, enabling parsing of programming languages) specification for OPL and another detailed OPD graph grammar. To facilitate verification of the EBNF specification, David Shorter wrote a script to evaluate consistency and completeness of the EBNF statement set. Further effort to add meaningful examples and complete all of the identified sections resulted in a draft of 138 pages by the time of the 2013 SC5 Plenary. Subsequently, the working draft was registered with the SC5 Secretariat as a Committee Draft for initial circulation to SC5 members.

Because the SC5 resolution calling for the OPM specification indicated that the document was to be registered as a Publicly Available Specification (PAS), it would have only one acceptance ballot opportunity. In April 2014, the New Work Item Proposal and revised Committee Draft for ISO/PAS 19450 was delivered to SC5 for consideration. By now the Committee Draft was 98 pages plus front matter, four annexes and 30 bibliographic references, totaling 183 pages. In March 2015, ISO registered the result of balloting for ISO/PAS 19450 as 8 Approve, 1 Approve with comments, and 1 abstain.

ISO/PAS 19450 was formally published with a total of 162 pages by ISO on December 15, 2015, culminating a six-year effort to provide the standardization community with a formal specification for a new approach to modeling that binds together graphics and textual representations into a single paradigm suitable for automated simulation of model behavior.

OPM vs. SysML and UML

; OPM vs. SysML

SysML is defined as an extension of the Unified Modeling Language (UML) using UML's profile mechanism. First, using the OPM approach enables to view at main diagram (SD) the main process, objects and the connection between them.

See also

  • Formal ontology
  • Process ontology
  • Ontology language
  • Upper ontology

References

  • Object-Process Methodology and Its Application to the Visual Semantic Web, presentation by Dov Dori, 2003.
  • Some Features of the Technical Language of Navya-Nyāya
  • Formalizing the Conceptual Modeling Thought Process to Benefit Engineers and Scientists., presentation by Dov Dori, 2015.
  • Formalizing the Conceptual Modeling Thought Process to Benefit Engineers and Scientists
  • US Patent US7099809B2 on conversion of OPD to and from text formats