Clever Geek Handbook

構造操作

エントリー



関係に関する記事で、関係を定義しました。



通信は、接続されたオブジェクト（操作）に共通の4-Dボリュームです



4-Dボリュームは任意の方法で空間と時間に投影できるため、接続は、希望する方法で接続されているオブジェクトとは別に考えることができます。 関係の記事では、「ベアリングの生産」と「ベアリングの消費」の2つの機能（合計4次元空間を読む）の関係の例を示しました。これは、「ベアリングの送受信」という形式でも提示しました。



4-Dオブジェクトとしてのコミュニケーションを考慮すると、 投影モデリングのフレームワークに有用な形式を導入できます。構造要素（スクリプト）の操作です。 これで、構造要素でもセット要素と同じ操作を実行できます。



多くは折りたたむことができるため、デザインを組み合わせることができます。



多くを減算できるため、ある設計から別の設計を減算できます。



セットの交差を検索できるため、構造の交差を検索できます。



リンクの解釈がなかったため、これは以前は実行できませんでした。 ある要素が別の要素に関連付けられている場合、どのようにして削除できますか？ 接続は、接続される4-Dオブジェクトに共通の4-Dオブジェクトとして定義されているため、接続された要素の1つを削除しても、接続はそのまま残ります。



関係の種類



ベアリングを使用した例では、モデルから「ベアリング生産」と「ベアリング消費」の2つの関数を削除した後でも、「レセプションベアリング転送」という接続が残ります。



「上」、「右」などのタイプの関係は、オブジェクトが配置されているスペースのプロパティを反映しており、モデルからオブジェクトが消えても消えません。 結局のところ、このオブジェクトが占有する空間ボリュームはモデルに残ります。 したがって、接続も残ります。



空間内の「より高い-より低い」関係の一時的な類似物である「先行-追従」関係も、モデルからオブジェクトが消えても消えません。これは、4D空間のプロパティであり、その中に置かれたオブジェクトではありません。



「ある操作でのアクティビティの結果が別の操作で使用される」などの因果関係も、モデルからオブジェクトが消えても消えません。これらは4-D空間のプロパティであり、その中に置かれたオブジェクトではありません。



構造操作



実際には、構造要素に対する減算と交差の加算の操作を実行する可能性を意味しますか？



空間（構造）に投影された4-Dボリュームについて話している場合：





時間通りに予測される4-Dボリューム（シナリオ）について話している場合：





上記から、空間またはシナリオに関係なく、構造を設計するための方法論が続きます。 詳細に考えてみましょう。



構造設計の方法論



空間構造を構築する場合、それは無限の空間にとどまらず、神はどこにいるかを知っています。 デザインは他の要素に囲まれています。 本格的な構造モデリングには、構造要素と構造外の要素との関係のモデリングが含まれます。 「高低」タイプの空間接続について話している場合、このデザインの要素について、デザインの範囲外のオブジェクトとのこれらの関係をモデル化できます。 物理学を学んだ人は、おそらく、光学系で、タスクを設定するときに、観察者の目を引くか、または力学では、ブロックがぶら下がっている上部支持体の上部を描くことを覚えているでしょう。 これは、設計モデルにないオブジェクトとの関係の説明です。



システムエンジニアリングでは、「システム」の説明はそのインターフェースの説明から始めるべきであるという事実がしばしば言及されます。 システムの概念がシステムエンジニアリングで何を意味するのかが明確ではないため、特にシステムの概念を紹介しません。オブジェクト、その構造、機能、または機能構造です。 ただし、メッセージは明確です。構造の完全な説明を作成する場合は、オブジェクトと外部環境の関係を説明してください。



設計の場合、これは設計モデルの一部ではないオブジェクトの空間位置です。



シナリオについて話している場合、外部の時間的および因果関係は外部環境とのリンクになります。 これらの接続は、スクリプトの操作の一方の端と操作の他方の端で「休止」します。これらはモデルにはありませんが、存在するという仮定があります。



機能構造について話している場合、境界機能は外部環境との接続になります。 それらは、外部の世界に向かう矢印の形で、IDEF0表記の図で見ることができます。



構造操作の方法論



マージ操作



2つの構造を結合する必要がある場合、このタスクはそのようには発生しません。 その背後にはニーズがあります。 この必要性は、構造記述の境界に達し、先に進みたいということです。 私たちが思い出すように、境界はコミュニケーションです。 説明には接続があるため、2つの構造のどちらの接続が共通であるかを指定するだけです。 したがって、あるデザインを別のデザインに適合させます。



疑問に思うかもしれません：なぜ結合は、構造がドッキングされるインターフェースですか？ これに共通のオブジェクトを使用することは可能ですか？ はい、ドッキングに使用するオブジェクトの種類は関係ありませんが、これらは両方の構造にあるものであり、それらを見ると、これは同じ要素であり、接続であろうとオブジェクトであろうと言えます。



2つの機能構造を結合する必要がある場合、共通の機能はそれらの間の結合として機能します。 組み合わせると、これらの一般的な機能を示すだけで、リンクが形成されます。 表記法の図では、IDEF0は矢印の結合です。

「矢印」や「機能」ではなく境界線を描くことは可能ですか？ デザインと同じ方法で-それは可能です。 これら2つの図に描かれているこれら2つの関数は、まったく同じ関数であると簡単に言うことができます。



2つのシナリオを結合する場合、それらの関係は一般的な時間的、または因果関係になります。 同様に、ドッキングは一般的な操作で実行できます。



減算と交差の方法論



モデルの作成者が構造の一部に集中したい場合、減算の必要性が生じます。 減算または交差の操作中、ルールは同じままですが、常識の観点から奇妙なことが起こる可能性があります。 たとえば、減算または交差の結果として、以下が残りとして残る場合があります。





上記のオブジェクトは構造と見なされますか？ 回答：オブジェクトとしてではなく、オブジェクトのセットとして見ると、それらは表示されます。 デザインは多くのオブジェクトであることを思い出させてください。 どのセットにも構図があります。 したがって、セットの構成は任意です。 デザインは多くのオブジェクトです。 このセットの構成は、何でも、または接続のみで構成される、直感に反する任意のものでもかまいません。



結論



結論：関係の定義により、構造を構成する要素のセットに、通常のセットの操作（加算、減算、交差）に類似した操作を導入できました。 これにより、シミュレーション領域の拡大または縮小に関連する問題のモデルの変換に正式にアプローチすることができました。


More articles:


All Articles