はじめに
前回の記事「 イベントと操作のモデリング」で 、同じ4-Dボリュームを空間と時間に投影する方法と、これらの投影を解釈する方法を示しました。 しかし、これは投影モデリングを理解するには十分ではありません。 今日は、他の投影法とその解釈についてお話します。 各プロジェクション、プロジェクションの各ペア、3、4などは、さまざまな方法で解釈できます。 すべての解釈は私が再語することはできません。 いくつかの一般的なタスクがどのように解決されるかを示します。
例1
同じ4-Dボリュームをオブジェクトの形で空間に投影します。 この投影法は、さまざまな観点からさまざまな解釈を持つことができると既に述べました。 前の記事で、4Dボリュームの空間への投影を機械として、また赤いオブジェクトとして検討することを提案しました。 しかし、異なる4-Dボリュームの異なる投影が同じ解釈を持つ別のケースを想像できます。 たとえば、1人の被験者がプロットの境界を指定し、2番目の被験者は彼に同意しません。 両方とも異なるボリュームを割り当てましたが、同じように扱います。
例2
同じ4-Dボリュームをオブジェクトの形と構造の形で空間に投影します。 構築物は多数のオブジェクトであることを思い出させてください（接続もオブジェクトです。オブジェクトを解釈する方法の数は無制限であり、構築物の数も解釈されることに注意してください。しかし、オブジェクトとその構築について話している場合、これらの解釈は互いに一貫している必要があります。この調整の基準を記述するタスクを自分で設定したが、それに対処できなかった-しかし、時間がないので、考えることは興味深いタスクである。例：オブジェクトの形での投影はボルト接続として扱われ、 e-structureは同じ名前ですが、9つのオブジェクトのように見えます：スペース、ボルト、ナット、最初の金属板、2番目の金属板、スペースのボルト位置（接続）、スペースのナット位置（接続）、スペースの最初のプレートの位置（接続） ）および空間内の2番目のプレートの位置（通信）。
この場合、一貫性の基準は、ボルト接続という2つの解釈に共通の名前になります。 ただし、最初のボルト接続はオブジェクトの解釈であり、2番目は構造の解釈です。 注意深いオブザーバーは、オブジェクトの解釈とサブジェクトの頭部の構造の解釈との間に関連があることに注意する必要があります。 つまり、実際にはオブジェクトとその構造はありませんが、2つの投影の解釈があります。 しかし、言葉には魔法の力があります。 そして、ほとんどのアナリストは、これらの2つの予測は被験者の意識ではなく、自然の中でつながっていると信じ始めます。 つまり、建物が基礎、壁、屋根で構成されているという事実は、被験者の意識に関係なく存在する本当の事実になります。
例3
同じ4-Dボリュームをオブジェクトとして、一時的に関数として空間に投影します。 次に、視点が合意された場合、彼らはこれがオブジェクトとその機能であると言います。 時には、オブジェクトとそのプロパティ。 たとえば、空間への4-Dボリュームの投影に時計の解釈があり、当面は時間を示す機能である場合、時計の機能は時間を表示すること、または時計のプロパティは時間を表示することであると言います。 これは時間を示す時計ではないことが理解されます。 クロックと機能は、4-Dオブジェクトの解釈です。 ここでは、前のケースと同じエラーが発生します。 オブジェクトとその構造があり、ここではオブジェクトとその機能がありました。 前に書いたように 、アナリストはどこでも図を見たいという欲求から、時計（無生物）が何か（アニメーションオブジェクトにのみ固有のプロパティ）を実行できると考えています。 これら2つの予測の他の同様の解釈は次のようになります。
- 時計には時間を表示する機能があります。
- 時計の使用は、時計が時刻を表示することです。
これらの解釈によって生成される多くの衝突を思い付くことができますが、より簡単に言うことができます：このため、アクティビティモデリングに関する一貫性のある一貫した定義のシステムはまだ見られません。 1つまたは別の方法。 プロジェクションモデリングの観点からすると、このようなステートメントは無意味です。 まるで、1つのランタンからの影が2つ目のランタンから影を生じさせるように、または1つの影を使用して、別の影を生じさせるようになりました。 私を信じてください、あなたは今私の言葉を理解しているので、私が自分自身を正しく考えることも困難です。
例4
関数は、無限数のイベント（操作、シナリオ）の形式での時間への投影です。 しかし、1つの機能ではなく、いくつかの機能、さらにそれらの間の接続を使用して、しばらくの間プロジェクトを行うことができます。 機能的な構造になります。 先ほど書いたように、機能的な構造のアイデアは、IDEF0表記の図を見ると得られます。 IDEF0表記のモデルと射影モデリングのモデルの違いは、射影モデルでは射影がその解釈から分離され、フローはイベントの関連機能に共通のクラスの形式の一般化に置き換えられることです。
ここで、構造の形で同じ4-Dボリュームを空間に投影することを検討できます。 投影法ではなく、次の条件を満たす投影法を使用します。各構造要素について、4次元ボリュームを見つけ、それを機能構造の要素に投影します。 したがって、私たちは、構造のオブジェクトと機能構造内の機能との間の相互対応を確立します。 この対応は次のように解釈できます。この設計はこの機能構造を実装します。 ロジックの観点からは、「実装」について話さない方が良いですが、私たちの言語には他の言葉はまだありません。 さらに進みましょう。 同じ4-Dボリュームをオブジェクトとして空間に投影します。 これは次のように解釈できることを覚えています：構築はオブジェクトの分解です。 時間としての機能構造を関数として投影します。 結果の関数は、機能構造の合成として解釈でき、結果のオブジェクトと関数は、オブジェクトとその関数として解釈できます。 今から楽しい部分です。 システムエンジニアリングでは、オブジェクトと構造を区別しません。 両方ともシステムと呼ばれます。 そしてさらに、出現したものだけがシステムと見なすことができると言われています。 上記の構造からオブジェクトを取得し、その機能を取得し、機能構造の要素の機能を取得し、それらを比較します。 機能が機能構造の機能と等しくない場合、出現が発生したと言います-新しい機能です。 しかし、今、そのような長い旅の後、あなたは質問に答えることができます：これらの投影はどのように関連していますか？ 回答：それらは、被験者の頭の中の投影の解釈です。 つまり、出現の特性を判断するには、4つの予測とその解釈が必要でした。 システムエンジニアリングでは、このために、「システム」という用語と「システムプロパティ」という用語が使用されますが、これは何らかの理由で「システム機能」という用語とは異なります。 個人的には、私のモデルはより説得力がありスリムです。 さらに、私のモデルでは、オブジェクトが出現する必要はありません。 構造があり、オブジェクトがあり、構造要素の機能とオブジェクトの機能があります。 これらの関数の解釈は異なる場合があります。 ある解釈では出現があり、ある解釈では出現しません。 したがって、個人的には、この用語の意味はわかりません。
考えられるすべての投影法とその解釈を検討したとは程遠いですが、投影法とその解釈を分離すれば、モデリングの問題が私の観点からどのくらい簡単に解決されるかを実証しようとしました。
これまで、実際の4-Dボリュームの予測を検討してきました。 しかし、モデリングの実際的な問題を解決するために、実際のオブジェクトだけでなく、架空のオブジェクトのモデルを構築する必要があります。 そのような構造の例を挙げます。
例5
プロジェクトとは何ですか？ 現在、複雑な構造物の設置では、いわゆる拡張現実を使用することが一般的になっています。 これは、対象が仮想現実として知覚する実空間の場所に何かが投影されるときです。 つまり、被験者の心の中では、実際の4-Dボリュームが架空の4-Dボリュームに置き換えられます。 パフォーマーのタスクは、想像と一致するような実際の4-Dボリュームを作成することです。 架空のボリュームはプロジェクトであり、このボリュームの説明はプロジェクトの説明です。 簡単にプロジェクト定義を取得できました。
結論
前に、2つのタイプのオブジェクトを生成する機器のモデリングには、物理的および機能的という2つの視点があると書きました。 しかし、私たちは何を見逃しましたか？ プロジェクトを逃しました。 これは第三の視点ですが、現実の世界ではなく、想像上のものです。 プロジェクトは、被験者に何を目指して努力するかのアイデアを与えるために構築された仮想現実です。 このプロジェクトの要素、つまり特定の機能オブジェクトのプロジェクトがあるとします。 このプロジェクトは、機能オブジェクトが満たすべき要件を示しています。 変電所が建設中であるとしましょう。 まだ鉄片で占められていない変圧器のための場所があるとしましょう。 ビルダーは、この空のスペースを見て、拡張現実、つまり想像上のトランスフォーマーを見ます。 彼がこれを見ると、彼は実際の物理的な変圧器をこの場所に置くことが容易になり、その結果、想像上の現実と現実の現実が一致し、物理的な変圧器が機能的な役割を果たします。
システムエンジニアリングの定義に戻ります。 私の知る限り、システムエンジニアリングでは、設計オブジェクトと機能オブジェクトを区別しません。 つまり、現実の世界と想像上の区別はありません。 私の意見では、これは間違っています。 このため、機能オブジェクトのライフサイクルを決定する際に衝突が発生します。 システムエンジニアリングに従って、機能オブジェクトは、その作成のアイデアが生まれたときにデザイナーの頭に存在し始め、物理的に破壊されたときに終了します。 実際、設計オブジェクトは設計者の頭から始まり、そこで終わります。 機能オブジェクトは、機器が起動した瞬間から始まり、停止したときに終了します。 物理オブジェクトは、作成されると始まり、破棄されると終了します。 プロジェクトオブジェクトと機能の組み合わせにより、プロジェクトから始まり、機能から（つまり物理的でさえ、ここではよくわかりませんが）完了したことがわかりました。 私見、それは美しさを楽しむために機能的な（現実からの想像上の世界）からプロジェクトオブジェクトを分離する必要があります。
よろしくお願いします！