Object Process Methodology: Difference between revisions

Revision as of 16:22, 18 April 2020

Latest revision as of 01:02, 27 August 2025

(46 intermediate revisions by 19 users not shown)

Line 1:

{{Short description|Modelling language and methodology for capturing knowledge and designing systems}}

{{Multiple issues|

{{RefimproveMore citations needed|date=April 2009}}

{{PrimaryOverly sourcesdetailed|date=MayFebruary 20172022}}

{{Copypaste|date=May 2017}}

}}

[[File:OpdContantnew.jpg|thumb|320px|Graphical contents: an example of a diagram in OPM]]

[[File:OplNEW.jpg|thumb|320px|Graphical contents OPL: an example of the OPM language]]

{{InfoMaps}}

''' Object Processprocess Methodologymethodology''' ('''OPM''') is a conceptual [[modeling language]] and [[methodology]] for [[Knowledge capture|capturing knowledge]] and [[Systems design|designing systems]], specified as [[International Organization for Standardization|ISO]]/[[Publicly Available Specification|PAS]] 19450.<ref name="ISO19450">{{cite web |url=https://www.iso.org/standard/62274.html |title=ISO/PAS 19450:2015 - Automation systems and integration -- Object-Process Methodology |website=iso.org |date=December 2015 |accessdateaccess-date=3 May 2017}}</ref> Based on a minimal universal [[Ontology (computer science)|ontology]] of [[stateful]] [[Object (computer science)|object]]s and [[Process theory|process]]es 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.<ref name="ReferenceA">{{cite journal|last=Dori|first=Dov|authorlinkauthor-link=Dov Dori|title=Object-Process Analysis: Maintaining the Balance between System Structure and Behavior|journal=[[Journal of Logic and Computation]]|date=1995|volume=5|issue=2|pages=227–249|doi=10.1093/logcom/5.2.227}}</ref> Since then, OPM has evolved and developed.

In 2002, the first book on OPM<ref name="Object-Process Methodology – A Holistic Systems Paradigm"/> was published, and on December 15, 2015, after six years of work by ISO TC184/SC5, [[International Organization for Standardization|ISO]] adopted OPM as ISO/PAS 19450.<ref name="ISO19450" /> A second book on OPM was published in 2016.<ref name="Model-Based"/>

Line 16:

== Overview ==

Object Processprocess Methodologymethodology (OPM) is a conceptual modeling language and methodology for capturing knowledge and designing systems. Based on a minimal universal [[Ontology (computer science)|ontology]] of [[stateful]] [[Object (computer science)|object]]s and [[Process theory|process]]es 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. Catering to human cognitive abilities, an OPM model represents the system under design or study bimodally in both graphics and text for improved representation, understanding, communication, and learning.

In OPM, an ''object'' is a thinganything that exists,does or mightdoes not exist, physically or informatically. Objects are [[stateful]]—they may have states, such that at each point in time, the object is at one of its states or in transition between states. A ''process'' is a thing that transforms an object by creating or consuming it, or by changing its state.

OPM is bimodal; it is expressed both visually/graphically in Objectobject-Processprocess Diagramsdiagrams (OPD) and verbally/textually in Object-Process Language (OPL), a set of automatically- generated sentences in a subset of English. A patented software package called OPCAT, for generating OPD and OPL, is freely available.<ref name="OPCAT">{{cite web |url=http://esml.iem.technion.ac.il/opcat-installation/ |title=Enterprise Systems Modeling Laboratory » OPCAT installation |website=technion.ac.il |accessdateaccess-date=3 May 2017}}</ref>

==History==

{{Blockquote

The shift to the [[Object-oriented programming|object-oriented]] (OO) paradigm for computer [[programming language]]s, which occurred in the 1980s and 1990s, was followed by the idea that programming should be preceded by [[object-oriented analysis and design]] of the programs, and, more generally, the systems those programs represent and serve. Thus, in the early 1990s, over 30 object-oriented analysis and design methods and notations flourished, leading to what was known as the "methods war".<ref>Booch, G. "Time for a ceasefire in the methods war". ''Journal of Object-Oriented Programming'', July/August 1993.</ref>

|text=The shift to the [[Object-oriented programming|object-oriented]] (OO) paradigm for computer [[programming language]]s, which occurred in the 1980s and 1990s, was followed by the idea that programming should be preceded by [[object-oriented analysis and design]] of the programs, and, more generally, the systems those programs represent and serve. Thus, in the early 1990s, over 30 object-oriented analysis and design methods and notations flourished, leading to what was known as the "methods war".<ref>Booch, G. "Time for a ceasefire in the methods war". ''Journal of Object-Oriented Programming'', July/August 1993.</ref>

|author=[[Dov Dori]]

|title="Preface"

|source=''Model-Based Systems Engineering with OPM and SysML'' (2017)

}}

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:

Around that time, in 1991, [[Dov Dori]], who then joined [[Technion – Israel Institute of Technology]] as faculty, realized that just as the procedural approach to software was not necessarily the most adequate one, neither was the "pure" OO approach, which puts objects as the sole "first class" citizens, with "methods" (or "services", or "operations") being their second-class subordinate procedures.{{Citation needed|date=May 2017}} When he and colleagues from [[University of Washington]] were trying to model a system for automated transformation of [[engineering drawing]]s to [[CAD model]]s, he realized that not all the boxes in their model were really objects; some were things that happen to objects.<ref>{{cite journal |last1=Dori |first1=Dov |last2=Tombre |first2=Karl |title=From engineering drawings to 3D CAD models: are we ready now? |journal=Computer-Aided Design |date=1995 |volume=27 |issue=4 |pages=243–254 |url=http://dori2.technion.ac.il/opm/documents/articles/article172.pdf|doi=10.1016/0010-4485(95)91134-7 |hdl=10068/41847 }}</ref> When he circled those things, a bipartite graph emerged, in which the nodes representing objects—the things that exist—were mediated by those circled nodes, which were identified as processes—the things that transform the objects. Dori published the first paper on OPM in 1995.<ref name="ReferenceA"/>

{{Blockquote

|text=realized that just as the procedural approach to software was inadequate, so was the “pure” OO approach, which puts objects as the sole “first class” citizens, with “methods” (or “services”) being their second-class subordinate procedures.

In 1997, the "methods war" culminated in the adoption of the [[Unified Modeling Language]] (UML), by the [[Object Management Group]] (OMG), making it the de facto standard for software design. UML 1.1 was submitted to the OMG in August 1997 and adopted by the OMG in November 1997.

|author=[[Dov Dori]]

|title="Preface"

|source=''Model-Based Systems Engineering with OPM and SysML'' (2017)

}}

Dori published the first paper on OPM in 1995.<ref name="ReferenceA"/>

UML 1.X had nine types of diagrams. Following a 2001 initiative of the [[International Council on Systems Engineering]] (INCOSE), in 2003 OMG issued the UML for Systems Engineering Request for Proposals, and in 2006 OMG adopted SysML ([[Systems Modeling Language]]) 1.0 specification, which is based on UML 2. Since then, SysML has become the de facto standard for systems engineering.

In 1997, [[Unified Modeling Language]] (UML), by the [[Object Management Group]] (OMG), became the de facto standard for software design. UML 1.1 was submitted to the OMG in August 1997 and adopted by the OMG in November 1997.

The first book on OPM, ''Object-Process Methodology: a Holistic Systems Paradigm'', was published in 2002,<ref name="Object-Process Methodology – A Holistic Systems Paradigm">{{cite book |last=Dori |first=Dov |authorlink=Dov Dori |title=Object-Process Methodology: A Holistic Systems Paradigm |date=2002 |publisher=[[Springer-Verlag]] |___location=Berlin, Heidelberg, New York |isbn=978-3540654711 |doi=10.1007/978-3-642-56209-9 }}</ref> and OPM has since been applied in many domains, ranging from the [[Semantic Web]] to defense and to molecular biology.<ref>{{cite book |last1=Perelman |first1=Valeria |last2=Somekh |first2=Judith |last3=Dori |first3=Dov |title=Model verification framework with application to molecular biology |date=2011 |publisher=Society for Computer Simulation International |pages=140–145 |url=http://dl.acm.org/citation.cfm?id=2048494 |ref=MolecularBiology}}</ref> The recognition that models can and should become the central artifact in system lifecycles has been gaining momentum in recent years, giving rise to [[model-based systems engineering]] (MBSE) as an evolving field in the area of systems engineering.<ref>{{cite journal |last1=Fischer |first1=Amit |last2=Nolan |first2=Mike |last3=Friedenthal |first3=Sanford |last4=Loeffler |first4=Michael |last5=Sampson |first5=Mark |last6=Bajaj |first6=Manas |last7=VanZandt |first7=Lonnie |last8=Hovey |first8=Krista |last9=Palmer |first9=John |last10=Hart |first10=Laura |title=3.1.1 Model Lifecycle Management for MBSE |journal=INCOSE International Symposium |date=2014 |volume=24 |pages=207–229 |doi=10.1002/j.2334-5837.2014.tb03145.x}}</ref>

The first book on OPM, ''Object-Process Methodology: a Holistic Systems Paradigm'', was published in 2002,<ref name="Object-Process Methodology – A Holistic Systems Paradigm">{{cite book |last=Dori |first=Dov |author-link=Dov Dori |title=Object-Process Methodology: A Holistic Systems Paradigm |date=2002 |publisher=[[Springer-Verlag]] |___location=Berlin, Heidelberg, New York |isbn=978-3540654711 |doi=10.1007/978-3-642-56209-9 |s2cid=13600128 }}</ref> and OPM has since been applied in many domains.<ref>{{cite book |last1=Perelman |first1=Valeria |last2=Somekh |first2=Judith |last3=Dori |first3=Dov |title=Model verification framework with application to molecular biology |series=TMS-Devs '11 |date=2011 |publisher=Society for Computer Simulation International |pages=140–145 |url=http://dl.acm.org/citation.cfm?id=2048494 |ref=MolecularBiology}}</ref><ref>{{cite journal |last1=Fischer |first1=Amit |last2=Nolan |first2=Mike |last3=Friedenthal |first3=Sanford |last4=Loeffler |first4=Michael |last5=Sampson |first5=Mark |last6=Bajaj |first6=Manas |last7=VanZandt |first7=Lonnie |last8=Hovey |first8=Krista |last9=Palmer |first9=John |last10=Hart |first10=Laura |title=3.1.1 Model Lifecycle Management for MBSE |journal=Incose International Symposium |date=2014 |volume=24 |pages=207–229 |doi=10.1002/j.2334-5837.2014.tb03145.x|s2cid=106677531 }}</ref>

SysML and OPM have been serving as the two MBSE languages, but since SysML was adopted as a standard about eight years before OPM and has been backed by top-notch vendors, its adoption is currently more widespread. However, OPM is rapidly gaining acceptance in academia and industry.{{cn|date=January 2020}}

In August 2014, after five years of work by ISO TC184/SC5,the ISO adopted OPM as ISO/PAS 19450.<ref name="ISO19450" />

A second book on OPM, which also covers SysML, was published in 2016.<ref name="Model-Based">{{cite book |last=Dori |first=Dov |authorlinkauthor-link=Dov Dori |title=Model-Based Systems Engineering with OPM and SysML |date=2016 |publisher=[[Springer-Verlag]] |___location=New York |isbn=9781493932955 |oclc=959032986 |doi=10.1007/978-1-4939-3295-5|s2cid=32425215 }}</ref>

==Design==

[[File:Opm methodology phases.png|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. Indeed, OPM is fundamentally simple; it builds on a minimal set of concepts: stateful objects—things that exist or might exist physically or informatically at some state, and processes—things that happen to objects and transform them by creating or consuming the objects or by changing their states.<ref name="Model-Based"/>{{rp|2}}

OPM offers a way to model systems of almost any ___domain, be it artificial or natural. OPM has an [[ontological commitment]] to a universal minimal ontology according to which objects exist, while processes transform them.<ref name="Model-Based"/>{{rp|x}}<ref>See also: {{cite journal |last1=Herre |first1=Heinrich |last2=Heller |first2=Barbara |last3=Burek |first3=Patryk |last4=Hoehndorf |first4=Robert |last5=Loebe |first5=Frank |last6=Michalek |first6=Hannes |date=July 2006 |title=General formal ontology (GFO): a foundational ontology integrating objects and processes: part I: basic principles |journal=Onto-Med Report |volume=8 |page=3 |url=http://www.onto-med.de/publications/2006/herre-h-2006-a.pdf |quote=Current languages in use for conceptual modeling like the [[Unified Modeling Language]] (UML), [[entity–relationship model]]ing in the database field, or the Object-Process Methodology can be examined according to their ontological commitments.}}</ref> Transformation|archive-date=2016-03-28 includes|access-date=2017-05-04 object creation and consumption, as well as change of the state of an object|archive-url=https://web. Hence, stateful objects and processes that transform them are the only two concepts in OPM's universal minimal ontologyarchive. Two other cornerstones of OPM are its biorg/web/20160328133208/http://www.onto-modal graphicalmed.de/publications/2006/herre-textual representation and its builth-in refinement2006-abstraction [[complexity management]] mechanisms of in-zooming and unfolding of a.pdf single type of diagram—Object|url-Processstatus=dead Diagram}}</ref> (OPD).

===Modeling===

OPM representsconsists theof systemobject modelprocess simultaneously in two different modalities: Object Process Diagramׂsdiagramׂs (OPD) and a corresponding set of sentences in a subset of English, called Object Process Language (OPL). OPL is generated automatically by OPCAT,<ref name="OPCAT"/> a software tool that supports modeling in OPM.<ref>{{cite journal|last1=Dori|first1=Dov|last2=Linchevski|first2=Chen|last3=Manor|first3=Raanan|title=OPCAT – A Software Environment for Object-Process Methodology Based Conceptual Modelling of Complex Systems|journal=Proc. 1st International Conference on Modelling and Management of Engineering Processes|date=2010|volume=University of Cambridge, Cambridge, UK, Heisig, P., Clarkson, J., and Vajna, S. (Eds.)|pages=147–151}}</ref>

; Object Processprocess Diagramdiagram (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.<ref name="SysMLvsOPM">{{cite book |last1=Grobshtein |first1=Yariv |last2=Perelman |first2=Valeriya |last3=Safra |first3=Eliyahu |last4=Dori |first4=Dov |title=Systems Modeling Languages: OPM Versus SysML |date=2007 |publisher=IEEE |___location=Haifa, Israel |isbn=978-1-4244-0770-5 |pages=102–109 |url=https://ieeexplore.ieee.org/document/424372 |accessdatearchive-url=https://web.archive.org/web/20200218141326/https://ieeexplore.ieee.org/document/424372 |url-status=dead |archive-date=February 18, 2020 |access-date=15 November 2018 |ref=SysMLvsOPM}}</ref> 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 Processprocess Languagelanguage (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. Since each model fact is expressed both graphically and textually, in a subset of natural English, it is readily accessible to non-technical stakeholders, enabling them to take part in the early, critical stages of the system requirements elicitation, architecting and development. 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.<ref name="Model-Based"/>{{rp|3}}

; OPM model animated simulation

Line 60 ⟶ 69:

In his foreword to Dori's book ''Model-Based Systems Engineering with OPM and SysML'', [[Edward F. Crawley]] said:

<blockquote>OPM semantics was originally geared towards systems engineering, as it can model information, hardware, people, and regulation. However, in recent years OPM started to serve also researchers in molecular biology, yielding new published findings related to the mRNA lifecycle. This is a clear indication of the universality of the object-and-process ontology.<ref name="Model-Based"/>{{rp|vi}}<ref>See also: {{cite web |url=http://esml.iem.technion.ac.il/wp-content/uploads/2011/07/Supplement-1.pdf |title=The mRNA Lifecycle |website=technion.ac.il |accessdateaccess-date=3 May 2017}}</ref></blockquote>

==Basics==

[[File:OPMEntities.png|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 Objectobject-Processprocess Diagramsdiagrams (OPDs), and a corresponding textual part—a set of sentences in Objectobject-Processprocess Languagelanguage (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.

Line 72 ⟶ 81:

===Entities===

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

; Object : An object is a thing, which once constructed, exists or can exist physically or informatically. 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.

Line 82 ⟶ 91:

; 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. The precondition is the existence of the required object instances in the preprocess object set, possibly in specific states, as modeled. If and only if the evaluation reveals satisfaction of the precondition, the process starts executing.

==Syntax and semantics==

===Things===

An OPM thing is a generalization of object and process. Objects and processes are symmetric in many regards and have much in common in terms of relations, such as aggregation, generalization, and characterization. OPM objects and OPM processes depend on each other in the sense that an object cannot be transformed without a process, while a process cannot happen without transforming at least one object.

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 the following three generic attributes:

# ''Perseverance''

# ''Perseverance'', which pertains to the thing's persistence and determines whether the thing is static, i.e., an object, or dynamic, i.e., a process.

# ''Essence''

# ''Essence'', which pertains to the thing's nature and determines whether the thing is physical or informatical. Accordingly, the values of the generic attribute Essence are physical and informatical.

# ''Affiliation''

# ''Affiliation'', which pertains to the thing's scope and determines whether the thing is systemic, i.e., part of the system, or environmental, i.e., part of the system's environment. Accordingly, the values of the generic attribute Affiliation are systemic and environmental. Graphically shading effects shall depict physical OPM things and dashed lines shall depict environmental OPM things.

OPM thing generic attributes have the following default values:

Line 104 ⟶ 113:

===Object states===

[[File:OPM Things.png|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, default, and final states : The initial state of an object is its state as the system starts executing or its state upon generation by the system during execution. The final state of an object is its state as the system completes executing or its state upon consumption by the system during execution. The default state of an object is its expected state—the state in which the object is most likely to be when randomly inspected. An object can have zero or more initial states, zero or more final states, and zero or one default state.

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

Line 119 ⟶ 128:

# ''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. According to the procedural link uniqueness OPM principle, at a given extent of abstraction, an object or an object state shall link to a process by only one procedural link.

; State-specified procedural links : Each procedural link may be qualified as 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.[[File:OPM Enabling Links.png|thumb|upright=1.5|OPM enabling links]]

; Transforming links : A transforming link specifies a connection between a process and its transformee (the object it creates, consumes, or changes the object state). The three kinds of transforming links are:

# ''Consumption link'': A transforming link specifying that the linked process consumes (destroys, eliminates) the linked object, the consumee. Existence of the consumee is precondition (or part of the precondition) to the activation of the process. 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.

# ''Effect link'': AnA 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.

# ''Result link'': A transforming link specifying that the linked process creates (generates, yields) the linked object, which is the resultee. 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.

[[File:OPM State-specified transforming links.png|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:

# ''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. It is an enabling link specifying that the agent object is necessary for the linked process to execute. 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.

# ''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. It is an enabling link specifying that the instrument object is necessary for the linked process to execute. Graphically, a line with an open circle ("white lollipop") at the terminal end extending from the instrument object to the process it enables defines an instrument link. The syntax of an instrument link OPL sentence is: Processing requires Instrument.

; State-specified transforming links : A state-specified transforming link connects one of the transformee states to or from that process.

# ''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. The syntax OPL sentence is: Process consumes qualified-state Object.

# ''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.

# ''State-specified effect links'':

Line 138 ⟶ 147:

#* 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.

#* 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.

#* 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. The syntax OPL sentence is: Process changes Object to output-state.

[[File:OPM Basic transforming event links.png|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.

# ''State-specified agent link'': An agent link that originates from a specific qualifying state of the agent. 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.

# ''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. The pre-process object set determines the precondition that must be satisfied before execution of that process starts and as a condition for that process to start executing. 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.

[[File:OPM Basic Enabling event links.png|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. The post-process object set shall determine the post-condition, which shall be satisfied after execution of that process ends. 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.

====Control links====

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 : An event link specifies a source event and a destination process to activate on event occurrence. 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.

[[File:OPM State-specified transforming event links.png|thumb|upright=1.5|OPM state-specified transforming event links]]

# ''Basic transforming event links'': A consumption event link is a link between an object and a process, which an instance of the object activates. Satisfaction of the process precondition and the subsequent process execution need to consume (affect) the instance of the activating object.

#* 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.

#* 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.

[[File:OPM State-specified agent event link.png|thumb|upright=1.5|OPM state-specified agent event link]]

# ''Basic enabling event links'':

#* 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.

#* Instrument event link: An instrument event link is an enabling link from an instrument object to the process that it activates and enables. 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.

#''State-specified transforming event links'':

#* 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. Satisfaction of the process precondition, including the activating object instance being at its specified state, and the subsequent process execution consume the activating object instance. 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.

#* 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.

#* 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.

Line 172 ⟶ 181:

#* 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."

[[File:OPM; Invocation links.png|thumb|upright=1.5|OPM invocation links]]

# ''Process invocation''

; Invocation links : An invocation link connects a source process to the destination process that it initiates.

# ''Self-invocation link''

# ''Process invocation'': Process invocation is an event of triggering of a process by a process. An invocation link is a link from an invoking process to the process that it invokes (triggers), meaning that when the invoking process terminates, it immediately triggers the process at the other end of the invocation link. Graphically, a lightning symbol jagged line from the invoking process terminating with a closed arrowhead at the invoked process end denote an invocation link. The syntax of an invocation link OPL sentence is: Invoking-process invokes invoked-process.

# ''Self-invocation link'': Self-invocation is invocation of a process by itself, such that that upon process termination, the process immediately invokes itself. The self-invocation link shall denote self-invocation. Graphically, a pair of invocation links, originating at the process and joining head to tail before terminating back at the original process denote the self-invocation link. The syntax of a self-invocation link OPL sentence is: Invoking-process invokes itself.

# ''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, which enables system control to skip the destination process if its precondition satisfaction evaluation fails, otherwise the process waits for the precondition to become true.

# ''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. However, if that object instance does not exist, then the process precondition evaluation fails and the control skips the process. 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. The syntax of the condition consumption link OPL sentence is: ''Process'' occurs if ''Object'' exists, in which case ''Object'' is consumed, otherwise ''Process'' is skipped.

# ''Condition effect link'': A condition effect link is a condition link between an object and a process, 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. 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. The syntax of the condition effect link OPL sentence is: ''Process'' occurs if ''Object'' exists, in which case ''Process'' affects ''Object'', otherwise Process is skipped.

# ''Condition agent link'': A condition agent link is a condition link from an object to a process, meaning that if at run-time an agent instance exists and the rest of the process precondition is satisfied, then the process executes and the agent handles execution. However, if that agent instance does not exist, then the process precondition evaluation fails and the control skips the process. 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. [[File:OPM Basic condition enabling link.png|thumb|upright=1.5|OPM basic condition enabling link]][[File:OPM Condition state-specified transforming link.png|thumb|upright=1.5|OPM Condition state-specified transforming link]]

# ''Condition instrument link'': A condition instrument link is a condition link from an object to a process, meaning that if at run-time an instrument instance exists and the rest of the process precondition is satisfied, then the process executes. However, if that instrument instance does not exist, then the process precondition evaluation fails and the control skips the process. 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.

# ''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. However, if that object instance does not exist in the specified state, then the process precondition evaluation fails and the control skips the process. 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.

# ''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. The effect is changing the object instance state from its input state to its output state (the state that the arrowhead of the link from the process points to). 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-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.

# ''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.

# ''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.

# ''Condition state-specified agent link'': A condition state specified agent link is a state-specified agent link from a specified state of an object to a process, meaning that if at run-time an object instance exists in that state and the rest of the process precondition is satisfied, then the process executes and the agent handles execution. However, if an agent instance does not exist in that state, then the process precondition evaluation fails and the control skips the process. Graphically, the condition agent link extending from a specified agent state to the process it enables. The syntax of the condition state-specified agent link OPL sentence is: Agent handles ''Process'' if Agent is ''qualifying-state'', else ''Process'' is skipped.

# ''Condition state-specified instrument link''

# ''Condition state-specified instrument link'': A condition state-specified instrument link is a state-specified instrument link from a specified state of an object to a process, meaning that if at runtime an object instance exists in that state and the process precondition is satisfied, then the process is executes. However, if an instrument instance does not exist in that state, then the process precondition evaluation fails and the control skips the process. If the skipped process is within an in-zoom context and there is a subsequent process in this context, control triggers that process, otherwise control transfers one level up to the in-zoomed process. Graphically, the condition instrument link extending from a specified instrument state to the process it enables. The syntax of the condition state-specified instrument link OPL sentence is: Process occurs if Instrument is qualifying-state, otherwise Process is skipped.

More information and examples can be found in ''Model-Based Systems Engineering with OPM and SysML'', Chapter 13 "The Dynamic System Aspect".<ref name="Model-Based"/>

Line 196 ⟶ 204:

; Unidirectional tagged structural link : Has a user-defined semantics regarding the nature of the relation from one thing to the other. Graphically, an arrow with an open arrowhead. Along the tagged structural link, the modeler should record a meaningful tag in the form of a textual phrase that expresses the nature of the structural relation between the connected objects (or processes) and makes sense when placed in the OPL sentence whose syntax follows.

; Unidirectional null-tagged structural link : AnA unidirectional tagged structural link with no tag. In this case, the default unidirectional tag is used. The modeler has the option of setting the default unidirectional tag for a specific system or a set of systems. If no default is defined, the default tag is "relates to".

; Bidirectional tagged structural link : When the tags in both directions are meaningful and not just the inverse of each other, they may be recorded by two tags on either side of a single bidirectional tagged structural link. Each tag shall align on the side of the arrow with the harpoon edge sticking out of the arrowhead unambiguously determining the direction in which each relation applies. The syntax of the resulting tagged structural link is two separate tagged structural link OPL sentences, one for each direction. Graphically, a line with harpoon shaped arrowheads on opposite sides at both ends of the link's line shall.

; Reciprocal tagged structural link : A reciprocal tagged structural link is a bidirectional tagged structural link with no more than one tag. In either case, reciprocity indicate that the tag of a bidirectional structural link has the same semantics for its forward and backward directions. When no tag appears, the default tag shall be "are related". The syntax of the reciprocal tagged structural link with only one tag shall be: Source-thing and destination thing are reciprocity-tag. The syntax of the reciprocal tagged structural link with no tag is: Source thing and Destination-thing are related.

; Fundamental structural relations : The most prevalent structural relations among OPM things and are of particular significance for specifying and understanding systems. Each of the fundamental relations is elaborate or refine one OPM thing, the source thing, or refinee, into a collection of one or more OPM things, the destination thing or things, or refineables. The fundamental structural relations are; Aggregation, Exhibition-characterization, Generalization-specialization, and Classification-instantiation.

; Aggregation-participation link : A refinee—the whole—aggregates one or more other refineables—the parts. Graphically, a black solid (filled in) triangle with its apex connecting by a line to the whole and the parts connecting by lines to the opposite horizontal base shall denote the aggregation-participation relation link.

; Exhibition-characterization link : A thing exhibits, or is characterized by, another thing. The exhibition-characterization relation binds a refinee—the exhibitor—with one or more refineables, which shall identify features that characterize the exhibitor Graphically, a smaller black triangle inside a larger empty triangle with that larger triangle's apex connecting by a line to the exhibitor and the features connecting to the opposite (horizontal) base defines the exhibition-characterization relation link.

; Generalization-specialization and inheritance : These are structural relations which provide for abstracting any number of objects or process classes into superclasses, and assigning attributes of superclasses to subordinate classes.

# ''Generalization-specialization link''

# ''Generalization-specialization link'': The refinee—the general—generalizes the refineables, which are specializations of the general. Binds one or more specializations with the same persistence attribute value as the general, such that either the general and all its specializations are objects or the general and all its specializations are processes. Graphically, an empty triangle with its apex connecting by a line to the general and the specializations connecting by lines to the opposite base defines the generalization-specialization link.

# ''Inheritance through specialization''

# ''Inheritance through specialization'': Inheritance is assignment of OPM elements of a general to its specializations. A specialization inherits from the general thing through the generalization-specialization link the following four kinds of inheritable elements, if there are any: 1. all the general's parts from its aggregation-participation link; 2. all the general's features from its exhibition-characterization link; 3. all the tagged structural links to which the general connects; and 4. all the procedural links to which the general connects. [[File:OPM Condition state-specified enabling link.png|thumb|upright=1.5|OPM condition state-specified enabling link]]

# ''Specialization restriction through discriminating attribute'': A subset of the possible values of an inherited attribute may restrict the specialization. An attribute whose different values determine corresponding specializations is a discriminating attribute. [[File:OPM Fundamental structural relations and link.png|thumb|upright=1.5|OPM fundamental structural relations and links]]

; Classification-instantiation and system execution : The relation between a class of things and an instance of that class in the system at the operational level.

# ''Classification-instantiation link'': A source thing, which is an object class or a process class connect to one or more destination things, which are valued instances of the source thing's pattern, i.e. the features specified by the pattern acquire explicit values. This relation provides the modeler with an explicit mechanism for expressing the relationship between a class and its instances created by the provision of feature values. Graphically, a small black circle inside an otherwise empty larger triangle with apex connecting by a line to the class thing and the instance things connecting by lines to the opposite base defines the classification-instantiation relation link. The syntax is: Instance-thing is an instance of Class-thing.

# ''Instances of object class and process class''

# ''Instances of object class and process class'': These are two distinct kinds of classes. An instance of a class is an incarnation of a particular identifiable instance of that class, an actual object of some class of objects bearing the same classification identifier. A single actual object is an object instance, while the pattern of object, which all the instances follow, is an object class. A process class is a pattern of happening, which involves object classes that are members of the preprocess and postprocess object sets. A single actual process occurrence, which follows this pattern and involves particular object instances in its preporcess and postprocess object sets, is a process instance. Hence, a process instance is a particular occurrence of a process class to which that instance belongs. Any process instance have associated with it a distinct set of preporcess and postprocess object instance sets.

; State-specified structural relations and links

; State-specified structural relations and links : These provide for associating a state of one object with another object or with a state of another object. [[File:OPM State-specified structural relations and links.png|thumb|upright=1.5|OPM state-specified structural relations and links]]

# ''State-specified characterization relation and link'': An exhibition-characterization relation from a specialized object that exhibits a value for a discriminating attribute of that object, meaning that the specialized object shall have only that value. Graphically, the exhibition-characterization link triangular symbol, with its apex connecting to the specialized object and its opposite base connecting to the value, defines the state-specified characterization relation. The syntax is: Specialized-object exhibits value-name Attribute-Name.

# ''State-specified tagged structural relations and links'': A structural relation between a state of an object or value of an attribute and another object or its state or value, meaning that these two entities are associated with the tag expressing the semantics of the association. In case of a null tag (i.e., the tag is not specified), the corresponding default null tag is used. Three groups of state-specified tagged structural relations exist: (1) source state-specified tagged structural relation, (2) destination state-specified tagged structural relation, (3) source-and-destination state-specified tagged structural relation. Each of these groups includes the appropriate unidirectional, bidirectional, and reciprocal tagged structural relation, giving rise to seven kinds of state-specified tagged structural relation link and corresponding OPL sentences.

Line 243 ⟶ 251:

; Logical AND procedural links

The logical operators AND, XOR, and OR among procedural relations enable specification of elaborate process precondition and postcondition. Separate, non-touching links shall have the semantics of logical AND.

Here, unlocking the safe requires all three keys.

In the example, opening the safe requires all three keys. [[File:Summary of XOR and OR converging consumption and result links.jpg|thumb|upright=1.5|XOR and OR converging consumption and result links]]

; Logical XOR and OR procedural links

A group of two or more procedural links of the same kind that originate from, or arrive at, the same object or process shall be a link fan. A link fan shall follow the semantics of either a XOR or an OR operator. The link fan end that is common to the links shall be the convergent link end. The link end that is not common to the links shall be the divergent link end.

The XOR operator shall mean that exactly one of the things in the span of the link fan exists, if the divergent link end has objects, or happens, if the divergent link end has processes. Graphically, a dashed arc across the links in the link fan with the arc focal point at the convergent end point of contact shall denote the XOR operator.

Line 253 ⟶ 261:

; State-specified XOR and OR link fans

Each one of the link fans in shall have a corresponding state-specified version, where the source and destination may be specific object states or objects without a state specification. Combinations of state-specified and stateless links as destinations of a link fan may occur.

[[File:Control-modified link fans.jpg|thumb|upright=1.5|Control-modified link fans]]

; Control-modified link fans

; Control-modified link fans : Each one of the XOR link fans for consumption, result, effect, and enabling links and their state-specified versions shall have a corresponding control-modified link fan: an event link fan and a condition link fan. The example presents the event and condition effect link fans, as representatives of the basic (non-state-specified) links version of the modified link fans.

[[File:Link probabilities and probabilistic link fans.jpg|thumb|upright=1.5|Link probabilities and probabilistic link fans]]

; Link probabilities and probabilistic link fans

; Link probabilities and probabilistic link fans : A process P with a result link that yields a stateful object B with n states s1 through sn shall mean that the probability of generating B at each one of its states shall be 1/n. The single result link shall be used instead of the result link fan. Usually, probabilities of following a specific link in a link fan are not equal. Link probability shall be a value assigned to a link in a XOR diverging link fan that specifies the probability of following that particular link among the possible links in the fan link. A probabilistic link fan shall be a link fan with probability annotations on each fan link, where the sum of the probabilities shall be exactly 1. Graphically, along each fan link an annotation shall appear in the form Pr=p, where p is the link probability numeric value or a parameter, which denotes the probability of the system control to select and follow that particular link of the fan. The corresponding OPL sentence shall be the XOR diverging link fan sentence without link probabilities omitting the phrase "exactly one of…" and the phrase "…with probability p" following each things name with a probability annotation "Pr=p".

[[File:Execution path and path labels.jpg|thumb|upright=1.5|Execution path and path labels]]

; Execution path and path labels : A path label shall be a label along a procedural link, which, in the case that there is more than one option to follow upon process termination, prescribes that the link to follow will be the one having the same label as the one which we entered the process, A path label is a label on a procedural link that removes the ambiguity arising from multiple outgoing procedural links by specifying that the link to be followed is the one with the same label as the one with which the process was entered.

==Modeling principles and model comprehension==

System function and modeling purpose is to guide the scope and level of detail of an OPM model. The definition of system purpose, scope, and function in terms of boundary, stakeholders and preconditions is the basis for determining whether other elements should appear in the model. This determines the scope of the system model.

OPM provides abstracting and refining mechanisms to manage the expression of model clarity and completeness. The model has a hierarchy tree for refinement, elaboration, or decomposition obtained by unfolding.<ref name="ISO19450"/><ref name="Model-Based"/>

; Stakeholder and system's beneficiary identification

In order to start an OPM model of a system, the first step is to determine the function of the system—the main process of the system. A beneficiary of the artificial, man-made system is a stakeholder who receives functional value and benefits from the function of the system. For man-made systems this function is expected to benefit a person or a group of people—the beneficiary. After the function of the system aligns with the functional value expectation of its main beneficiary, the modeler identifies and adds other principal stakeholders to the OPM model. Modeling a system starts by defining, naming, and depicting the function of the system, which is also its top-level process.

; System diagram

The resulting top-level OPD is the system diagram (SD), which includes the stakeholder group, in particular the beneficiary group, and additional top-level environmental things, which provide the context for the system's operation. The SD should contain only the central and important things—those things indispensable for understanding the function and context of the system. 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 of the operand whose value the process changes. An OPM model fact needs to appear in at least one OPD in order for it to be represented in the model. SD should also contain an object representing the system that enables the function. The default name of this system is created by adding the word "System" to the name of the function. For example, if the function is Car Painting, the name of the system would be Car Painting System.

; OPD tree

[[File:OPD process tree.png|thumb|An OPD process tree with two nodes and one labelled edge]]

SD is always the only top-level OPD—it is the root of the OPD tree. The set of OPDs, organized as a process tree, which together specify the system. The OPD set keeps growing as additional OPDs are gradually constructed to increasingly refine the model and make it more concrete. The ability to add a descendant, subordinate OPD whenever the one currently under work reaches its congestion limits makes it possible to avoid over-cluttering any single OPD.

; Clarity and completeness trade-off

Clarity is the extent of unambiguous comprehension the system's structure and behavior models convey. Completeness is the extent of specification for all the system's details. These two model attributes conflict with each other. On the one hand, completeness requires the full stipulation of system details. On the other hand, the need for clarity imposes an upper limit on the extent of detail within an individual model diagram, after which comprehension deteriorates because of clutter and overloading. Establishing an appropriate balance requires careful management of context during model development. However, the modeler may take advantage of the union of information provided by the entire OPD set of an OPM system model and have one OPD which is clear and unambiguous but not complete, and another that focuses on completeness for some smaller part of the system by adding more details.

; Refinement-abstraction mechanisms

OPM shall provide abstracting and refining mechanisms to manage the expression of model clarity and completeness. These mechanisms make possible the specification of contextualized model segments as separate, yet interconnected OPDs which, taken together, shall provide a model of the functional value providing system. These mechanisms shall enable presenting and viewing the system, and the things that comprise it, in various contexts that are interrelated by the objects, processes and relations that are common amongst them. Explicitly depicting the states of an object in an OPD may result in a diagram that is too crowded or busy, making it hard to read or comprehend. The OPM refinement-abstraction mechanisms shall be the following pairs of inverse operations: State expression and suppression, unfolding and folding, and in-zooming and outzooming.

; State expression and state suppression

[[File:State OPM.png|thumb|upright=1.5|A stateful object with all its five states expressed (left) and a suppressed version (right), in which only the relevant subset of states are left while the rest are replaced by the ellipsis (…) state]]

OPM shall provide an option for state suppression, i.e., suppressing the appearance of some or all the states

within an object as represented in a particular OPD when those states are not necessary in that OPD's context.

The inverse of state suppression shall be state expression, i.e., refining the OPD by adding the information

concerning possible object states. The OPL corresponding to the OPD shall express only the states of the

Line 290 ⟶ 293:

; Unfolding and folding

Unfolding is a mechanism for refinement, elaboration, or decomposition. It reveals a set of things that are hierarchically below the unfolded thing. The result is a hierarchy tree, the root of which is the unfolded thing. Linked to the root are the things that constitute the context of the unfolded thing. Conversely, folding is a mechanism for abstraction or composition, which applies to an unfolded hierarchical tree.

; In-zooming and out-zooming

Line 297 ⟶ 300:

==Meta modeling==

[[File:OPM Model.jpg|thumb|upright=1.5|OPM model structure]]

A metamodel is a model of a model. In particular, using OPM model to present aspects of OPM. The examples described here are a part of the comprehensive metamodels of OPM appear in an annex of ISO 19450.

; OPM model structure

[[File:OPM Model 2.jpg|thumb|upright=1.5|OPM model structure—OPL]]

OPM model is a metamodel, as shown in the image of OPM model on the right. Using OPM to specify the structure of an OPM model of a system. It depicts the conceptual aspects of OPM as parallel hierarchies of the graphic and textual OPM modalities and their correspondence to produce equivalent model expressions. An OPD Construct is the graphical expression of the corresponding textual OPL Sentence, which express the same model fact. An OPD and its corresponding OPL Paragraph are collections of model facts that a modeller places into the same model context.

; Model of OPD Construct and Basic Construct

[[File:OPD Metamodel.jpg|thumb|upright=1.5|OPD model]]

Line 319 ⟶ 318:

; OPM model of Thing generic properties

[[File:OPM model of Thing generic properties.jpg|thumb|upright=1.5|OPM model of Thing generic properties]]

OPM model of Thing generic properties, depicts Thing and its Perseverance, Essence, and Affiliation generic properties modelled as attribute refinees of an exhibition-characterization link. Perseverance is the discriminating attribute between Object and Process. Essence is the discriminating attribute between Physical Object and Physical Process on the one hand, Informatical Object, and Informatical Process on the other hand. Affiliation is the discriminating attribute between Systemic Object and Systemic Process on the one hand, Environmental Object, and Environmental Process on the other hand.

; In-zooming and out-zooming models

[[File:Zoom OPM.png|thumb|upright=1.5|New-diagram in-zooming generic example]]

Both new-diagram in-zooming and new-diagram out-zooming create a new OPD context from an existing OPD context. New-diagram in-zooming starts with an OPD of relatively less details and adds elaboration or refinement as a descendant OPD that applies to a specific thing in the less detailed OPD.

New-diagram out-zooming starts with an OPD of relatively more details and removes elaboration or refinement to produce a less detailed, more abstract thing in an ancestor context.

New-diagram in-zooming elaborates a refineable present in an existing OPD, say SDn, by creating a new OPD, SDn+1, which elaborates the refineable by adding subprocesses associated objects, and relevant links. The new-diagram in-zooming and in new-diagram out-zooming processes are inverse operations.

New-diagram in-zooming and new-diagram out-zooming models depict the new-diagram in-zooming and new-diagram out-zooming processes. The model on the right uses in-diagram in-zooming of the model on the left to elaborate the two processes, one for creating a new-diagram in-zoomed context and one for creating a new-diagram out-zoomed context.

New-diagram in-zooming begins with Content Showing, followed by Link Refining. New-diagram out-zooming begins with Link Abstracting, the inverse process of Link Refining, followed by Content Hiding, the inverse process of Content Showing.

==Versions==

Line 346 ⟶ 337:

A previous OPCAT version, 3.1, with fewer capabilities, is also available from the same site. Both are coded in Java. The first OPCAT version, OPCAT 1.X, was written in Visual C++ in 1998.

In the beginning of 2016 a team of students under the management of Dori began working on the new generation of OPCAT which will be called OPCloud.<ref>{{cite web |last1=Enterprise Systems Modeling Laboratory |title=opcloud |url=https://www.opcloud.tech/}}</ref> 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.<ref>{{cite web |last1=Dori |first1=Dov |last2=Jbara |first2=Ahmad |last3=Levi |first3=Natali |last4=Wengrowicz |first4=Niva |title=Object-Process Methodology, OPM ISO 19450 – OPCloud and the Evolution of OPM Modeling Tools |url=https://www.ppi-int.com/syen61-a1/ |website=Project Performance International |accessdateaccess-date=18 November 2018}}</ref>

==Standardization==

Line 352 ⟶ 343:

===ISO and OPM===

In June 2008, Richard Martin approached [[Dov Dori]] after his presentation at the [[International Council on Systems Engineering|INCOSE]] International Symposium in Utrecht, the Netherlands, to inquire about the possibility of creating an International Standard for OPM.{{Citation<ref needed|datename=May":0" 2017}}/> Martin, convener of ISO TC184/SC5/WG1 for automation systems interoperability architecture and modelling, had for some time been searching for methodologies offering more than static information and process modeling.{{Citation needed|date=May 2017}} He provided Dori with a simple example to model that could demonstrate both the modelling capability of OPM and its dynamic simulation opportunity.{{Citation needed|date=May 2017}}

In May 2010, Dori presented a brief overview of OPM and his demonstration model at the ISO Technical Committee 184/Sub-Committee 5 (TC184/SC5) plenary meeting, which then adopted a resolution to create an OPM Study Group for the purpose of examining the potential for OPM to enhance the standards created by SC5.<ref>{{cite web |last1=Dori |first1=Dov |last2=Howes |first2=David |last3=Blekhman |first3=Alex |last4=Martin |first4=Richard |title=OPM as a Basis for Model - Based Enterprise Standards, Report of the ISO TC184/SC5 OPM Working Group to the Plenary ISO TC184/SC5Meeting, Tokyo 26, 2010 |url=http://esml.iem.technion.ac.il/wp-content/uploads/2011/05/OPM_WG_Report_to_TC184-SC5_Tokyo_March_26_2010.pdf |accessdateaccess-date=18 November 2018}}</ref>

The OPM Study Group began its work in October 2010 and issued an interim report for the 2011 SC5 Plenary.<ref name=":0">{{cite web |last1=Blekhman |first1=Alex |last2=Dori |first2=Dov |last3=Martin |first3=Richard |title=Model-Based Standards Authoring |url=http://esml.iem.technion.ac.il/wp-content/uploads/2011/07/Model-Based-Standards-Authoring-March-2011.pdf |accessdateaccess-date=18 November 2018}}</ref> 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.<ref>{{cite web |last1=SC 5 PLENARY MEETING |title=Meeting Report |url=http://esml.iem.technion.ac.il/wp-content/uploads/2011/05/ISO-TC184-SC5_N1185_2012_SC5_Plenary_Meeting_Report_-_Haifa_.pdf |accessdateaccess-date=18 November 2018}}</ref> 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.{{Citation needed|date=May 2017}}

===ISO 19450 Document===

Line 369 ⟶ 360:

== OPM vs. SysML and UML ==

; OPM vs. SysML

[[File:OPMvsSYSML.png|thumb|upright=1.5|Comparison between SysML and OPM attributes]]

SysML is defined as an extension of the [[Unified Modeling Language]] (UML) using [[profile (UML)|UML's profile mechanism]].<ref name="SysMLvsOPM"/>

OPM and [[SysML]] represent two different approaches to system modeling. SysML is defined as an extension of the [[Unified Modeling Language]] (UML) using [[profile (UML)|UML's profile mechanism]]. In SysML up to nine multiple models are used, which are independently derived, and may not be completely consistent.<ref name="Object-Process Methodology – A Holistic Systems Paradigm"/>{{Page needed|date=October 2017}} In OPM, only one single model emerges. The need to integrate several kinds of models may be more complicated in OPM. In OPM there is a combination between complex—the inherent fact that a system contains many parts interacting in multiple, often inexplicable ways, and complexity—the way a system model is presented through a certain modeling language and is perceived by a user. OPM with its minimal ontology of stateful objects and processes favorably responds to the challenge of reducing the complexity of the representation to the bare necessities without sacrificing accuracy and details.<ref name="SysMLvsOPM"/>

; OPM vs. UML

The differences between OPM and UML are highly perceivable during the analysis and design stages. While UML is a multi-model, OPM supports a single unifying structure-behavior model. The crucial differences stem from the structure-oriented approach of UML, in which behavior is spread over thirteen diagram types, a fact that inevitably invokes the model multiplicity problem.<ref>{{cite journal | last1 = Peleg | first1 = M. | last2 = Dori | first2 = D. | year = 2000 | title = The Model Multiplicity Problem: Experimenting with Real-Time Specification Methods | url = | journal = IEEE Transactions on Software Engineering| volume = 26 | issue = 8| pages = 742–759 | doi=10.1109/32.879812| citeseerx = 10.1.1.321.5507 }}</ref> First, using the OPM approach enables to view at main diagram (SD) the main process, objects and the connection between them.<ref name="Object-Process Methodology – A Holistic Systems Paradigm"/>{{Page needed|date=October 2017}} In addition, it is easy to understand what is the main system's benefit (presented at the SD). In OPM, it's also easier to understand the main three aspects of the system: behavior, structure and functionality (contrary to UML which describes these aspects with different types of diagrams).<ref name="Object-Process Methodology – A Holistic Systems Paradigm"/>{{Page needed|date=October 2017}} Database unfolding modeling contributes to the understanding of system and all details which is stored in the system. In addition, creating in-zooming enables simplifying the model. OPM requires extensive knowledge of systematic processes such as how the system saved the path and gets decisions.

==Generating SysML views from an OPM model==

While both languages aim at the same purpose of providing a means for general-purpose systems engineering, these languages take different approaches in realizing this goal. SysML is a profile of UML (Unified Modeling Language). Therefore, it is possible to convert an OPM diagram to an UML or SysML diagram.

The OPM-to SysML translation is one-to-many in the sense that a single OPM element (entity or link) usually translates to several SysML elements that belong in different SysML diagram types. For example, an OPM process, which is defined as an entity that transforms (generates, consumes, or changes the state of) an object, can be mapped to any subset of the following SysML entities:

* Use case (in a Use[[use Casecase Diagramdiagram]])

* Action (in an Activity[[activity Diagramdiagram]])

* State transition trigger (in a Statestate Machinemachine Diagramdiagram).

As OPM and SysML are two distinct and differently designed languages, not all the constructs in one language have equivalent constructs in the other language.

# The first type of diagram in UML that can be generated from an OPM diagram is the use case diagram which is intended for modeling the usage of a system. The main elements comprising the use case diagram are actors and use cases (the entities) along with the relationships (links) among them. Generation of a use case diagram from OPM is therefore based on environmental objects (the actors) and the processes (the use cases) linked to them. Figure 1 is an example of use case diagram generation of SD0. The figure shows the root OPM diagram (a), the corresponding OPL text (b), and the created use case diagram (c). Figure 2 shows a SD1 level of OPD from the same OPM model (a), and the generated use case diagram (b).

[[File:OPMtoUML SD0.png|thumb|upright=1.5|Figure 1: Use Case Diagram generation of SD0]]

# The second type of diagram is the block definition diagram (BDD) which defines features of blocks (like properties and operations) and relationships between blocks, such as associations and generalizations. Generating a BDD is based upon the systemic objects of the OPM model and their relationships—mainly structural relations to other model elements.

[[File:OPMtoUML SD1.png|thumb|upright=1.5|Figure 2: Use Case Diagram generation of SD1]]

# The third type of diagram is activity diagrams which are intended to specify flow. Key components included in the activity diagram are actions and routing flow elements. In our context, a separate Activity Diagram can be generated for each OPM process containing child subprocesses, i.e., a process which is in-zoomed in the OPM model. There are two kinds of user parameters that can be specified via the settings dialog. The first one deals with selection of the OPM processes: One option is to explicitly specify the required OPM processes by selection from a list. The alternative, which is the default option, is to start with the root OPD (SD) and go down the hierarchy. Here we reach the second parameter (that is independent of the first one), which is the required number of OPD levels (k) to go down the hierarchy. In order to give the user control over the level of abstraction, the diagrams are generated up to k levels down the hierarchy. Each level will result in the generation of an additional activity diagram, which is a child activity (subdiagram) contained in the enclosing higher-level activity. The default setting for this option is "all levels down" (i.e., "k = ∞").<ref>{{cite book |last1=Grobshtein |first1=Yariv |last2=Dori |first2=Dov |title=Creating SysML views from an OPM model |date=2009 |publisher=IEEE |___location=Haifa, Israel |isbn=978-1-4244-2967-7 |pages=36–44 |ref=SysMLfromOPM|doi=10.1109/MBSE.2009.5031718 |s2cid=6195904 }}</ref>

# The first type of diagram in UML that can be generated from an OPM diagram is the Use Case Diagram which is intended for modeling the usage of a system. The main elements comprising the Use Case Diagram are actors and use cases (the entities) along with the relationships (links) among them. Generation of a Use Case Diagram from OPM is therefore based on environmental objects (the actors) and the processes (the use cases) linked to them. Figure 1 is an example of Use Case Diagram generation of SD0. The figure shows the root OPM diagram (a), the corresponding OPL text (b), and the created Use Case Diagram (c). Figure 2 shows a SD1 level of OPD from the same OPM model (a), and the generated Use Case Diagram (b).

# The second type of diagram is the Block Definition Diagram (BDD) which defines features of blocks (like properties and operations) and relationships between blocks, such as associations and generalizations. Generating a BDD is based upon the systemic objects of the OPM model and their relationships—mainly structural relations to other model elements.

# The third type of diagram is Activity Diagrams which are intended to specify flow. Key components included in the Activity Diagram are actions and routing flow elements. In our context, a separate Activity Diagram can be generated for each OPM process containing child subprocesses, i.e., a process which is in-zoomed in the OPM model. There are two kinds of user parameters that can be specified via the settings dialog. The first one deals with selection of the OPM processes: One option is to explicitly specify the required OPM processes by selection from a list. The alternative, which is the default option, is to start with the root OPD (SD) and go down the hierarchy. Here we reach the second parameter (that is independent of the first one), which is the required number of OPD levels (k) to go down the hierarchy. In order to give the user control over the level of abstraction, the diagrams are generated up to k levels down the hierarchy. Each level will result in the generation of an additional Activity Diagram, which is a child activity (subdiagram) contained in the enclosing higher-level activity. The default setting for this option is "all levels down" (i.e., "k = ∞").<ref>{{cite book |last1=Grobshtein |first1=Yariv |last2=Dori |first2=Dov |title=Creating SysML views from an OPM model |date=2009 |publisher=IEEE |___location=Haifa, Israel |isbn=978-1-4244-2967-7 |pages=36–44 |ref=SysMLfromOPM|doi=10.1109/MBSE.2009.5031718 }}</ref>

[[File:The OPM to Activity Diagram Map.jpg|centre|thumb|598x598px]]

==Study of model comprehension==

In order to assess and examine the effectiveness of the newly developed OPM-to-SysML algorithm and application, Dov Dori and Yariv Grobshtein performed a controlled experiment, which had two major goals:

# Since improved system comprehension was among the potential predicted benefits, they ventured to examine whether the additional SysML diagrams that had been generated automatically with their new application affected system model comprehension;

# They wished to test the quality of the autocreated diagrams, mainly in terms of modeling errors and inconsistencies with the original OPM model from which they were generated.

They carried out the experiment within a lecture of the course "Enterprise Systems Modeling" taught in 2008. Testing the null hypothesis that there is no difference in comprehension level between the OPM-only model and the combined OPM-and-SysML model, against the two-sided alternative that there is a difference, they rejected the null hypothesis in both cases. For both systems, the students' answers to comprehension questions relating the combined OPM-and-SysML models were significantly better than answers relating to OPM-only models.

It seems that the additional diagrams were helpful in answering some of the questions more than the others. Only one question of eight in each of the cases scored lower when the combined diagrams specification was used. The SysML diagram that seems to have the biggest added value is the Block Definition Diagram (BDD), which specifies system hierarchy and features of blocks like attributes and operations. The relatively high helpfulness of the BDD is evident from both the students'assessment of the contribution of this diagram type and from analysis of the scores in the individual questions in both systems. According to the results of the experiment, the Use Case diagram seems to have the least effect on system comprehension, and this is also in agreement with the students' assessment of the Use Case diagram type contribution. In between are the Activity diagram and the State Machine diagram, which appear to have a positive effect, albeit not as high as the effect of the BDD.

As noted, the other goal of the experiment was to assess the quality of the OPM-to-SysML application in terms of errors and inconsistencies between the source OPM model and the generated SysML diagrams. In this regard, the students did not find any issues of errors, inconsistencies, or contradictions associated with the SysML diagrams, indicating that the application has achieved a high level of model-to-model translation fidelity.

In the study an algorithm for automatic SysML views generation from an OPM model was developed and applied. For each SysML view, a mapping scheme from OPM elements to SysML elements constitutes the foundation for the OPM-toSysML sub algorithm and translation engine application. The mappings are partial and do not utilize all the available language elements. The software implementation was OPCAT, the OPM-supporting modeling tool.<ref>{{cite journal |last1=Grobshtein |first1=Yariv |last2=Dori |first2=Dov |title=Generating SysML views from an OPM model: Design and evaluation |journal=Systems Engineering |date=February 2011 |volume=14 |issue=3 |pages=327–340 |doi=10.1002/sys.20181 |ref=SysMLtoOPMEval }}</ref>

== See also ==