概要 オブジェクトプロセス手法(OPM)は、知識の獲得とシステム設計のための概念モデリング言語および手法です。状態を持つ オブジェクト と、それらを変換するプロセス からなる最小限の普遍的オントロジー に基づき、OPMは、多様な領域における人工システムおよび自然システムの機能、構造、動作を形式的に記述するために使用できます。人間の認知能力に対応するため、OPMモデルは、設計または研究対象のシステムをグラフィックとテキストの両方で二面的に表現し、表現、理解、コミュニケーション、学習を向上させます。
OPMにおいて、オブジェクトとは 存在するか否かを問わず、あらゆるものを指します。オブジェクトは状態を 持ち、各時点において、いずれかの状態にあるか、状態遷移中である可能性があります。プロセス とは、オブジェクトを作成または消費したり、その状態を変更したりすることによって、オブジェクトを変換するものです。
OPMはバイモーダルであり、オブジェクトプロセス図(OPD)で視覚的/グラフィカルに表現されるとともに、英語のサブセットで自動生成された一連の文であるオブジェクトプロセス言語(OPL)で言語的/テキスト的に表現されます。OPDとOPLを生成するためのOPCATと呼ばれる特許取得済みのソフトウェアパッケージは無料で利用できます。[ 5 ]
歴史 1980年代から1990年代にかけてコンピュータプログラミング言語の オブジェクト指向 (OO)パラダイムへの移行が起こり、プログラミングの前に、プログラム、そしてより一般的には、それらのプログラムが表現し、サービスを提供するシステムのオブジェクト指向分析と設計を 行うべきだという考え方が生まれました。そのため、1990年代初頭には30を超えるオブジェクト指向分析と設計の手法と表記法が盛んになり、「手法戦争」として知られる事態に発展しました。[ 6 ]
—ドヴ・ドリ 、「序文」、モデルベースシステムエンジニアリング(OPMとSysML使用 )(2017年)
その頃、1991年にテクニオン・イスラエル工科大学の 教員となったドブ・ドリは 、 2016年の著書『モデルベースシステムエンジニアリング:OPMとSysML』 の中で次のように述べている。
ソフトウェアに対する手続き型アプローチが不十分であるのと同様に、オブジェクトを唯一の「第一級」要素とし、「メソッド」(または「サービス」)を第二級の従属的な手続きとする「純粋な」オブジェクト指向アプローチも不十分であることに気づいた。
—ドヴ・ドリ 、「序文」、モデルベースシステムエンジニアリング(OPMとSysML使用 )(2017年)
ドリは1995年にOPMに関する最初の論文を発表した。[ 2 ]
1997年、オブジェクト管理グループ(OMG)による 統一モデリング言語 (UML)が、ソフトウェア設計の事実上の標準となった。UML 1.1は1997年8月にOMGに提出され、同年11月にOMGによって採択された。
OPMに関する最初の書籍である『Object-Process Methodology: a Holistic Systems Paradigm 』は2002年に出版され[ 3 ] 、それ以来OPMは多くの分野で応用されている[ 7 ] [ 8 ] 。
2014年8月、ISOはOPMをISO/PAS 19450として採用した。[ 1 ]
OPMに関する2冊目の書籍(SysMLも扱っている)は2016年に出版された。[ 4 ]
デザイン OPM手法の段階 オブジェクト・プロセス手法(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モデルは最後まで実行されず、どこで、なぜ停止したかを示すため、視覚的なデバッガーとして機能します。
発達 ドリーの著書『 OPMとSysMLを用いたモデルベースシステムエンジニアリング』 の序文で、エドワード・F・クローリーは 次のように述べている。
OPMセマンティクスは、情報、ハードウェア、人、規制をモデル化できるため、元々はシステムエンジニアリング向けでした。しかし、近年では、OPMは分子生物学の研究者にも利用されるようになり、mRNAライフサイクルに関連する新しい研究結果が発表されています。これは、オブジェクトとプロセスのオントロジーの普遍性を明確に示しています。[ 4 ] : vi [ 12 ]
基本 OPMエンティティ:オブジェクト、オブジェクト状態、およびプロセス OPMは、言語と方法論という2つの主要な部分から構成されています。言語はバイモーダルであり、2つの相補的な方法(様式)で表現されます。1つは視覚的、図解的な部分で、1つ以上のオブジェクトプロセス図(OPD)のセットです。もう1つは対応するテキスト部分で、英語のサブセットであるオブジェクトプロセス言語(OPL)で書かれた一連の文です。
最上位のOPDはシステム図(SD)であり、システムの機能に関するコンテキストを提供します。人工システムの場合、この機能は個人またはグループ(受益者)に利益をもたらすことが期待されます。機能はSDにおける主要なプロセスであり、このプロセスに関与するオブジェクト、すなわち受益者、オペランド(プロセスが操作するオブジェクト)、そして場合によってはプロセスによって値が変化する属性も含まれます。
OPMのグラフィック要素は、閉じた図形として表現されるエンティティと、エンティティを接続するリンクとして表現される関係に分けられます。
エンティティ エンティティはOPMの構成要素です。エンティティには、オブジェクトとプロセス(総称して「もの」と呼ばれる)およびオブジェクトの状態が含まれます。
物体 オブジェクト間の関連性は、モデル化対象システムのオブジェクト構造を構成する。OPLテキストでは、オブジェクト名は太字で表記し、各単語の頭文字を大文字にする。 オブジェクトの状態 オブジェクトの状態とは、オブジェクトのライフサイクルのある時点における、特定の状況分類のことです。オブジェクトは常に、いずれかの状態にあるか、入力状態から出力状態へと、2つの状態の間を遷移している状態にあります。 プロセス プロセスとは、システム内のオブジェクトの変換パターンを表すものです。プロセスは単独で存在するのではなく、常に1つ以上のオブジェクトと関連付けられ、それらのオブジェクトに対して発生します。プロセスは、オブジェクトを作成、消費、または状態を変更することによってオブジェクトを変換します。このように、プロセスはシステムの動的かつ動作的な側面を提供することで、オブジェクトを補完します。OPLテキストでは、プロセス名は太字で表記され、各単語は大文字で始まります。
リンク OPM構造リンク OPMの手続き関連リンク 構造的リンク 構造リンクは構造関係を定義する。構造関係は、システム内で少なくとも一定期間存続する関連性を指定する。 手続き上のリンク 手続きリンクは手続き関係を定義します。手続き関係は、オブジェクトを変換するプロセスの時間依存または条件付きトリガーを指定することにより、システムがその機能を達成するためにどのように動作するかを規定します。 イベントと状況 イベント-条件-アクションのパラダイムは、OPMの操作的意味論 と制御フローを提供します。イベントとは、オブジェクトが作成される(またはシステムの観点から作成されたように見える)時点、あるいはオブジェクトが特定の状態に入る時点のことです。実行時には、このプロセストリガーによってプロセスの前提条件の評価が開始されます。したがって、プロセス実行を開始するには、(1)トリガーとなるイベントと、(2)前提条件の充足という2つの前提条件があります。 イベントが何らかのプロセスをトリガーすると、そのイベントは消滅する。
構文と意味論
もの オブジェクトとプロセスは多くの点で対称的であり、集約、一般化、特性化といった関係性において多くの共通点を持っている。
OPMを効果的に適用するには、モデラーはオブジェクトとプロセスの本質的な区別を明確にする必要があります。これは、システム分析と設計を成功させるための前提条件です。デフォルトでは、名詞はオブジェクトを識別するものとみなされます。
物の一般的な属性 OPMのアイテムには、3つの一般的な属性があります。
忍耐力 エッセンス 所属 OPMの汎用属性には、以下のデフォルト値が設定されています。
オブジェクト の汎用属性「所属」のデフォルト値は「systemic」です。システムの本質は、システムの主要な本質である。物の本質と同様に、その価値は情報的かつ物理的である。情報システムにおいて、大部分の物が情報的なものである場合は、その本質は主に情報的なものとなり、大部分の物が物理的なものである場合は、その本質は主に物理的なものとなる。 主に情報的な[物理的]システムにおけるもののEssence 汎用属性のデフォルト値は、情報的な[物理的]とする。
オブジェクトの状態 OPMの物とオブジェクトの状態 ステートフルオブジェクトとステートレスオブジェクト Dov Dori は著書『Model-Based Systems Engineering with OPM and SysML』 の中で、「オブジェクトの状態とは、オブジェクトが存在しうる状況のことである。オブジェクトの状態は、それが属するオブジェクトのコンテキストにおいてのみ意味を持つ」と説明している。ステートレスオブジェクトとは、状態の指定がないオブジェクトのことである。ステートフルオブジェクトとは、許容される一連の状態が指定されているオブジェクトのことである。ランタイムモデルでは、任意の時点において、ステートフルオブジェクトのインスタンスは、特定の許容状態にあるか、2 つの状態の間を遷移している状態にある。 属性値 属性とは、物事を特徴づけるオブジェクトのことです。属性値とは、状態の一種であり、値が属性の状態であるという意味です。つまり、あるオブジェクトは属性(別のオブジェクト)を持ち、その属性を持つオブジェクトが存在する期間、その属性に値が割り当てられます。 オブジェクトの状態表現 状態は、所有オブジェクトの内側に配置された、ラベル付きの角丸長方形によってグラフィカルに定義されます。オブジェクトなしでは存在できません。OPLテキストでは、状態名は太字で表記され、大文字は使用されません。 初期状態、デフォルト状態、最終状態 初期状態、最終状態、およびデフォルト状態の表現 初期状態は、太い輪郭線で表現された状態表現によってグラフィカルに定義されます。最終状態は、二重の輪郭線で表現された状態表現によってグラフィカルに定義されます。デフォルト状態は、左から斜めに伸びる開いた矢印で表現された状態表現によってグラフィカルに定義されます。対応するOPL文には、初期状態、最終状態、またはデフォルト状態を示す明示的なインジケータを含める必要があります。
リンク
イベント・条件・アクション制御 オブジェクトセットの前処理と前条件の処理 OPMプロセスがトリガーされた後に実行を開始するには、1つ以上の消費オブジェクト(一部は特定の状態にある可能性がある)および/または影響オブジェクトからなるオブジェクトのセットが必要であり、これらを総称して前処理オブジェクトセットと呼びます。インスタンスレベルの実行では、プロセスPの前処理オブジェクトセット内の各消費オブジェクトBは、Bを消費するPの最下位レベルのサブプロセスの開始時に消費され、存在を停止します。プロセスPの前処理オブジェクトセット内の各影響オブジェクト(状態が変化するオブジェクト)Bは、Pの最下位レベルのサブプロセスの開始時に入力状態から終了します。 OPM の基本有効化イベントリンク 後処理オブジェクトセットと処理後条件 プロセスを実行し、その実行に関連する変換を実行すると、1つ以上の結果(一部は特定の状態にある可能性がある)および/または影響を含むオブジェクトのセット(総称して後処理オブジェクトセットと呼ばれる)が生成されます。プロセスPの後処理オブジェクトセット内の各結果Bは、Bを生成するPの最下位レベルのサブプロセスの終了時に作成され、存在を開始します。プロセスPの後処理オブジェクトセット内の各影響Bは、Pの最下位レベルのサブプロセスの終了時にその出力状態に入ります。
制御リンク イベントリンクと条件リンクは、それぞれイベントと条件を表します。制御リンクは、オブジェクトとプロセス間、または2つのプロセス間で発生します。
イベントリンク プロセスをトリガーすると、プロセスの実行が試みられますが、その試みが必ず成功するとは限りません。トリガーイベントは、プロセスの前提条件が満たされているかどうかの評価を強制します。前提条件が満たされている場合に限り、プロセスの実行が続行され、プロセスがアクティブになります。前提条件が満たされているかどうかにかかわらず、イベントは失われます。前提条件が満たされていない場合、別のイベントによってプロセスがアクティブ化され、前提条件の評価が成功してプロセスが実行されるようになるまで、プロセスの実行は行われません。 基本的な変換イベントリンク :消費イベントリンクとは、オブジェクトとプロセスの間のリンクであり、オブジェクトのインスタンスによってアクティブ化されます。 消費イベントリンク:グラフィカルには、オブジェクトからプロセス(イベントを表す小文字のe)に向かう、矢印の先端が閉じた矢印で表されます。消費イベントリンクのOPL文の構文は次のとおりです。オブジェクトがプロセスをトリガーし、プロセスがオブジェクトを消費します。 効果イベントリンク:グラフィカルには、オブジェクトとプロセスの間に、両端が閉じた矢印が付いた双方向の矢印で表され、小文字の e(イベントの略)が付きます。効果イベントリンクの OPL 文の構文は次のとおりです。オブジェクトがプロセスをトリガーし、プロセスがオブジェクトに影響を与えます。 基本的な有効化イベントリンク : エージェントイベントリンク: エージェントイベントリンクは、エージェントオブジェクトから、それがアクティブ化および有効化するプロセスへの有効化リンクです。グラフィカルには、エージェントオブジェクトから、それがアクティブ化および有効化するプロセスまで伸びる、端に塗りつぶされた円(「黒いロリポップ」)が付いた線で、小文字の e(イベントの e)が付いています。エージェントイベントリンクの OPL 文の構文は次のとおりです。エージェントがプロセスをトリガーして処理します。 計測器イベントリンク: グラフィカルには、計測器オブジェクトから、それがアクティブ化し、小文字の e (イベントの e) で有効化するプロセスまで伸びる、終端に空の円 (「白いロリポップ」) が付いた線です。計測器イベントリンクの OPL 文の構文は次のとおりです。Instrument が Process をトリガーし、Process は Instrument を必要とします。 状態指定変換イベントリンク : 状態指定消費イベントリンク: 状態指定消費イベントリンクとは、オブジェクトの特定の状態から始まり、そのオブジェクトのインスタンスがアクティブ化するプロセスで終了する消費リンクです。グラフィカルには、オブジェクトの状態からプロセス(イベントを表す小文字の e が付く)に向かう閉じた矢印で表されます。状態指定消費イベントリンクの OPL 文の構文は次のとおりです。指定状態のオブジェクトが、オブジェクトを消費するプロセスをトリガーします。 入出力指定効果イベントリンク: 入出力指定効果イベントリンクは、オブジェクトが指定された入力状態に入ったときに影響を受けるプロセスをアクティブ化するという追加の意味を持つ入出力指定効果リンクです。グラフィカルには、入出力指定効果リンクは小文字の e (イベントの e) で表されます。入出力指定効果イベントリンクの OPL 文の構文は次のとおりです。入力状態オブジェクトがプロセスをトリガーし、オブジェクトを入力状態から出力状態に変化させます。 入力指定効果イベントリンク: 入力指定効果イベントリンクは、オブジェクトが指定された入力状態に入ったときに影響を受けるプロセスをアクティブ化するという追加の意味を持つ入力指定効果リンクです。グラフィカルには、入力指定効果リンクは小文字の e (イベントの e) で表されます。入力指定効果イベントリンクの OPL 文の構文は次のとおりです。入力状態オブジェクトがプロセスをトリガーし、プロセスはオブジェクトを入力状態から変更します。 出力指定効果イベントリンク:出力指定効果イベントリンクとは、オブジェクトが生成されたときに影響を受けるプロセスをアクティブ化するという追加の意味を持つ出力指定効果リンクです。グラフィカルには、出力指定効果リンクは小文字のe(イベントのe)で表されます。出力指定効果イベントリンクのOPL文の構文は次のとおりです。任意の状態のオブジェクトがプロセスをトリガーし、プロセスはオブジェクトを宛先状態に変更します。 州指定のエージェントイベントリンク : 状態指定エージェントイベントリンク:状態指定エージェントイベントリンクとは、エージェントが指定された状態に入ったときにプロセスをアクティブ化するという追加の意味を持つ状態指定エージェントリンクです。グラフィカルには、状態指定エージェントリンクは小文字のe(イベントのe)で表されます。状態指定エージェントイベントリンクのOPL文の構文は、「修飾状態エージェントが処理をトリガーして処理します」です。 状態指定機器イベントリンク:状態指定機器イベントリンクとは、機器が指定された状態に入ったときにプロセスをアクティブ化するという追加の意味を持つ状態指定機器リンクです。グラフィカルには、小文字のe(イベントを表す)が付いた状態指定機器リンクです。状態指定機器イベントリンクのOPL文の構文は次のとおりです。「Qualifying-state InstrumentがProcessingをトリガーし、Processingはqualifying-state Instrumentを必要とします。」 呼び出しリンク プロセス呼び出し 自己呼び出しリンク 暗黙的な呼び出しリンク :暗黙的な呼び出しは、ズームインされたプロセスのコンテキスト内でサブプロセスが終了した際に発生し、そのサブプロセスは直下のサブプロセスを呼び出します。グラフィカルには、呼び出し元と呼び出されるサブプロセスの間にリンクはありませんが、親プロセスのズームインされたコンテキスト内での相対的な高さによって、この意味合いが示されます。条件リンク 条件リンクとは、ソースオブジェクトまたはオブジェクト状態と宛先プロセスとの間の手続き的なリンクであり、バイパスメカニズムを提供するものです。 条件消費リンク :条件消費リンクとは、オブジェクトからプロセスへの条件リンクのことです。つまり、実行時にオブジェクトインスタンスが存在し、かつプロセスの前提条件が満たされている場合、プロセスが実行され、オブジェクトインスタンスが消費されます。図式的には、オブジェクトからプロセスに向かう閉じた矢印と、矢印の近くに小文字のc(条件を表す)が付記された矢印で、条件消費リンクを表します。条件効果リンク :ただし、そのオブジェクトインスタンスが存在しない場合、プロセスの前提条件評価は失敗し、制御はプロセスをスキップします。図では、影響を受けるオブジェクトと影響を受けるプロセスの間の両方向を指す、閉じた矢印の先端を持つ双方向矢印で表され、矢印のプロセスの端の近くに小文字の c(条件を表す)があります。条件エージェントリンク :グラフィカルには、エージェントオブジェクトから有効化するプロセスまで伸びる、終端に塗りつぶされた円(「黒いロリポップ」)が付いた線で、プロセスの終端付近に小文字のc(条件を表す)が付いています。条件エージェントリンクのOPL文の構文は次のとおりです。エージェントが 存在する場合、エージェントは プロセス を処理し、存在しない場合はプロセス はスキップされます。条件付き機器リンク :グラフィカルには、機器オブジェクトからそれが有効化するプロセスまで伸びる、終端に空の円(「白いロリポップ」)が付いた線で、プロセスの終端付近に小文字のc(条件を表す)が付いているものが、条件付き機器リンクを表します。条件付き機器リンクのOPL文の構文は次のとおりです。機器が 存在する場合はプロセス が実行され、存在しない場合はプロセス はスキップされます。条件状態指定消費リンク :条件状態指定消費リンクとは、オブジェクトの指定された状態から始まり、プロセスで終了する条件付き消費リンクです。つまり、オブジェクトインスタンスが指定された状態に存在し、プロセスのその他の前提条件が満たされている場合、プロセスが実行され、オブジェクトインスタンスが消費されます。図では、オブジェクトの条件を満たす状態からプロセスに向かう、矢印の先端が閉じた矢印で表され、矢印の先端の近くに小文字の「c」(条件を表す)が記されます。条件付き入出力指定効果リンク : 条件付き入出力指定効果リンクは、実行時にオブジェクト インスタンスが存在し、それがプロセスの入力状態にある場合 (かつ、プロセスの前提条件の残りの部分が満たされていると仮定した場合)、プロセスが実行され、オブジェクト インスタンスに影響を与えるという追加の意味を持つ、入出力指定効果リンクです。グラフィカルには、入力の矢印の近くに小文字の c (条件を表す) が付いた条件付き入出力指定効果リンクです。条件付き入出力指定効果リンクの OPL 文の構文は次のとおりです。オブジェクトが入力状態である場合にプロセスが発生し、その場合、プロセスはオブジェクトを入力状態から出力状態に変更します。そうでない場合、プロセスはスキップされます。条件入力指定効果リンク : 条件入力指定効果リンクは、入力指定効果リンクに、実行時にオブジェクト インスタンスが指定された入力状態に存在し、プロセスの前提条件の残りの部分が満たされている場合、プロセスが実行され、オブジェクト インスタンスの状態を入力状態から未指定の状態に変更することによってオブジェクト インスタンスに影響を与えます。ただし、そのオブジェクト インスタンスが入力状態に存在しない場合、プロセスの前提条件の評価が失敗し、制御はプロセスをスキップします。グラフィカルには、入力リンクの矢印の近くに小文字の c (条件を表す) が付いた条件入力指定効果リンクです。条件入力指定効果リンクの OPL 文の構文は次のとおりです。オブジェクトが入力状態である場合に プロセス が発生し、その場合、プロセスは オブジェクトを 入力状態から変更します。そうでない場合、プロセスはスキップされます。条件付き出力指定効果リンク : 条件付き出力指定効果リンクは、実行時にオブジェクトインスタンスが存在し、プロセスの前提条件の残りの部分が満たされている場合、プロセスが実行され、オブジェクトインスタンスの状態を指定された出力状態に変更することでオブジェクトインスタンスに影響を与えます。ただし、そのオブジェクトインスタンスが存在しない場合、プロセスの前提条件の評価が失敗し、制御はプロセスをスキップします。グラフィカルには、入力リンクの矢印の近くに小文字の c (条件を表す) が付いた条件付き出力指定効果リンクです。条件付き出力指定効果 OPL 文の構文は次のとおりです。オブジェクトが存在する場合に プロセス が発生し、その場合、プロセスは オブジェクトを 出力状態 に変更します。そうでない場合、プロセス はスキップされます。条件状態指定エージェントリンク : 条件状態指定エージェントリンク OPL 文の構文は次のとおりです: Agent が資格状態 の場合、Agent はProcess を処理します。そうでない場合は、Process はスキップされます。状態指定機器リンク 詳細情報と例については、『モデルベースシステムエンジニアリングとOPMおよびSysML』 第13章「動的システム側面」を参照してください。 [ 4 ]
構造的なつながり 構造リンクは、システム内の静的で時間に依存しない、長期にわたる関係を規定します。構造リンクは、2つ以上のオブジェクトまたは2つ以上のプロセスを接続しますが、展示特性リンクの場合を除き、オブジェクトとプロセス同士を接続することはありません。
一方向タグ付き構造リンク 両者の関係性の性質に関して、ユーザー定義のセマンティクスを持ちます。図では、開いた矢印の先端を持つ矢印で表されます。タグ付けされた構造リンクに沿って、モデラーは、接続されたオブジェクト(またはプロセス)間の構造的関係の性質を表し、後述の構文のOPL文に挿入したときに意味を成すテキストフレーズの形で、意味のあるタグを記録する必要があります。 単方向ヌルタグ構造リンク タグのない単方向タグ付き構造リンク。この場合、デフォルトの単方向タグが使用されます。モデラーは、特定のシステムまたはシステムセットに対してデフォルトの単方向タグを設定できます。デフォルトが定義されていない場合、デフォルトのタグは「関連」です。 双方向タグ付き構造リンク 双方向のタグが意味を持ち、単に互いの逆ではない場合、単一の双方向タグ付き構造リンクの両側に 2 つのタグで記録することができます。結果として得られるタグ付き構造リンクの構文は、各方向ごとに 1 つずつ、2 つの別々のタグ付き構造リンク OPL 文です。図的には、リンクの線の両端に銛形の矢印が付いた線で表されます。 相互タグ付け構造リンク タグが 1 つだけの双方向タグ付き構造リンク。いずれの場合も、相互性は、双方向構造リンクのタグが順方向と逆方向で同じ意味を持つことを示します。タグがない場合、デフォルトのタグは「関連している」となります。タグが 1 つだけの相互タグ付き構造リンクの構文は、次のようになります。ソース シングと宛先シングは相互タグです。タグのない相互タグ付き構造リンクの構文は、次のようになります。ソース シングと宛先シングは関連しています。 基本的な構造的関係 OPM の要素間の最も一般的な構造的関係は、システムの仕様記述と理解において特に重要です。基本的な関係のそれぞれは、1 つの OPM 要素 (ソース要素、または精製対象) を、1 つ以上の OPM 要素 (宛先要素、または精製対象) の集合に精緻化または洗練します。 集約参加リンク 精製対象(全体)は、1つまたは複数の他の精製対象(部分)を集約する。図式的には、頂点が全体と線でつながり、部分が反対側の水平な底辺と線でつながる黒色の塗りつぶされた三角形が、集約と参加の関係を表す。 展示特性リンク ある物が別の物を表したり、別の物によって特徴づけられたりする。表象と特徴づけの関係は、精錬対象(表象者)を、表象者を特徴づける特性を識別する一つ以上の精錬対象と結びつける。図式的には、大きな空の三角形の中に小さな黒い三角形があり、その大きな三角形の頂点が線で表象者に接続され、特徴が反対側の(水平な)底辺に接続されていることで、表象と特徴づけの関係リンクが定義される。 一般化・特殊化と継承 これらは、任意の数のオブジェクトやプロセス クラスをスーパークラスに抽象化し、スーパークラスの属性を下位クラスに割り当てることを可能にする構造的な関係です。 一般化と特化の関連性 特殊化による継承 識別属性による特化の制限 :継承属性の可能な値のサブセットによって、特化が制限される場合があります。分類インスタンス化とシステム実行 分類インスタンス化リンク : オブジェクトクラスまたはプロセスクラスであるソースシングは、ソースシングのパターンの値付きインスタンスである 1 つ以上のデスティネーションシングに接続します。つまり、パターンによって指定されたフィーチャは明示的な値を取得します。この関係は、フィーチャ値の提供によって作成されたクラスとそのインスタンス間の関係を表現する明示的なメカニズムをモデラーに提供します。グラフィカルには、頂点がクラスシングに線で接続され、インスタンスシングが反対側の底辺に線で接続された、それ以外は空の大きな三角形の中にある小さな黒い円が、分類インスタンス化関係リンクを定義します。構文は次のとおりです。インスタンスシングはクラスシングのインスタンスです。オブジェクトクラスとプロセスクラスのインスタンス 国家が指定する構造的関係とリンク 状態指定特性関係とリンク :特殊化されたオブジェクトから、そのオブジェクトの識別属性の値を示す表示特性関係。つまり、特殊化されたオブジェクトはその値のみを持つことになります。グラフィカルには、頂点が特殊化されたオブジェクトに接続され、反対側の底辺が値に接続される表示特性リンクの三角形のシンボルが、状態指定特性関係を定義します。構文は次のとおりです。特殊化されたオブジェクトが値名属性名を示す。状態指定タグ付き構造関係とリンク : オブジェクトの状態または属性の値と、別のオブジェクトまたはその状態または値との間の構造関係。つまり、これら 2 つのエンティティは、関連付けの意味を表すタグに関連付けられています。null タグ (つまり、タグが指定されていない) の場合は、対応するデフォルトの null タグが使用されます。状態指定タグ付き構造関係には、次の 3 つのグループがあります。(1) ソース状態指定タグ付き構造関係、(2) 宛先状態指定タグ付き構造関係、(3) ソースおよび宛先状態指定タグ付き構造関係。これらの各グループには、適切な単方向、双方向、および相互タグ付き構造関係が含まれており、7 種類の状態指定タグ付き構造関係リンクと対応する OPL 文が生成されます。詳細情報と例については、『モデルベースシステムエンジニアリングとOPMおよびSysML』の 第3.3章「構造リンクの追加」を参照してください。[ 4 ]
関係のカーディナリティ リンクのカーディナリティの概要 構造的および手続き的リンクにおけるオブジェクトの多重性 構造的および手続き的リンクにおけるオブジェクトの多重性 オブジェクトの多重度とは、リンクに関連付けられたオブジェクトインスタンスの数または数に関する要件または制約仕様を指します。多重度仕様が存在しない場合、リンクの両端はそれぞれ1つのオブジェクトインスタンスのみを指定します。多重度を持つオブジェクトを含むOPL文の構文では、オブジェクト名の前にオブジェクトの多重度を指定し、オブジェクト名は複数形で記述します。多重度仕様は、以下のいずれかの場合に記述できます。
あらゆる種類のタグ付き構造リンクに対して、複数のソースまたは宛先オブジェクトインスタンスを指定する。 集約参加リンクにおいて、複数のインスタンスを持つ参加オブジェクトを指定する。この場合、全体を構成する各部分には、異なる参加仕様を付加することができる。 手続き的関係において、複数のインスタンスを持つオブジェクトを指定する。 オブジェクトの多重度表現と制約 オブジェクトの多重度には算術式が含まれる場合があり、その場合は演算子記号「+」、「–」、「*」、「/」、「(」、「)」を通常の意味で使用するものとし、対応するOPL文では通常のテキスト対応を使用するものとする。
整数または算術式によってオブジェクトの多重度を制約することができます。グラフィカルには、式制約は、制約対象の式とセミコロンで区切られた後に表示され、等号/不等号記号 "="、"<、">、"<="、および ">="、セットメンバーを囲むための波括弧 "{" および "}"、およびメンバーシップ演算子 "in" (要素、∈) を、通常の意味で使用するものとします。対応する OPL 文では、制約が適用されるオブジェクトの後に、制約句を太字で ", where constraint" の形式で配置します。
属性値と多重度制約 構造リンクおよび手続きリンクのオブジェクト多重度の表現では、整数値または整数値に解決されるパラメータ記号を指定します。これに対し、オブジェクトまたはプロセスの属性に関連付けられる値は、整数値または実数値、あるいは整数値または実数値に解決されるパラメータ記号、さらに文字列および列挙値にすることができます。グラフィカルには、属性内に配置されたラベル付きの角丸長方形は、ラベル名に対応する値または値の範囲(整数、実数、または文字列)を持つ属性値を表します。OPL テキストでは、属性値は太字で、大文字のみで表示されます。
属性値を持つオブジェクトの構文は、OPL文で次のようになります。オブジェクト の属性は 値 です。
属性値範囲を持つオブジェクトの構文は、OPL文で「Attribute of Object range is value-range」 とします。実数値を持つ属性に接続する構造リンクまたは手続きリンクは、オブジェクトの多重度とは異なる関係制約を指定できます。
グラフィカルに言えば、属性値制約とは、リンクの属性端付近にあり、リンクと整列した、数値(整数または実数)または記号パラメータによる注釈のことである。
論理演算子:AND、XOR、OR論理リンクと手続きリンク 論理リンクと手続きリンク 手続き関係における論理演算子AND、XOR、ORを用いることで、詳細な処理の前提条件と事後条件を指定できます。互いに接触しない個別のリンクは、論理ANDのセマンティクスを持ちます。ここでは、金庫のロックを解除するには3つの鍵すべてが必要です。
論理XORおよびOR手続きリンク リンクファンは、XOR演算子またはOR演算子のいずれかのセマンティクスに従うものとする。リンクに共通するリンクファンの端は収束リンク端とし、リンクに共通しないリンク端は発散リンク端とする。
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と、システムのより小さな部分について詳細を追加することで完全性を高めることに重点を置いた別のOPDを作成することができます。
洗練・抽象化メカニズム OPMは、モデルの明確性と完全性を表現するための抽象化および洗練メカニズムを提供するものとする。これらのメカニズムにより、システムおよびそれを構成する要素を、それらに共通するオブジェクト、プロセス、および関係によって相互に関連付けられた様々なコンテキストで提示および閲覧することが可能となる。
国家表現と国家抑圧 状態抑制の逆は状態表現であり、すなわち、可能なオブジェクト状態に関する情報を追加することによってOPDを洗練することである。OPDに対応するOPLは、描写されるオブジェクトの状態のみを表現するものとする。
展開と折りたたみ これは、展開されたものの下位階層にある一連の要素を明らかにします。結果として階層ツリーが生成され、そのルートは展開されたものになります。ルートには、展開されたもののコンテキストを構成する要素がリンクされています。逆に、折り畳みは抽象化または構成のためのメカニズムであり、展開された階層ツリーに適用されます。
ズームインとズームアウト インズームは一種の展開であり、集約参加にのみ適用可能で、追加のセマンティクスを持ちます。プロセスの場合、インズームによって、サブプロセス、その時間的順序、オブジェクトとの相互作用、およびこのコンテキストとの間での制御の受け渡しをモデル化できます。オブジェクトの場合、インズームによって、構成要素となるオブジェクトの空間的または論理的な順序をモデル化できる独自のコンテキストが作成されます。グラフィカルには、インズームされたプロセスのコンテキスト内のタイムラインは、そのプロセスの楕円シンボルの上部から下部へと流れます。
OPMモデル構造 OPMモデル構造 OPMモデル構造—OPL OPD構成モデルと基本構成 OPDモデル OPDメタモデルの画像に示されているように、このモデルはOPDコンストラクトの概念を詳細に説明しています。このモデルの目的は、基本コンストラクトを他の可能性のあるOPDコンストラクトと区別することです。基本コンストラクトはOPDコンストラクトの特殊化であり、正確に1つのリンクで接続された正確に2つのThingで構成されます。非基本コンストラクトには、リンクファンを持つものや、2つ以上のリファインメントを持つものなどが含まれます。
モデラーは、Thing Set の切断状態と接続状態を追加することで、モデルにプロセスを追加できます。したがって、モデルの目的には、リンクセットを接続手段として使用して、切断された Thing Set を接続された Thing Set に変換する動作が含まれます。
OPMモデルのThing OPMモデルのThing OPM の Thing モデルは、OPM Thing のモデルであり、以下の Thing モデルの画像に示すように、オブジェクトとプロセスへの特殊化を示しています。オブジェクトは一連の状態によって特徴付けられ、状態のないオブジェクトの場合は空、状態のあるオブジェクトの場合は空でない状態になります。
s個の状態を持つステートフルオブジェクトは、各状態に対応するs個のステートレスな状態固有オブジェクトのセットを生成します。特定の状態固有オブジェクトは、特定の状態にあるオブジェクトを参照します。状態固有オブジェクトの概念をオブジェクトと状態の両方としてモデル化することで、オブジェクトを指定するだけでオブジェクトとその任意の状態を参照できるため、概念モデルを簡素化できます。
モノの汎用プロパティのOPMモデル モノの汎用プロパティのOPMモデル OPMモデルにおける「物」の汎用特性は、「物」とその汎用特性である「持続性」「本質」「所属」を、展示-特性化リンクの属性精緻化としてモデル化したものである。持続性は、オブジェクトとプロセスを区別する属性である。
インズームモデルとアウトズームモデル 新しい図の拡大表示と拡大表示はどちらも、既存の OPD コンテキストから新しい OPD コンテキストを作成します。新しい図の拡大表示は、比較的詳細度の低い OPD から開始し、詳細度の低い OPD 内の特定の対象に適用される子孫 OPD として、詳細な情報や改良を追加します。
バージョン OPMロゴ OPM 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年初頭、Doriの指導の下、学生チームがOPCloudと呼ばれる次世代OPCATの開発に着手した。[ 13 ] ソフトウェア名が示すように、これはクラウドベースのアプリケーションであり、ユーザーはWebベースのアプリケーションを使用してOPMモデルを作成できるようになる。[ 14 ]
標準化 ISO (国際標準化機構)は、162の国家標準化団体が加盟する独立した非政府国際機関であり、イノベーションを支援し、世界的な課題に対する解決策を提供する、自主的かつ合意に基づく市場関連性の高い国際規格を策定しています。これらの規格は、製品、サービス、システムに関する世界最高水準の仕様を提供し、品質、安全性、効率性を確保します。
ISOとOPM 2008 年 6 月、リチャード マーティンは、オランダのユトレヒトで開催されたINCOSE 国際シンポジウムでのプレゼンテーションの後、ドブ ドリに近づき、OPM の国際標準を作成する可能性について問い合わせた。 [ 15 ] 自動化システムの相互運用性アーキテクチャとモデリングに関する ISO TC184/SC5/WG1 のコンビーナーであるマーティンは、静的な情報とプロセス モデリング以上のものを提供する方法論をしばらく探していた。彼は、OPM のモデリング機能と動的シミュレーションの可能性の両方を実証できる簡単なモデルの例をドリに提供した。
2010年5月、DoriはISO技術委員会184/小委員会5(TC184/SC5)の全体会議でOPMの概要と彼のデモンストレーションモデルについて簡単に発表し、その後、SC5によって作成された標準を強化するOPMの可能性を検証する目的でOPM研究グループを設立するという決議が採択された。[ 16 ]
OPM研究グループは2010年10月に活動を開始し、2011年のSC5総会に向けて中間報告書を発表しました。[ 15 ] この報告書には、既存のSC5規格をモデル化するためのOPMのいくつかの用途が含まれており、テキストベースであるISO規格は矛盾や不完全な情報に悩まされやすいという認識から、OPMの標準化への最初の動機が生まれました。規格がテキストベースではなくモデルベースであれば、この欠点は大幅に軽減できる可能性があり、OPMはこの目的のために有用な基盤となるモデリングパラダイムを提供しました。
2012年のSC5総会で、OPM研究グループの最終報告書とモデルベース標準作成文書のメタモデルの草案が提出されました。[ 17 ] OPM研究グループの取り組みが進むにつれて、OPMはモデルベースシステムエンジニアリング(MBSE)や自然システムと人工システムの両方のモデリングのための堅固で包括的な基盤としても機能することが明らかになりました。
ISO 19450文書 TC184/SC5/WG1の参加者は、2011年9月にOPM PASの最初の草案を受け取りました。草案は16ページ、付録2つ、参考文献1つで、合計25ページでした。内容のほとんどは、単に小節の見出しとスペースホルダーの図を識別するものでした。2012年のSC5総会までに、PAS草案にはOPMの機能を記述した10の完全な条項と6つの付録が含まれ、合計86ページになりました。1つの付録はOPLのEBNF(拡張バッカス・ナウア記法、文脈自由言語を形式的に指定するために使用され、プログラミング言語の構文解析を可能にする)仕様であり、もう1つは詳細な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は、2015年12月15日にISOによって正式に発行され、全162ページから構成されています。これは、グラフィックとテキストによる表現を単一のパラダイムに統合し、モデルの動作の自動シミュレーションに適した新しいモデリング手法の正式な仕様を標準化コミュニティに提供するための6年間にわたる取り組みの集大成です。
OPMとSysMLおよびUMLの比較 OPMとSysMLの比較 SysMLは、 UMLのプロファイルメカニズムを使用した 統一モデリング言語 (UML)の拡張として定義されています。[ 11 ]
OPM対UML OPM と UML の違いは、分析および設計段階で非常に顕著になります。UML はマルチモデルですが、OPM は単一の統一された構造と動作のモデルをサポートします。重要な違いは、UML の構造指向アプローチに起因しており、動作は 13 種類の図に分散しているため、モデルの多重性の問題が必然的に発生します。[ 18 ] まず、OPM アプローチを使用すると、メイン図 (SD) でメインプロセス、オブジェクト、およびそれらの間の接続を表示できます。[ 3 ] さらに、メインシステムの利点 (SD で提示) が何であるかを簡単に理解できます。OPM では、システムの主要な 3 つの側面 (動作、構造、機能) を理解しやすくなっています (これらの側面を異なる種類の図で記述する UML とは対照的です)。[ 3 ] データベース展開モデリングは、システムとシステムに格納されているすべての詳細の理解に貢献します。さらに、ズームインを作成することでモデルを簡素化できます。 OPMには、システムがどのように経路を保存し、意思決定を行うかといった体系的なプロセスに関する幅広い知識が必要です。
OPMモデルからSysMLビューを生成する 両言語は汎用システムエンジニアリングのための手段を提供するという同じ目的を目指しているが、その実現方法には違いがある。SysMLはUML(統一モデリング言語)のプロファイルである。
OPMからSysMLへの変換は、1対多の関係にあります。つまり、1つのOPM要素(エンティティまたはリンク)は、通常、異なるSysML図タイプに属する複数のSysML要素に変換されます。たとえば、オブジェクトを変換(生成、消費、または状態変更)するエンティティとして定義されるOPMプロセスは、以下のSysMLエンティティの任意のサブセットにマッピングできます。
OPMとSysMLはそれぞれ異なる設計の言語であるため、一方の言語のすべての構成要素が他方の言語に同等の構成要素を持つわけではありません。
OPM ダイアグラムから生成できる UML の最初のタイプのダイアグラムは、システムの使用をモデル化することを目的としたユースケースダイアグラムです。ユースケースダイアグラムを構成する主な要素は、アクターとユースケース (エンティティ)、およびそれらの間の関係 (リンク) です。したがって、OPM からユースケースダイアグラムを生成するには、環境オブジェクト (アクター) と、それらにリンクされたプロセス (ユースケース) に基づいて行います。図 1 は、SD0 のユースケースダイアグラム生成の例です。この図は、ルート OPM ダイアグラム (a)、対応する OPL テキスト (b)、および作成されたユースケースダイアグラム (c) を示しています。図 2 は、同じ OPM モデルの OPD の SD1 レベル (a) と、生成されたユースケースダイアグラム (b) を示しています。 2つ目のタイプの図は、ブロック定義図(BDD)です。BDDは、ブロックの特徴(プロパティや操作など)と、ブロック間の関係(関連や一般化など)を定義します。BDDの生成は、OPMモデルのシステムオブジェクトとそれらの関係、主に他のモデル要素との構造的な関係に基づいています。 3 つ目のタイプの図は、フローを指定することを目的としたアクティビティ図です。アクティビティ図に含まれる主要なコンポーネントは、アクションとルーティングフロー要素です。このコンテキストでは、子サブプロセスを含む各 OPM プロセス、つまり OPM モデルでズームインされているプロセスごとに、個別のアクティビティ図を生成できます。設定ダイアログで指定できるユーザー パラメータには 2 種類あります。1 つ目は OPM プロセスの選択に関するものです。1 つのオプションは、リストから選択して必要な OPM プロセスを明示的に指定することです。もう 1 つのオプションは、デフォルトのオプションで、ルート OPD (SD) から始めて階層を下っていくことです。ここで、2 番目のパラメータ (最初のパラメータとは独立) に到達します。これは、階層を下っていくために必要な OPD レベルの数 (k) です。ユーザーが抽象化レベルを制御できるように、図は階層を下って k レベルまで生成されます。各レベルでは、上位レベルのアクティビティに含まれる子アクティビティ (サブ図) である追加のアクティビティ図が生成されます。このオプションのデフォルト設定は「すべてのレベルを下げる」(つまり「k = ∞」)です。[ 19 ]
参考文献 1 2 3 4 5 「ISO/PAS 19450:2015 - 自動化システムと統合 - オブジェクトプロセス方式」 . iso.org . 2015 年 12 月. 2017 年 5 月 3 日 取得 . 1 2 Dori, Dov (1995). "オブジェクトプロセス分析: システム構造と動作のバランスを維持する". Journal of Logic and Computation . 5 (2): 227–249 . doi : 10.1093/logcom/5.2.227 . 1 2 3 4 5 Dori, Dov (2002). Object-Process Methodology: A Holistic Systems Paradigm . Berlin, Heidelberg, New York: Springer-Verlag . doi : 10.1007/978-3-642-56209-9 . ISBN 978-3540654711 . S2CID 13600128 . 1 2 3 4 5 6 7 8 9 10 Dori, Dov (2016). Model-Based Systems Engineering with OPM and SysML . New York: Springer-Verlag . doi : 10.1007/978-1-4939-3295-5 . ISBN 9781493932955 . OCLC 959032986 . S2CID 32425215 . 1 2 3 「エンタープライズシステムモデリング研究所 » OPCATのインストール」 . technion.ac.il . 2017年 5月3日 取得. ↑ Booch, G.「メソッド戦争に休戦の時が来た」。オブジェクト指向プログラミングジャーナル 、1993年7月/8月。 ↑ Perelman, Valeria; Somekh, Judith; Dori, Dov (2011). 分子生物学への応用を伴うモデル検証フレームワーク 。TMS-Devs '11。国際コンピュータシミュレーション学会。pp. 140–145 。 ↑ Fischer, Amit; Nolan, Mike; Friedenthal, Sanford; Loeffler, Michael; Sampson, Mark; Bajaj, Manas; VanZandt, Lonnie; Hovey, Krista; Palmer, John; Hart, Laura (2014). "3.1.1 MBSE のモデルライフサイクル管理". Incose International Symposium . 24 : 207–229 . doi : 10.1002/j.2334-5837.2014.tb03145.x . S2CID 106677531 . ↑ 参照: Herre, Heinrich; Heller, Barbara; Burek, Patryk; Hoehndorf, Robert; Loebe, Frank; Michalek, Hannes (2006 年 7 月) 「一般形式オントロジー (GFO): オブジェクトとプロセスを統合する基礎オントロジー: パート I: 基本原則」 (PDF) 。 Onto-Med レポート 。 8 : 3。 2016 年 3 月 28 日に オリジナル (PDF)からアーカイブ済み 。 2017 年 5 月 4 日 に取得。 統一モデリング言語 (UML)、データベース分野の エンティティ関係モデリング 、オブジェクト プロセス メソドロジーなど、概念モデリングに現在使用されている言語は、 そのオントロジー的コミットメントに従って検討することができます。 ↑ Dori, Dov; Linchevski, Chen; Manor, Raanan (2010). "OPCAT – 複雑なシステムのオブジェクトプロセス手法に基づく概念モデリングのためのソフトウェア環境". Proc. 1st International Conference on Modelling and Management of Engineering Processes . University of Cambridge, Cambridge, UK, Heisig, P., Clarkson, J., and Vajna, S. (Eds.): 147– 151. 1 2 グロブシュテイン、ヤリブ。ペレルマン、ヴァレリヤ。サフラ、エリヤフ。ドリ、ダブ (2007)。 システム モデリング言語: OPM と SysML 。イスラエル、ハイファ: IEEE。 102 ~ 109 ページ 。ISBN 978-1-4244-0770-5 2020年2月18日にオリジナルからアーカイブされました。 2018年 11月15日 に取得 。↑ 参照:「mRNAライフサイクル」 (PDF) . technion.ac.il . 2017年 5月3日 取得 . ↑ エンタープライズシステムモデリング研究所。 「opcloud」 。 ↑ Dori, Dov; Jbara, Ahmad; Levi, Natali; Wengrowicz, Niva. "オブジェクトプロセス手法、OPM ISO 19450 – OPCloud および OPM モデリングツールの進化" . Project Performance International . 2018 年 11 月 18 日 取得 . 1 2 Blekhman, Alex; Dori, Dov; Martin, Richard. "モデルベースの標準作成" (PDF) . 2018年 11月18日 取得 。 ↑ Dori, Dov; Howes, David; Blekhman, Alex; Martin, Richard. "OPM as a Basis for Model - Based Enterprise Standards, Report of the ISO TC184/SC5 OPM Working Group to the Plenary ISO TC184/SC5 Meeting, Tokyo 26, 2010" (PDF) . 2018年 11月18日 取得 。 ↑ SC 5 全体会議。 「会議報告書」 (PDF) 。2018 年 11 月 18 日 に取得 。 {{cite web}}: CS1 maint: 数値名: 著者リスト (リンク)↑ Peleg, M.; Dori, D. ( 2000). "モデル多重性問題: リアルタイム仕様手法の実験". IEEE Transactions on Software Engineering . 26 (8): 742–759 . CiteSeerX 10.1.1.321.5507 . doi : 10.1109/32.879812 . ↑ グロブシュタイン、ヤリブ。ドリ、ダブ (2009)。 OPM モデルから SysML ビューを作成します 。イスラエル、ハイファ: IEEE。 pp. 36–44 . 土井 : 10.1109/MBSE.2009.5031718 。 ISBN 978-1-4244-2967-7 . S2CID 6195904 .
外部リンク オブジェクトプロセス手法とそのビジュアルセマンティックウェブへの応用、Dov Doriによるプレゼンテーション、2003年。 ナヴィヤ・ニャーヤの技術言語のいくつかの特徴 エンジニアと科学者に役立つ概念モデリング思考プロセスの体系化。、Dov Doriによるプレゼンテーション、2015年。 エンジニアと科学者に役立つ概念モデリングの思考プロセスを体系化する 米国特許US7099809B2( OPDとテキスト形式の変換に関する特許)