ただし、実際にはこの方法は機能しませんでした。 クラス、属性値、またはメソッドを使用して、希望に応じて同じ事実をモデル化できます。 これについては、書籍Business Objects：Re-Engineering for Re-useで Chriss Partridgeが詳しく説明しています 。
彼はコリーの例を挙げています。 オブジェクトのクラス、値タイプが文字列の「Breed」属性の値、または-ディレクトリ「Breeds」のオブジェクトへの参照、またはブール値属性「Collie」の値「yes」を指定できます。
Chriss Partridgeの例では、クラスと属性から選択します。 しかし、クラスまたはメソッドを使用してまったく同じ事実をモデル化できる代替手段があります。
たとえば、属性の値と、場合によってはメソッドを使用して、オブジェクトのクラスを使用して金メッキをモデル化できる状況を想像できます。
モデリング方法の選択は、情報モデルのコンテキストと境界に依存します。 ただし、遅かれ早かれ、情報システムの境界がボリュームに拡大する瞬間が訪れます。ある視点からの同じ事実を使用してモデル化する必要があるときです。 一方、クラスは、関数、操作、または属性値を使用します。 そして、これらの異なる視点間のマッピングは、アナリストにとって真の挑戦となります。
障害は、そのようなマッピングの技術的な複雑さだけでなく、想像力の限界でもあります。
- 私たちは世界の構造をモデリングしていると考えていますが、各主題には独自の世界があることが長く知られており、世界ではなく主題の世界のアイデアをモデリングしています。 最初の論文と2番目の論文の違いは、被験者が異なれば見ているため、同じものに対して異なる視点を持つことができるということです。
- 属性のタイプと値は完全に異なるものだと思いますが、それらはオブジェクトのグループを区別する異なる方法にすぎません。 その結果、たとえば、あるクラスでは個別のクラスを使用して、別のクラスではリテラル値を使用して、第3のクラスでは参照への参照を使用して色をモデル化する場合、データ統合のタスクにほとんど対処できません。
- 3次元オブジェクトは簡単に想像できますが、操作とそのシーケンスはほとんど想像できませんが、オブジェクトを操作として、または操作をオブジェクトとして想像することはできません。 その結果、オブジェクトを操作に分解したり、一連の操作として機能を表すなどのアクションは与えられません。
これについては以前に書きました。 しかし、モデリングを開始する前に、自分自身に尋ねなければならないもう1つの重要な質問があります。 どのタイプのモデルを構築するのかを知る必要があります。 最近、私は論文を聞いた：モデルのモデルはモデルでもある（モデルの推移性の特性が言及された）。 たとえば、契約モデルであるドキュメント「Agreement」がある場合、この契約をモデル化するWordファイルも契約モデルです。 秘Theは、この論文が1つのタイプのモデル（オブジェクトモデル）にのみ当てはまるということです。 別のタイプのモデル-概念モデル-では、この論文は正しくありません。 2つを区別するものはほとんどありません。 そのため、プレゼンテーションのメインラインから少し離れて、アナリストが使用するモデルの種類について話すことにしました。
モデル分類
まず、通常モデルと呼ばれるもの。 モデルとは、情報オブジェクトを意味します。 被験者が別の被験者に、現実世界の何らかの物体についての彼の考えを伝えることにしたと仮定します。 これを行うには、記法（言語）を使用して、このオブジェクトを情報オブジェクトとして提示することを説明します。 この情報オブジェクトは別の主題の手に落ち、その表記法を知っていれば、彼の頭の中の最初の主題の概念を再現します。 これは、ある科目から別の科目への知識の伝達であり、したがって言語は学習において非常に重要な役割を果たします。
厳密に言えば、モデルは対象が念頭に置いているものであり、情報オブジェクトはこのモデルのモデルです。 しかし、モデルの推移性により、情報オブジェクトもモデルであると考えられています。 この情報オブジェクトは、必要に応じて継続的に調整および修正できます。これは、あるサブジェクトが別のサブジェクトに何かを説明するときに発生します。
さまざまなタスクのサブジェクトが同様のオブジェクトに遭遇するとします。 たとえば、同様の詳細。 その後、異なる詳細については、彼は同様のモデルを取得できます。 ある時点で、アナリストがそれに含まれ、このアナリストはモデルの統合を必要とします。 一度作業してモデリングの時間を節約するには、統合が必要です。
統一とは、アナリストがすべての同様の詳細に対して1つのモデルを作成することです。 これが詳細の概念です。 パーツモデルとの違いは、パーツモデルを無限に洗練できることですが、コンセプトは1つではなく多くのパーツを参照するため、無限に洗練することはできません。 詳細は互いに異なるため、概念を無期限に改良する方法はありません。
概念からオブジェクトモデルを再構築することは可能ですか？ 可能ですが、推測の助けを借りて。 オブジェクトのモデルに概念を簡単に思い付きます。 ただし、これを簡単に行うことは、概念モデルがオブジェクトモデルであることを意味するものではありません。 概念に基づいてオブジェクトモデルを復元するには、概念モデルをオブジェクトモデルに補完するコンテキストが必要です。
ここで、タスクを複雑にし、サブジェクトが構造をモデル化すると仮定します。 デザインとは、オブジェクトとそれらの間のつながりの集合であることを思い出させてください。 明らかに、構築モデルは、オブジェクトのモデルと同様に、無期限に指定できます。
ここで、部品の場合のように、被験者が類似の構造、たとえばディーゼル機関車の設計をモデル化するタスクを持っていると仮定します。 最初のケースと同じように振る舞うと、被験者はモデルを統一し、多くのデザイン用にモデルを作成することができます-デザインコンセプト。
建設の概念は、多くの概念-オブジェクトの概念-構造要素とこれらの要素間の関係の概念で構成されています。 次の記述は、ディーゼル機関車の設計コンセプトに当てはまります。設計コンセプトの各要素について、実際のディーゼル機関車には1つの要素しかありません。 それ以外の場合は、次のように再定式化できます。ディーゼル機関車の設計コンセプトのモデルにおける接続の「アリティ」は、常に「1対1」です。
しかし、一般的な場合、これは真実ではありません。 多くの場合、接続の「アリティ」が「1対1」と異なる概念モデルを見つけることができます。
構築の概念は、概念モデルとも呼ばれます。 確かに、概念モデルの広範な定義には非常に重大な間違いが1つあります。 通常、概念モデルは概念と概念間の関係のモデルであると言われています。 概念モデルには接続がなく、接続のモデルでさえなく、接続の概念があるため、これは真実ではありません。 このエラーを何らかの方法でマスクするために、彼らは概念モデルの接続にアリティがあると言います-例えば、「1対3」。 これについては以前に書きましたが、「矢印」セクションの「 アカウンティングオブジェクトのモデリング 」という記事をご覧ください。
この種のモデルをよりよく想像するために、ERモデルを調べることができます。 それらには、オブジェクトの概念と接続の概念があります。 ERモデルに基づいて設計概念モデルを再構築することは可能ですか？ 悲しいかな、それは不可能です。 したがって、設計モデルを復元することはできません。
つまり、要約すると、オブジェクトのモデルと概念のモデルという2つのタイプのモデルがあると言えます。 オブジェクトモデルの場合、推移性の原則は真ですが、概念モデルの場合、この原則は機能しません。
例
2つの取引相手の間で合意があると仮定します。 この取り決めにはモデルがあります-契約書。 このようなドキュメントがいくつかあり、それぞれがこの配置のモデルです。 文書のモデルを含むWordファイルがあるとします。 後で必要な数のコピーを印刷できるように、1か所で変更を加えると便利です。 このWordファイルも合意のモデルであることがわかりました。
書面による文書を作成する必要のあるそれぞれの契約について、多くの合意があります。 統合を行い、これらのすべてのドキュメントに対して1つのモデル、つまりモデルコントラクトを作成します。 標準契約は、特定の契約のモデルをすばやく作成できるという点で便利です。 しかし、それは具体的な合意のモデルではありません。 したがって、モデル契約のあるWordファイルは、特定の契約のモデルではありません。 そして、モデルの推移性はここにはありません。
質問：BPMN表記を使用して作成されるモデルのタイプは何ですか？ あなた自身が答えられることを望んで、私はこの質問には答えません。
質問：どのタイプのモデルがIDEF0表記を使用して作成されますか？ また、あなた自身がこの質問に答えることを願っています。