ビジネスインテリジェンスの聖杯を見つける

私が見ているものを歌う、または私が歌うものを見る？

新しいソフトウェアの開発におけるビジネスアナリストの主なタスクは、対象分野を研究し、受け取った情報をモデル（ドメインモデル）の形式で正式に記述することです。 アナリストは、自分が見ているものと見たいものを歌わなければなりません。 これを行うには、彼は彼の歌を実行する言語を持っている必要があります。 ただし、アナリストは常に適切な言語に精通しているわけではないため、多くの場合、他の言語を使用します。 これは、プロジェクト管理がサブジェクトエリアの観点からではなく、実装の観点から実行されるという事実に一部起因しています。 そして、アナリストは不幸になる可能性があります。彼は歌うために必要なものを見ることをやめ、使用する言語の語彙にある単語だけを見始めることができます。 他のすべては彼のために存在しなくなります。 次に、アナリストは、自分が見ているものを歌う代わりに、自分が歌っているものを見始めます。 私は言語に反対しているのではなく、これらの言語の不足から生じる分析分野を狭めることに反対しているとすぐに言わなければなりません。

何を覚えておく必要がありますか？

対象分野を研究および説明するには、アナリストは次のことを知っている必要があります。

• どう思う？
• 思考の結果をどのように構成しますか？ これを行うには、 FMの思考の結果を記録するのに適した形式言語を知っている必要があります。

結果を記録するために、アナリストは常にFMを使用する機会があるわけではないため、アナリストはこれも知っている必要があります。

• 他のモデリング言語が存在する知識の領域。 たとえば、SQLを使用して、テーブルを作成できます。 この言語の一部は、ERモデルに反映される場合があります。 UMLは、オブジェクトプログラミング言語で記述されたプログラムをシミュレートするように設計されています。
• ドメインモデリングタスクのフレームワーク内で他の目的のために作成された言語を使用する方法は？ これを行うには、アナリストがFMを別の言語にモックできる必要があります。 つまり、 FM言語で記述された特定の構成のシフトが、UMLなどの別の言語の構成でどのように発生するかを理解する必要があります。

未解決の問題

• FMとプログラミングで使用されるモデリング言語との間にはギャップがあります。
• 同時に、 FMのタイトルには応募者がいますが、まだ誰もが一般に認められているわけではありません。 大学のプログラムでは、このトピック専用のコースはありません。 それまでの間、トピックや質問はありません。

結果：



一般に、UML言語およびERモデルを使用して、制限なしにサブジェクト領域をモデル化することができます。 そのため、アナリストは、モデリング言語によって課せられた制限によりこれを正しく行うことができない場合でも、UMLまたはERでサブジェクト領域をシミュレートしようとします。



問題を理解している同じアナリストにとって、聖杯は、対象領域とプログラムコードの実装の両方を同時にシミュレートできるツールになります。 そのため、科学者は輪になって動き続け、新しいオントロジー標準を作成すると同時に、これらのオントロジーをサポートするプログラミング言語を作成します。 しかし、これまでのところ、ギャップは広くなっています。

歴史ツアー

ヨーロッパでは、アリストテレスが思考の結果をどのように構成するかという質問に最初に答えようとしました。 彼は私たちの意識がこのように働くと決めました：私たちが見るすべてのオブジェクト、私たちは特定のタイプに関係しています。 タイプは、アリストテレスによれば、このタイプのインスタンスを記述する属性のリストです。 各インスタンスは、これらの属性の順序付けられた値によってモデル内で表されます。 アリストテレスの仮定は、私たちの世界のオブジェクトの記録が元々データプレートの形式で実行されたという根拠に基づいて生まれました。 アリストテレスは絵を与えましたが、彼は私たちが現在持っている知識を持っていなかったので、タイプの彼の絵は別の財産によって補われるべきです。 この物件はまだ発表せず、あなたにお任せします。 このように：

• テーブルは、型とその型のインスタンスに関する知識の集まりです
• パラメータ文字列はタイプです
• パラメーター行のタイトルはパラメーターの名前です
• 値の文字列はこのタイプのインスタンスです
• 値文字列の値-このインスタンスの特定の属性

空のテーブルが表示され、タイプとその説明が目の前にある場合、完成したテーブルが表示され、タイプとその説明に加えて、このタイプの特定のインスタンスの説明が表示されます。 このような写真は、記事の冒頭に記載されています。



また、このようなテーブルに会います：







この表には何が示されていますか？ 質問への答えは2つの方法で与えることができます。 そして、両方とも真実です。 質問について考えさせてください：このテーブルは何をモデル化していますか？ そして、この表のデータは何を意味していますか？

同じ文の2つの異なる意味。

その結果、アリストテレスは私たちに用語を与えました：オブジェクトのタイプとオブジェクトのタイプのインスタンス。 インスタンスという用語を聞くとすぐに、型について話していることを意味します。 たとえば、「私は三銃士の本のコピーを持っている」ということわざがあります。 これは次のように解釈されます。「三銃士」という種類の本があり、この種類のオブジェクトの特定のインスタンス-特定の本があります。 この声明は、「The Three Musketeers」という本を持っています。 このステートメントは、次の2つの方法で解釈できます。

• 私が手に持っているオブジェクトにはプロパティがあると言えます。 オブジェクトのこのプロパティは、Three Musketeers（Intensional Context）というタイトルの本です
• 三銃士の本クラスのオブジェクト（要素）が私たちの前にあると言えます。 この声明は、拡張的な文脈について語っています。

アリストテレスの見解では、すべてのオブジェクトに特定のプロパティがある内包的コンテキストでのみ動作します。 このクラスの表現は、オントロジー標準MOFで修正されています。 ERモデルとOOPは両方ともこの標準に基づいて構築されています。 質問：オブジェクトをタイプするこの方法は、私たちがどう考え、どのように知識を構築するかのアイデアを本当に与えてくれますか？ これが正しいかどうかを理解するには、実験を行う必要があります。

従業員と実験

実験物理学の実験室の従業員のグループと、実験室の従業員が実施した一連の実験があるとします。 自問してみましょう：この主題分野をアリストテレスの論理の観点からどのようにモデル化するのでしょうか？ 最初に頭に浮かぶのは、各従業員が「実験」という記号、開始日、終了日を取得することです。これは、従業員が何時にどの実験で忙しいかを示します。 つまり、アリストテレスの論理では、実験は従業員のサインになります。 これは、「これはどのような従業員ですか？」という質問に答えることができることを意味します。「実験に参加した」。







従業員が一度に2つの実験に取り組み始めるまで正確に。 そうすると、従業員と実験の関係がすぐに多対多になるため、「実験」パラメーターを取得できなくなります。

この接続を記号でモデル化することはできなくなりました。 新しいタイプのエンティティ「接続」を作成する必要があります。これは、従業員と実験へのリンクを保存しますが、それ自体では何も意味しません。 そのようなオブジェクトは自然界には存在しません！







さらに、モデルが大幅に進歩しました。 ある時点までは2種類のエンティティで管理していましたが、従業員が一度に複数の実験に取り組むことができることが判明した時点で、これらのエンティティは少数であることがわかりました。 私たちの脳はそのように機能しません。 彼にとって、複数の実験に取り組んでいる1人または数人の従業員に違いはありません。 頭の中では、存在のモデルはこれから変わりません。 つまり、このクラスのモデルには制限があります。



おそらく、OOPは世界をどのようにモデル化するかという質問に対する答えを私たちに与えるでしょうか？ これを行うには、別の例を検討してください。 りんごの木、りんごの木の種類、およびそれらの成長領域をシミュレートしてみましょう。

リンゴの木とエリア

リンゴの木があり、それらの成長領域をモデル化する必要があるとします。 特定のリンゴの木はその地域について何も知ることができないことを思い出させてください。 彼らは成長の場所の座標のみを知っています。 範囲は、リンゴの木のクラスで、クラスのみで決定されます。 質問：OOPモデルのどのオブジェクトがArealパラメーターの値を格納しますか？ OOPでは、これをさまざまな方法で行うことができます。

最初の実装オプション

Apple Treeクラスで静的変数を作成できます。 この変数はどういう意味ですか？ この変数は、このクラスのオブジェクト用に作成されます。 質問：これはクラス変数ですか、それともクラスオブジェクトですか？ 論理的には、変数の値がクラスのオブジェクトにアクセスできる場合、これはオブジェクトのクラスではなく、クラスのオブジェクトの変数です！ つまり、静的変数を作成しても、クラス変数を作成する問題は解決されません。 したがって、タスクを実装する2番目の方法に進みます。

2番目の実装オプション

クラス「リンゴの木のサブクラス」を作成し、パラメータ「エリア」を宣言します。 Apple Tree SubclassesクラスのオブジェクトであるApple Tree Classオブジェクトには、Arealパラメーターの値が含まれます。 「Apple tree subclasses」クラスの「Apple tree list」パラメーターを追加します。 次に、オブジェクト「リンゴの木のクラス」には、クラス「リンゴの木」のオブジェクトへのリンクのリストがあります。 新しい構造のおかげで、今何ができるでしょうか？ 「Grushovka」と呼ばれるクラス「Apple tree subclasses」の新しいオブジェクトを作成し、このオブジェクトに「apple tree」クラスのオブジェクトのリストを関連付けます。これを梨の木としてマークする必要があります。 したがって、リンゴの木のサブクラス-ナシのクラスを設計し、リストに必要な操作を追加することで、クラスオブジェクトだけでなくクラスを操作できます。 これにより、さまざまな種類のリンゴの木の生息地の交差点とそれらの関連を調査する機会が得られます。 このアプローチの何が問題になっていますか？

何が悪いの？

• まず、OOPがオブジェクトクラスを操作できるという仮説を立てながら、「Apple Tree Class」オブジェクトを手動で作成しました。 ただし、OOPには、クラスではなくクラスオブジェクトを操作するための組み込みメカニズムがあります。 つまり、クラスを宣言すると、実際にはクラス自体ではなく、このクラスのオブジェクトを記述していることになります！ オブジェクトのクラスには、交差、結合などの標準操作があります。 OOPにこのような操作を実装するための組み込みメカニズムはありません。 それらを実装するには、手動でシミュレートする必要があります。 たとえば、リンゴの木の場合、ナシをシミュレートするために、「アップルツリーサブクラス」という補助クラスを使用する必要がありました。
• 第二に、UML言語では、オブジェクト「リンゴの木のクラス」とクラス「リンゴの木」のオブジェクトの間に接続を描く方法がありません。 この関係は分類と呼ばれます。 OOPモデルにはありません。
• 第三に、UMLではオブジェクトを作成できず、オブジェクトを分類するだけです。 また、分類結果が私たちに合わなかった場合、オブジェクトを再分類することは不可能です。 これは、実際のドメインモデリングからのOOPの基本的な制限です。 この制限は、アリストテレスの論理の制限と同等です。

結論

• OOPタイプまたはクラスのカテゴリでのモデリングは、構築されたモデルが拡張可能でないという事実につながることを見ました。 つまり、成長のためにデータ構造を事前に構築する必要があります。そうしないと、既存の機能を壊さずに機能を拡張することができなくなります。
• アリストテレス論理の矛盾の分析は、集合論の発展につながった。 最初に、カントールが提案した原始理論、次に現代。 現代の集合論の公理の1つでは、用語集合は用語クラスに置き換えられ、それらの違いが強調されます。 しかし、これらは誰もが慣れているクラスではありません（OOPクラス）。
• 私たちが作成する世界のモデルは、通常、紙にテキストや表の形で書くものよりもはるかに豊かです。 既存のモデルを作成するときに意識がどのように機能し、どのように書かれるべきかを理解するために多くの努力が費やされました。

集合論がこれらのタスクをどのように処理するかを見てみましょう（続き） 。



PS古典的な記法でのドメインモデリングに反対していると思うかもしれません。 いいえ、考えて、これらの考えを伝え、正しい方法でモデルに反映できるようにしたいだけです。