Content deleted Content added
final removal |
Citation bot (talk | contribs) Altered journal. | Use this bot. Report bugs. | Suggested by Headbomb | Linked from Wikipedia:WikiProject_Academic_Journals/Journals_cited_by_Wikipedia/Sandbox | #UCB_webform_linked 934/990 |
||
| (29 intermediate revisions by 13 users not shown) | |||
Line 2:
{{Multiple issues|
{{More citations needed|date=April 2009}}
{{Overly detailed|date=February 2022}}
}}
[[File:OplNEW.jpg|thumb|320px|Graphical contents OPL: an example of the OPM language]]
{{InfoMaps}}
'''
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 17 ⟶ 16:
== Overview ==
Object
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
==History==
Line 43 ⟶ 42:
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,<ref name="Object-Process Methodology – A Holistic Systems Paradigm">{{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 }}</ref> and OPM has since been applied in many domains.<ref>{{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}}</ref><ref>{{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=
In August 2014, the ISO adopted OPM as ISO/PAS 19450.<ref name="ISO19450" />
Line 53 ⟶ 52:
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.<ref name="Model-Based"/>{{rp|2}}
OPM offers a way to model systems of almost any ___domain, be it artificial or natural.<ref name="Model-Based"/>{{rp|x}}<ref>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 model]]ing in the database field, or the Object-Process Methodology can be examined according to their ontological commitments. |archive-date=2016-03-28 |access-date=2017-05-04 |archive-url=https://web.archive.org/web/20160328133208/http://www.onto-med.de/publications/2006/herre-h-2006-a.pdf |url-status=dead }}</ref>
===Modeling===
OPM consists of
; Object
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 |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}}</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
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 74 ⟶ 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
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 165 ⟶ 164:
; 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.
# ''Basic transforming event links'': A consumption event link is a link between an object and a process, which an instance of the object activates.
#* 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.
# ''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.
Line 182 ⟶ 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 191 ⟶ 189:
# ''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.
# ''Condition agent link'': 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.
# ''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.
Line 214 ⟶ 212:
; Generalization-specialization and inheritance : These are structural relations which provide for abstracting any number of objects or process classes into superclasses, and assigning attributes of superclasses to subordinate classes.
# ''Generalization-specialization link''
# ''Inheritance through specialization''
# ''Specialization restriction through discriminating attribute'': A subset of the possible values of an inherited attribute may restrict the specialization.
; Classification-instantiation and system execution
# ''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
# ''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 ⟶ 251:
; 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
Line 281 ⟶ 279:
; OPD tree
; Clarity and completeness trade-off
Line 290 ⟶ 287:
; 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
Line 324 ⟶ 321:
; 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.
Line 346 ⟶ 343:
===ISO and OPM===
In June 2008, Richard Martin approached [[Dov Dori]] after his presentation at the [[International Council on Systems Engineering|INCOSE]] International Symposium in Utrecht, the Netherlands, to inquire about the possibility of creating an International Standard for OPM.
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.<ref>{{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}}</ref>
The OPM Study Group began its work in October 2010 and issued an interim report for the 2011 SC5 Plenary.<ref name=":0">{{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}}</ref> 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.<ref>{{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}}</ref> 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}}
Line 363 ⟶ 360:
== OPM vs. SysML and UML ==
; OPM vs. SysML
SysML is defined as an extension of the [[Unified Modeling Language]] (UML) using [[profile (UML)|UML's profile mechanism]].<ref name="SysMLvsOPM"/>
; 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.<ref>{{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 }}</ref> First, using the OPM approach enables to view at main diagram (SD) the main process, objects and the connection between them.<ref name="Object-Process Methodology – A Holistic Systems Paradigm"/>{{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).<ref name="Object-Process Methodology – A Holistic Systems Paradigm"/>{{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==
Line 374 ⟶ 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
* Action (in an
* State transition trigger (in a
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
# The second type of diagram is the
# The third type of diagram is
▲# 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 ==
| |||