Object Process Methodology: Difference between revisions

Revision as of 15:55, 11 April 2023

Revision as of 08:42, 30 April 2023

Line 7:

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

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'' anything that does or does not exist. 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 |access-date=3 May 2017}}</ref>

==History==

Line 55:

===Modeling===

OPM consists of Objectobject Processprocess 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 |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. 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}}

Line 73:

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

; Invocation links

# ''Process invocation''

Line 280 ⟶ 279:

; OPD tree

; Clarity and completeness trade-off

Line 373 ⟶ 371:

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 Useuse Casecase Diagramdiagram which is intended for modeling the usage of a system. The main elements comprising the Useuse Casecase Diagramdiagram are actors and use cases (the entities) along with the relationships (links) among them. Generation of a Useuse Casecase Diagramdiagram 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 Useuse Casecase Diagramdiagram generation of SD0. The figure shows the root OPM diagram (a), the corresponding OPL text (b), and the created Useuse Casecase Diagramdiagram (c). Figure 2 shows a SD1 level of OPD from the same OPM model (a), and the generated Useuse Casecase Diagramdiagram (b).

# The second type of diagram is the Blockblock Definitiondefinition Diagramdiagram (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 Activityactivity Diagramsdiagrams which are intended to specify flow. Key components included in the Activityactivity Diagramdiagram 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 Activityactivity Diagramdiagram, 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 |s2cid=6195904 }}</ref>

== See also ==