Object Process Methodology: Difference between revisions

Revision as of 13:04, 14 February 2022

Revision as of 14:44, 15 February 2022

Line 82:

===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 97:

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

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.

Line 105:

# ''Perseverance''

# ''Essence''

# ''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 129:

# ''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 : The three kinds of transforming links are:

# ''Consumption link'': Graphically, an arrow with a closed arrowhead pointing from the consumee to the consuming process defines the consumption link. By assumption, the consumed object disappears as soon as the process begins execution. The syntax of a consumption link OPL sentence is: Processing consumes Consumee.

Line 166:

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

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

Line 183:

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

; Invocation links

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

# ''Process invocation''

# ''Self-invocation link''

Line 190:

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

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

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 207:

; 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 : 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 bidirectional tagged structural link with 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.

Line 219:

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

; 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 253:

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

In the exampleHere, openingunlocking 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 321:

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

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

==Versions==