モデリングハンズオン：連絡網をモデリングしてみた[設計]

社内でモデリングワークショップをやってみたので、進め方と学びをシェアします。

開催概要

モチベーション

・モデリング手法などの知見を貯めたい
・モデリング好きな人でわいわい議論したい
・DDDの実装サンプルのネタにしたい

これらを明示してから始めました。

参加者

新卒1年目〜30前後の中堅の8人ほどで行いました。

参加者に興味を持ってもらったモチベーションを聞いたところ、

若手のモチベ：
やったことないのでやってみたい、仕事で使いそう

中堅のモチベーション：
経験的にある程度できるけどメンバーにやってもらうヒントを得るために

といったものでした。そういったメンバーで、若手・中堅を混ぜて2グループに分かれてホワイトボードを囲んでディスカッションしてもらいました。

進め方

モデリングカフェ「Square」〜UMLでモデリングを愉しもう（第１回） | オブジェクトの広場

こちらのページを参考に、モデリングの進め方を読み合わせし、ここに記載されれていたお題を書きました。

紹介されていたモデリングの進め方

• ステップ1：状況を理解する
• ステップ2：モデルのコンセプトを決める
• ステップ3：モデルを作成する

お題

(画像は上記リンク先から引用)

実際の流れ

ステップ1：状況を理解する

小学校の頃の連絡網の記憶を思い出しながらいろいろな要素が洗い出されてきました。

• ゆうじって生徒？先生？
  • 連絡網って一番末の人まで回したら先生に返すとかあったよね、それってどう表現する？
  • 昔は名簿にあるのは生徒だけだったような？そうする先生はこの図の外？
  • ゆうじは先生ということにして末尾の人はゆうじに連絡を返すことにしよう
• 誰が始点で誰が終点ってどう表現すればいいんだろう？
  • 最初が先生だったら始点？終点は？
  • そもそも始点終点って知りたいのかな？
• 電話つながらなかったらスキップして次の人とかあったね
  • それってどうやって表現するんだろう。。
  • 先生はスキップされたこととか知る必要あるのかな？
• あれ、そもそも連絡したかどうかってモデリングする必要あるの？

このように、議論をしている「あれ？これモデリングするのか？」という疑問が湧いてきます。

そこで次のステップで整理することにしました。

ステップ2：モデルのコンセプトを決める

ここでモデルとは"現実世界を正しく表現したもの"ではないという話 / 境界付けられたコンテキストの必要性で書いた、

モデルが表現するのは 特定の側面(selected aspects) であり、 目的にあるのは 関連する問題を解決する ということなのです。

ということをおさらいします。
つまり

解決したい問題を決めない限り、「良いモデル」の定義はできない ということです。

そこで、今回のコンセプト(スコープ)を以下のように定義しました。

• 「連絡網を作成すること」に焦点を絞る
• 実際に連絡がされたかどうかはスコープ外とする

ステップ3：モデルを作成する

実際にモデルを作っていきます。

例題の通り、今回はクラス図とオブジェクト図を作成することにします。

クラス図を作成するために、「こういうデータがあればいいんじゃない？」という案を出しました。

ここで

• 始点終点はどうやって表現する？
• そもそも表現する必要はあるのか？

という話がでました。

表現の要否はモデル作成の意思なので、コンセプトを振り返って考えます。

今回は「作成すること」に絞ったのですが、始点終点は必要でしょうか？

スコープには定義し切れてない観点なので、ここで決めることにしました。

「個別の連絡の線が始点か終点かわからないと、1個1個の線を全部組み立ててみないとどこが始点、終点かわからない。それは不便かも」

という話が出たので、持たせることにしました。
また、以下のような議論を経て、最終的に下図のようになりました。

• 始点情報を「先生」というラベルとして人に持たせると、「学級委員長が始点を務める」といったときに柔軟に対応できなくなるから連絡の線の方に持たせた方がよさそう
• 始点と終点は1つの項目で区分値で一度書いたが、始点と終点が同時になることはないのか？と考えたらあった(人が二人しかいない場合)ので、別の項目として持つ

クラス図を作る

これを元にクラス図を作ることにしました。

ここで気付きます。

「あれ、このオブジェクト何て名前なんだ？」

「生徒」にしてしまうとゆうじが先生の場合このオブジェクトに含められなくなります。なのでここは(だいぶざっくりですが)「人」というオブジェクト名にしました。

また、もう一つのオブジェクトは迷った末に「連絡経路」としました。

これでクラス図が完成です。

ここで多重度を考えようとしますが、初心者もいたのでなかなかこの図からは難しい・・・ということで、例題に倣ってオブジェクト図を作成します。

オブジェクト図を作る

オブジェクト図とは、クラス図などで表現されたクラス構成や相互関係に対して、それを具体化(インスタンス化)したレベルで表現された図です

IT専科 オブジェクトの定義より

だいぶイメージが湧いてきました。

「オブジェクト図ってよくわからなかったけど、書いてみると実際のイメージが湧くからとても良い！」

という意見が出てきました。こちらを参考にクラス図の多重度を決めました。

この辺りで時間切れでした。

なお、もう一方のチームでは、「クラス」というオブジェクトが連絡網を保有する形のモデルにたどり着いていました。

※このモデル自体はまだ改良余地があると思いますが、ひとまずはワークショップの成果紹介ということでご容赦ください・・・！(^^;

学び

解決したい問題定義の大切さ

「解決したい問題を決めない限り、「良いモデル」の定義はできない」というのを体感したので、必要性を自然に認識することができました。

ただ、始点終点の要否は曖昧だったので、おそらくここではユースケース図を作ってアクターとそのユースケースを定義した方がスコープが明らかになったと思います。

ネーミングの大切さ

なんとなくデータのイメージを並べていたところから、名前をつけることでそこに含まれる者が適切かどうかが判断できることが体感できました。

設計メソッドの重要さ

今回はサンプルにあったモデリングの流れに沿っていった結果、背景の洗い出しやスコープ定義を自然とすることができました。これはメソッドの力です。この辺りの手法は色々流派があるので、普段のプロジェクトワークに適した者は何か探っていきたいです。

モデリングは普通に楽しい

モデリングは興味がある人でやると普通に超盛り上がるのできっかけさえ作れたらうまくいきそうです。

ただし、ある程度できる人が導かないとまとまるところまでいかなかったり、フィードバックができないので、メンバー構成はすこし配慮が必要そうです。

もう少しまとめれば効率の良いコンテンツにできそう

1時間ぐらいで上記のような視点を持ってもらうことができるので、かなり費用対効果はよさそうでした。 これをもう少し進めながら取り入れやすい設計メソッドを検討していきたいと思います。

また、これを実装に落とし込むところも非常に良い学びになりそうなので、今後はモデリングと実装も併せて検討していきたいと思います。