→ 概念：セット、タイプ、属性
→ 分析を混同する方法。 パート1
→ 分析を混同する方法。 パート2：ドメインモデリングとは
→ 分析を混同する方法。 パート3。 動詞と数字
要するに、オブジェクトのライフサイクルについて、その変換と、それに関するアイデアの変換という点で触れました。
→ 分析を混同する方法-4.確率と精度
次に、操作、関数、オブジェクトのモデリングを単一の視点から検討し始めました。
→ 分析を混同する方法-5.概念的な装置
これはすべて、情報システムを作成する際のモデリングの範囲を超えていますが、それらの間にアダプターを作成することでさまざまな情報システムを統合する問題を解決することは非常に必要です。
アダプターを作成するには、オブジェクトとアクションとして異なる方法で同じものをモデル化する方法を学ぶ必要があります。 哲学的な考えでは、これは新しいものではありません。オブジェクトは時間の外に存在せず、アクションはオブジェクトなしでは実行できないためです。 実際、仏教徒が見ているように世界を見る必要があります。オブジェクトとアクションは同一です。 このような世界観の必要性は、同じものに異なる視点を組み合わせる必要性から生じています。 この記事では、現実の可能性のある表現と、それらの間の気象関係（部分的な関係）を検討します。
時計説明実験
時計があります。 3人を連れてきて、彼らが見たものを説明してもらいます。
- 最初は、それが時計と呼ばれるオブジェクトであると言います。
- 二番目は、それが現在の時間のデモンストレーションと呼ばれる関数であると言うでしょう。
- 3番目は、これが「分針を1部門分回す」という一般名での一連の操作であると言います。
3つすべてが1つの4次元時空オブジェクトを記述しますが、異なる方法でこれを行います。
- 最初のケースでは、オブジェクトのモデルを取得します。
- 第二に-機能モデル、
- 3番目の操作モデル。
それぞれがオブジェクト、操作、または機能としてモデル化される3つの異なる情報システムを接続するアダプターを作成する場合、視点を変更する方法と、同じ量でオブジェクトを表示する方法を学習する必要があります。 、および機能、および操作。 これを行うには、オブジェクト、操作、および機能が同じ時空間ボリュームの異なる記述であるという考えを受け入れる必要があります。
オブジェクト、操作、または機能は人間の心の中に存在しますが、現実には存在しません。 読者が考えるかもしれない独身主義の意味ではなく（現実の世界が存在する）、この世界を解釈するという意味では、オブジェクト、操作、および機能は同じ時空ボリュームの異なる解釈であるためです。
現実をモデル化すると、オブジェクトの形での現実の表現に簡単に対応できますが、機能や操作の形での現実の表現を扱うことはほとんどできません。 また、既存の標準はこれを理解するのに役立ちません。 この記事では、現実をオブジェクト、機能、操作として表現することの関係を調べます。
モデリングは、4次元時空ボリュームの説明から始まり、アナリストはその解釈を行います。 このために、このボリュームの境界のモデルが構築されます-空間と時間の場所。 たとえば、属性「開始日」と「終了日」は、時間の境界を記述するために使用されます。 ボリュームを説明した後、アナリストはこのボリュームを解釈します。
オブジェクトとしての現実の表現
時空の体積をオブジェクトの形で解釈するとき、静的に焦点を当てます。 フォームスタティック、コンストラクションスタティック、またはプロパティスタティックにすることができます。 たとえば、椅子には静的な形状と構造があり、川には土手と水面があり、時計には構造（形が変わる）があり、チェスのゲームにはプレーヤーとテーブルがあります。
オブジェクトの構築を記述するために、モデルは相互接続されたオブジェクトのセットの形で構築されます-シミュレートされたオブジェクトの一部。 オブジェクトとして扱われるボリュームは、それぞれがオブジェクトとして扱われる部分に分割されます。
関数としての現実の表現
時空の4次元ボリュームを関数として解釈するとき、再現性の特性を持つダイナミクスに焦点を当てます。 たとえば、時間を示す機能は動的ですが、この動的に伴うイベントは、特定の角度（静的）による矢印の回転という1つのクラスに属します。 つまり、関数の不変式は、観測可能なイベントのクラスです。
時計の機能は時間を表示することだと人々が言うのをよく聞くことができます。 この論文では、オブジェクトと機能を分離しています。 実際、オブジェクトと関数は同じボリュームの異なる解釈です。 したがって、モデリングの観点から言えば、時計として解釈されるボリュームは、空間の特定のセクションで発生する現在の時刻を示す関数として解釈することもできます。 そのような論文は、かなり膨大なモデルの構築につながります。それが、アナリストがしばしば2つのオブジェクト（関数（時間デモ）、オブジェクト（時計）、およびそれらの間の接続）に減らす理由です。 これにより、モデリングの量は減りますが、正しく考えることができなくなります。 私の解釈では、モデルは会計オブジェクトのいずれかに関して対称的です-オブジェクトであれ、関数であれ、他の何かであれ。 モデルの対称性により、アダプターを作成できます。
関数は、IDEF0表記を使用してモデル化されます。 同じ表記法を使用すると、機能の部分的な構造-機能構造に建設的な分割をモデル化できます。 これは、関数が部分に分割され、各部分が関数として解釈される場合です。 多くの場合、このモデルは誤ってプロセスモデルと呼ばれます。
同じ表記法で、オブジェクトの形で関数の構築をモデル化する初歩を見ることができます。 これらは、いわゆる「下からの矢印」です。 しかし、この場所では、これらの矢印の意味が明確ではないため、表記は不完全です。参加者の時間的部分、これらの部分の解釈（ロール）、または参加者自身です。 したがって、モデリングの基礎はあると言えますが、表記は不完全です。 これについては後で詳しく説明します。
操作としての現実の表現
時空間の4次元ボリュームを操作の形式で解釈するとき、一般的な場合、時間に関して不変量はないが、操作が行われる空間に関して不変量があるダイナミクスに注目します。 つまり、操作は特定のボリュームで発生します。そのボリュームでは、被験者の観点から、因果関係を観察する必要があります。
操作のダイナミクスは、4次元ボリュームの出現と破壊に関連付けられています。 オブジェクト、オブジェクトなどの状態として解釈されるボリュームです。 したがって、操作モデルは、一部の4次元ボリュームの開始日と完了日のセットです。
操作は、操作の設計と区別する必要があります。 通常、操作モデルは、その構築の特定のモデルとして理解されます。 操作の検出された構造は、2つのタイプに分けられます。 最初のタイプの構成は、その参加者の記述であり、2番目は、一時的な接続（プロセス）によって接続されたサブオペレーションの形式の構成です。 多くの場合、操作のモデルとは、参加者の列挙、つまり参加者の形での設計を意味します。 この種のエラーの理由は、モデリングの目的でした。 誰もが操作につながった因果関係、または変更の説明に興味を持っています。 因果関係は、役割の明らかな構成またはサブオペレーションの明白なシーケンスのいずれかを参照することで説明できます。 これは2つのステップで行われます。
- 最初のステップは、操作の一時的な部分をシミュレートすることです。 時間内に操作を分割すると、これらは時間的に分離された部分になり、将来的には操作として扱われます。 操作を空間で分割すると、これらは操作全体に同時に存在する部分になります。 これらの部分はさらに役割として扱われます。
- 2番目のステップでは、被験者の経験に訴えて、手術で生じた変化を彼に説明することが必要です。
最初に、参加ロールの形式で操作の設計モデルを検討します。 このように因果関係を説明するには、何が起こっているのかを説明する明白な参加者を示す必要があります。 たとえば、リンゴがなぜ地球に落ちたのかを説明したい場合、落下操作の明らかな参加者は次のようになります：リンゴ1の一時的な部分は身体1の役割を果たし、地球の一時的な部分は身体2の役割を果たし、身体間の重力相互作用です。 私たちは重力の法則に言及し、したがって、地球への物体の落下を説明しました。 この種の説明をシミュレートするには、最初のステップで、オブジェクトの一時的な部分としてさらに処理されるボリュームをリストする必要があります。これらのボリュームを、地球とリンゴとして解釈されるボリュームに接続する必要があります。 2番目のステップでは、参加者の役割のボリュームを割り当てます：普遍的な重力の法則における身体1と身体2の役割。 その後、法律を参照して説明を入手してください。 この場合、因果関係のモデルは役割のモデルであり、参加者のモデルはこれらの役割の実行者のモデルです。 非常に多くの場合、参加者のモデルと役割のモデルが混同され、すべてが1つの山に捨てられている状況に遭遇することがあります。
一連のサブオペレーションの形式でオペレーションを構築するためのモデルを検討します。 このように因果関係を説明するには、何が起こっているのかを説明する明らかな副操作をリストする必要があります。 たとえば、クライアントからのアプリケーションが処理された理由を説明するには、アプリケーションの受信からアーカイブまでの一連の操作を考慮する必要があります。 このようなシーケンスを見ると、この操作に関心のあるすべての関係者が満足した理由を簡単に理解できます。 このために、一連の副操作とそれらの間の関係が構築されます。 ここでも、2つのレベル-時間ボリュームと、第1レベル、第2レベルの時空での位置-これらのボリュームを操作の形式で解釈し、それらの間の因果関係を説明します。
これまでのところ、これらのレベルを明確に分離する標準を見たことはありません。 現在、ボリュームのモデリングとその解釈は1つのヒープに積み上げられています。 たとえば、プロセスには結果が必要であるとよく言われます。 しかし、結果はモデルの第2レベルです。 それでは、シーケンスはあるが結果も因果関係の説明もない最初のレベルは何ですか？ アナリストはこのレベルのモデリングをスキップするため、これらの種類のオブジェクトに名前を付ける必要はありません。 しかし、本格的なモデルを構築するには、これらの名前を探す必要があります。 または、最近、ビジネスアナリストの役割はビジネスを支援することだと聞きました。 しかし、これは再びモデルの2番目のレベルであり、最初のレベルにはモデリングアクティビティのみがありますが、目標と因果関係はありません。 そして、最初のレベルを何と呼ぶかは明らかではありません。
これらのレベルの混合は、先祖から受け継いだ言語と神話上の意識によっても促進されます。 馬が乗っていると読んだとき、私はこの論文を3つの異なる方法で解釈できます。 特定の動きをする、馬の形をした動く物体を想像でき、そのような動きを生み出すことができる機械システムを想像でき、馬の精神機能を考えることができます。 プレゼンテーションの3つのモードにはすべて、1つの動詞があります-ジャンプし、区別のヒントはありません。 1つのモデルのアナリストが、事実、原因、結果、および被験者の意図の3つのレベルすべてを混同することがよくあるのはそのためです。 残念ながら、これらの3つの異なるモデルを言語で分離する方法はありません。
異なる被験者は、操作の同じ参加者を見るという点で収束できますが、役割の解釈は異なります。 たとえば、戦争では、戦争当事者はしばしば、敵対行為における自分自身および他の人々の役割について強く反対します。 そうでない場合もあります-被験者は同じ役割の構成を認識しますが、異なる参加者に名前を付けます。 たとえば、重力相互作用には2つの質量が関与しますが、天文学ではよくあることですが、これらの質量の申請者は異なる場合があります。
これに基づいて、アダプターを構築する場合、物理的（ボリューム）または精神的（原因と効果の関係）に関係なく、現実に関するさまざまな視点を縫製できる必要があります。 そのようなモデルをどのように構築するかは、以前に話したように、独立した物理的および精神的モデルの構築が考慮される最初の段階で、別の非常に大きなトピックです。
異なるタイプのオブジェクト間のメリオロジー関係
同じボリュームを異なるタイプのオブジェクトの形で表すことができること、オブジェクトをオブジェクトの構造、関数またはオブジェクトから構成される構造の形の関数、構造の形の操作の形で表すことができることがわかりました。オブジェクトまたは操作で構成されます。 不思議に思うかもしれません：関数と操作からオブジェクト構造を構築することは可能ですか？ 操作から機能の構築を構築することは可能ですか、または機能から操作の構築を構築することは可能ですか？ これらは非常に特殊なモデルですが、あるべき場所もあります。
- オブジェクト-企業はデザインの形で表すことができ、その要素は機能です：「機器の生産」と「機器の販売」。
- オブジェクト-時計は、「時計の針を回す」操作で構成されるデザインの形式で提示できます（多くの時計がありますが、原則としてこれは可能です）。
- 機能-時計との類推による現在時刻のデモンストレーションは、「時計を回す」操作で構成される設計の形式で表すことができます。
- 操作を一連の関数として表すこともできます。 「杭を地面に打ち込む」操作は、「杭を設定位置に保持する」機能と「杭の端でハンマーで叩く」機能で構成されるデザインの形で表すことができます。
したがって、ボリュームを異なるタイプのオブジェクトの形で表すことができるだけでなく、異なるタイプのオブジェクトを、モデル化されたオブジェクトとは異なるタイプのオブジェクトで構成される構造の形で表すこともできます。オブジェクトのタイプに制限はありません。
これで、オブジェクトのタイプとオブジェクト間の関係についてのストーリーを完成させました。 これで、セマンティック接続を以前に見た構造を実験して見つけることができます。 オブジェクト間の因果関係（客観的）関係と、因果関係タイプまたは主題の意図の架空の関係を分離することもできます。
モデリングが実際にどのように見えるか
これまでのところ、すべてが論理的でシンプルなようです。 ただし、少し複雑にしましょう。 将来は可能性のある結果の空間を使用してモデル化され、過去のモデル化は知識の精度によって制限されることを思い出してください。 したがって、特定のオブジェクト、たとえば光子ロケットの存在の開始日について話すとき、この日付は2100年以降のどこかにあると言います。 2050年が来たら、この日付を明確にし、そのようなミサイルの発射日は2150年以降のどこかにあると言います。 したがって、「開始日」属性の値にはスプレッドがあり、このスプレッドは時間とともに変化します。 したがって、「開始日」属性の値は単なる値ではなく、値の範囲であり、この領域は時間とともに変化するため、この領域の関連日付に関連付ける必要があります。
システムエンジニアリングでは、オブジェクトのライフサイクルは設計の瞬間から始まり、処分の瞬間で終わると考えられています。 処分の時間について議論することは不可能ですが、私はデザインの開始の瞬間に議論します。 設計プロセス中に、オブジェクトの存在の計画開始日が議論されます。 そして、この日付はオブジェクトの設計の開始日と等しくありません。 オブジェクトの存在の開始の計画日は、設計文書の改良とともに指定されています。 オブジェクトの存在の始まりの日付がそのデザインの始まりの日付であることを受け入れると、理髪師のシェーバーのパラドックス、つまりナンセンスに類似したものが得られます。 プロジェクトは、施設の作成日とその処分を示します。 プロジェクトで、オブジェクトの作成日がそのデザインの開始日であると言われている場合、衝突が発生します。