UMLでは、コンポーネントオブジェクトが複合オブジェクトにアクセスできる場所で集約を描画できますか?この画像のように、関連線は1つしかありません。そのため、Aに触れるアソシエーションの最後にはダイヤモンドと矢印があります。 それができない場合は、私が描いた図は有効ですか?そうでない場合、なぜですか?同じエンドでの集約とナビゲート可能性
答えて
もう1つの視点として、モデル内をナビゲートする方法とインスタンスにアクセスする方法を示すことが可能です。
もう1つのポイントはOCLです。ナビゲーション可能性が定義されていないと、一部のOCLクエリは書きにくくなります。ナビゲーション可能とは、実行時にリンクに参加するインスタンス(アソシエーションのインスタンス)がアソシエーションの他端のインスタンスから効率的にアクセスできることを意味します。そのような効率的なアクセスが達成される正確な仕組みは実装特有です。終わりがナビゲート不可能な場合、他の端からのアクセスは可能である場合とできない場合があり、そうである場合は効率的でない可能性があります。
プロパティクラス(p149)について:クエリisNavigable()は、プロパティ間を移動できるかどうかを示します。 body:classifier-> isEmpty()またはassociation.navigableOwnedEnd-> includes(self)ではありません。
モデルにはナビゲート可能かどうかが重要です。
あなたは、両方の側に航行を持つようにしたい場合は、以下の画像があることを示しています。
しかしspecifiationのセクション6では、それが書かれている:
協会どちらの端もナビゲート可能な矢印でマークされていない場合、関連が双方向にナビゲート可能であることを意味します。
アソシエーション終了のナビゲート可能性を示すために矢印表記が使用されます。定義上、クラス所有のすべての関連終点はナビゲート可能です。慣例により、メタモデル内のすべての関連付け所有エンドはナビゲート不可能である。
したがって、以下のスキーマは上記と同じです。これは難しいことですが、それは本当のようです。
もちろん可能です。
あなたがスペースを節約したい場合は、関連付けのために、単一の行を使用することができますが:
はここで航行についての私の個人的な意見だ:ナビゲーション矢印は、プロパティの存在として必要とされていませんowner
それはすでに意味している。
P.仕様110:特性はownedAttribute介し協会以外の分類子によって所有されている場合
、それは分類の属性を表しています。
P. 200:
航行表記はしばしばナビゲート端部があると仮定したのに対し、非ナビゲート端は協会によって所有されているものとしたことにより非公式慣例に従って過去に使用しました。反対側のクラシファイアが所有しています。この規約は廃止予定です。集約タイプ、ナビゲート可能性、およびエンド・オーナーシップは、それぞれ独自の明示的な表記法を持つ別々の概念です。クラスによって所有されているアソシエーションの終了は常にナビゲート可能ですが、アソシエーションによって所有されているアソシエーションの終了はナビゲート可能であるかどうかは関係ありません。
しかし、単に命名された団体は何ですか?それは今までのところ役に立たない構成です。あなたが意図しているのは、最終的にいずれかのクラスで属性を作成することです。その場合は、この(新しい)ドットを追加します。私にとって、これは単純に過度に構成され、実用的ではありません。誰が本当にそれらの点を使用していますか? EAではサブメニューを開いてそれらを表示させる必要があります。私にとって(そしておそらくほとんどのUMLリーダー)、ロール名はプロパティーを表し、これはもう一方の属性です。それは、その命題の背後にある "(私の)人間の論理"です。だから、私の実用的なアプローチ:関連ため
- 使用シンプルなコネクタ
- 最終的に(非)航行(十字と)矢印その後
- 他端の属性を使用することを示すために、ロール名を追加を追加します(クラスのリストに型付き属性を追加するのではなく)。
これだけです。 a)EAを作成するのが難しく、b)認識するのがさらに困難なばかげた点を忘れてしまいます。
この最後の部分は、実際のモデリングに関する私の推奨です。
私はグラニエルの答えを受け入れました。あなたが言ったことは私のためには十分でしたが、矢印は本当に必要ではないと私は同意します、もともと私は同じ端でダイヤモンドと矢について尋ねました。彼の図はそれが可能であることを示しています。 – klenium
さて、私の最初の質問は、矢印について何も言わない。しかし、それは私が知りたかったものです。これで申し訳ありません。 – klenium
@Thomas Kilian:手元の問題は個人的な意見でも、哲学的でもない。 UML仕様によれば、「所有者」のような関連付けエンドによって定義されるプロパティが、オーナーシップドットによってクラスによって所有される属性(反対側のもの)であると定義される場合にのみ、ナビゲート可能性が暗示される。 「所有者」という名前を使用して所有権がすでに定義されていると思われるかもしれませんか? –
- 1. cakephpの集約可能な集約クエリ
- 2. ジャンゴ集約:同じモデル
- 3. Androidで編集可能なListView - iOSと同じ
- 4. MongoDB集約フレームワークの可用性
- 5. すべてのページで同じ編集可能な地域/コンテンツ
- 6. クエリでの編集可能性
- 7. AJAXスプレッドシート、編集可能なナビゲート可能なWebテーブル/グリッドの作成方法は?
- 8. 同じ名前と異なる値のデータフレームを集約する
- 9. PHPSESSID同じ属性が可能ですか?
- 10. jQuery:同じアクションで異なるイベントをリファクタリングする可能性
- 11. 同じクラスタイプの設計の可能性のあるベクトルのベクトル
- 12. Java enumsの可用性の可能性と可能性?
- 13. UITextField内の編集可能なスクロール可能性
- 14. 編集可能なJComboBoxとボタンを同じフレームに追加する方法..?
- 15. MongoDB集約:累積値の平均は可能ですか?
- 16. slickgridの編集可能な行と編集不可能な行
- 17. DDD(java)集約ルーツと永続性
- 18. 同じID行の文字値の集約/連結
- 19. 同じ観測可能性のサブスクライブで観測値の前の値を取得
- 20. 弾性検索 - 集約
- 21. 同じタイプではありませんが、同じタイプではない可能性があります。
- 22. 同じ値の複数列を集約するパンダ
- 23. ノードの約束とコードの可読性
- 24. 非同期タスクの可能性
- 25. がscalazでscalazエンド機能
- 26. 同じ関数で異なる引数の可能性を文書化する
- 27. 同じヘッダーのcolspanと折りたたみ - 可能ですか?
- 28. SQL可能な異なる結果を持つ同じ列のデータを収集
- 29. APEXのエンド・ユーザー編集ページの作成
- 30. Node.js同じ子レストサービスへの並行呼び出しと集約応答
申し訳ありませんが、それはナンセンスです。プロパティを指定すると、それはナビゲート可能であることを意味します。 –
ples @kilianは、UML仕様の関連付けでは間違いなくナビゲート可能であるか、ナビゲート不可能である可能性があります。だからそれは言い訳ではないと言っているのは、この部分ではナンセンスです。私は仕様書の一部をコピーしました。したがって、UMLの場合、アサーションはナビゲート可能であるかどうかはわかりませんが、アローが必要です。あなたがそれを使用しない、またはこれが重要ではないと思うなら、これはあなたの視点であり、それは可能です。しかし、UMLの場合、それは重要であり、モデルであるかどうかは問わない。マイナス1を削除できますか? – granier
また、いつものように、コードでモデルを翻訳する選択肢は何ですか?しかしこれはもう一つのポイントであり、仕様書に直接関係していません。 – granier