http://martinfowler.com/bliki/DerivedInformation.html

派生情報をUMLでどう表す？

簡単な例を考えてみましょう。長方形クラスがあるとします。その長方形の高さ、幅、面積を知りたい。さて、高さと幅を使って面積を導きだすには、どのようにすればよいでしょうか。

高さと幅を属性にして、面積は操作にするのが一般的なやり方でしょう。 高さと幅をフィールド値にし、面積を計算するメソッドを実装すればよいからです。

UML には、派生プロパティを記述する方法もあります。 派生プロパティの名前のプレフィックスに「/」を用いればよいのです。 今回の場合、「面積」にこのプレフィックスが使えることになります。

どちらもやり方も合理的ですが、それぞれが別のやり方をしていますよね。 フィールド値のことを属性としか呼ばないチームもあります。 このようなチームは、派生記法を用いないか、 派生情報がフィールド内にあると分かる場合のみ、派生記法を使います。 派生マークは、派生の命名がフィールドに対する命名規約に一致するならば使うというチームもあります。（getArea()のようなメソッドや、C#やRubyで用いられるプロパティのような場合）（★？？）

私はすこし違ったやり方を好みます。オブジェクトのキープロパティのひとつがカプセル化されているやり方です。 私が長方形クラスのユーザーであれば、長方形の面積が計算されているかどうかを知る必要もなければ、気にする必要もありません。実装者が高さと面積を計算し、幅を導き出してストアしてるかもしれませんが、私にはそれが分からないですし、どうでもいいことです。 ですので、フィールドや派生情報に命名規則を用いて実装するのです。そうして、クラス図ですべてがプロパティだと分かるようにします。

派生用のマークをつけないのかって？ つけません。面積を派生としてマークできると幸せですが、これだと、3つの値の間に制約が生まれてしまいますし、何が導きだされて、何がストアされているか、ちゃんと明示できません。 似たような議論ですが、三角形の三辺をプロパティとして持った場合、ひとつを派生としてマークするのが妥当です。

実際問題、どのアプローチを選ぶかなんてほとんど問題になりません。それよりもチーム内のスタイルに合わせることのほうが重要となります。あと、これも重要ですので覚えて置いてください。「みんなやり方が違う(different people do different things)」。これは、他のチームのダイアグラムを見るときに理解しておかねばならないことです。 （ 本で使っているほど私は派生を使いません。 なぜなら、解釈に一貫性がないからです。 ） これは思っているよりもUMLは厳密じゃないっていう一例ですね。