構造分類：例と誤解

これは、モデル分類サイクルの最終記事です。 この記事では、デザインを分類します。 イラストがないことをおmustびしなければなりませんが、それは起こりました。 したがって、今日は単なるテキストです。 この記事は以前の記事に基づいていることを警告する必要があります。これは、オブジェクト、操作、および機能が異なる解釈のみを持つオブジェクトであることを詳細に説明しています。

規約

「一部があります」という用語から始めましょう。 日常生活では、次の声明に出会います。象-哺乳類の一部です。 多くの象が多くの哺乳類のサブセットであるという事実について話している。 この記事では、「一部があります」という用語を異なる意味で使用します。 この用語は、特定のオブジェクトに関連してのみ使用します。 たとえば、特定のツリーブランチは特定のツリーの一部です。 概念に定義を与えるときのように、木の枝について話していると考える必要はありません。木の枝は木の一部です。 数学的論理の観点では、このステートメントは次のようになります。ツリーブランチには、このブランチがこのツリーの一部であるようなツリーがあります。 このようなステートメントは、特定のオブジェクトを指すのではなく、オブジェクトを定義する概念を指すようになりました。 記事でそう言う必要がある場合は、明示的に言います。 それ以外の場合は、特定のオブジェクトについて説明します。



次の用語が含まれます。 ツリーにブランチが含まれると言う場合、特定のブランチが特定のツリーの一部であることを意味します。 そして、我々はまだ特定のオブジェクトについて話しているのであって、セットや概念について話しているわけではありません。



対処が少し難しいもう1つの用語。 この用語は「からなる」という用語は「含む」という用語に近いようですが、それらを区別します。 ツリーは、枝、幹、根で構成されていると言います。 同時に、ツリーの構造を完全に把握できるように、ツリーの一部が完全にリストされていることを意味します。 つまり、「からなる」という用語は、オブジェクトの構造（構造）に関連して使用されます。 これらのオブジェクトの一部を取得する場合、これらのサブオブジェクトで構成されるオーバーオブジェクトは機能しない（何かが欠落している）と言います。 したがって、そのような階層は正しい：スーパーオブジェクト、スーパーオブジェクトの構成、その要素はサブオブジェクトであり、その要素はサブオブジェクトであり、サブオブジェクトはスーパーオブジェクトの一部であり、スーパーオブジェクトの構成の要素である。

設計パラダイム

1つのオーバーオブジェクトは、異なるデザインの形で表すことができます。 オーバーオブジェクトは、異なる分割の原則（異なる根拠）に従って部分に分割できます。 空間の部分のコンパクトさを保持する分割の原則があります-空間分割。 例：建物は施設で構成されています。 「建物は施設で構成されている」という論文は次のステートメントと同等であることを思い出させてください。 別の基礎は機能的です。 例：建物は、建物のエンベロープ、屋根、およびエンジニアリングサブシステムで構成されています。 言い換えれば、スーパーオブジェクトを分割するための基礎は構築パラダイムであると言えます。



人体の構造は、多くの場合、2つのパラダイムで考慮されます。1つは人間の外部構造と呼ばれ、2つ目は内部構造です。 外部構造は、人体の一部、腕、脚、頭、体を表します。 内部構造は、循環系、消化器系、神経系など、人間のサブシステムを記述しています。 外部構造は、建物を部屋に空間分割することに相当します。 内部構造は、建物をサブシステムに機能分割することに相当します。

構造分類

通常、構造を単純に考えます。ここにサブオブジェクト、サブオブジェクト、サブオブジェクト間の関係があります。これらはサブオブジェクトのプロパティを説明します。 構造要素の分類を通じて構造を分類します。

構造要素はオブジェクトと同じクラスに属します

要素がオーバーオブジェクトと同じクラスに属する構造を考えてください。 たとえば、水は部分で構成され、各部分も水です。 または砂の山、その要素も砂の山です。 オブジェクトがこのように分割されている場合、多くの場合、そのためのメジャーを導入できます。 これはそのような構造の特徴です。 たとえば、オブジェクトの質量はその部分の質量の合計に等しく、図の面積はその部分の面積の合計に等しく、物質の体積はその部分の体積の合計に等しいなどです。 それほど明白でない例を考えてみましょう。 操作とその部分、つまり副操作があります。 その場合、メジャーは4次元のボリュームになります。 例：人が4時間手術を行った。 操作の量は4人時です。 操作を4つのサブ操作に分割します。 各サブオペレーションには、1人時のボリュームが必要です。 したがって、サブオペレーションのボリュームの合計は、オーバーオペレーションのボリュームに等しくなります。

誤解

ここでの多くは間違いを犯すことに注意し、操作の概念について話したと思います。 いいえ、この文脈では、2016年4月12日の12-00から16-00にVasilievによってコミットされた具体的な操作でした。 操作の概念について話すと、その概念が4時間続くとは言えません。 このタイプの操作は平均4時間続くと言えます。 私はよく（主要なアナリストからでも）このトピックに関する誤った記述を聞きます。 彼らは、BPMN表記で長方形として指定した操作は4時間続くと言います。 ただし、BPMN表記は操作をモデル化せず、操作の概念をモデル化します。 したがって、この表記では、特定の操作がどれだけ続くかを言うことはできません。 BPMN表記で作成されたオブジェクトのプロパティには、このタイプの操作の平均期間という属性がありますが、操作の期間という属性はありません。 これはまさにBusinessstudioで行われたものです。 EPC表記または表記で作成されたオブジェクトのプロパティでは、特定のタイプの操作の継続時間の分布を指定できます。 そしてこれは本当です。

最初のタイプの構造の例

そのような構造の例：家を建てる操作は、家を建てるネットワーク図で観察する操作で構成される構造の形で提示されます。 IDEF0表記の図は、関数で構成される関数構造をモデル化しています。



間違った例：BPMNダイアグラムでは、サブプロセスは操作構造であると考えるかもしれませんが、そうではありません。 BPMNダイアグラムには操作モデルはありません。 操作の概念モデルがあります。 概念の定義に非常によく似ているため、同じです。 BPMNのボックスは操作をモデル化するのではなく、操作の概念をモデル化します。 BPMN表記の図は、オブジェクトモデルではなく概念モデルです。

要素が同じクラスに属する構築クラス。

この種の構造は、あるクラスに属する要素で構成され、スーパーオブジェクトは別のクラスに属します。



たとえば、特定のブースは4つの特定のボードで構成されています。 ブースのボリュームがボードのボリュームの合計と等しくないことは明らかであるため、メジャーを導入することはできません。 アクティビティの説明の例：操作は参加者で構成されています。 参加者は物質的または機能的なオブジェクトとして認識しますが、操作としては認識しません。 この場合、BPMN表記でモデルを見つけることができる操作の概念についてではなく、ガントチャートでモデルを見つけることができる操作について話していることを強調しておきます。 たとえば、2011年5月13日9時00分に行われた「ハンマーネイル」操作の参加者は、シドロフ、ハンマー、ネイル、2枚のボード、スツール、ランプ、テーブル、部屋でした。



BPMN表記で作成されたオブジェクトについて誰かがこのようなことを言おうとすると、次のように聞こえます。BPMN表記でモデル（タイプ）が表示されるこのタイプのすべての操作には、以下のタイプの参加者がいます。 「ハンマーネイル」タイプの各操作には、「パフォーマー」、「ネイル」、および「ハンマー」タイプのオブジェクトが含まれます。 確かに、例外があります。 たとえば、操作の種類を決定する際に、参加者の種類ではなく、特定のリソースのモデルへのリンクを見つけることができます。 次に、このタイプの操作では、参加者は特定のオブジェクトであり、特定のオブジェクトではなく、たとえば、「建物の建設の承認を得る」クラスの各操作では、参加者が示されているという事実について話している：モスクワ市の管理（オブジェクト）。

すべての構築オブジェクトは異なるクラスに属します。

次のケースが最も一般的です。上下のオブジェクトは異なるクラスに属します。 たとえば、トランスはコアと2つの巻線で構成されます。 アクティビティの説明に適用されるように、パフォーマーが異なるクラスに属しているという事実の文脈で前の例を考慮することができます。 シドロフ-人々へ、ハンマー-道具へ、そして爪-材料へ。 それはすべて、オブジェクトの分類方法に依存します。

要素をリストせずに構造の説明

次のケースはより複雑です。 要素の列挙がない構造について話しているが、構造を構成するオブジェクトのタイプについて言及している。 たとえば、建物はレンガで構成されています。 コンクリートの建物は、「レンガ」タイプのオブジェクトで構成されています。 特定のブリックの列挙はありませんが、これらのオブジェクトが属するタイプの表示があります。 このような構造のモデリングは、現代のモデリング言語ではかなり困難です。 実際、そのようなステートメントをモデル化するには、2次述語が必要です。 しかし、2次述語のモデル化のために研ぎ澄まされる言語はありません。 これは、1次述語で作成されたモデルが計算可能であれば、2次述語で作成されたモデルは計算できないためです。 つまり、1次述語に記録された事実に基づいて、明確な結論を導き出すことができます。 モデルが2次述語で構築されている場合、ある程度の確率でしか結論を出すことができません。 たとえば、森林がアスペン60％とシラカバ30％（残りの木は他の種に属している）であると言えば、この森林で任意に取られた木の種については、ある程度の確率でのみ確認できます。



IPを作成すると、特定の操作を自動化するタスクが設定されます。 ほとんどの場合、これらは決定論的操作であり、確率的結果の場所はありません。 ほとんどのプログラマーはそのような問題を正確に解決します。 したがって、一次述語、特にOOPのモデリングのために、すべてのツールが強化されています。 したがって、2次述語をモデル化する必要がある場合、OOPは対応しません。

例

このようなケースは非常にまれであると思うかもしれませんが、企業の活動をモデル化することは、オブジェクト間のこの種の関係のモデル化に直接関係しています。 たとえば、ビジネス機能の構築をモデル化します。 その構築を表す一般的な方法は3つあります（構築パラダイム）。 最初の方法は上記で言及されました-過剰機能は、サブ機能からなる構成体として表されます（IDEF0表記）。 2番目の方法-関数の構築は、その参加者のセットで構成されます（たとえば、販売関数は売り手、潜在的な買い手、および製品で構成されます）。 このタイプの構造は、下の正方形に表示される矢印を使用して、IDEF0表記でモデル化されます。 3番目のタイプの構造は、現在のケースに対応します。関数は特定のタイプの操作で構成されます。 たとえば、販売機能は商品の販売操作で構成されます。 機能はオブジェクトであり、操作はオブジェクトです。 販売オペレーション-同じタイプのオブジェクト。 つまり、建物がレンガで構成されているというテーゼは、テーゼに似ています。機能は特定のタイプの操作で構成されています。 そのようなステートメントをモデル化する言語はありません。 私が言ったように、理由はこのステートメントが二次述語にあるからです。 この種のステートメントの別の例：結晶は原子で構成されています。 結晶との類推を通じて、構造の記述に関連して理解するのが最も難しいケースに進みます。

異なるタイプのオブジェクトを含むセルの設計

クリスタルがあります。 これまで、構造要素間の関係を構築の一部として考慮していませんでした。 これからは、接続が必要になります。 オブジェクトをパーツに分割するには、要素間の関係の説明が必要であることは明らかです。 列挙された要素で分割する場合、要素間のすべての関係をリストできます。 ただし、すべての要素をリストせずに同じタイプのオブジェクトに分割すると、構造要素間の関係をどのように記述するかという疑問が生じます。 たとえば、建物では、ほとんどのレンガは石積みモルタルを介して他のレンガと接続されています。 次に、建物はレンガで構成され、各レンガは隣接するレンガと接続していると言います。 同時に、ブリックの5％には5個の隣人が、30％には4個の隣人が、5％には3個の隣人が、5％には2個の隣人がいます。 したがって、最初のグループから選択したレンガには、建物の一部であり、石積みモルタルを介して選択したレンガに接続されている5つのレンガがあります。 ここで、ビジネス機能に関する同じステートメントを記述します。 販売機能は、販売業務で構成されます。 操作が次々に続くと仮定します。 次に、すべての操作について、その前に同じタイプの操作があり、それに続いて同じタイプの操作があると言えます。 そのため、設計では接続のタ​​イプをモデル化しました。これは、オブジェクトではなくオブジェクトのタイプによって記述されます。 ここで、より複雑な構造の結晶を想像してください。この結晶では、さまざまな元素の原子が関与し、複雑な結晶格子に配置されています。 そのような結晶の構造をどのように説明しますか？ 結晶の記述と分類に携わる人は、この種の格子を記述する方法は無限にあることを知っています。 たとえば、2つの異なるタイプAとBの原子の1次元チェーンがあり、1オングストロームの増分で互いに交互になっているとします。 結晶はセルで構成され、各セルは1オングストロームのA型とB型の原子で構成され、セル間のシフトは2オングストロームであると言えます。 （結晶が3オングストロームに位置するタイプAおよびBの原子で構成されるセルで構成されることも事実です。セル間のシフトは2オングストロームであり、セルは空間で交差します。そのような規則的な構造はそれぞれ、結晶のX線回折パターンに表示されますオプションの数を制限するには、通常、最も近い間隔の原子を使用します）。 一方、結晶はAとBの2種類の原子で構成されていると言えます。この記述は前のものと似ていますが、最初の場合は結晶構造がセルで構成され、セル構造が原子から。 2番目の場合、結晶構造は直接原子で構成されます。 別の例：販売機能で、条件の合意と商品の出荷の2種類の操作を実行します。 関数はセルで構成されていると言えます。各セルには、条件に同意する操作と、商品を出荷する操作があります。 そして、我々は言うことができます：機能は、商品の出荷のための条件と操作に同意する操作で構成されています。 これらは2つの異なるステートメントです。

典型的なセル内の要素のシーケンスの選択

操作のシーケンスを見てみましょう：ABABAWAV ...チェーンは無限であり、どこからでもセルの選択を開始できることがわかります。 たとえば、最初にフェニックスの鳥は灰から生まれ、次に燃やされ、それから灰から生まれ、そして燃やされました。 または：まず、フェニックスの鳥が燃え尽きて、それが灰から生まれ、それから再び燃え尽きました。 セルはどこからでも開始できます。 したがって、開始する理由を得るために、セルのすべての操作で満たされる条件が選択されます。 たとえば、すべてのトランザクションは1つのトランザクションに関連しています。 条件は任意であり、一般的な場合、セルは任意のタイプの操作で開始できます。 アナリストは通常​​これを知らず、セルの初期操作の選択を何らかの形で正当化するために、チェーンには神秘的な目的があるべきだという考えで催眠術をかけます。 チェーン内の操作を何らかの（一般的に任意の）基準に従ってグループにまとめることができると言う代わりに、アナリストは錬金術式を思いつきます。 さらに、この錬金術はプロセスの定義に存在します。

OWLを使用した2次述語モデリング

OWL Full標準では、オブジェクトとクラス（オブジェクトのセット）、さらにオブジェクト（述語）間に存在する可能性のあるタイプの関係でさえ、ステートメントでオブジェクトの役割を果たすことができるため、2次ステートメントをシミュレートできます。 OWLのこれらすべての種類のエンティティは、エッジが具体的なステートメントであるグラフのノードです。

OWLの形式で記述された2次ステートメントは、原則として、計算可能性（論理推論マシンを使用して結論を​​取得する可能性）を提供しません。 ただし、これを自動化システムの実装に対する障害とみなすべきではありません。 ほとんどの場合、OWLモデルの操作はアプリケーションプログラムコードで行われ、特定のタスクの機能と制限を考慮し、「すべてを計算する」ふりをしません。 実際には、一次ステートメントでも処理する場合でも、標準の論理的結論に完全に依存することは不可能です-大量のデータとさまざまなデータを使用する場合、そのようなタスクには大量のコンピューティングリソースが必要です。

OWLでクラスステートメントをモデル化する方法はいくつかあります。 最も実用的な方法の1つは、オブジェクトがクラスまたは述部に関するステートメントである特別なクラスを導入することです。 次に例を示します（標準に慣れていない人のために、自然言語で記述してください）。

• クラス「建物」があります
• 「ブリック」のクラスがあります
• 「オブジェクトの構成要件」というクラスがあります
• クラス「オブジェクトの構成要件」のクラスとクラスの間には、「クラスのオブジェクトを参照する」という関係があります。
• クラス「オブジェクトの構成の要件」のクラスとクラスの間には「構成が必要」という関係があります。
• 「オブジェクトの構成の要件」クラスに属するオブジェクトAがあり、次の関係があります。
• 要件A-オブジェクトを参照-クラス "Building"（このステートメントは述語として記述できます：オブジェクトを参照します（要件A、クラス "Building"））。
• 要件A-構成する必要がある-クラス「ブリック」

要件の機能を一般化することができます-「...オブジェクトの構成」という言葉をクラス名から削除し、それが参照する述語を含めます（クラス「要件」のリンクの中で）（「からなる」、「位置する」）。 同様に、クラス名からモダリティを除外することもできます（「must」、「may」など）。 その場合、クラスは「Requirement」ではなく「Statement」または「Axiom」と呼ばれます。 これにより、完全な第2レベルがモデルの構造に追加され、グラフの形式で表示されます。 形式主義のレベルの選択は、適用される問題のみに依存します。

自動化されたシステムは、たとえば次のようにして上記のステートメントを読み取り、解釈します。Brickクラスの少なくとも1つのオブジェクトが、Buildingクラスの各オブジェクトの構成に存在する必要があります。 コンクリートのレンガのレベルにまで下がる必要はありません。ステートメントを別の方法で解釈します。建物は基本的にBrickクラスのオブジェクト（これは不明）で構成されていると言います。 この場合、「レンガ」クラスに関する他のステートメントを使用できます。たとえば、レンガ（つまり、「レンガ」クラスのすべてのオブジェクト）には特定の密度、質量、熱伝導率などがあります。これにより、プログラムは建物の特性について結論を導き出すことができます。

いずれの場合でも、このロジック（「オブジェクトの構成の要件」のクラスのオブジェクトを要件として解釈する機能）をコードに埋め込む必要があります。これは、特定の適用問題を解決するフレームワークで許可されます。

少し異なる方法で行くことができます-述語の2番目の位置だけでなく、最初の位置にもクラスを配置する、つまり、クラスに関するステートメントを作成する：

• クラス「建物」があります
• 「ブリック」のクラスがあります
• クラスとクラスの間には「クラスオブジェクトのみを含むオブジェクトを含める必要があります」という関係（述語）があります。
• クラス「Building」-クラスのオブジェクトのみを含むオブジェクトを含める必要があります-クラス「Brick」

もちろん、この種のステートメントの解釈もアプリケーションソフトウェアに残っています。

クラスに関するいくつかのステートメントは、標準の論理推論マシンを使用してモデルの計算可能性を失うことなく、OWLのより厳密な形式のフレームワーク内でも作成できることに注意してください。 これは、プロパティ値の制限（カーディナリティ）を量指定子（一部、のみ、正確など）で使用することによって実現されます。この例を記述する別の方法は次のとおりです。

• クラス「建物」があります
• 「ブリック」のクラスがあります
• 「からなる」関係がある
• 「Building」クラスは匿名クラスのサブクラスです。「Consists of」接続の値が「Brick」クラスのオブジェクトであるオブジェクトについて

このステートメントをグラフに保存すると、いわゆる「空のノード」が形成されます。 この場合、空のノードは制限が指定されている匿名クラスになります。 OWL標準の意図によれば、空のノードは存在の量指定子を持つステートメントです。つまり、この場合、ブリックで構成されるオブジェクトがあるというステートメントです。 そのようなオブジェクトのサブクラスは建物です。

この設計はやや面倒であり、推論規則はアプリケーションで遅く気まぐれなので、実際には通常、最初の方法または2番目の方法を使用する方が簡単です。

これまで、「建物はレンガで構成されています」という文について議論してきましたが、その意味は論理的な観点からはあまり正確ではありません。 何を言いたかったのかは明確ではありません。

• レンガで構成されるものはすべて建物であり、
• 建物はレンガのみで作られるべきであり、
• 建物がレンガで構成されており、

などなど。 自動化システムを実装する場合、このようなセマンティックな「バックラッシュ」を排除する必要があります。 そのため、この記事の冒頭で、現在の記事の枠組みの中で使用する用語の定義をすぐに示しました。

混合デザイン

ツリーの構築に戻り、論文を見てみましょう。ツリーは、枝、幹、根で構成されています。 この論文は、ツリー構造がオブジェクト-トランクと2つの異なるタイプのオブジェクト-ブランチとルートで構成されることを示唆しています。

擬似構築の例

図がIDEF0表記で構築される一般的なケースを考えてください。 次に、この図の関数の1つは、BPMN表記の図に「分解」されるとよく​​言われます。 これは、前述のBusinessstudioプログラムにあります。 関数はサブジェクト領域のオブジェクトであり、BPMN表記の図は概念のモデルであるため、エラーが発生することがわかります。関数は概念に分割されます。 これはできません。 この機能は、操作によってセルに分割できます。 各セルには、一時的な接続によって相互接続されたいくつかの操作があります。 すべてのセルについて、同様のタイプのセルの概念が導入されています。 この概念はBPMN表記法でモデル化されています。 そうです。

2つの異なるパラダイムの構築相関

頻繁に遭遇するオブジェクトの記述方法は次のようになります。たとえば、「外部」および「内部」構造のパラダイムなど、2つの異なるパラダイムでオブジェクトを構築することを検討してください。 次に、オブジェクトを2つのまったく異なる方法に分割します。 たとえば、建物を一方で建物に、他方で技術サブシステムに分割します。 そして、ここで非常に重要な要素がトリガーされます。これは、原則として、気づいていませんが、直感のレベルで機能します。 オブジェクトを2つの異なるパラダイムの部分に分割し、2つの異なるパラダイムの構造要素間でも対応を確立できるようにします。 たとえば、建物を部屋とサブシステムに分割した後、敷地も部分に分割することができます-これらの部屋にあるサブシステムの部分。 つまり、2つの異なるパラダイムでの部分への分割は、直感的に互いに依存します。 そして、これは決して明らかではありません。 エンジニアリング設計の現代の標準は、オブジェクトのこの区分に基づいていますが、モデリングに関するこのような制限についての書面による要件はないと確信しています。