概念の厳密な定義：オブジェクト、状態、イベント、ビジネストランザクション、ビジネス機能

この記事では、オブジェクト、状態、イベント、操作、機能という用語を定義します。 どのようにそれらを想像できるかについてお話します。 モデリングのメタメタモデルとして、 MOFではなく集合論を採用します。 なぜ彼女なのか？ これは、数学的な基礎を持つ今日知られている唯一のモデリング手法であるため、その適用性の限界は非常に広く正当化されています。


過去の記事は、OOPツールを使用してドメインをモデル化する人々（OOP言語、UML表記）の間で活発な議論を巻き起こしました。 私が話しているアカウンティングオブジェクトはUMLでモデル化されていないことを常に強調しているという事実にもかかわらず、OOPメソッドを使用してモデル化する問題は何度も繰り返します。 OOPがサブジェクトエリアのモデリングになぜそれほど悪いのか、もう一度説明する必要があると思います。

1. OOPはクラスとタイプを混在させました。 アリストテレスによってタイプと呼ばれるものはOOPではクラスと呼ばれ、数学者がクラスと呼ぶものはOOPでは名前が付けられていません。
   
   
2. OOPには、継承という用語があります。 これは、タイプサブタイプ階層モデリングツールです。 これは、PLOがアリストテレスのロジック上に構築されていることを意味します。 ドメインモデリングに適用されるこのロジックの制限は既知であり、前の記事で言及した書籍Business Objects：Re-Engineering for Re-Useで説明されています。 そのような制限の例として、ゾウのクラスのオブジェクトとクラスの馬車のオブジェクトの高さのモデリングを想像することができます。 OOPのこれら2つの属性は相互に接続されていないため、これらの属性を作成したプログラマーに連絡することで象が馬車に収まることを理解することしかできません。 たとえば、特殊な属性としての部屋の高さ、オブジェクトの高さなど、特殊な属性を導入できますが、これも実行できません。
   
   
3. OOPでは、メソッドはクラスオブジェクトに属します。 疑問が生じます-車を運転しているのは誰ですか：ホイールまたはエンジン？ 別の質問が正しいだろう：操作の参加者は誰ですか？ メソッドはクラスから分離する必要があり、参加の程度の解釈はモデルの読者に委ねるべきです。 しかし、ISへのそのような参加の解釈を解釈しても、実際には誰が何をしたのか、誰が、いつ、どこで忙しかったのか、彼に何が起こったのかにはまったく興味がないため、データ分析には影響しません最初の質問への答えがあると。

OOPに関連する問題に加えて、現在流行のプロセスアプローチに関連する別の問題があります。 プロセスアプローチでは、プロセスはプロセスのインスタンスと呼ばれ、プロセスのタイプ、機能、および機能構造はプロセスと呼ばれます。 OOPがオブジェクトのクラスをオブジェクトのタイプと混同した場合、1つのボトル内のプロセスアプローチは、オブジェクトとオブジェクトのタイプを混合し、つまり、性質の異なるオブジェクトを呼び出します。 この用語の混乱でプログラマがどのように生き残るかはわかりませんが、私が読んだことから判断すると、彼らはこの問題を無視しようとします。

これらの問題の少なくとも一部の解決策は、オントロジーモデリング技術、特にセマンティックネットワークテクノロジー、セマンティックウェブによって提供されます。 不幸な名前と困難な運命にもかかわらず、実世界の一部のモデルを電子形式で翻訳するためのツールは、OOPやビジネスプロセスのモデリングのための一般的な表記よりもはるかに優れています。 これらのテクノロジーの機能については、 こちらをご覧ください 。

これらの技術の助けを借りて、さまざまなオブジェクトのさまざまな視点を単純にシミュレートすることが可能であり、複数の被験者が同意する共通のポイントとそれぞれのプライベートな視点の両方を反映できるという事実に特に注意を払う必要があります。 （異なる人々の観点から）互いに矛盾する事実をモデルで表現し、これらの矛盾を考慮に入れて論理的な結論を得ることができます。 オントロジーツールを使用してこのような知識を操作する例は、 ここにあります 。

オブジェクトのモデリングを検討してください。 一般に、空間内のオブジェクトには境界が明確に定義されています。 ただし、すべてのアカウンティングオブジェクトにそのような境界があるわけではないという事実に慣れる必要があります。 たとえば、操作。 ガスのボールを想像してください。 その空間的境界は明確で理解しやすいものです-これらはボールの壁です。 ボールが破裂し、ボールに含まれるガスが膨張し始めたとします。 その後、伝播するガスが存在する領域の体積を制限する表面を正確に記述することはできませんが、このガスが正確に超えていない境界を記述することはできます（終了するまで）。 同様に、操作の正確な境界を記述することはできませんが、操作を超えない境界を非常に簡単に記述することができます。 たとえば、ボルトの回転操作はワークショップの外に出ません。 したがって、作業はワークショップで発生していると言えます。 さらに、オブジェクトを密なオブジェクトと見なすのが慣習的であり、他のオブジェクトと同時に交差することはできません。 ただし、いわば操作は機能しません。 同じワークショップで同時に2つの操作を行うことができます。 ボールとの比較を続けると、ボールが破裂した後、伝播ガスは他のガスと交差する体積を占有し始めました。 操作について、どれだけ開始し、いつ終了したかを確認できます。 これは、経時的なオブジェクトの境界の説明です。 同様に、操作だけでなく任意のオブジェクトの時間境界を指定することができます。 たとえば、ボルトは2016年9月1日から2017年11月23日までの間に再溶解されました。
ボルトの境界を記述するために、次の用語を使用します：宇宙で：どこにありますか？ 時間内：いつ存在しますか？ 操作の境界を説明するために、次の用語を使用します：宇宙で：どこで発生しましたか？ やがて：いつそれが起こりましたか？ ボルトについて尋ねることは珍しいことです。いつ起こったのでしょうか？ そして、操作について：どこに存在しますか？ 問題は言語です。 異なる種類の会計オブジェクトに対して、まったく同じ質問が別々に定式化されます。 これは、操作を4次元オブジェクトとして想像することが難しいもう1つの理由です。

したがって、4次元オブジェクトをモデル化するには、4次元時空の境界の記述をこの記述の解釈から分離する必要があります。 さらなる議論では、4次元オブジェクトをモデル化するために使用する手法と、これらの記述方法が関連付けられている解釈について説明します。

オブジェクトを記述するために、シミュレートされたオブジェクトを制限する境界が構築されます。 数学的倒錯の対象にならない場合、4次元オブジェクトの境界は3次元オブジェクトになります。 この3次元の境界線をできるだけ正確に知りたいです。 たとえば、ハンマー（4次元オブジェクト）が2016年12月1日から2017年3月1日まで在庫があると言う場合、これはハンマーの悪いモデルになります。 ハンマーについてもう少し知りたいです。 たとえば、キュ​​ーブが配置されているキューブの正確な座標を指定できます。 立方体の正確な境界は次のようになります：X軸に沿って：10から20 cm、Y軸に沿って：30から35 cm、Z軸に沿って：120から135 cm、2016年12月1日から1に時間軸に沿って2017年3月。 次に、操作として解釈される4次元オブジェクトを取得します。 この4次元オブジェクトの説明は、ハンマーとして解釈される4次元オブジェクトの説明と同じに見えます。 このため、3境界は、インシデントが発生した場所、操作の開始時間と完了時間を使用して記述されます。 これまでのところ、操作の説明とハンマーの説明を区別するものはありません。 操作とハンマーを本当に区別するのは、それを理解することです。 私たちの見解では、ハンマーは時間とともに形状が変化しない高密度のオブジェクトです。 それどころか、操作は構成が緩く、一定の明確な形式を持たない。 しかし、この知識はモデルには含まれていませんが、これらのモデルに付随する契約に含まれています。 ハンマーと操作の違いを強調するために、言語パターンが使用されます。操作が発生すると、ハンマーが存在します。 これらのパターンは、ハンマーの不変性と操作の可変性を強調しています。

ハンマーを調べて、そのハンドルに沿って移動するとします。 この動きにより、表面のテクスチャは変化しません。 時間軸に沿ったこのような動きの類似物を想像するには、時間軸に沿って移動するときの4次元オブジェクトの表面が状態によって記述されることを理解する必要があります。 これは、類推を引き出すために、時間軸に沿った動きが会計オブジェクトの状態を変えないことが必要であることを意味します。 たとえば、ハンマーはテーブルの上にあり、誰も使用しません。 ハンマーの状態は変わりません。

今、ハンマーのハンドルがペイントでペイントされ、このペイントが赤から青へのグラデーションであると想像してください。 ハンドルに沿って移動すると、色の小さな変化が観察されます。 そのような時間の動きの類似物は、オブジェクトの状態の変化の観測であり、それぞれの（状態）は時間的に隣接する状態とはわずかに異なります。 このような状態の変化の例は、空間内での物質ハンマーの動きです。 体の状態は連続的かつスムーズに変化します。 さらに、限られた時間で蓄積された変化は、診断と観察のために十分に強い可能性があります。 このような有限の時間の変化は、操作と呼ばれます。

今、ハンマーのハンドルに沿って移動して、ストライカーに出会ったと想像してください。 これは、表面テクスチャの急激な変化です。 時間軸に沿って移動するときのこのようなジャンプの類似物は、アカウンティングオブジェクトまたはイベントの状態の急激な変化です。 宇宙でのハンマーの動きを考慮すると、これは宇宙での位置の予期しないジャンプになります。 このようなジャンプを防ぐ慣性を持っているため、マテリアルボディについてこれを想像することは困難です。 ただし、従来のビジネスオペレーションを考慮すると、このイベントはオペレーションのリソースの吸収、2つの機能オブジェクトの1つへの統合、つまりターナーが職場に着き、製品をリリースすることである可能性があります。 いずれにせよ、イベントとは、オブザーバーがこの時間をゼロと見なすような短い時間でのアカウンティングオブジェクトの状態の変化です。 別のオブザーバーが状態の研究により注意を払っており、変化が瞬間的にではなく徐々に起こったことがわかることは明らかです。 したがって、イベントは、オブジェクトの状態の変化に対する主観的な認識です。 オブジェクトは、私たちが構築しているモデルである客観的現実の一部であるとよく耳にします。 ただし、最近見たように、オブジェクト自体は4空間の4ボリュームの主観的な表現でもあります。 したがって、そのオブジェクト、そのイベント、その操作は現実のモデルであり、主観的な知覚の結果です。

オブジェクトを4空間の4ボリュームモデルとして定義したため、オブジェクトのタイプを判別できます。 多くの4ボリュームモデル、または多くのオブジェクトがあるとします。 これらのモデルは、意識の中で被験者に保存されます。 これらのモデルが互いに類似している場合、被験者はこれらのモデルのモデルを作成できます。 このモデルは、被験者の心にも保存されています。 このモデルのモデルは、オブジェクトのタイプです。 モデルモデルは、抽象化の第2レベルです。 抽象化の最初のレベルは4空間モデルで、これをオブジェクトと呼びます。

表面のモデリングを通じて4次元オブジェクトをシミュレートするには、大量のデータが必要です。 特定の仮定を行うことにより、この量を減らす方法があります。

たとえば、操作を説明するために、操作の開始時にリソースの吸収と機能オブジェクトの統合のすべてのイベントが発生し、操作の終了時に完成品のリリースが発生すると想定できます。 これが一般的に正しくないことは明らかですが、この記述方法では、すべてのイベントを操作の開始または完了まで減らすことができます。

ボルトのシミュレーションを行いたいとします。ボルトのスレッドには多くのターンがあります。 それをシミュレートするには、スレッドのピッチと長さを示すだけで十分です。 つまり、サーフェスを要素に分割でき、それぞれが互いに類似している場合、これらすべての要素のモデルに対して1つのモデルを作成できます（コイルのタイプ）。 これらの要素の数とそれらのドッキング方法を指定すると、そのようなサーフェスをモデル化するために必要な情報量を大幅に削減できます。 この記述は、表面要素を分類することにより、モデルの体積を減らします。

ほうきのリリースのイベント（ボルトのスレッドなど）が定期的に（ただしスペースではなく時間内に）続く操作をシミュレートする場合、これらすべてのイベント（イベントのタイプ）に対して1つのモデルを作成し、時間を指定できます。その間、ほうきが生産されました。 これにより、イベントを分類することで操作モデルのボリュームが削減されます。

ここで、問題のモデルのフレームワーク内で長さが明らかに不明であるが、モデル化された領域よりも大きいスレッドがモデル化されていると仮定します。 ある種の長い無限スレッド。 それをモデル化するために、ターンのモデル（ターンのタイプ）のモデルを作成することもできますが、モデルのフレームワーク内の数は無限であるため、その数を示すことはできません。 唯一言えることは、糸のピッチ、または単位長さあたりの巻き数です。 したがって、このような無限スレッドの説明はターンのタイプになります。

空間内の幾何学的オブジェクトが繰り返されるのではなく、時間内のイベントである無限スレッドの記述に類似しているのは、たとえば別のほうきが生成されるなど、特定の時間間隔で同様のイベントが発生する記述です。 このようなイベントの数はわからないので、その頻度についてのみ言うことができます。たとえば、1時間に1つのほうきです。 このようなオブジェクトの記述は、ビジネス機能の記述に対応し、彼らはこれがほうきを生産する機能であると言います。 つまり、関数の説明はイベントのタイプになります。

私はビジネス機能の私の定義に来ます。 ビジネス関数は、これらのイベントの密度を経時的に示す一連のイベントタイプの形式で記述された4次元オブジェクトです（縮退した場合、1つのタイプのみ、たとえばほうきを放すためのイベントタイプ）。 この定義は、関数が入力ストリームを出力ストリームに変換すると定義されている一般に受け入れられている定義とは非常に異なることに注意してください。 しかし、矛盾はありません。 関数の通常の定義は、私の特別な場合です。 問題は、関数をモデル化する同じタイプ（イベントのクラス）の各イベントセットに対して、マテリアルアカウンティングオブジェクトのストリームを属性付けできることです。 そして、各タイプのイベントは、オブジェクトのストリームとこのストリームの方向に起因します。 ただし、このような機能の理解は、アクションを実行するアクターの助けを借りて操作を説明することと同じです。 これは、異なる視点からモデルを見ることができないことです。 私の定義では、イベントの種類ごとに、アナリストが必要な会計オブジェクトを彼だけに帰属させることができる場合、古典的なモデルではこれは不可能です。 そして、これにより、Traisabilitiの要件を考慮してモデルを構築することができなくなります。 さらに、イベントタイプをモデル化するとき、スレッドモデリングにまったく縛られていません。 関数を出入りする会計オブジェクトを見つけることが難しいため、オブジェクトのフローを記述することができない場合があります。 たとえば、ピエロの指に回転するボールを保持する機能をシミュレートすると、そのような機能内のオブジェクトの流れをシミュレートすることはできません。「ピエロボール」システムからは何も流れず、機能には何も流れません。 確かに、「クラウンボール」システムでは、発生するイベントは離散的ではなく、連続的です。

連続したイベントの流れを理解するために、電気モーターに目を向けましょう。 一方では、電動機を物体として想像するのは簡単です。 これは非常に頻繁に行われます。 電気モーターのシャフトの動きをシミュレートする必要がない場合、アナリストは次のように記述します。電気モーターはそのようなものです。 これは、3次元オブジェクトの形式の4次元オブジェクトのシミュレーションです。 一方、電動機のシャフトの回転をシミュレートすることもできます。 モーターシャフトは均等に回転します。 任意の時点での各シャフト位置は状態です。 そのような条件はすべて同じタイプです。 そのような状態の数は、測定が行われる離散に依存します。 これは一時的な離散であっても、角張っていてもよい。 モデリングの目的では、角度離散をとるのが便利です。つまり、特定の角度、たとえば1回転分だけシャフトの回転と一致する状態を同じタイプと見なすのが便利です。 次に、時間軸上のそのような状態の密度-毎分の回転数は、シャフトの回転速度について話します。 したがって、ピエロの指で回転するボールは、このボールの回転の角速度によって説明されます。 時間軸に沿って分布する状態の密度は、同じタイプのある状態から別の状態への遷移が発生する速度について教えてくれます。 人間の意識が膨大な数の同様の状態に直面している場合、アナリストは状態モデリングから状態密度のモデリングに移行することを余儀なくされ、これは関数としてのオブジェクトの記述です。 モーター軸の回転の場合、これは軸の回転の関数です。

4次元のオブジェクトを同時にシミュレートできることに注意してください。

1. 3オブジェクトとして-モーター。
2. シャフト回転の関数として。

これは、会計対象が現実ではなく現実のモデルであるという理論をもう一度確認します。 ただし、4次元オブジェクトを関数として同時にオブジェクトとしてモデル化する機能は偶然ではありません。 まるで水の流れを見ているようで、最初のスライバーが通り過ぎるのを見て、目は個々のスライバーを区別しなくなりますが、その流れを知覚し始めます。 これは、人間の心が大量の情報を処理できず、オブジェクトの知覚からオブジェクトの流れの知覚に移行するために発生します。 この遷移は、動的システムとしての4次元オブジェクトの認識から、静的オブジェクトとしての認識への遷移を意味します。 したがって、関数は同じタイプのイベントを生成する静的オブジェクトです。

次の記事では、4次元オブジェクト間の「部分的」関係を検討し、これにより定義できる概念を説明します。