Object Process Methodology

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

{{Multiple issues|

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

{{Overly detailed|date=February 2022}}

}}

File:OplNEW.jpg

{{InfoMaps}}

Object process methodology (OPM) is a conceptual modeling language and methodology for capturing knowledge and designing systems, specified as ISO/PAS 19450.{{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}} Based on a minimal universal ontology of stateful objects and processes 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.{{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}} Since then, OPM has evolved and developed.

In 2002, the first book on OPM was published, and on December 15, 2015, after six years of work by ISO TC184/SC5, ISO adopted OPM as ISO/PAS 19450. A second book on OPM was published in 2016.

Since 2019, OPM has become a foundation for a Professional Certificate program in Model-Based Systems Engineering - MBSE [https://www.edx.org/professional-certificate/israelx-model-based-systems-engineering at EdX]. Lectures are available [https://www.youtube.com/channel/UCMJTbOJq-3RCM7E1mfHCF5Q as web videos on Youtube].

Overview

Object process methodology (OPM) is a conceptual modeling language and methodology for capturing knowledge and designing systems. Based on a minimal universal ontology of stateful objects and processes 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 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 object-process diagrams (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.{{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}}

History

{{Blockquote

|text=The shift to the object-oriented (OO) paradigm for computer programming languages, 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".Booch, G. "Time for a ceasefire in the methods war". Journal of Object-Oriented Programming, July/August 1993.

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

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

|author=Dov Dori

|title="Preface"

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

}}

Dori published the first paper on OPM in 1995.

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,{{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 }} and OPM has since been applied in many domains.{{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}}{{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 }}

In August 2014, the ISO adopted OPM as ISO/PAS 19450.

A second book on OPM, which also covers SysML, was published in 2016.{{cite book |last=Dori |first=Dov |author-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 }}

Design

File:Opm methodology phases.png

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.{{rp|2}}

OPM offers a way to model systems of almost any domain, be it artificial or natural.{{rp|x}}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 modeling in the database field, or the Object-Process Methodology can be examined according to their ontological commitments.}}

=Modeling=

OPM consists 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, a software tool that supports modeling in OPM.{{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}}

; Object process diagram (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.{{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 |archive-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}} 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 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. 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.{{rp|3}}

; OPM model animated simulation

OPM models are not just static graphical and textual representations of the system—they are also executable. A correct OPM model constructed in OPCAT can be simulated by animating it, visually expressing how the system behaves over time to achieve its function at all detail levels. An incorrect OPM model will not execute all the way through, and will indicate where and why it is stuck, effectively serving as a visual debugger.

=Development=

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

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.{{rp|vi}}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 |access-date=3 May 2017}}

Basics

File:OPMEntities.png

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 object-process diagrams (OPDs), and a corresponding textual part—a set of sentences in object-process language (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.

OPM graphical elements are divided into entities, expressed as closed shapes, and relations, expressed as links that connect entities.

=Entities=

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

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

=Links=

File:OPM Sructural Links.png

File:OPM Procedural Links.png

; Structural link : A structural links defines a structural relation. A structural relation shall specify an association that persists in the system for at least some interval of time.

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

Syntax and semantics

=Things=

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.

=Thing generic attributes=

OPM things have three generic attributes:

  1. Perseverance
  2. Essence
  3. Affiliation

OPM thing generic attributes have the following default values:

  1. The default value of the Affiliation generic attribute of a thing is systemic.
  2. System essence shall be the primary essence of the system. Like thing essence, its values are informatical and physical. Information systems, in which the majority of things are informatical, shall be primarily informatical, while systems in which the majority of things are physical shall be primarily physical.
  3. The default value of the Essence generic attribute of a thing in a primarily informatical [physical] system shall be informatical [physical].

=Object states=

File:OPM Things.png

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

=Links=

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

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

=Relationship cardinalities=

File:Link cardinalities summary.jpgFile:Object multiplicity in structural and procedural links.jpg

; Object multiplicity in structural and procedural links

Object multiplicity shall refer to a requirement or constraint specification on the quantity or count of object instances associated with a link. Unless a multiplicity specification is present, each end of a link shall specify only one thing instance. The syntax of an OPL sentence that includes an object with multiplicity shall include the object multiplicity preceding the object name, with the object name appearing in its plural form. Multiplicity specifications may appear in the following cases:

  1. to specify multiple source or destination object instances for a tagged structural link of any kind;
  2. to specify a participant object with multiple instances in an aggregation-participation link, where a different participation specification may be attached to each one of the parts of the whole;
  3. to specify an object with multiple instances in a procedural relation.

; Object multiplicity expressions and constraints

Object multiplicity may include arithmetic expressions, which shall use the operator symbols "+", "–", "*", "/", "(", and ")" with their usual semantics and shall use the usual textual correspondence in the corresponding OPL sentences.

An integer or an arithmetic expression may constrain object multiplicity. Graphically, expression constraints shall appear after a semicolon separating them from the expression that they constrain and shall use the equality/inequality symbols "=", "<", ">", "<=", and ">=", the curly braces "{" and "}" for enclosing set members, and the membership operator "in" (element of, ∈), all with their usual semantics. The corresponding OPL sentence shall place the constraint phrase in bold letters after the object to which the constraint applies in the form ", where constraint".

; Attribute value and multiplicity constraints

The expression of object multiplicity for structural and procedural links specifies integer values or parameter symbols that resolve to integer values. In contrast, the values associated with attributes of objects or processes may be integer or real values, or parameter symbols that resolve to integer or real values, as well as character strings and enumerated values. Graphically, a labelled, rounded-corner rectangle placed inside the attribute to which it belongs shall denote an attribute value with the value or value range (integers, real numbers, or string characters) corresponding to the label name. In OPL text, the attribute value shall appear in bold face without capitalization.

The syntax for an object with an attribute value OPL sentence shall be: Attribute of Object is value.

The syntax for an object with an attribute value range OPL sentence shall be: Attribute of Object range is value-range. A structural or a procedural link connecting with an attribute that has a real number value may specify a relationship constraint, which is distinct from an object multiplicity.

Graphically, an attribute value constraint is an annotation by a number, integer or real, or a symbol parameter, near the attribute end of the link and aligning with the link.

=Logical operators: AND, XOR, and OR=

File:Logical AND procedural links.jpg

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

; Logical XOR and OR procedural links

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.

The OR operator shall mean that at least one of the two or more things in the span of the link fan exists, if the divergent link end has objects, or happens, if the divergent end has processes. Graphically, two concentric dashed arcs across the links with their focal point at the convergent end point of contact shall denote the OR operator.

; State-specified XOR and OR link fans

File:Control-modified link fans.jpg

; Control-modified link fans

File:Link probabilities and probabilistic link fans.jpg

; Link probabilities and probabilistic link fans

File:Execution path and path labels.jpg

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

Modeling principles and model comprehension

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.

; Stakeholder and system's beneficiary identification

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.

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

; Clarity and completeness trade-off

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

; State expression and state suppression

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

objects that are depicted.

; Unfolding and folding

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

In-zooming is a kind of unfolding, which is applicable to aggregation-participation only and has additional semantics. For processes, in-zooming enables modeling the sub-processes, their temporal order, their interactions with objects, and passing of control to and from this context. For objects, in-zooming creates a distinct context that enables modeling the constituent objects spatial or logical order. Graphically, the timeline within the context of an in-zoomed process flows from the top of its process ellipse symbol to the ellipse bottom.

Meta modeling

File:OPM Model.jpg

; OPM model structure

File:OPM Model 2.jpg

; Model of OPD Construct and Basic Construct

File:OPD Metamodel.jpg

The model, as seen in the image of OPD metamodel, elaborates the OPD Construct concept. The purpose of this model is to distinguish Basic Construct from another possible OPD Construct. A Basic Construct is a specialization of OPD Construct, which consists of exactly two Things connected by exactly one Link. The non-basic constructs include, among others, those with link fans or more than two refinees.

A modeller could add a process to the model, by adding states disconnected and connected of Thing Set.

The purpose of the model thus includes the action of transforming a disconnected Thing Set to a connected Thing Set using the Link Set as an instrument of connection.

; OPM model of Thing

File:OPM model of Thing.jpg

OPM model of Thing, is a model for an OPM Thing, showing its specialization into Object and Process, as depicted in the image of model of thing below. A set of States characterize Object, which can be empty, in a Stateless Object, or non-empty in the case of a Stateful Object.

A Stateful Object with s States gives rise to a set of s stateless State-Specific Objects, one for each State.

A particular State-Specific Object refers to an object in a specific state. Modelling the concept of State-Specific Object as both an Object and a State enables simplifying the conceptual model by referring to an object and any one or its states by simply specifying Object.

; OPM model of Thing generic properties

File:OPM model of Thing generic properties.jpg

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.

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

Versions

File:Object Process Methodology (logo).jpg

; OPM

The current version of OPM is ISO/PAS 19450:2015 as specified in Automation Systems and Integration — Object-Process Methodology. The specification in Dori's 2016 book is a superset of ISO/PAS 19450:2015.

The previous version of OPM was specified in Dori's 2002 book.

; OPCAT

The current OPCAT version is 4.1. It is available freely from Technion's Enterprise Systems Modeling Laboratory.

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.{{cite web |last1=Enterprise Systems Modeling Laboratory |title=opcloud |url=https://www.opcloud.tech/}} 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.{{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 |access-date=18 November 2018}}

Standardization

ISO—the International Organization for Standardization—is an independent, non-governmental international organization with a membership of 162 national standards bodies, which develops voluntary, consensus-based, market relevant International Standards that support innovation and provide solutions to global challenges. These standards provide world-class specifications for products, services and systems, to ensure quality, safety and efficiency.

=ISO and OPM=

In June 2008, Richard Martin approached Dov Dori after his presentation at the INCOSE International Symposium in Utrecht, the Netherlands, to inquire about the possibility of creating an International Standard for OPM. 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.{{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 |access-date=18 November 2018}}

The OPM Study Group began its work in October 2010 and issued an interim report for the 2011 SC5 Plenary.{{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 |access-date=18 November 2018}} 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.{{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 |access-date=18 November 2018}} 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=

TC184/SC5/WG1 participants received the first draft of the OPM PAS in September 2011 with 16 pages, 2 annexes and a bibliography for a total of 25 pages.{{Citation needed|date=May 2017}} Most of the content simply identified sub-clause headings and space holder graphics.{{Citation needed|date=May 2017}} By the 2012 SC5 Plenary, the PAS draft included 10 full clauses describing OPM features and 6 annexes totaling 86 pages.{{Citation needed|date=May 2017}} One annex was an EBNF (Extended Backus-Naur Form, used to formally specify context free languages, enabling parsing of programming languages) specification for OPL and another detailed OPD graph grammar. To facilitate verification of the EBNF specification, David Shorter wrote a script to evaluate consistency and completeness of the EBNF statement set.{{Citation needed|date=May 2017}} Further effort to add meaningful examples and complete all of the identified sections resulted in a draft of 138 pages by the time of the 2013 SC5 Plenary.{{Citation needed|date=May 2017}} Subsequently, the working draft was registered with the SC5 Secretariat as a Committee Draft for initial circulation to SC5 members.{{Citation needed|date=May 2017}}

Because the SC5 resolution calling for the OPM specification indicated that the document was to be registered as a Publicly Available Specification (PAS), it would have only one acceptance ballot opportunity. In April 2014, the New Work Item Proposal and revised Committee Draft for ISO/PAS 19450 was delivered to SC5 for consideration.{{Citation needed|date=May 2017}} By now the Committee Draft was 98 pages plus front matter, four annexes and 30 bibliographic references, totaling 183 pages.{{Citation needed|date=May 2017}} In March 2015, ISO registered the result of balloting for ISO/PAS 19450 as 8 Approve, 1 Approve with comments, and 1 abstain.{{Citation needed|date=May 2017}}

ISO/PAS 19450 was formally published with a total of 162 pages by ISO on December 15, 2015, culminating a six-year effort to provide the standardization community with a formal specification for a new approach to modeling that binds together graphics and textual representations into a single paradigm suitable for automated simulation of model behavior.

OPM vs. SysML and UML

; OPM vs. SysML

SysML is defined as an extension of the Unified Modeling Language (UML) using UML's profile mechanism.

; 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.{{cite journal | last1 = Peleg | first1 = M. | last2 = Dori | first2 = D. | year = 2000 | title = The Model Multiplicity Problem: Experimenting with Real-Time Specification Methods | journal = IEEE Transactions on Software Engineering| volume = 26 | issue = 8| pages = 742–759 | doi=10.1109/32.879812| citeseerx = 10.1.1.321.5507 }} First, using the OPM approach enables to view at main diagram (SD) the main process, objects and the connection between them.{{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).{{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).

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:

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.

  1. 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).
  2. 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.
  3. 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 = ∞").{{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 }}

See also

References

{{reflist}}