UMLのクラス図を、実際にソースコードに落としたときのスケルトンでまとめてみました。
まずは単純な関連です。誘導可能性がないため、どちらにも参照をもつ*1形になってしまいますね。あんまりよろしくないでしょう。
public class Directory { private File child; } public class File { private Directory parent; }
誘導可能性を追加すると、片方にしか参照をもたなくなります。一般的な関連といえますね。
public class Directory { private File child; } public class File { }
継承はこんな感じ。
public class Directory { private File child; } public class File extends Directory { }
集約(Aggregate)にしてみました。ここでは配列ですが、Listでもよいですね。
public class Directory { private File[] child; } public class File extends Directory { }
インターフェースの実現の関係です。
public interface Entry { } public class Directory implements Entry { private Entry[] entry; } public class File implements Entry { }
依存はフィールドに持たないような関連性の低い関連(?)*3を表すときに用います。
関連性の低い関連、を説明しているサイトがありました
ここを引用すると、
パラメータの型を命名したり一時変数内にオブジェクトを作ったりすることは、「依存」を意味する。
んだそうです。だいたい上の説明であってるみたい。
複数の会社に属する人がいるってのを表すと、始めこうモデル化されると思いました。
オブジェクト図で表すと下図のようになりますが、
よく考えると社員は複数の会社の社員番号*5をもてないって事になります。
いろいろ考えるとモデリングが悪いって事で、改善した結果がこれ。
オブジェクト図を書いてみて、正しく表現できそうですね。
この社員情報クラスのように、二つのインスタンス間の関連に付属する属性のクラスのことを関連クラスというそうです。UMLで記述する場合
と書きます。
クラス間で、どの属性を用いて相手のインスタンスを特定するかを表すために限定子という記号を用います。たとえば、次のモデルの場合
会社から見た場合、組織は組織コードによってユニークになります。それを表すとき
と書きます。この組織コードという一つの四角のことを限定子と呼びます。限定子によって組織クラスはユニークとなるため、関連の多重度が1になっているところがポイントです。
この記事は
現在のアクセス:196775