【コードで分かるUMLシリーズ】クラス図の書きかた（関連端名のつけ方と確認のしかた）

#この記事の対象者
この記事は、クラス図に関連端名を付けようとしているけれど、いま一つ違和感のある人向けです。
よく目にする変な関連端名のパターンを紹介し、同様の間違いをしないような考えかたについて触れます。

#おかしな関連端名の一例
関連端名を付けようとして、なんてつければ良いか分からず、
「対象○○」と命名された関連端名を見かけることがよくあります。
![対象関連端名.png](https://qiita-image-store.s3.amazonaws.com/0/197297/71f7be83-71ad-30b8-b2df-c22254c8171c.png)

上図が、その一例です。
これのどこがおかしいのでしょうか？
##そもそも関連端名とは
そもそも、関連端名は「関連端の反対側のクラスから見たときの役割名のこと」です。
例えば、私はPCを2台持っていますが、一台は自分用で、もう一台は家族用です。
関連端名で書くと、こうなります。
![umlPC.png](https://qiita-image-store.s3.amazonaws.com/0/197297/6976f75a-b388-40d1-9e31-3480efd8d442.png)

コードのほうが分かりやすい人のためにコードにすると、こんな感じになります。

```csharp:Hoge.cs
class Hoge {
  PC MyPC = new PC();      // 自分用PC
  PC FamilyPC = new PC();  // 家族用PC
  public void function(){
    MyPC.PowerON();        // 自分用PC.電源ON
    FamilyPC.PowerON();    // 家族用PC.電源ON
  }
}
```

##適切な関連端名はスムーズに読み下せる
クラス名「PC」と関連端名「自分用PC」を読み下すと、
「このPCは、自分用PCである」
と読めます。
コードの例でみても、
「自分用PCを電源ONする」というコードは、何をしたいのか分かりやすいです。

それに対し、先ほどの図を読み下すと、
「この設定データは、対象データである」
となります。
何かおかしいですよね。

初めに挙げたおかしな関連端名の例を、コードにすると、

```csharp:Hoge.cs
class Hoge {
  SettingData ObjctData = new SettingData();      // 対象データ
  public void function(){
    bool valid = ObjectData.IsValid();   // 対象データ.検証する ... そもそも対象データってなんだ？
  }
}
```
こんな感じになり、
function()の中だけを読んでも、何のことだか分かりづらくなります。

おかしな関連端名の例のモデルを、自然になるように直してみると、
「このデータは、設定データである」
や
「この調整パラメータは、最新設定パラメータである」
「この調整パラメータは、前回設定パラメータである」
といったものでしょう。
図にすると、
![umlsetting.png](https://qiita-image-store.s3.amazonaws.com/0/197297/d779d33e-0809-5bc9-3214-10cd73ef0c92.png)
や
![umlparam.png](https://qiita-image-store.s3.amazonaws.com/0/197297/52d35489-56fb-a001-b0c5-7560e19b56cf.png)
です。

仮に「この設定パラメータは、、、」の方をコードにしてみると、

```csharp:Hoge.cs
class Hoge {
  AdjustParam NewSettingParam = new AdjustParam();   // 最新設定パラメータ
  AdjustParam PreSettingParam = new AdjustParam();   // 前回設定パラメータ
  public void function(){
    NewSettingParam.CopyTo(PreSettingParam); // 最新設定パラメータを前回設定パラメータにコピーする
  }
}
```
このような感じになり、読みやすくなります。

この違いが、不具合の埋め込みやすさに影響することは、ごく自然なことではないでしょうか。

##この例のおかしさに気づくポイント

先ほどの「設定データは、対象データである」がおかしいと気づきやすいポイントは、
実は「設定データ」が役割を示しているかも知れない、という点です。

「この設定データは、対象データである」と読み下して、
おかしい！と感じたら、
「設定データ」というクラス名を、関連端名に移動して、
「この〇〇は、設定データである」
と読み下しし直してみましょう。
腑に落ちる”〇〇”が見つかり、
それで自然に読み下せる文になったら、
それをクラス名と関連端名として、クラス図を書いてみましょう。
スムーズに読み下せるようになれば、適切になった可能性があります。

#なぜ、この手の間違いを犯すのか？
私自身と周囲の人の間違えから推測すると、

「関連端名とは関連端の反対側のクラスから見たときの役割名のこと」
と教えられているので、
先に出してしまったクラスの名前を見ながら、「これってどんな役割なんだろう？」と自問自答してしまい、
結果として、やや無理やりな関連端名を思いついてしまうのかも知れません。

つまり、
「「調整データ」という名前がモノの名前だと思い込んでしまい、役割の名前だと気づけなくなる」ことが、
あるのではないでしょうか。
![umlillegal.png](https://qiita-image-store.s3.amazonaws.com/0/197297/d51bef4a-cd37-6a53-9602-dabf7f48e049.png)
この思い込みを防いだり、思い込みから抜け出す方法が、先ほどの「読み下し」です。
読み下した時の違和感を大事にし、違和感のない自然な言葉を見つけると良いと思います。

#最後に加えての疑問
では、類似のケースでクラス名と関連端名が同じケースについては、どう考えればよいのでしょうか？
![umlsame.png](https://qiita-image-store.s3.amazonaws.com/0/197297/f1e1eb34-212f-15d3-4917-389c50889d08.png)
たとえば、「担任」というクラスの役割（＝関連端名）は、「担任」と書いてみます。
前述の「対象データ」の例に比べると、それほど違和感を感じませんね。

では、読み下してみましょう。
「この担任は、担任である」
......
やや、変ですね。

モデルは、コミュニケーションをとるための言語ですから、
読み下しておかしければ、見直したほうがベターです。

実は、モデルの文脈によっては、同一でも良いケースもあるのですが、
それは、また今度書きたいと思います。

#関連端名を付けているときの様子の動画

どのように考えながらUMLモデリングしているかを声に出しながらモデリングする
モデリングライブを行いました。UMTPのホームページに動画が載っていますので、もしよろしければどうぞ。
https://umtp-japan.org/activity-report/10409