オブジェクトプロセス方法論

オブジェクトプロセス方法論（OPM ）は、知識を捕捉しシステムを設計するための概念モデリング言語および方法論であり、ISO / PAS 19450として規定されています。 ^[1]状態のあるオブジェクトとそれらを変換するプロセスの最小限のユニバーサルオントロジーに基づいて、OPMは、さまざまなドメインにおける人工システムと自然システムの機能、構造、動作を正式に指定するために使用できます。

OPMはDov Doriによって考案され開発されました。OPMの基礎となるアイデアは1995年に初めて公開されました。^[2]それ以来、OPMは進化と発展を遂げてきました。

2002年にOPMに関する最初の書籍^[3]が出版され、2015年12月15日、ISO TC184/SC5による6年間の作業を経て、ISOはOPMをISO/PAS 19450として採用しました^[1]。OPMに関する2冊目の書籍は2016年に出版されました^[4]。

2019 年以来、OPM は EdX のモデルベース システム エンジニアリング(MBSE)のプロフェッショナル認定プログラムの基盤となっています。講義は YouTube の Web ビデオとしてご覧いただけます。

オブジェクト プロセス方法論 (OPM) は、知識を取り込み、システムを設計するための概念モデリング言語および方法論です。状態のあるオブジェクトとそれらを変換するプロセスの最小限のユニバーサルオントロジーに基づいて、OPM は、さまざまなドメインにおける人工システムと自然システムの機能、構造、および動作を正式に指定するために使用できます。人間の認知能力に対応するため、OPM モデルは、設計または研究中のシステムをグラフィックスとテキストの両方でバイモーダルに表現し、表現、理解、コミュニケーション、および学習を向上させます。

OPM では、オブジェクトとは存在するもの、または存在しないもののことです。オブジェクトは状態を持ちます。つまり、オブジェクトは状態を持つ場合があり、各時点でオブジェクトはいずれかの状態にあるか、状態間の遷移中にあります。プロセスとは、オブジェクトを作成または使用したり、状態を変更したりしてオブジェクトを変換するものです。

OPMはバイモーダルであり、視覚的/グラフィカルなオブジェクトプロセスダイアグラム（OPD）と、英語のサブセットで自動生成された一連の文章であるオブジェクトプロセス言語（OPL）の両方で表現されます。OPDとOPLを生成するための特許取得済みソフトウェアパッケージOPCATは無料で入手できます。^[5]

1980年代から1990年代にかけて、コンピュータプログラミング言語のオブジェクト指向（OO）パラダ​​イムへの移行が起こり、プログラミングの前にプログラム、さらに一般的にはプログラムが表現し提供するシステムのオブジェクト指向分析と設計を行うべきだという考え方が生まれました。そのため、1990年代初頭には、30を超えるオブジェクト指向分析と設計の方法と表記法が盛んになり、「方法論戦争」と呼ばれる戦争が起こりました。^[6]

—  Dov Dori、「序文」、OPM と SysML によるモデルベース システム エンジニアリング(2017)

その頃、1991 年にイスラエル工科大学のテクニオンに教員として加わったDov Dori氏は、2016 年に出版した著書「Model-Based Systems Engineering with OPM and SysML」の中で次のように述べています。

ソフトウェアに対する手続き型アプローチが不十分であるのと同様に、「純粋な」オブジェクト指向アプローチも不十分であることに気づきました。このアプローチでは、オブジェクトが唯一の「第一級」のオブジェクトとして位置付けられ、「メソッド」(または「サービス」) が第二級の従属手続きとなります。

—  Dov Dori、「序文」、OPM と SysML によるモデルベース システム エンジニアリング(2017)

ドリは1995年にOPMに関する最初の論文を発表しました。^[2]

1997 年、Object Management Group (OMG) によるUnified Modeling Language (UML) がソフトウェア設計の事実上の標準となりました。UML 1.1 は 1997 年 8 月に OMG に提出され、1997 年 11 月に OMG によって採用されました。

OPMに関する最初の書籍「オブジェクトプロセス方法論：全体論的システムパラダイム」は2002年に出版され^[3]、それ以来OPMは多くの分野で応用されてきました。^{[7] [8]}

2014年8月、ISOはOPMをISO/PAS 19450として採用した。^[1]

SysMLもカバーしたOPMに関する2冊目の本が2016年に出版されました。^[4]

オブジェクトプロセス方法論 (OPM) は、あらゆるシステムに固有の 2 つの側面、つまり構造と動作を統合するシステムモデリングパラダイムです。構造は、オブジェクトとそれらの間の構造関係 (集約と参加 (全体と部分の関係) や一般化と特殊化 ("is-a" 関係) など) によって表されます。動作は、プロセスと、プロセスがオブジェクトを変換する方法 (オブジェクトを作成または消費する方法、またはオブジェクトの状態を変更する方法) によって表されます。^{[4] : 2}

OPMは人工的なものであろうと自然のものであろうと、ほぼあらゆる領域のシステムをモデル化する方法を提供します。^{[4] : x  [9]}

OPMはオブジェクトプロセスダイアグラム（OPD）と、それに対応する英語のサブセットで書かれたオブジェクトプロセス言語（OPL）の文章から構成されています。OPLはOPMのモデリングをサポートするソフトウェアツールであるOPCAT ^[5]によって自動的に生成されます。^[10]

オブジェクトプロセスダイアグラム（OPD）

OPD は、OPM の唯一のダイアグラムです。このダイアグラムの種類の独自性は、OPM のシンプルさに大きく貢献しており、14 種類のダイアグラムがある UML や 9 種類のダイアグラムがある SysML とは対照的です。^[11] OPD は、オブジェクト、プロセス、およびそれらの間のリンクを図で表します。リンクは、構造的または手続き的になります。構造リンクは、オブジェクトをオブジェクトに、またはプロセスをプロセスに接続し、静的なシステムの側面、つまりシステムがどのように構造化されているかを表現します。手続きリンクは、オブジェクトをプロセスに接続し、動的なシステムの側面、つまりシステムが時間とともにどのように変化するかを表現します。システム全体は、階層的に編成された OPD のセットによって表されます。ルート OPD はシステム ダイアグラム (SD) と呼ばれ、システムの「鳥瞰図」を指定し、下位レベルの OPD は、詳細レベルを上げてシステムを指定します。システムの OPD セット内のすべての OPD は、お互いを「認識」しており、それぞれがシステムまたはその一部をある詳細レベルで表示します。システム全体は、すべての OPD に表示される詳細 (モデル ファクト) の結合によって全体的に指定されます。

オブジェクトプロセス言語 (OPL)

各 OPD 構成 (つまり、1 つ以上のリンクで接続された 2 つ以上のもの) は、自然な英語のサブセットである OPL の文に変換されます。OPL の強みは、人間が読めるだけでなく、コンピュータが解釈できるという点にあります。これらは、最も重要な設計上の決定が下される段階です。OPM のグラフィックスとテキストのバイモーダル性により、顧客またはそのドメイン専門家と、システム アーキテクト、モデラー、設計者の両方が関与するチームによる要件の共同モデリングに適しています。^{[4] : 3}

OPMモデルのアニメーションシミュレーション

OPM モデルは、システムの静的なグラフィックおよびテキスト表現であるだけでなく、実行可能です。OPCAT で構築された正しい OPM モデルは、アニメーション化してシミュレートすることができ、システムが時間の経過とともにどのように動作して、すべての詳細レベルで機能を達成するかを視覚的に表現します。正しくない OPM モデルは最後まで実行されず、どこでなぜ停止したかを示し、効果的にビジュアル デバッガーとして機能します。

Dori の著書『 Model-Based Systems Engineering with OPM and SysML』の序文で、Edward F. Crawley は次のように述べています。

OPMセマンティクスはもともとシステムエンジニアリング向けに設計されており、情報、ハードウェア、人、規制をモデル化できる。しかし近年ではOPMは分子生物学の研究者にも利用され始め、mRNAライフサイクルに関連する新しい研究結果が発表されている。これはオブジェクトとプロセスのオントロジーの普遍性を明確に示している。^{[4] : vi  [12]}

OPM には、言語と方法論という 2 つの主要な部分があります。言語はバイモーダルで、2 つの相補的な方法 (モダリティ) で表現されます。視覚的なグラフィカル部分 (1 つ以上のオブジェクト プロセス ダイアグラム (OPD) のセット) と、対応するテキスト部分 (英語のサブセットであるオブジェクト プロセス言語 (OPL) の文章のセット) です。

最上位レベルの OPD はシステム ダイアグラム (SD) であり、システムの機能のコンテキストを提供します。人工システムの場合、この機能は個人またはグループ (受益者) に利益をもたらすことが期待されます。機能は SD のメイン プロセスであり、このプロセスに関係するオブジェクト (受益者、オペランド (プロセスが実行されるオブジェクト)、およびプロセスによって値が変更される属性) も含まれます。

OPM グラフィカル要素は、閉じた図形として表現されるエンティティと、エンティティを接続するリンクとして表現されるリレーションに分けられます。

エンティティは OPM の構成要素です。エンティティには、総称して「モノ」と呼ばれるオブジェクトとプロセス、およびオブジェクトの状態が含まれます。

物体

オブジェクト間の関連は、モデル化されるシステムのオブジェクト構造を構成します。OPL テキストでは、オブジェクト名は太字で表示され、各単語は大文字で表記されます。

オブジェクトの状態

オブジェクトの状態とは、オブジェクトの存続期間中のある時点でのオブジェクトの特定の状況の分類です。どの時点においても、オブジェクトはいずれかの状態にあるか、または 2 つの状態の間 (入力状態から出力状態へ) に遷移しています。

プロセス

プロセスは、システム内のオブジェクトの変換パターンの表現です。プロセスは単独では存在せず、常に 1 つ以上のオブジェクトに関連付けられ、それらのオブジェクトに対して発生します。プロセスは、オブジェクトを作成、消費、または状態を変更することで、オブジェクトを変換します。したがって、プロセスは、システムの動的な動作の側面を提供することで、オブジェクトを補完します。OPL テキストでは、プロセス名は太字で表示され、各単語は大文字で表記されます。

構造リンク

構造リンクは構造関係を定義します。構造関係は、少なくとも一定の時間間隔でシステム内に存続する関連を指定します。

手続き上のリンク

手続き型リンクは手続き型関係を定義します。手続き型関係は、オブジェクトを変換するプロセスの時間依存または条件付きトリガーを指定して、システムがその機能を達成するためにどのように動作するかを指定します。

イベントと条件

イベント-条件-アクション パラダイムは、OPM の操作セマンティクスと制御フローを提供します。イベントとは、オブジェクトが作成される (またはシステムの観点から作成されたように見える) 時点、またはオブジェクトが指定された状態になる時点です。実行時に、このプロセス トリガーによって、プロセスの前提条件の評価が開始されます。したがって、プロセス実行を開始するには、(1) トリガー イベントと (2) 前提条件の満足という 2 つの前提条件があります。

イベントがプロセスをトリガーすると、イベントは存在しなくなります。

オブジェクトとプロセスは多くの点で対称的であり、集約、一般化、特性化などの関係の点で多くの共通点があります。

OPM を効果的に適用するには、モデル作成者は、システム分析と設計を成功させるための前提条件として、オブジェクトとプロセスの間の重要な区別を行う必要があります。デフォルトでは、名詞はオブジェクトを識別します。

OPM には 3 つの一般的な属性があります。

1. 忍耐力
2. エッセンス
3. 所属

OPM モノの汎用属性には次のデフォルト値があります。

1. モノのAffiliation汎用属性のデフォルト値はsystemic です。
2. システム本質は、システムの主要な本質です。物本質と同様に、その価値は情報的であり、物理的です。大部分の物が情報的である情報システムは主に情報的であり、大部分の物が物理的であるシステムは主に物理的です。
3. 主に情報的 [物理的] システム内のもののエッセンス汎用属性のデフォルト値は、情報的 [物理的] でなければなりません。

ステートフルオブジェクトとステートレスオブジェクト

Dov Dori は、OPM と SysML を使用したモデルベース システム エンジニアリングで、「オブジェクト状態とは、オブジェクトが存在する可能性がある状況です。オブジェクト状態は、それが属するオブジェクトのコンテキストでのみ意味を持ちます」と説明しています。状態のないオブジェクトとは、状態が指定されていないオブジェクトです。状態のあるオブジェクトとは、許容される状態のセットが指定されているオブジェクトです。ランタイム モデルでは、どの時点でも、状態のあるオブジェクト インスタンスは、特定の許容される状態にあるか、または 2 つの状態間の遷移状態にあります。

属性値

属性とは、物事を特徴付けるオブジェクトです。属性値は、値が属性の状態であるという意味で、状態の特殊化です。つまり、オブジェクトには属性があり、その属性は別のオブジェクトであり、その属性を示すオブジェクトが存在する間、その値はそのオブジェクトに割り当てられます。

オブジェクトの状態表現

状態は、所有オブジェクト内に配置された、ラベル付きの角丸の四角形によってグラフィカルに定義されます。オブジェクトがないと、状態は存在できません。OPL テキストでは、状態名は大文字にせず太字で表示されます。

初期状態、デフォルト状態、最終状態

初期状態、最終状態、デフォルト状態の表現

初期状態は、太い輪郭を持つ状態表現によってグラフィカルに定義されます。最終状態は、二重輪郭を持つ状態表現によってグラフィカルに定義されます。デフォルトの状態は、左から斜めに向いた開いた矢印を持つ状態表現によってグラフィカルに定義されます。対応する OPL 文には、初期状態、最終状態、またはデフォルト状態を示す明示的なインジケータを含める必要があります。

手続き型リンクは、次の 3 種類のいずれかです。

1. 変換リンクは、トランスフォーマー (プロセスが変換するオブジェクト) またはその状態をプロセスに接続し、オブジェクト変換、つまりプロセス実行の結果としてのそのオブジェクトの生成、消費、または状態変化をモデル化します。
2. 有効化リンクは、イネーブラー（プロセスの発生を可能にするが、そのプロセスによって変換されないオブジェクト）またはその状態をプロセスに接続し、そのプロセスの発生を可能にします。
3. 制御リンクは、制御修飾子 (文字 e (イベント) または c (条件)) が付いた手続き型 (変換または有効化) リンクで、制御要素のセマンティクスを追加します。文字 e はリンクされたプロセスをトリガーするイベントを示し、文字 c はリンクされたプロセスの実行条件、または呼び出しまたは例外を示す 2 つのプロセスの接続を示します。

手続き的リンクの一意性 OPM 原則

プロセスは、少なくとも 1 つのオブジェクトを変換する必要があります。したがって、プロセスは、変換リンクを介して少なくとも 1 つのオブジェクトまたはオブジェクト状態に接続されます。抽象化の特定の範囲では、オブジェクトまたはそのいずれかの状態は、リンク先のプロセスに関して、モデル要素として 1 つの役割だけを持ちます。つまり、オブジェクトは変換対象またはイネーブラーになります。さらに、イベントのトリガー (制御修飾子 e がある場合)、または条件付けオブジェクト (制御修飾子 c がある場合)、またはその両方になることができます。

州が定める手続き上のリンク

状態指定の手続き型リンクは、プロセスをオブジェクトに接続するのではなく、プロセスをそのオブジェクトの特定の状態に接続するという点で、対応する手続き型リンクの詳細バージョンです。

リンクの変換

変換リンクには次の 3 種類があります。

1. 消費リンク: グラフィカルに、消費対象から消費プロセスを指す閉じた矢印が消費リンクを定義します。想定により、消費されたオブジェクトはプロセスの実行が開始されるとすぐに消えます。消費リンク OPL 文の構文は、処理が消費対象を消費します。
2. 効果リンク: リンクされたプロセスがリンクされたオブジェクト (影響を受けるオブジェクト) に影響を与えることを指定する変換リンク。つまり、プロセスは影響を受けるオブジェクトの状態に何らかの不特定の変更を引き起こします。グラフィカルに、影響を与えるプロセスと影響を受けるオブジェクトの間で各方向を指す 2 つの閉じた矢印を持つ双方向矢印で効果リンクを定義します。効果リンク OPL 文の構文は、処理が影響を受けるオブジェクトに影響を与えるというものです。
3. 結果リンク: グラフィカルに、作成プロセスから結果先を指す閉じた矢印は、結果リンクを定義します。結果リンク OPL 文の構文は次のとおりです: 処理により結果先が生成されます。

リンクを有効にする

有効化リンクは、プロセスの有効化を指定する手続き型リンクです。有効化とは、プロセスが発生するために存在する必要があるオブジェクトですが、プロセスが完了した後のそのオブジェクトの存在と状態は、プロセスの開始直前と同じです。有効化リンクには次の 2 種類があります。

1. エージェントとエージェント リンク: インテリジェントな意思決定が可能な人間または人間のグループで、システムと対話してプロセスを有効にし、実行全体を通じてプロセスを有効化または制御します。グラフィカルに言えば、エージェント オブジェクトからそれが有効化するプロセスまで伸びる、終端に塗りつぶされた円 (「黒いロリポップ」) が付いた線がエージェント リンクを定義します。エージェント リンク OPL 文の構文は、エージェントが処理を処理します。
2. 機器および機器リンク: 機器が存在し、利用可能でなければ開始または実行できない、プロセスの無生物または意思決定を行わないイネーブラー。

州指定の変換リンク

1. 状態指定消費リンク: 消費対象の特定の状態から発生する消費リンク。つまり、リンク先のプロセスによって消費されるためには、消費対象はその状態にある必要があります。図的には、特定のオブジェクト状態からオブジェクトを消費するプロセスを指す閉じた矢印が、状態指定消費リンクを定義します。
2. 状態指定の結果リンク: 結果対象の特定の状態で終了する結果リンク。つまり、結果対象は、構築時にその結果の状態になります。図的には、プロセスから特定のオブジェクト状態を指す閉じた矢印が、状態指定の結果リンクを定義します。構文 OPL 文は、プロセスが修飾状態のオブジェクトを生成します。
3. 州指定の効果リンク:
   • 入力および出力効果リンク - 入力リンクはオブジェクトの入力状態から変換プロセスへのリンクであり、出力リンクは変換プロセスからオブジェクトの出力状態へのリンクです。
   • 入力-出力指定効果リンク: 効果リンクのペア。入力リンクは影響を受ける側の特定の状態から発生し、出力リンクはそのプロセスから発生し、同じ影響を受ける側の出力状態で終了します。グラフィカルに言うと、影響を受ける側の入力状態から影響を与えるプロセスへの閉じた矢印のペアと、そのプロセスからプロセス終了時の影響を受ける側の状態への同様の矢印は、入力-出力指定効果リンクを定義します。構文 OPL 文は、プロセスがオブジェクトを入力状態から出力状態に変更します。
   • 入力指定効果リンク: 効果リンクのペア。入力リンクは影響を受ける側の特定の状態から発生し、出力リンクはそのプロセスから発生し、特定の状態を指定せずに影響を受ける側で終了します。図式的には、影響を受ける側の特定の状態 (入力状態) からプロセスへの閉じた矢印の矢印と、そのプロセスから影響を受ける側への同様の矢印 (その状態のいずれにも該当しない) で構成される矢印のペアが、入力指定効果リンクを定義します。構文 OPL 文は、プロセスが入力状態からオブジェクトを変更します。
   • 出力指定効果リンク: 入力 (ソース) リンクが影響を受ける側から発生し、出力リンクがプロセスから発生して同じ影響を受ける側の出力 (宛先、結果) 状態で終了する効果リンクのペア。図で表すと、影響を受ける側から影響を受けるプロセスへの矢印のペア (影響を受ける側のいずれの状態からも矢印の先端が閉じていない矢印) と、影響を受けるプロセスから影響を受ける側の特定の状態 (出力状態) への同様の矢印のペアが、出力指定効果リンクを定義します。

州指定の有効化リンク

特定の適格状態から発生し、プロセスで終了します。つまり、リンクの発生元の状態にオブジェクトが存在する場合にのみ、プロセスが発生する可能性があります。

1. 状態指定エージェント リンク: グラフィカルに、エージェント オブジェクトの適格状態からそれが有効にするプロセスまで伸びる、終端に塗りつぶされた円 (「黒いロリポップ」) が付いた線は、状態指定エージェント リンクを定義します。構文 OPL 文は、適格状態エージェントが処理を処理します。
2. 状態指定のインストルメント リンク: インストルメントの特定の適格状態から発生するインストルメント リンク。グラフィカルに言うと、インストルメント オブジェクトの適格状態からそれが有効にするプロセスまで伸びる、終端に空の円 (「白いロリポップ」) がある線は、状態指定のインストルメント リンクを定義します。構文 OPL 文は、「処理には適格状態のインストルメントが必要です」です。

オブジェクトセットを前処理し、前提条件を処理する

OPM プロセスがトリガーされて実行を開始するには、1 つ以上の消費 (一部は特定の状態にある場合あり) および/または影響 (まとめて前処理オブジェクト セットと呼ばれる) で構成されるオブジェクトのセットが必要です。インスタンス レベルの実行では、プロセス P の前処理オブジェクト セット内の各消費 B は消費され、B を消費する P の最低レベルのサブプロセスの開始時に存在を停止します。プロセス P の前処理オブジェクト セット内の各影響 (状態が変化するオブジェクト) B は、P の最低レベルのサブプロセスの開始時に入力状態から終了します。

後処理オブジェクトセットと事後条件の処理

プロセスを実行し、その実行に関連する変換を実行することで、1 つ以上の結果 (一部は特定の状態にある場合あり) および/または影響 (まとめてポストプロセス オブジェクト セットと呼ばれる) から構成されるオブジェクトのセットが生成されます。プロセス P のポストプロセス オブジェクト セット内の結果の各 B は、B を生成する P の最低レベルのサブプロセスの終了時に作成され、存在し始めます。プロセス P のポストプロセス オブジェクト セット内の影響を受ける各 B は、P の最低レベルのサブプロセスの終了時に出力状態になります。

イベント リンクと条件リンクは、それぞれイベントと条件を表します。制御リンクは、オブジェクトとプロセスの間、または 2 つのプロセス間で発生します。

イベントリンク

プロセスをトリガーすると、プロセスの実行が開始されますが、この試行が成功することは保証されません。トリガー イベントは、プロセスの前提条件が満たされているかどうかの評価を強制します。この前提条件が満たされた場合のみ、プロセスの実行が続行され、プロセスがアクティブになります。前提条件が満たされているかどうかに関係なく、イベントは失われます。前提条件が満たされていない場合は、別のイベントによってプロセスがアクティブ化され、前提条件の評価が成功してプロセスの実行が可能になるまで、プロセスは実行されません。

1. 基本的な変換イベント リンク: 消費イベント リンクは、オブジェクトのインスタンスによってアクティブ化される、オブジェクトとプロセス間のリンクです。
   • 消費イベント リンク: グラフィカルには、閉じた矢印がオブジェクトからプロセスを指し、小文字の e (イベント) が付いています。消費イベント リンク OPL 文の構文は次のとおりです: オブジェクトがプロセスをトリガーし、プロセスがオブジェクトを消費します。
   • 効果イベント リンク: グラフィカルには、オブジェクトとプロセスの間に、両端に閉じた矢印が付いた双方向矢印と、小文字の e (イベント) が表示されます。効果イベント リンク OPL 文の構文は次のとおりです: オブジェクトがプロセスをトリガーし、プロセスがオブジェクトに影響します。

1. 基本的な有効化イベントリンク:
   • エージェント イベント リンク: エージェント イベント リンクは、エージェント オブジェクトから、それがアクティブ化して有効にするプロセスへの有効化リンクです。グラフィカルに表現すると、エージェント オブジェクトから、それがアクティブ化して有効にするプロセスまで伸びる、終端に塗りつぶされた円 (「黒いロリポップ」) と、小文字の e (イベント) が付いた線です。エージェント イベント リンク OPL 文の構文は、エージェントがプロセスをトリガーして処理します。
   • 計測器イベント リンク: グラフィカルに表現すると、計測器オブジェクトから、それがアクティブ化して有効にするプロセスまで伸びる、終端に空の円 (「白いロリポップ」) が付いた線で、小文字の e (イベント) が付いています。計測器イベント リンク OPL 文の構文は、次のとおりです。計測器はプロセスをトリガーし、そのプロセスには計測器が必要です。
2. 状態指定変換イベントリンク:
   • 状態指定消費イベント リンク: 状態指定消費イベント リンクは、オブジェクトの特定の状態から始まり、オブジェクトのインスタンスがアクティブ化するプロセスで終了する消費リンクです。図では、閉じた矢印がオブジェクトの状態からプロセスを指し、小文字の e (イベント) が付いています。状態指定消費イベント リンク OPL 文の構文は、指定された状態のオブジェクトがプロセスをトリガーし、プロセスがオブジェクトを消費するというものです。
   • 入力-出力指定効果イベント リンク: 入力-出力指定効果イベント リンクは、オブジェクトが指定された入力状態になったときに影響するプロセスをアクティブ化するという追加の意味を持つ入力-出力指定効果リンクです。グラフィカルに表すと、入力-出力指定効果リンクには小文字の e (イベント) が付いています。入力-出力指定効果イベント リンク OPL 文の構文は次のとおりです: 入力状態のオブジェクトがプロセスをトリガーし、オブジェクトが入力状態から出力状態に変更されます。
   • 入力指定効果イベント リンク: 入力指定効果イベント リンクは、オブジェクトが指定された入力状態になったときに影響するプロセスをアクティブ化するという追加の意味を持つ入力指定効果リンクです。グラフィカルに表すと、入力指定効果リンクには小文字の e (イベント) が付いています。入力指定効果イベント リンクの OPL 文の構文は次のとおりです: 入力状態のオブジェクトがプロセスをトリガーし、オブジェクトが入力状態から変更されます。
   • 出力指定効果イベントリンク: 出力指定効果イベントリンクは、オブジェクトが存在するようになったときに影響するプロセスをアクティブ化するという追加の意味を持つ出力指定効果リンクです。グラフィカルに言うと、出力指定効果リンクには小文字の e (イベント) が付いています。出力指定効果イベントリンク OPL 文の構文は次のとおりです。任意の状態のオブジェクトがプロセスをトリガーし、オブジェクトが宛先状態に変わります。
3. 状態指定エージェントイベントリンク:
   • 状態指定エージェント イベント リンク: 状態指定エージェント イベント リンクは、エージェントが指定された状態になったときにプロセスをアクティブ化するという追加の意味を持つ状態指定エージェント リンクです。グラフィカルに表現すると、状態指定エージェント リンクには小文字の e (イベント) が付いています。状態指定エージェント イベント リンク OPL 文の構文は、「Qualifying-state Agent triggers and handles Processing」です。
   • 状態指定の計器イベント リンク: 状態指定の計器イベント リンクは、計器が指定された状態になったときにプロセスをアクティブ化するという追加の意味を持つ状態指定の計器リンクです。グラフィカルに、小文字の e (イベント) が付いた状態指定の計器リンクです。状態指定の計器イベント リンク OPL 文の構文は、次のとおりです。"適格状態の計器が処理をトリガーします。処理には適格状態の計器が必要です。"

呼び出しリンク

1. プロセスの呼び出し
2. 自己呼び出しリンク
3. 暗黙的な呼び出しリンク: 暗黙的な呼び出しは、ズームされたプロセスのコンテキスト内でサブプロセスが終了したときに発生し、その時点でサブプロセスはすぐ下のサブプロセスを呼び出します。グラフィカルには、呼び出し元のサブプロセスと呼び出されるサブプロセスの間にリンクはありません。祖先プロセスのズームされたコンテキスト内での相対的な高さによって、このセマンティクスが暗示されます。

条件リンク

条件リンクは、バイパス メカニズムを提供するソース オブジェクトまたはオブジェクト状態と宛先プロセス間の手順リンクです。

1. 条件消費リンク: 条件消費リンクは、オブジェクトからプロセスへの条件リンクです。つまり、実行時にオブジェクト インスタンスが存在し、プロセスの前提条件が満たされている場合、プロセスが実行され、オブジェクト インスタンスが消費されます。図では、オブジェクトからプロセスを指す閉じた矢印の先端と、矢印の先端の近くにある小文字の c (条件) が条件消費リンクを表します。
2. 条件効果リンク: ただし、そのオブジェクト インスタンスが存在しない場合は、プロセスの前提条件の評価は失敗し、コントロールはプロセスをスキップします。グラフィカルには、影響を受けるオブジェクトと影響を与えるプロセスの間で各方向を指す 2 つの閉じた矢印が付いた双方向矢印で、矢印のプロセス端の近くに小文字の c (条件) があります。
3. 条件エージェント リンク: グラフィカルには、エージェント オブジェクトからそれが有効にするプロセスまで伸びる、終端に塗りつぶされた円 (「黒いロリポップ」) が付いた線で、プロセスの終端近くに小文字の c (条件) があります。条件エージェント リンク OPL 文の構文は次のとおりです:エージェントが存在する場合はエージェントがプロセスを処理し、それ以外の場合はプロセスはスキップされます。
4. 条件インストルメント リンク: グラフィカルに、インストルメント オブジェクトからそれが有効にするプロセスまで伸びる、終端に空の円 (「白いロリポップ」) が付いた線と、プロセスの終端近くに小文字の c (条件) が付いた線は、条件インストルメント リンクを表します。条件インストルメント リンク OPL 文の構文は、次のようになります: インストルメントが存在する場合はプロセスが実行され、存在しない場合はプロセスがスキップされます。
5. 条件状態指定消費リンク: 条件状態指定消費リンクは、オブジェクトの指定された状態から始まり、プロセスで終了する条件消費リンクです。つまり、指定された状態にオブジェクト インスタンスが存在し、プロセスの残りの前提条件が満たされている場合、プロセスが実行され、オブジェクト インスタンスが消費されます。図では、閉じた矢印がオブジェクト条件状態からプロセスを指し、矢印の近くに小文字の c (条件) が付いています。
6. 条件入力-出力指定効果リンク: 条件入力-出力指定効果リンクは、実行時にオブジェクト インスタンスが存在し、それがプロセス入力状態にある場合 (およびプロセスの残りの前提条件が満たされていると仮定)、プロセスが実行され、オブジェクト インスタンスに影響を与えるという追加の意味を持つ入力-出力指定効果リンクです。グラフィカルに表すと、条件入力-出力指定効果リンクには、入力の矢印の近くに小文字の c (条件) が表示されます。条件入力-出力指定効果リンク OPL 文の構文は次のとおりです。オブジェクトが入力状態の場合、プロセスが発生します。その場合、プロセスはオブジェクトを入力状態から出力状態に変更します。それ以外の場合は、プロセスはスキップされます。
7. 条件入力指定効果リンク: 条件入力指定効果リンクは、実行時にオブジェクト インスタンスが指定の入力状態に存在し、プロセスの前提条件の残りが満たされている場合、プロセスが実行され、オブジェクト インスタンスの状態が入力状態から未指定の状態に変更されることによってオブジェクト インスタンスに影響を与えるという追加の意味を持つ入力指定効果リンクです。ただし、そのオブジェクト インスタンスが入力状態に存在しない場合、プロセスの前提条件の評価は失敗し、コントロールはプロセスをスキップします。グラフィカルに、条件入力指定効果リンクには、入力リンクの矢印の近くに小文字の c (条件) が表示されます。条件入力指定効果リンク OPL 文の構文は次のとおりです。オブジェクトが入力状態の場合、プロセスが発生します。その場合、プロセスはオブジェクトを入力状態から変更します。それ以外の場合は、プロセスはスキップされます。
8. 条件出力指定効果リンク: 条件出力指定効果リンクは、実行時にオブジェクト インスタンスが存在し、プロセスの前提条件の残りが満たされている場合、プロセスが実行され、オブジェクト インスタンスの状態が指定された出力状態に変更されることによってオブジェクト インスタンスに影響を与えるという追加の意味を持つ出力指定効果リンクです。ただし、そのオブジェクト インスタンスが存在しない場合、プロセス前提条件の評価は失敗し、コントロールはプロセスをスキップします。グラフィカルに、条件出力指定効果リンクには、入力リンクの矢印の近くに小文字の c (条件) が表示されます。条件出力指定効果 OPL 文の構文は次のとおりです。オブジェクトが存在する場合にプロセスが発生し、その場合、プロセスはオブジェクトを出力状態に変更し、それ以外の場合はプロセスはスキップされます。
9. 条件状態指定エージェント リンク: 条件状態指定エージェント リンク OPL 文の構文は次のとおりです:エージェントが適格状態の場合、エージェントはプロセスを処理し、そうでない場合はプロセスはスキップされます。
10. 条件指定機器リンク

より詳しい情報と例は、『OPMとSysMLを使用したモデルベースシステムエンジニアリング』の第13章「動的システムの側面」に記載されています。 ^[4]

構造リンクは、システム内の静的で時間に依存しない長期的な関係を指定します。構造リンクは、展示特性リンクの場合を除き、2 つ以上のオブジェクトまたは 2 つ以上のプロセスを接続しますが、オブジェクトとプロセスを接続しません。

一方向タグ付き構造リンク

あるものから別のものへの関係の性質に関するユーザー定義のセマンティクスを持ちます。グラフィカルには、開いた矢印の先を持つ矢印です。タグ付けされた構造リンクに沿って、モデラーは、接続されたオブジェクト (またはプロセス) 間の構造関係の性質を表現し、構文が続く OPL 文に配置すると意味を成すテキスト フレーズの形式で意味のあるタグを記録する必要があります。

一方向のヌルタグ付き構造リンク

タグのない単方向のタグ付き構造リンク。この場合、デフォルトの単方向タグが使用されます。モデラーには、特定のシステムまたはシステムのセットに対してデフォルトの単方向タグを設定するオプションがあります。デフォルトが定義されていない場合、デフォルトのタグは「関連」になります。

双方向タグ付き構造リンク

両方向のタグが意味を持ち、互いの逆でない場合は、単一の双方向タグ付き構造リンクの両側に 2 つのタグで記録できます。結果として得られるタグ付き構造リンクの構文は、各方向に 1 つずつ、2 つの別々のタグ付き構造リンク OPL 文になります。図的には、リンクのライン両端の反対側に銛形の矢印が付いたラインになります。

相互タグ付き構造リンク

1 つのタグを持つ双方向のタグ付き構造リンク。どちらの場合も、相互性は双方向構造リンクのタグが前方と後方の方向で同じセマンティクスを持つことを示します。タグが表示されない場合、デフォルトのタグは「関連している」になります。タグが 1 つだけの相互タグ付き構造リンクの構文は、次のようになります: ソース物と宛先物は相互タグです。タグのない相互タグ付き構造リンクの構文は、次のようになります: ソース物と宛先物は関連しています。

基本的な構造関係

OPM の物事と間の最も一般的な構造関係は、システムの指定と理解にとって特に重要です。それぞれの基本的な関係は、1 つの OPM の物事 (ソースの物事、または精製対象) を 1 つ以上の OPM の物事 (デスティネーションの物事、または精製可能な物事) のコレクションに精緻化または精製することです。

集約参加リンク

精製対象（全体）は、1 つ以上の他の精製対象（部分）を集約します。図では、頂点が線で全体に接続され、部分が線で反対側の水平ベースに接続された黒の実線（塗りつぶされた）三角形が、集約と参加の関係リンクを示します。

展示と特徴のリンク

ある物が別の物を展示するか、別の物によって特徴付けられます。展示-特徴付け関係は、精緻化対象 (展示者) を 1 つ以上の精緻化可能対象に結び付け、精緻化可能対象は展示者を特徴付ける特徴を識別するものとします。図で表すと、大きな空の三角形の中に小さな黒い三角形があり、その大きな三角形の頂点が線で展示者に接続され、特徴が反対側 (水平) の底辺に接続されて、展示-特徴付け関係リンクが定義されます。

一般化-特殊化と継承

これらは、任意の数のオブジェクトまたはプロセス クラスをスーパークラスに抽象化し、スーパークラスの属性を従属クラスに割り当てることを可能にする構造的関係です。

1. 一般化と特殊化のリンク
2. 専門化による継承
3. 識別属性による特殊化の制限: 継承された属性の可能な値のサブセットによって、特殊化が制限される場合があります。

分類インスタンス化とシステム実行

1. 分類インスタンス化リンク: オブジェクト クラスまたはプロセス クラスであるソース シングは、ソース シングのパターンの値インスタンスである 1 つ以上の宛先シングに接続します。つまり、パターンによって指定された機能は明示的な値を取得します。この関係は、機能値の提供によって作成されたクラスとそのインスタンスの関係を表現するための明示的なメカニズムをモデラーに提供します。グラフィカルに、頂点が線でクラス シングに接続され、インスタンス シングが線で反対側の底辺に接続されている、それ以外は空の大きな三角形内の小さな黒い円が、分類インスタンス化関係リンクを定義します。構文は次のとおりです: インスタンス シングはクラス シングのインスタンスです。
2. オブジェクトクラスとプロセスクラスのインスタンス

州指定の構造関係とリンク

1. 状態指定の特性関係とリンク: 特殊オブジェクトからそのオブジェクトの識別属性の値を示す表示特性関係。つまり、特殊オブジェクトはその値のみを持つことになります。グラフィカルに、頂点が特殊オブジェクトに接続され、反対の底辺が値に接続された表示特性リンクの三角形のシンボルは、状態指定の特性関係を定義します。構文は、特殊オブジェクトが値名属性名を示します。
2. 状態指定のタグ付き構造関係およびリンク: オブジェクトの状態または属性値と別のオブジェクトまたはその状態または値との間の構造関係。つまり、これら 2 つのエンティティは、関連のセマンティクスを表すタグに関連付けられます。ヌル タグ (つまり、タグが指定されていない) の場合、対応するデフォルトのヌル タグが使用されます。状態指定のタグ付き構造関係には、(1) ソース状態指定のタグ付き構造関係、(2) 宛先状態指定のタグ付き構造関係、(3) ソースと宛先の状態指定のタグ付き構造関係の 3 つのグループがあります。これらの各グループには、適切な一方向、双方向、および相互のタグ付き構造関係が含まれており、7 種類の状態指定のタグ付き構造関係リンクと対応する OPL 文が生成されます。

より詳しい情報と例は、『OPMとSysMLを使用したモデルベースシステムエンジニアリング』の第3.3章「構造リンクの追加」に記載されています。 ^[4]

構造的および手続き的リンクにおけるオブジェクトの多重性

オブジェクトの多重度は、リンクに関連付けられたオブジェクト インスタンスの数または数に関する要件または制約の指定を指します。多重度の指定がない限り、リンクの各端は 1 つのインスタンスのみを指定します。多重度を持つオブジェクトを含む OPL 文の構文には、オブジェクト名の前にオブジェクトの多重度が含まれ、オブジェクト名は複数形で表示されます。多重度の指定は、次の場合に出現することがあります。

1. あらゆる種類のタグ付けされた構造リンクに対して複数のソースまたは宛先オブジェクト インスタンスを指定します。
2. 集約参加リンクで複数のインスタンスを持つ参加者オブジェクトを指定します。全体の各部分に異なる参加仕様を添付できます。
3. 手続き型関係で複数のインスタンスを持つオブジェクトを指定します。

オブジェクトの多重度表現と制約

オブジェクトの多重性には算術式が含まれる場合があり、算術式では通常の意味を持つ演算子記号「+」、「–」、「*」、「/」、「(」、および「)」を使用し、対応する OPL 文では通常のテキスト対応を使用する必要があります。

整数または算術式は、オブジェクトの多重度を制約する場合があります。図式的には、式の制約は、制約する式と区切るセミコロンの後に表示され、等号/不等号記号「=」、「<」、「>」、「<=」、「>=」、セット メンバーを囲む中括弧「{」および「}」、およびメンバーシップ演算子「in」(要素、∈) が通常のセマンティクスで使用されます。対応する OPL 文では、制約が適用されるオブジェクトの後に、制約句を太字で「, where 制約」の形式で配置します。

属性値と多重度制約

構造リンクおよび手続きリンクのオブジェクト多重度の式は、整数値または整数値に解決されるパラメータ シンボルを指定します。対照的に、オブジェクトまたはプロセスの属性に関連付けられた値は、整数値または実数値、または整数値または実数値に解決されるパラメータ シンボル、および文字列と列挙値です。グラフィカルに、属する属性内に配置されたラベル付きの角丸四角形は、ラベル名に対応する値または値の範囲 (整数、実数、または文字列) を持つ属性値を示します。OPL テキストでは、属性値は大文字にせず太字で表示されます。

属性値を持つオブジェクトの OPL 文の構文は次のようになります:オブジェクトの属性は値です。

属性値範囲を持つオブジェクトの OPL 文の構文は、次のようになります:オブジェクト範囲の属性は値範囲です。実数値を持つ属性に接続する構造リンクまたは手続きリンクは、オブジェクトの多重度とは異なる関係制約を指定できます。

グラフィカルに言えば、属性値制約は、リンクの属性の端の近くにあり、リンクと揃った数値、整数、実数、またはシンボル パラメータによる注釈です。

論理的かつ手続き的なリンク

手続き関係における論理演算子 AND、XOR、および OR を使用すると、複雑なプロセスの前提条件と事後条件を指定できます。個別の非接触リンクは、論理 AND のセマンティクスを持ちます。ここでは、金庫のロックを解除するには、3 つのキーすべてが必要です。

論理XORとOR手続きリンク

リンク ファンは、XOR または OR 演算子のセマンティクスに従う必要があります。リンクに共通するリンク ファン エンドは、収束リンク エンドになります。リンクに共通しないリンク エンドは、発散リンク エンドになります。

XOR 演算子は、分岐リンク端にオブジェクトがある場合、リンク ファンの範囲内の 1 つのものだけが存在すること、または分岐リンク端にプロセスがある場合、その 1 つだけが発生することを意味します。グラフィカルに、リンク ファン内のリンクを横切る破線の円弧と、収束端の接点に円弧の焦点がある図は、XOR 演算子を表します。

OR 演算子は、分岐リンク端にオブジェクトがある場合、リンク ファンの範囲内の 2 つ以上の事柄のうち少なくとも 1 つが存在すること、または分岐端にプロセスがある場合、発生することを意味します。グラフィカルに、リンクを横切る 2 つの同心円の破線弧で、焦点が収束端の接点にあるものが OR 演算子を表します。

状態指定のXORおよびORリンクファン

制御改造リンクファン

リンク確率と確率的リンクファン

実行パスとパスラベル

パス ラベルは、プロセス終了時に従うオプションが複数ある場合に、従うリンクがプロセスに入ったリンクと同じラベルを持つリンクになることを規定する、手順リンクに沿ったラベルです。

境界、利害関係者、前提条件の観点から見たシステムの目的、範囲、機能の定義は、モデルに他の要素を含めるかどうかを決定する基礎となります。これにより、システムモデルの範囲が決まります。OPMは、モデルの明確さと完全性の表現を管理するための抽象化と洗練のメカニズムを提供します。^{[1] [4]}

利害関係者とシステムの受益者の特定

人間が作成したシステムの場合、この機能は個人またはグループ、つまり受益者に利益をもたらすことが期待されます。システムの機能が主な受益者の機能的価値期待と一致した後、モデラーは他の主要な利害関係者を特定し、OPM モデルに追加します。

システム図

結果として得られるトップレベルの OPD はシステム ダイアグラム (SD) であり、これには利害関係者グループ、特に受益者グループと、システムの運用のコンテキストを提供する追加のトップレベルの環境要素が含まれます。SD には、システムの機能とコンテキストを理解するために不可欠な中心的で重要な要素のみを含める必要があります。機能は SD のメイン プロセスであり、このプロセスに関係するオブジェクト (受益者、オペランド (プロセスが動作するオブジェクト)、およびプロセスによって値が変更されるオペランドの属性) も含まれます。SD には、機能を有効にするシステムを表すオブジェクトも含める必要があります。このシステムの既定の名前は、機能の名前に「System」という単語を追加して作成されます。たとえば、機能が Car Painting である場合、システムの名前は Car Painting System になります。

OPD ツリー

明確さと完全性のトレードオフ

適切なバランスを確立するには、モデル開発中にコンテキストを注意深く管理する必要があります。ただし、モデラーは、OPM システム モデルの OPD セット全体によって提供される情報の統合を利用して、明確で曖昧さはないが完全ではない OPD を 1 つ作成し、詳細を追加することでシステムの一部の完全性に重点を置いた OPD を作成することができます。

洗練と抽象化のメカニズム

OPM は、モデルの明確さと完全性の表現を管理するための抽象化および洗練化メカニズムを提供します。これらのメカニズムにより、システムとそれを構成するものを、オブジェクト、プロセス、およびそれらに共通する関係によって相互に関連付けられたさまざまなコンテキストで提示および表示できるようになります。

国家の表現と国家の抑制

状態抑制の逆は状態表現、つまり、可能なオブジェクト状態に関する情報を追加して OPD を改良することです。OPD に対応する OPL は、描画されるオブジェクトの状態のみを表現します。

展開と折りたたみ

展開されたものより階層的に下にあるものの集合を明らかにします。その結果、展開されたものがルートとなる階層ツリーが作成されます。ルートにリンクされているのは、展開されたもののコンテキストを構成するものです。逆に、折りたたみは抽象化または構成のメカニズムであり、展開された階層ツリーに適用されます。

インズームとアウトズーム

インズームは一種の展開であり、集約参加にのみ適用され、追加のセマンティクスを持ちます。プロセスの場合、インズームにより、サブプロセス、サブプロセスの時間的順序、オブジェクトとの相互作用、およびこのコンテキストへの制御の受け渡しをモデル化できます。オブジェクトの場合、インズームにより、構成オブジェクトの空間的または論理的順序をモデル化できる明確なコンテキストが作成されます。グラフィカルに見ると、インズームされたプロセスのコンテキスト内のタイムラインは、そのプロセスの楕円記号の上部から楕円の下部に流れます。

OPMモデル構造

OPD 構造と基本構造のモデル

OPD メタモデルの画像に示されているモデルは、OPD 構成概念を詳しく説明しています。このモデルの目的は、基本構成を他の OPD 構成と区別することです。基本構成は OPD 構成の特殊化であり、1 つのリンクで接続された 2 つのものから構成されます。非基本構成には、リンク ファンや 2 つ以上のリファイニーを持つものなどがあります。

モデラーは、モノ セットの切断状態と接続状態を追加することで、モデルにプロセスを追加できます。したがって、モデルの目的には、リンク セットを接続の手段として使用して、切断されたモノ セットを接続されたモノ セットに変換するアクションが含まれます。

モノのOPMモデル

OPM モノのモデルは、以下のモノのモデルの図に示すように、オブジェクトとプロセスへの特殊化を示す OPM モノのモデルです。一連の状態がオブジェクトを特徴付けます。状態のないオブジェクトの場合は空になる可能性があり、状態のあるオブジェクトの場合は空ではない可能性があります。

状態を持つ状態フル オブジェクトは、状態ごとに 1 つずつ、状態のない状態固有オブジェクトのセットを生成します。特定の状態固有オブジェクトは、特定の状態にあるオブジェクトを参照します。状態固有オブジェクトの概念をオブジェクトと状態の両方としてモデル化すると、オブジェクトを指定するだけでオブジェクトとその状態のいずれかを参照できるため、概念モデルを簡素化できます。

モノの汎用プロパティのOPMモデル

モノの一般的なプロパティの OPM モデルは、モノとその永続性、本質、所属の一般的なプロパティを、展示と特性のリンクの属性の詳細としてモデル化して表します。永続性は、オブジェクトとプロセスを区別する属性です。

インズームとアウトズームのモデル

新しいダイアグラム イン ズームと新しいダイアグラム アウト ズームはどちらも、既存の OPD コンテキストから新しい OPD コンテキストを作成します。新しいダイアグラム イン ズームは、比較的詳細度の低い OPD から開始し、詳細度の低い OPD 内の特定のものに適用される子孫 OPD として詳細化または改良を追加します。

オプティマム

OPMの現在のバージョンは、オートメーションシステムと統合 - オブジェクトプロセス方法論で指定されているISO/PAS 19450:2015です。^[1] Doriの2016年の本の仕様は、ISO/PAS 19450:2015のスーパーセットです。^[4]

OPMの以前のバージョンは、Doriの2002年の本で指定されていました。^[3]

OPCAT

現在のOPCATバージョンは4.1です。テクニオンのエンタープライズシステムモデリング研究所から無料で入手できます。^[5]

機能が少ない以前の OPCAT バージョン 3.1 も同じサイトから入手できます。どちらも Java でコーディングされています。最初の OPCAT バージョンである OPCAT 1.X は、1998 年に Visual C++ で作成されました。

2016年の初めに、ドリの管理下にある学生チームが、OPCloudと呼ばれる新世代のOPCATの開発に着手しました。^[13]ソフトウェアの名前が示すように、これはクラウドベースのアプリケーションであり、ユーザーはWebベースのアプリケーションを使用してOPMモデルを作成できるようになります。^[14]

ISO（国際標準化機構）は、162 の国家標準化団体が加盟する独立した非政府国際組織であり、革新をサポートし、世界的な課題に対するソリューションを提供する、自主的で合意に基づいた市場関連の国際規格を開発しています。これらの規格は、製品、サービス、システムに関する世界クラスの仕様を提供し、品質、安全性、効率性を保証します。

2008 年 6 月、リチャード マーティンはオランダのユトレヒトで開催されたINCOSE国際シンポジウムでの発表後にドヴ ドリに連絡を取り、OPM の国際標準を作成する可能性について問い合わせました。 ^[15]オートメーション システムの相互運用性アーキテクチャとモデリングに関する ISO TC184/SC5/WG1 の議長であるマーティンは、静的な情報とプロセスのモデリング以上のものを提供する方法論を長い間探していました。^{[引用が必要]}彼は、OPM のモデリング機能と動的シミュレーションの可能性の両方を実証できる簡単なモデル例をドリに提供しました。^{[引用が必要]}

2010年5月、DoriはISO技術委員会184/小委員会5（TC184/SC5）の総会でOPMと彼のデモンストレーションモデルの概要を発表し、総会ではOPMがSC5によって作成された標準を強化する可能性を検討する目的でOPM研究グループを設立する決議が採択されました。^[16]

OPM研究グループは2010年10月に作業を開始し、2011年のSC5総会に向けて中間報告書を発表しました。^[15]この報告書には、既存のSC5標準をモデル化するためのOPMの使用法がいくつか含まれており、テキストベースであるISO標準は矛盾や不完全な情報に悩まされやすいという認識から、OPMの標準化に向けた最初の動機が生まれました。標準がテキストベースではなくモデルベースであれば、この欠陥は大幅に軽減される可能性があり、OPMはこの目的に役立つ基礎的なモデリングパラダイムを提供しました。

最終的なOPM研究グループ報告書とモデルベース標準オーサリング文書のメタモデルの草案は、2012年のSC5総会で提出されました。^[17] OPM研究グループの取り組みが進むにつれて、OPMはモデルベースシステムエンジニアリング（MBSE）や自然システムと人工システムの両方のモデリングのための強固で包括的な基盤としても機能できることが明らかになりました。^{[引用が必要]}

TC184/SC5/WG1 参加者は、2011 年 9 月に 16 ページ、2 つの付録、および参考文献の合計 25 ページの OPM PAS の最初のドラフトを受け取りました。^{[引用が必要]}コンテンツのほとんどは、サブ条項の見出しとスペース ホルダーのグラフィックを特定するだけのものでした。^{[引用が必要]} 2012 年の SC5 総会までに、PAS ドラフトには OPM の機能を説明する 10 の完全な条項と 6 つの付録が含まれ、合計 86 ページになりました。^{[引用が必要]付録}の 1 つは、OPL の EBNF (拡張 Backus-Naur 形式。文脈自由言語を正式に指定し、プログラミング言語の解析を可能にするために使用される) 仕様と、別の詳細な OPD グラフ文法でした。EBNF 仕様の検証を容易にするために、David Shorter は EBNF ステートメント セットの一貫性と完全性を評価するスクリプトを作成しました。^{[引用が必要]意味}のある例を追加し、特定されたセクションをすべて完了するためのさらなる努力の結果、2013 年の SC5 総会までに 138 ページの草案が完成しました。^{[引用が必要]}その後、作業草案は SC5 事務局に委員会草案として登録され、SC5 メンバーに最初に配布されました。^{[引用が必要]}

OPM 仕様を求める SC5 の決議では、文書は公開仕様(PAS) として登録されることが示されていたため、承認投票の機会は 1 回のみでした。2014 年 4 月、ISO/PAS 19450 の新規作業項目提案と改訂された委員会草案が検討のために SC5 に提出されました。^{[引用が必要]}この時点で、委員会草案は 98 ページ、前書き、4 つの付録、30 の参考文献で、合計 183 ページでした。^{[引用が必要]} 2015 年 3 月、ISO は ISO/PAS 19450 の投票結果を、承認 8 件、コメント付き承認 1 件、棄権 1 件として登録しました。^{[引用が必要]}

ISO/PAS 19450 は、合計 162 ページで ISO により 2015 年 12 月 15 日に正式に発行されました。これは、グラフィックスとテキスト表現を、モデル動作の自動シミュレーションに適した単一のパラダイムに結合する新しいモデリング手法の正式な仕様を標準化コミュニティに提供するための 6 年間の取り組みの集大成です。

OPM と SysML

SysMLは、 UMLのプロファイルメカニズムを使用した統一モデリング言語（UML）の拡張として定義されています。^[11]

OPM と UML

OPM と UML の違いは、分析および設計の段階で非常に顕著です。UML はマルチモデルですが、OPM は単一の統一された構造-動作モデルをサポートします。決定的な違いは、動作が 13 種類のダイアグラムに分散している UML の構造指向アプローチに起因しており、この事実は必然的にモデルの多重性の問題を引き起こします。^[18]まず、OPM アプローチを使用すると、メイン ダイアグラム (SD) でメイン プロセス、オブジェクト、およびそれらの接続を表示できます。^{[3] [ページが必要]}さらに、メイン システムの利点 (SD で提示) が何であるかを簡単に理解できます。OPM では、動作、構造、機能というシステムの主な 3 つの側面も簡単に理解できます (これらの側面を異なる種類のダイアグラムで記述する UML とは対照的)。^{[3] [ページが必要]}データベース展開モデリングは、システムとシステムに格納されているすべての詳細の理解に役立ちます。さらに、インズームを作成することでモデルを簡素化できます。 OPM には、システムがどのようにパスを保存し、決定を下すかなどの体系的なプロセスに関する広範な知識が必要です。

どちらの言語も汎用システム エンジニアリングの手段を提供するという同じ目的を目指していますが、この目標を実現するためのアプローチは異なります。SysML は、UML (Unified Modeling Language) のプロファイルです。

OPM から SysML への変換は、1 つの OPM 要素 (エンティティまたはリンク) が通常、異なる SysML ダイアグラム タイプに属する複数の SysML 要素に変換されるという意味で、1 対多です。たとえば、オブジェクトを変換 (生成、消費、または状態の変更) するエンティティとして定義される OPM プロセスは、次の SysML エンティティの任意のサブセットにマップできます。

• ユースケース（ユースケース図）
• アクション（アクティビティ図内）
• 状態遷移トリガー (ステート マシン図内)。

OPM と SysML は 2 つの異なる言語であり、設計も異なるため、一方の言語のすべての構成要素がもう一方の言語で同等の構成要素を持つわけではありません。

1. OPM 図から生成できる UML の最初のタイプの図は、システムの使用法をモデル化するためのユース ケース図です。ユース ケース図を構成する主な要素は、アクターとユース ケース (エンティティ) およびそれらの関係 (リンク) です。したがって、OPM からのユース ケース図の生成は、環境オブジェクト (アクター) とそれらにリンクされたプロセス (ユース ケース) に基づいています。図 1 は、SD0 のユース ケース図生成の例です。この図は、ルート OPM 図 (a)、対応する OPL テキスト (b)、および作成されたユース ケース図 (c) を示しています。図 2 は、同じ OPM モデルからの OPD の SD1 レベル (a) と、生成されたユース ケース図 (b) を示しています。
2. 2 番目のタイプの図は、ブロック定義図 (BDD) です。これは、ブロックの機能 (プロパティや操作など) と、関連や一般化などのブロック間の関係を定義します。BDD の生成は、OPM モデルの体系的なオブジェクトとそれらの関係 (主に他のモデル要素との構造的関係) に基づいています。
3. 3 つ目のタイプのダイアグラムは、フローを指定するためのアクティビティ ダイアグラムです。アクティビティ ダイアグラムに含まれる主要なコンポーネントは、アクションとルーティング フロー要素です。このコンテキストでは、子サブプロセスを含む OPM プロセス (つまり、OPM モデルで拡大表示されるプロセス) ごとに個別のアクティビティ ダイアグラムを生成できます。設定ダイアログで指定できるユーザー パラメーターは 2 種類あります。最初のパラメーターは、OPM プロセスの選択に関するものです。1 つのオプションは、必要な OPM プロセスをリストから選択して明示的に指定することです。もう 1 つのオプション (デフォルト オプション) は、ルート OPD (SD) から始めて階層を下っていくことです。ここで、2 番目のパラメーター (最初のパラメーターとは独立) に到達します。これは、階層を下っていくために必要な OPD レベル数 (k) です。抽象化のレベルをユーザーが制御できるように、ダイアグラムは階層の k レベルまで生成されます。各レベルで、追加のアクティビティ ダイアグラムが生成されます。これは、囲んでいる上位レベルのアクティビティに含まれる子アクティビティ (サブダイアグラム) です。このオプションのデフォルト設定は「すべてのレベルダウン」（つまり「k = ∞」）です。^[19]

• 形式オントロジー
• プロセスオントロジー
• オントロジー言語
• 上位オントロジー

• オブジェクトプロセス方法論とビジュアルセマンティック Web へのその応用、Dov Dori によるプレゼンテーション、2003 年。
• ナヴィヤ・ニヤーヤの専門用語の特徴
• エンジニアと科学者に役立つ概念モデリングの思考プロセスを形式化する、Dov Dori によるプレゼンテーション、2015 年。
• エンジニアと科学者に利益をもたらす概念モデリングの思考プロセスを形式化する
• OPD とテキスト形式間の変換に関する米国特許 US7099809B2