はじめに
部品を回転させるプロセスを観察しているとします。 私たちは自分自身に問いかけます：誰が部品を磨くのですか？ 答えは次のとおりです。イワノフ、ターナー、ショップマネージャー、ペトロフの友人。 これはまったく同じ人だと言えますが、ターナーは人ではなく、役割、店長、友人でもあることを理解しています。 だから誰が部品を研いでいるのか？
リンゴの熟したイベントがあります。 このイベントの前、リンゴは緑でしたが、このイベントの後、リンゴは赤に変わりました。 質問：イベント自体の過程でリンゴはどのようなものでしたか？
この記事では、これら2つの質問に投影モデリングの観点から答えます。
先ほど言ったように、時間と空間に関する2つの予測は、シミュレートされた時空間ボリュームのアイデアを与えます。 一度に4Dボリュームを投影するには、次の3つの方法があります。
- イベント（操作）の形式で、
- イベント（操作）の有限セット（シナリオ）、
- 無限数のイベント（操作）（関数）。
操作は、「from」と「to」という時間間隔内にあります。 測定の精度が「s」と「by」を区別できず、それらがマージされると、「when」という日付のイベントが発生します。
一方、4-Dボリュームも空間に投影されます。 4-Dボリュームを空間に投影するには、次の3つの方法があります。
- 施設
- オブジェクト（構造）の有限セット、
- 無限の数のオブジェクト（ヒープ）。
4-Dボリュームがオブジェクトの形で空間に投影される場合、次のように解釈できます。車がペイントされた。
4-Dボリュームは構造の形で空間に投影され、次のように解釈できます。Ivanovはワークピースからパーツを回転させました。
4-Dボリュームがヒープの形で空間に投影される場合、次のように解釈できます。商品のバッチがリリースされます。
前述したように、投影モデリングはイベントの解釈には関与しませんが、モデリングの解釈の基礎を作成します。 そのタスクは、4-Dボリュームを正しくシミュレートすることであるため、後でこのモデルの上でこれらのボリュームの解釈を構築できます。 これは、たとえば、部品がワークピースから受け取られたなど、イベントの解釈が、4-D操作ボリュームに、部品として扱われる4-Dボリュームと、ワークピースとして扱われる4-Dボリュームがあるという事実を超えることを意味します。 なぜこれが行われるのですか？ 同じ操作を異なる方法で解釈できるため、同じ部分も解釈できます。 2つの被験者は、部品、ワークピース、工作機械、およびIvanovが操作に参加したという点で収束できますが、解釈が異なる可能性があります。 機械の部品を回転させたのはイワノフであると言う人もいれば、イバノフの制御下で部品を回転させたのは機械であると言う人もいます。
別の例：それは販売操作であったと言うかもしれません。 別の人は、操作が購入であったと言うかもしれません。 1人は両生類を販売し、2人目はボートを購入しました。 各操作とその参加者は情報システムに記録されますが、一方が両生類、もう一方がボートと解釈されるオブジェクトの運命を追跡するには、その解釈とは別に4-Dボリュームをシミュレートできる必要があります。
4-Dボリュームモデルの上に解釈モデルを構築することは常に可能ですが、解釈に基づいて4-Dボリュームモデルを構築することは、残念ながら不可能です。 そのようなモデルを構築するには、4-Dボリュームのモデルをその解釈のモデルから分離することを学ぶ必要があります。 現代のアナリストは、このスキルに大きな問題を抱えています。 さらに、何らかの理由でこれを行うのは悪い形と見なされます。 結果は、1つの視点のみを反映するモデルです。 十分な場合、モデルは正しく構築されますが、より多くの視点を考慮する必要がある場合、タスクは解決できなくなります。
記事「 プロジェクションモデリングを使用した企業の資産のモデリング」で、物理オブジェクトの会計の観点と機能オブジェクトの会計の観点の2つの異なる観点からモデルを同時に構築する必要が生じたときの実践の例を思い出しました。 アクティビティの異なる分野で同じ用語が異なるオブジェクトを意味するため、それらを考慮する必要が生じたことを思い出させてください。 操作用の変圧器と資材会計用の会計用の変圧器は異なるオブジェクトです。 違いは、材料計量用の変圧器では鉄の山であり、必ずしも回路に含まれていないことです。 このような変圧器は、物理オブジェクトまたは機器のユニットと呼ばれます。 動作させるには、変圧器を回路に接続する必要があります。 このようなトランスフォーマーは、機能オブジェクトと呼ばれます。 これには結果があります。 操作をシミュレートする場合、異なる視点からの4D部分は、物理トランスフォーマーの一部として、または機能トランスフォーマーの一部として、さまざまな方法で解釈できます。 つまり、同じ4-Dボリュームを物理的なトランスフォーマーまたは機能的なトランスフォーマーとして解釈できます。
システムエンジニアリングでは、2つの事前定義された視点を使用してこのタスクに対処します（ただし、私の意見では、これは非常に紛らわしく矛盾していると標準で説明されています）。 しかし、2つの観点が不十分になると、システムエンジニアリングは失敗します。 たとえば、ノードが3つの機能を同時に実行すると言う必要がある場合：モーターシャフトの温度、速度、回転速度を測定する場合、1つの観点から、4-Dボリュームは温度計と呼ばれる機能オブジェクトとして解釈できるとは言えません-方法速度計と呼ばれる機能的なオブジェクト、および3番目-タコメーターと呼ばれる機能的なオブジェクトとして。 したがって、先へ進むことを余儀なくされます。
それでは、ビジネスに取り掛かりましょう。
イベントの形での予測の解釈
まず、オブジェクトの形で空間に投影します。 つまり、1つのオブジェクトの形で空間に投影された4-Dボリュームがあります。 このような投影をどのように解釈できますか？
「車が赤から白に塗り直される」というイベントをシミュレートするとします。 この事実をシミュレートする方法は？ まず、このイベントには特定の4-Dボリュームが関係しています。 このボリュームは、マシンの4-Dボリュームの一部として解釈されます。 したがって、4-Dボリュームの最初の解釈はマシンです。 別の解釈は、それは白いオブジェクトであり、3番目は赤いオブジェクトであるということです。 これはシュレーディンガー猫に非常に似ています。 イベントが終了するまで、車の色はわかりません。また、赤と白の両方が同時に表示されます。
このモデルを見て、イベントのデータから、イベント後の車の色を推測することは可能ですか？ いいえ、できません。 車の前と後を理解するには、前の操作、イベント、後の操作のシナリオが必要です。 Do氏は、車は赤だったと言っています。 後の操作は、それが白色であると言います。 次に、シナリオを知って、イベント内でマシンの色が変わったという事実を推測できます。
これは直感に反しますが、論理的にはそうです。 長い間、私はクリス・パートリッジを理解できませんでした。彼が書いた場所では、熟成作業でリンゴは熟していて熟していないと書いています。 今、この道を自分で旅して、私は彼が何について話しているのかを理解しました！
そのため、マシンの色が赤から白に変わったという事実は、スクリプトからのみ推測できます。 イベントからこの事実を導き出すことは不可能です。 そして、これは、イベントが何かの状態の変化であるという広範な主張と矛盾しています。 変更はスクリプトであり、操作やイベントではありません。
しかし、シナリオを知っていても、さまざまな方法で解釈できます。 したがって、マシンの色が変わったという事実を推測することは可能ですが、それがなぜ起こったのかはわかりません。 「なぜ」という質問に対する答えは、イベントの解釈、つまり絵画にかかっています。 イベントを絵画として扱い、この解釈に基づいて、色の変化は絵画のために発生したと結論付けます。 しかし、何を描いて、イベントを言うべきですか？ そして、ここにあなたが注意を払うべきその楽しい機能があります。 イベントでマシンとして扱われる時空の部分は、赤いオブジェクトとしても扱うことができることを覚えています。 質問：イベントには何が描かれていますか？ 答えは次のとおりです。役割。 つまり、役割は4-Dボリュームの指定であり、視点によって異なる解釈が可能です。 赤いオブジェクトとして、マシンとして解釈できます。 このため、Role1は操作のために考えられ、操作の解釈は次のようになると言われています。役割1の色付け。今、役割1の解釈を置き換えると、新しいステートメントが得られます。 部品は、ターナー兼ショップマネージャーであるイワノフによって研がれたことがわかりました。
これで、ペイントイベントのシミュレーションの終了です。 イベントとその解釈を離れる場合、マシンの色が変わったと言うのに十分な知識がありますか？ いいえ、十分ではありません。ペイント操作が正常に終了しなかった可能性があるためです。 それが正常に完了したという事実は、イベント以外で得られた知識に基づいて-スクリプトから明らかになります。
操作のすべての参加者は、同時に参加を開始し、同時に終了します。 これも奇妙に思えます。 たとえば、ワークピースとパーツが旋削加工への参加を開始と同時に終了し、終了と同時に終了するというのはばかげているように見えます。 光をオンにする操作で、暗闇と光が同時に参加を開始し、同時に終了するという事実。 直観はこの論文に抵抗します。 しかし、直観が私たちに伝えるものを見てみましょう。 彼女は言う：光をオンにする操作では、暗闇が最初に参加し、光-その後。 光と闇は交差できません！ つまり、直感はスクリプトに訴えます！ 彼女は次のように語っています。まず暗闇、次に明かりのシナリオを見てみましょう。 つまり、異なる側面で暗闇と光を分離するために、モデルを改良しましょう。 しかし、モデルを指定すると、光と闇が一緒に存在するイベントに出くわします。 このような精度の競争は永遠に続く可能性があります。 数学が好きな人のために：一連の改良モデルが私たちに与えてくれ、最終的に特定の時間値に収束する時系列を想像できます。 この値は、明暗の断面と呼ばれます。 こんにちは、ディリクレの断面図！
1つの4-Dボリュームの投影を時間通りに調べたところ、すでに非常に多くの驚くべき直感に反する結果が生じていることに注意してください。 これはほんの始まりに過ぎません。 カーテンを少し持ち上げただけです！ ロジックに従うと、信じられないほどのさまざまなモデリングの可能性が広がります。
ロール定義
投影法のさまざまな組み合わせに対して、さまざまな解釈を続けることができますが、今は少し立ち止まって少し戻りたいと思います。 これまでの議論から得られた別の美しい事実を共有したいと思います。 機能的な役割についてお話したいと思います。
役割という用語の定義は、関数という用語の定義と同じくらい困難です。 最近、システムエンジニアリングフォーラムで、関数という用語は基本的かつ不明確な概念であるという意見に出会いました。 もしそうなら、この定義では関数を分解することさえできません！ そして、これは非常に悪いです。 そのような関数の定義を提示しました。その結果、関数で何でもやりたいことができます。異なる角度から調べたり、分解したり、それに基づいてより大きな関数を合成したりできます。 この記事では、関数にロールがどのように現れるかを説明します。 これにより、機能と同じように、希望どおりにロールを操作できます。
イベントの解釈には役割があります。 ロールには名前が割り当てられます。 最も一般的なロール名は、アクティビティ理論から借用したものです。 アクティビティの理論では、各アクティビティには、アクティビティが「実行者」と呼ぶサブジェクト、アクティビティのオブジェクト：作業の対象：材料、アクティビティの結果：結果、アクティビティのツール：ツールが必要であると述べています。 時々、彼らは活動の目標である目標についても覚えています。 役割に名前を付けるこのアプローチは、情報モデルの作成に役立ちます。 役割にはいくつかのタイプがあり、それらは統合されており、ほとんどすべての操作で見つけることができます。 問題は、彼らが活動理論から借用していることです。 そして活動は、メカニズムの活動ではなく、被験者の精神機能を説明します。 そして、サブジェクトが存在するアクティビティを考慮する場合にのみ、アクティビティの観点からも、指定されたロールの名前を使用できます。 メカニズムの活動を記述する必要がある場合、または活動の観点からではなく活動を記述する必要がある場合、活動の理論は適用されなくなります。 コンドームを地球上に引き寄せたいという願望を持ち続けると、メカニズムがアニメーションオブジェクトのプロパティを保持するモデルが表示されます。それらは、何かを実行したり、管理したり、アクションを実行したりできます。 この欺ceptionを理解している人はほとんどいませんが、この欺forの理由を理解している人はほとんどいません。 私は彼についてあなたに話しました。 私は非常に興味があります、誰かがそれを理解しましたか？ 私はこれを理解した人々から答えを聞きたいです。
アクティビティ理論から事前に定義された役割は、アクティビティを記述するには不十分になることがあります。 その後、人々は特定の役割を思いつきます。 たとえば、ターニング操作のエグゼキューターはターナーと呼ばれ、プラント管理機能のエグゼキューターはディレクターです。 そのため、他にも多くの役割があります。 私たちの周りには多くの操作、多くの機能があります。 同じ4-Dボリュームが異なる操作と機能に同時に参加できます。 したがって、部門の長とターナーが1人の場合に交差が発生します。 1つの4Dボリュームだけが、ある機能の参加者として、および別の機能の参加者として同時に扱われます。
よろしくお願いします！ 次の記事では、モデルに関するストーリーの続きをご覧ください。 複雑なケースより複雑なモデルについて説明します。