会計の対象とその分類の結果（名詞）
思考実験をしましょう。 モデルの2つのリポジトリを想像してください。 車両のモデルを格納するクラスは1つのストアで作成され、車のモデルを別のストアに格納するクラスが作成されました。 クラスのオブジェクトとして1つのストレージに記述されているオブジェクトがウォータークラフトであり、2番目のオブジェクトにクラスのオブジェクトとして記述されているオブジェクトがあるとします。 これらのリポジトリを1つにマージすることがタスクであるとします。 これをどうやってやるの？
おそらく、ウォータークラフトのクラスのサブクラスでもある車のサブクラスを作成し、作成したサブクラスにモデルを追加して、車のクラスのモデルとウォータークラフトのクラスのモデルを削除します。 おそらく、船のクラスからオブジェクトを削除し、同時に車両のクラスのオブジェクトを船のクラスのオブジェクトにします。
あなたが何をするにしても、私は質問があります：あなたは今、シミュレートされたオブジェクトに何を命名しますか？ 船？ そして、後でこのオブジェクトが属する他のクラスが表示される場合は？ 名前をハイフンでリストして、「car-boat-alpha-omega」と言いますか？ アナリストにこの質問をすると、答えは次のようになります。これはまったく同じオブジェクトで、車と船の両方です。 文字通り、これは車と船舶の両方として同時に分類できる会計オブジェクトがあることを意味します。 このことから、私たちは車やボートをモデル化するのではなく、オブジェクトを計測することになります！
- 倉庫でのオブジェクトの作成は、会計オブジェクトのシミュレーションです
- 作成されたオブジェクトをクラスに入れることは、その分類です。
これらの2つの異なる操作は通常同時に実行されるため、区別されません。 このため、実際には会計の対象ですが、車やボートをモデル化しているという感覚があります。 私たちの言語はこの混乱の一因となっています。
ステートメントを比較します。
- これは木です
- これは、ツリーとして分類される会計項目です。
2番目のステートメントは正しいですが、実際には長すぎます。
OOPはこの混乱の結果を継承し、オブジェクトモデルを作成する操作とその分類を区別することはできません。 そのため、アナリストは、対象領域のモデリングは、会計対象ではなく、機械とボートをシミュレートすることであると考えることがよくあります。
この意味で、OWL標準はより正確です。なぜなら、その中に会計オブジェクトの未分類モデルを作成できるからです。 これにより、会計オブジェクトをモデル化する操作とその分類の操作を分離できます。
会計の対象とその分類の結果（形容詞）
車が赤であると言うとき、車には黒、赤などの特性があると仮定します。 しかし、マシンは本当にプロパティを持つことができますか？
思考実験を続けます。 先ほど調べた2つのストレージに同じ名前の属性があるとします。車には色の属性があり、ボートには色の属性があります。 ある店舗では赤い車として、別の店舗では赤い船として説明したオブジェクトがあるとします。 これらのリポジトリを1つにまとめるのがタスクになります。 あなたは何をしますか？
以前は、オブジェクトをシミュレートするために、車とボートのサブクラスを作成しました。 次に、タスクは2色ではなく1色をシミュレートすることです。 これを行うには多くの方法があります。
おそらく、車のクラスとボートのクラスに対して1つのスーパークラスを作成し、属性の色を作成します。 ビークルおよびボートクラスの場合、スーパークラスから継承される色属性を作成します。 次に、新しいビジョンに合わせてすべてのオブジェクトを作り直します。
おそらく、インターフェイス「色」を定義し、このインターフェイスを各クラスに実装します。
何をするにしても、結果の「色」属性は車にも船にも属さないことを理解することが重要です。 これらのクラスの外部に存在するものです。 属性はタイプに関連付けられていないため、これは正しいです。 属性は、多くのオブジェクトをタイプとは異なる方法でサブセットに分割する方法です。 私は以前の記事でこのことについて書いたtype属性を設定します明らかです。
。
したがって、厳密には、オブジェクトに属するプロパティについて話すことはできません。たとえば、次のように、タイプやオブジェクトに関係なくプロパティについて話す必要があります：
アカウンティングオブジェクトは、赤いオブジェクトのクラス、つまり分類に割り当てられます。
私はこの種の発言を正しく行っていますが、実際、この方法で話すのは費用がかかりすぎます。 その理由は言語です。 情報を別のエンティティに転送するとき、実行される作業量を減らすよう努めます。 ステートメントを比較します。
- 赤い車
- 会計オブジェクトは、車のクラスと赤のオブジェクトのクラスに属します
どの場合、あなたはより少ない仕事をしましたか？ もちろん、最初に。 しかし、このステートメントの問題は、属性が型に属し、属性値が分類されたオブジェクトに属すると考えるようになることです。
OOPはこの誤解を受け継いでいます。 OOPを使用すると、クラスとは別に属性を作成できません（ただし、インターフェイスを使用できます）。 繰り返しになりますが、OWLは私たちを支援します。この標準では、型と属性は互いに別々に存在します。 したがって、OWLで2つのモデルをマージする場合、OOPで行う必要があるほど多くの作業を行う必要はありません。 マージするには、2つの属性を同等に等しく宣言するだけです。
分類プロセスの意味
モデルのリポジトリが2つあるとします。 ある店舗には、楽器の販売業務のモデルが保存されています。 別のストアでは、楽器を購入するための操作のモデルが保存されます。 1つの店舗で、エグゼキュータがマルティノフである販売オペレーションとして分類された1つのオペレーションがあり、別のストアで、エグゼキュータがガブリロフである購入オペレーションとしても分類されているとします。 2つのストレージを結合するプロセスでのタスクは、これらのモデルを1つに結合することです。 質問：ユニファイドストレージでこの操作のモデルを提示する方法は？
急いで、「販売と購入」と呼ばれる操作をシミュレートする新しいモデルを作成することになりました。これは、マルティノフとガブリロフによって実行されます。 しかし、疑問が生じます：マーティノフのパフォーマーはどこに行ったのですか？ガブリロフのパフォーマーはどこに行ったのですか？ 新しいモデルでは、操作は目的を持つべきアクションであるため、この情報は失われ、衝突さえ発生しました。 販売には目標があります-より高価に販売すること、そしてマルティノフはそれのために働きました。 購入には目標があります-より安く購入すること、そしてガブリロフはそれのために働きました。 また、利害関係者がいないため、販売には目標がありません。 結合される前にリポジトリにあった情報を保存し、衝突を回避し、同時に操作モデルを結合する方法は？
これを行うには、自動車で行ったのと同じことを行う必要があります。 会計オブジェクトのモデルを作成し、それを2つの異なるクラスに同時に割り当てる必要があります。販売オペレーションのクラスと購入オペレーションのクラスです。 さまざまなクラスに1つの属性「executor」があり、その値は、検討するクラス（購入のクラス、または販売のクラス）に依存します。 これは予想外のことです。1つのアカウンティングオブジェクトの属性の値は、アカウンティングオブジェクトをどのように分類したかに依存する可能性があります。
奇妙に思えますが、ここでは驚くべきことは何もありません。 人によって、同じオブジェクトを異なる方法で分類できます。 誰かがこれが車だと信じており、誰かがこれが船だと信じています。 ある人にとっては販売操作であり、ある人にとっては購入操作です。 現在、分類の意味が明確にされています。 会計オブジェクトの分類は、会計オブジェクトに関する特定の観点の表現です。 車はありませんが、会計オブジェクトと、この会計オブジェクトを車として扱うサブジェクトがあります。 販売操作はありません。会計オブジェクトを販売操作として扱うサブジェクトがあります。
属性値には同じ意味があります。 アカウンティングオブジェクトと、このアカウンティングオブジェクトを特定のクラスの属性値に属するものとして扱うサブジェクトがあります。
したがって、車と船舶に関する論文を明確にする必要があります。
- Ivanovの観点からの会計オブジェクトは、ウォータークラフトとして分類されます。
- シドロフの観点からは、同じ会計オブジェクトが船舶のクラスに割り当てられます。
- イワノフとシドロフの観点から、同じオブジェクトは赤いオブジェクトとして分類されます。
このオブジェクトの説明を行った主題に言及せずに、会計のオブジェクトについて何かを言うことは意味がありません。 当たり前のようですが、何らかの理由で、アナリストはそれを忘れています。
OWLを使用する方法を学習するには、アカウントにさまざまな視点を取るストアを構築することができ、資料に記載： 多視点オントロジーを意思決定、それはサポートの仕組みため 。
結論
ドメインモデリングは、分類による会計オブジェクトのモデリングです。 分類は常に主観的であるため、分類を実施した被験者の表示が必要です。