-どうやって？
-非常に簡単です！ エンサインはタスクを与えます：「今日はフェンスから昼食まで掘ります」
この記事では、定期的に発生し、批判的な分析をせずに情報モデルに迷い込む混乱の話を始めます。
前の記事で、タイプと属性を定義しました。 思い出させてください：
- タイプとは、ヒープ（セット）からヒープ（サブセット）を選択し、このヒープのオブジェクトに固有の名前（名詞）を付与することです。
- この属性は、ヒープ（セット）をヒープ（サブセット）に分割し、これらのヒープのオブジェクトにさまざまな形容詞を与えます。
これは、分析に基づくタイプ定義と属性定義でした-ヒープを部分に分割しました。 実際、分析を使用したタイプビルディングでした。 次に、合成に基づいてタイプと属性を作成する方法を示します。
多くのボート、多くのインフレータブルマットレス、多くの水上飛行機を利用して、それらを1つのセットにまとめて、たくさんの水泳用具を手に入れることができます。 そのため、いくつかのセットを合成することで多くのボートが得られます。
先ほど、「オブジェクト」タイプは推論できないと主張しました。 導出可能性とは、スーパーセットからサブセットを分離することです。 ただし、タイプ「オブジェクト」は合成できます。 これを行うには、新しい会計オブジェクトがオブジェクトのタイプに関連しているかどうかを判断する専門家が必要です。 このようにして、「オブジェクト」のタイプを合成できます。 合成は次の方法で実行できます。
- このタイプに関連するすべての会計オブジェクトのリスト
- このタイプに関連するすべてのタイプのアカウンティングオブジェクトのリスト。
属性でも同じことができます。 複数のヒープを取得し、それらに値を割り当て、それらを結合して、すべての属性と呼ぶことができます。
セットに対するすべての操作に一般化します：
- タイプは、セットオブジェクトの共通プロパティであり、これらのオブジェクトの共通名です。 さらに、セットの構成の識別は、任意の便利な方法で可能です。
- 属性はサブセットのセットであり、各サブセットは一意の属性値に対応しています。
山での操作は原始的すぎると言えます。 結局、グラフ、ロジック、代数などの抽象化を扱うことができます。 しかし、この背後にあるものを深く理解せずに新しい抽象概念を導入すると、すぐに混乱してしまいます。 同時に、数学者はツールを使用して論理的な誤りを犯しません。一方で、彼らは数学の基礎を研究することで教え込まれた推論の厳格な規律を順守します。モデル同士で。 さまざまな主題分野のモデルを構築する際に、必要な数学的装置を所有していないことがよくあります。たとえば、ヨルダンの尺度やスケーリングとは何かを知りませんが、同時に、さまざまなモデルを結合する最も複雑な問題を解決します。 たとえば、1つは波長で、もう1つは-電磁波の振動の周波数で、3つ目は「赤」などの言葉で表現されたモデルに簡単に出くわすことができます。 または、あるモデルの「コリー」が「犬」クラスの属性であり、別のモデルでは別のクラスのオブジェクトであることがあります。 もちろん、あるモデルから別のモデルへの変換を構築できます。 しかし、どのようにそれを行い、その背後にあるものは何ですか？
混乱しないように、簡単な方法を使用できます。遺伝レベルで私たち全員ができることに依存します。つまり、ヒープを部分に分割し、ヒープをまとめます。 したがって、型と属性に関する私の話は、とても素朴に思えましたが、この基盤に基づいてモデルを構築する方法を実証するという非常に重要な目標がありました。 数学者がそれらを導入したであろうように、タイプと属性の概念を導入しようとしましたが、アプリケーション主義者にとって理解可能な言語でした。
私が話している混乱を理解するには、簡単な質問をする必要があります。
- なぜ、3個のリンゴと4個のバスケットを掛け合わせた結果、12個のバスケットや12個のリンゴバスケットではなく、12個のリンゴになるのですか？
- 3アンペアに4ボルトを掛けると、12アンペアまたは12ボルトではなく12ワットになるのはなぜですか？
- 3メートル×4メートルで12平方メートルになるのはなぜですか？
- なぜパスカルはバーに入り、100,000パスカルがあるのを見るのですか？
- なぜ線形空間変換と線形基底変換のモデルはまったく同じように見えるのですか？行列の形で？ これらのアクションの物理的な意味は完全に異なりますか？
答えは簡単です。数学はモデリングツールにすぎません。 しかし、問題は：なぜですか？ 会計オブジェクトなどの会計オブジェクト、会計オブジェクトが属するクラス、または会計オブジェクトのモデル？ 数字、式、グラフなどを使用すると、簡単に混乱し、この簡単な質問に正確に答えることができなくなります。 会計オブジェクトのモデル、タイプのモデル、およびモデルのモデルが同じキャンバスに表示される場合、このキャンバスでの作業には細心の注意が必要です。 私の経験では、この場合はエラーが保証されることが示唆されています。
会計オブジェクトのモデルから始めましょう。 アカウンティングオブジェクトは、サブジェクトによって実世界の一部として割り当てられますが、まだ分類されておらず、たとえば4次元時空ボリュームなどの名前は付けられていません。 さらに、この会計オブジェクトは、メタモデルを使用して、被験者の意識のモデリング段階を通過します。 メタモデルは、モデル化の方法に関する個人の見解です。 たとえば、私たち全員にとって共通の考え方は、オブジェクトがあり、オブジェクトによって実行されるアクションがあり、オブジェクトのタイプ、オブジェクトによって実行されるアクションのタイプ、およびプロパティがあるということです。 このメタモデルは、アリストテレスによって注目され、説明されました。 未回答の質問は1つだけでした。木に属性「高さ」があり、建物に属性「高さ」がある場合、これは同じ属性ですか、これらの異なる属性ですか。 アリストテレスがこの主題についてどのように考えていたかはわかりませんが、この点に関して私たちが考えていることは知っています。それはすべて主題の視点と解決すべき課題に依存します。それは1つの属性であるか、異なる属性があります。
アリストテレスが気づいたメタモデルには、私たちの意識が機能していることに基づいて、厳しい制限があります。 これは、モデルを表現する言語が、完全性と簡潔性の間でバランスをとっているという事実によるものです。 言語が完全である場合、この言語の声明は非常に重くなり、現実の世界では人は生き残れません。 言語が簡潔である場合、すべての場面に適用できるわけではない狭い専門的なコンテキスト言語になります。 ユニバーサル言語はこれらの両極端の間にあるため、完全でも簡潔でもありません。
数学者はメタモデルの限界に直面し、それに基づいて私たちは心の中でモデルを構築し、これらの欠点のない独自のメタモデルを開発しようとしました。 このメタモデルは、オブジェクトとセットで構成されています。 このメタモデルの利点は、一貫性のある拡張可能なモデルを構築できることです。 欠点は、このメタモデルを使用して構築されたモデルが通常の人間の言語に翻訳されず、扱いにくいことです。
セットおよびオブジェクト上に構築されたモデリング標準がある場合、この標準を使用すると、タイプがセットでモデル化され、属性がセットのセットでモデル化され、モデル自体が無制限に拡張できるモデルを構築できます。 しかし、これまでのところ、そのような標準はありません。 おそらく、このメタモデルに基づいて構築されたモデルはボリュームが非常にふさふさしていることでしょう。モデルの各属性値に対して個別のオブジェクトクラスを作成する必要があるためです。 そのような標準を作成する過程で、型と属性を考える習慣に制約される可能性があります。 いずれにせよ、まだそのような標準はなく、これは悪いことです。 モデリングの理論の面で悪い。
実際には、既存のモデリング標準は、同時に2つの椅子に座り、同時にタイプ、セット、属性をモデリングしようとします。
そのため、OOPのモデリングタイプには「クラス」が使用されます。 それらは、それらに組み込まれた一連の属性によってモデル化されます。 このタイプのオブジェクトの名前を指定することもできます。 しかし、OOPでタイプを記述するための情報はこれ以上ありません。
OOPで属性をモデル化するために、これらの「クラス」の属性が作成されます。 OOPで複数のタイプのオブジェクトに共通の属性をモデル化する必要がある場合、このためには、これらのタイプのオブジェクトをモデル化する「heirs」を空の「スーパークラス」を作成する必要があります。 複数の遺産なしではできないことは明らかです。
OOPでは、たとえば、このタイプのオブジェクトの固有の機能を示すために、タイプの他のプロパティをモデル化する必要があるとします。 これを行うには、チートすることができます。 オブジェクトがタイプである「クラス」、つまり「インスタンス」がオブジェクトタイプであるタイプの「クラス」を作成できます。 したがって、2つのオブジェクトがモデルに同時に表示され、1つのタイプをモデリングします。オブジェクトの「クラス」と、タイプの「クラス」の関連する「インスタンス」です。 同時に、OOPには、このモデルの整合性を維持するための通常のメカニズムはありません。 これで、モデルの整合性はプログラマーの精度に依存します。
多くをシミュレートする必要がある場合、OOPはさまざまな方法を使用します：リスト、コレクションなど。 しかし、このシミュレーションはセットの構成にすぎません。 OOPの標準メソッドとセットの操作を使用してセット自体をモデル化することは不可能です。 セットモデルを作成するには、セットの「インスタンス」がセットをモデル化するセットの「クラス」を作成する必要があります。 コレクションとそれに関連付けられたこのオブジェクトは、1つのオブジェクト（セット）を一緒にモデル化します。 繰り返しになりますが、モデルの整合性はプログラマーの手に委ねられています。
型とオブジェクトの混乱
プログラマは、オブジェクトタイプモデリングとオブジェクトモデリングは同じものだと考えることがよくあります。 たとえば、OOPのクラスは何らかの理由で頑固にオブジェクト（たとえば、カップ）と呼ばれ、オブジェクトの種類ではありません。何らかの理由で、オブジェクトは頑固に "カップのインスタンス"と呼ばれ、 "カップ"ではありません。 このため、標準はすでに衝突が埋め込まれた状態で生まれています。
有向グラフを使用してプロセスをモデル化できることを聞いたことがありますか？ 以下に例を示します。 有向グラフにはサイクルがある場合とない場合があります。 時間は常に前進し、後退することはできないため、一連の操作に関しては、一連の操作をモデル化したグラフにサイクルを含めることはできません。 この要件を満たすグラフは、ネットワークグラフと呼ばれます。 ただし、BPMN表記で作成されたモデルにはループが含まれる場合があります。 したがって、BPMN表記法では一連の操作ではなく、他の何かをモデリングしているという論理的な結論を出すことができます。 個人的には、これは私には明らかなように思えますが、これを理解しているプログラマはほとんどいません。 これに関する多くの例は、私の記事の議論で見つけることができます。
タイプとセットの混乱
別の混乱は、プログラマがオブジェクトのタイプとオブジェクトのセットを区別しないことが多いという事実から生じます。 たとえば、OOPのクラスはセットモデルであるという意見があります。 しかし、悲しいかな、これはオブジェクト型モデルですが、セットモデルではありません。 この混乱のため、オブジェクトとそれらの間の関係で構成される多くの構造要素をシミュレートする必要がある場合、プログラマーは合格します。 異なるタイプのオブジェクトがどのように1つのセットに分類されるかを想像するのは困難です。
これらは広範囲にわたる混乱の例でしたが、外出しないプログラマーの輪を超えています。 はるかに普及しているものがあります。 次の記事では、それらについて話をしようとします。