名付けのためにクラス図を元に会話しよう/Let's-use-class-diagram-to-communicate-with-client

イベント：オブジェクト指向LT会 vol.3 #ooltjp
で使用した資料。
https://rakus.connpass.com/event/225776/

元ネタのブログ：
https://nainaistar.hatenablog.com/entry/2020/04/29/UML%E3%81%AF%E8%A6%9A%E3%81%88%E3%81%A6%E3%81%8A%E3%81%8F%E3%81%B9%E3%81%8D%28%E3%82%AF%E3%83%A9%E3%82%B9%E5%9B%B3%E7%B7%A8%29

Transcript

1. 名付けのために
   クラス図を元に会話しよう
   オブジェクト指向LT会 vol.3 #ooltjp
   きり丸（水上　皓登）@nainaistar
   

   View Slide

2. 名前：きり丸（水上 皓登）
   twitter：nainaistar
   GitHub：hirotoKirimaru
   ブログ：きり丸の技術日記
   https://nainaistar.hatenablog.com/
   2
   これから
   クラス図大事！
   って発表するけど、
   正直クラス図作るのつらい
   

   View Slide

3. エンジニアの仕事は
   概念に名前を付けること
   

   View Slide

4. 前回の登壇：
   Code Smellsの
   Primitive Obsessionに
   気を付けて設計する
   ラクス様
   リーダブルコード LT会
   Vol2
   

   View Slide

5. 全ての概念について
   名前がついているわけではない
   他人に言われて初めて
   名前がついていることに気づく
   概念も多い
   

   View Slide

6. クラス図を使って
   概念の関係性を深堀り
   する機会を作ろう！
   

   View Slide

7. 今日のゴール
   

   View Slide

8. クラス図を使えば
   もっと概念を理解する
   きっかけ作りができることを学ぶ
   

   View Slide

9. クラス図を書くために大事なこと
   ● 多重度
   ● 関連端名
   この2つだけ覚えてほしい！
   

   View Slide

10. 多重度について
    クラス間の関係が次のどれかであるか分かるだけで、
    クラス間の関係を推し量ることができます。
    ● １：１
    ● １：多
    ● 多：多
    

    View Slide

11. 関連端名について
    分析において
    「最重要要素」
    だと私は考えています。
    

    View Slide

12. 関連端名について
    関連端名とは、関連先クラスに対して持つ役割を記述したもの。
    なぜ重要かというと、
    この特定のクラスから見た別クラスを表現する言葉に
    業務に詳しい人が業務上で使用している名前に
    知識が詰まっているからです。
    

    View Slide

13. ECサイトの例
    カートと商品の関係性
    

    View Slide

14. ECサイトの例
    購入履歴と商品の関係性
    

    View Slide

15. ECサイトの例
    カートと購入履歴と商品の関
    係性
    

    View Slide

16. 注意！
    異なるモデルが業務で表現している概念で一致していることが
    分かったからと言って、
    永続化（テーブル）を一致させる必要はありません。
    それはそれ。
    これはこれ。
    

    View Slide

17. クラス図も更に分類できる
    ● 概念クラス図
    ● 設計クラス図
    

    View Slide

18. 概念クラス図について
    業務の概念、クラス間の関係を掴むためのクラス図です。
    概念を掴むものなので、多対多で紐づけても問題ありません。
    複雑なドメインであるほど、まずは概念で理解することが必要です。
    概念クラス図の関連であれば、関連端名を導きやすいです。
    

    View Slide

19. 設計クラス図について
    概念クラス図をアプリとして実装できるように
    制約を付与したクラス図です。
    一般的なクラス図は設計クラス図を指すことが多いです。
    ● システム制約
    多対多だと実装できないため、中間に別の概念を加えて1対多にする等。
    ● 業務制約
    一度に購入できる数は10個まで、
    リモートワーク申請できるのは月に5日まで 等々。
    

    View Slide

20. 設計クラス図の注意点
    概念クラス図を元に設計クラス図を作成している場合は、
    概念クラス図で記載されている関係を壊してはいけません。
    概念クラス図だとアプリケーションを作成できない為に、
    異なる実装クラス図を作ってしまうことはありがちです。
    どうしても実装できない場合は、概念クラス図を変更しましょう。
    

    View Slide

21. できればモデリングツールを使ってほしい
    astah*等のモデリングツールだと、
    概念クラス図を作成したのちに、
    容易に設計クラス図に落とし込めます。
    概念クラス図を修正すると、参照しているすべてのクラス図も
    変更できるので、変更漏れがなくなります。
    PlantUMLやPowerPointだとできないため、
    メンテナンスコストが高いのが非常に難点です。
    

    View Slide

22. モデリングツール例
    ● astah*
    チェンジビジョン社。iPad版はクラス図しか書けない。
    ● EnterpriseArchitect
    SparxSystems社。チームでの開発を想定している。
    ● Rational Rhapsody
    IBM社。組み込み系で良く使われており、NASAの火星探索機とかも使わ
    れてるらしい。
    ● Papyrus
    Eclipseで無料で使える。
    

    View Slide

23. まとめ
    多重度・関連端名を重要視してクラス図を作り、
    業務に詳しい人と会話するきっかけを作りましょう。
    また、クラス図には概念クラス図・設計クラス図があります。
    制約を気にしない概念クラス図を元に、
    業務に詳しい人と会話するきっかけを作りましょう。
    

    View Slide

24. クラス図を使えば
    もっと概念を理解する
    きっかけ作りができる！
    

    View Slide

25. Appendix
    

    View Slide

26. ブログ
    UMLは覚えておくべき(クラス図編)
    

    View Slide

27. 話すこと / 話さないこと
    ● ●
    話すこと 話さないこと
    

    View Slide

28. 対象者 / 非対象者
    ● ●
    対象者 非対象者
    

    View Slide

29. 登壇を見た人への期待するアクション
    ●
    アクション
    

    View Slide