|
; Invocation links : An invocation link connects a source process to the destination process that it initiates.
# ''Process invocation''
# ''Self-invocation link''
# ''Self-invocation link'': Self-invocation is invocation of a process by itself, such 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. 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.
# ''Condition effect link'': However, if that object instance does not exist, then the process precondition evaluation fails and the control skips the process. Graphically, ana bidirectional arrow with atwo closed arrowheadarrowheads, one pointing fromin each direction between the affected object toand the affecting process, with the small letter c (for condition) near the arrowheadprocess shallend denoteof athe condition consumption linkarrow. The syntax of the condition consumptioneffect link OPL sentence is: ''Process'' occurs if ''Object'' exists, in which case ''ObjectProcess'' isaffects consumed''Object'', 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'': Graphically, the condition instrument link extending from a specified instrument state to the process it enables.
# ''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"/>
; Unidirectional null-tagged structural link : A 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 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 : 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 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
; 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
==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]]
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]]
; 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
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 outin-zooming startselaborates witha refineable present in an existing OPD, ofsay relativelySDn, moreby detailscreating anda removesnew elaborationOPD, orSDn+1, refinementwhich toelaborates producethe arefineable lessby detailed,adding moresubprocesses abstractassociated thingobjects, in anand ancestorrelevant contextlinks.
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==
; 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
==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:
| 