きり丸の技術日記

技術・エンジニアのイベント・資格等はこちらにまとめる予定です

UMLは覚えておくべき(クラス図編)

はじめに

UMLは覚えておくべき(概念編)UMLは覚えておくべき(ユースケース記述編) の続編です。

クラス図は、重要さを知ってる人は多いと思います。
なので、サクっと自分がなんで重要だと思っているかを記載します。

クラス図で覚えておくべきもの

個人的には2つ覚えれば十分です。

  1. 多重度
  2. 関連端名

他にも、集約やコンポジション、継承等はありますが…。
あれを有効に使えた記憶が無いです。

自分が使いこなせてないだけって可能性は往々にしてあるのですが…。
オブジェクト指向を極めれば、自分の中で意識が変わるんですかね…?

多重度について

1:1なのか、1:多なのかが分かるだけで、クラス間の関係を推し量ることができます。

まずこれが分析できないと、プログラムに落とせないので重要。

関連端名について

関連端名の重要性を語るためにこの記事を書いたといっても過言ではないくらい、地味に重要な項目。
おそらく、関連端名という名前を聞いたことが無い人も多いのではないかと思います。

関連端名とは、関連先クラスに対して持つ役割を記述したものです。

なぜ重要かというと、この特定のクラスから見た別クラスを表現する言葉にドメインエキスパートが表現するユビキタス言語が詰まっているからです。

関連端名の例

例えば、amazonを想像してください。
商品とカートという概念間にはどういう関係があるでしょうか。
商品から見たカートは一度に決済する単位、カートから見た商品はこれから購入しようとしているアイテムと言い換えることもできるのではないでしょうか。

f:id:nainaistar:20200429001902p:plain

ここで、ユーザーの購買履歴という概念が入ってきたとき、商品とどういう関係があるでしょうか。

ユーザの購買履歴から見た商品はそのままの表現で購入した商品、商品から見た購買履歴はいつ購入されたものか判別できる材料、と言い換えることもできるのでしょうか。

f:id:nainaistar:20200429001931p:plain

更に、ユーザーの購買履歴とカートにはどういう関連があるでしょうか。
システム化の範囲によりますが、実は時系列が違うだけで、同じ概念を指していることもあります。
カートはこれから買おうとする、もしくは購入中の未来と現在を表す表現。 ユーザーの購買履歴は購入した過去を表す表現と言い換えても問題ないと思います。

f:id:nainaistar:20200429001958p:plain

なお、図ではしれっと表現してますが、現在、未来を表すカートの多重度は1で、過去を表す購入履歴はの多重度は多だと思います。

関連端名の例のまとめ

関連端名のすごさを表現する例としては異なったかもしれません。
ただ、時系列によって異なる表現をしているだけ、ということを掴めたのであれば業務に精通している人(ドメインエキスパート)との会話も楽になるのではないでしょうか。

また、これをもとにドメインエキスパートの捉えている表現を共有してもらうことで、相手と共有できる表現(ユビキタス言語)を獲得することもできます。

ユビキタス言語を獲得することで、用語集の作成時に認識ずれを起こさないので、外部の人が参加した場合に効率よく参画してもらうことができます。

ちょっとした悩み事

plantUMLで表現した図を使っているので、気づいている方もいると思いますが、困ったことに、plantUMLでは、多重度と書く場所が被っているので、書きづらい…。
これが関連の下側に多重度、上側に関連端名を書ければ最高なんですが…。

クラス図について

概念クラス図について

クラス間の関係を掴むためのクラス図です。

あくまで、概念を掴むものなので、多対多で紐づけても問題ありません。
複雑なドメインであるほど、まずは概念で理解することが必要です。

あと、概念クラス図の間であれば、上記に記載した関連端名を導きやすいです。

後述する設計クラスでも関連端名を導くことができれば素晴らしいのですが、実装都合で出てくるクラスとの関連端名を付けようとするとなかなか難しいものがあります。

関連端名を重要視している自分としては、可能な限りここでドメインエキスパートと話してユビキタス言語を引き出しておきたいです。

設計クラス図について

実装できるように制約を付与したクラス図です。
一般的なクラス図はこちらでしょうか。

制約といっても、多対多だと実装ができなくなるので、中間に別の概念を加えて1対多にするとかのシステム的な制約とか。
あるいは一度に購入できる数は10個まで、といった業務制約とかを指します。

最終的には実装するために、設計クラス図に落とし込まなければいけないのですが、最初から実装を意識してしまうと実装制約に囚われてしまうので、概念クラス図でざっくり理解してから落とし込んだ方が理解度は高まります。

これが、astah*等のモデリングツールだと、概念クラス図と設計クラス図の複数作っても、一部直すと全部適応されるので、そこまで苦ではないのですが…。
plantUMLやパワポ等のただのお絵かきツールでやると一か所修正で複数個所直す工数がかかるので、大変になります…。

終わりに

クラス図が大事だということは皆さん知っているとは思いますが、関連端名に注目したことはないのではないでしょうか。

システム化の範囲によって関連端名が異なってしまうので、本に載っているクラス図は関連端名を詳しく書けないんですよね…。
自分で開発する気のないクラス図は、多重度だけ見て何をしたいかさえ伝わればいいと思いますし…。

逆に言うと、このシステムでは関連をこのようにとらえています、ということを表現するのには優秀だと思います。

まぁ、関連端名そのものではなく、関連端名を考えることによって理解度を深めることが重要だと思うので、一度考えてみてはいかがでしょうか。