Object Process Methodology: Difference between revisions

Content deleted Content added
starting work on this, removing and replacing with quotes content copied from Dov Dori's 2016 book Model-Based Systems Engineering with OPM and SysML. Copyrighted content: Do NOT restore
remove some more copied content
Line 56:
 
===Modeling===
OPM representsconsists the system model simultaneously in two different modalities:of Object Process Diagramׂs (OPD) and a corresponding set of sentences in a subset of English, called Object Process Language (OPL). OPL is generated automatically by OPCAT,<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 Process Diagram (OPD)
Line 62:
 
; Object Process Language (OPL)
Each OPD construct (i.e., two or more things connected by one or more links) is translated to a sentence in OPL—a subset of natural English. The power of OPL lies in the fact that it is readable by humans but also interpretable by computers. 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 92:
; 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'', 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.
 
Line 114:
===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 131:
; 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'': A transforming link specifying that the linked process affects the linked object, which is the affectee, i.e., the process causes some unspecified change in the state of the affectee. Graphically, a bidirectional arrow with two closed arrowheads, one pointing in each direction between the affecting process and the affected object, shall define the effect link. The syntax of an effect link OPL sentence is: Processing affects Affectee.
# ''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 148:
#* 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.
Line 172:
# ''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.
Line 184:
[[File:OPM Invocation links.png|thumb|upright=1.5|OPM invocation links]]
; Invocation links : An invocation link connects a source process to the destination process that it initiates.
# ''Process invocation''
# ''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 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.