MENU

モデリング勉強会に参加してきた。

はじめに

先日、モデリングのオフライン勉強会に参加してきました。

  • 土曜日の朝からモデリング・分析・設計に興味のある人たちが集合
  • 一日かけて、「図書管理システムの書籍貸出機能」をテーマに要求定義/要件定義を行う

そんな感じのぶっ飛んだ会でした。 私は比較的モデリングの経験が浅い人たちのチームに入ったのですが、学びや気づきがかなりあったのでここに書き留めていこうと思います。 半分メモのようなものなので、これだけ読んでもよくわからないところが多いかもしれません。

当日の流れ

※ 図書館の図書管理システムの内、「書籍の貸し出しを行う」というユースケースをテーマに設定し、ワークショップ形式で要求定義/要件定義を行った

  1. 概念モデル作成
  2. 概念モデルを元にユースケース作成(アクティビティ図)
  3. ロバストネス分析
  4. 分析モデル作成
  5. シーケンス図作成

※『ユースケース駆動開発実践ガイド』の流れが一番近いかもしれません ※ ただ、ユースケース本ではロバストネス分析後の要求レビューで要求定義を完了させていましたが、当日はユースケース検討時にロバストネス図を修正したりということもやっていました。

当日の成果物

※ 写真は最終形態のもの

概念モデル図

ユースケース

ロバストネス分析

分析クラス図

シーケンス図

気づき・学び

要求定義フェーズ

[概念モデル]

  • 概念モデル作成では、このユースケースに関係あるかどうか関係なしに、思いついたヒト・モノ・コトについて書き出していった。そのやり方はかなりよかったように思う。(後から全く新しい登場人物が出現することをかなり防ぐことができた)

[ユースケース]

  • ユースケースに着手しようとした時、「どの段階からこのユースケースがスタートするのか」に関してメンバーの認識のずれがあった。(利用者が本を選ぶところからなのか、本を選び終わって窓口に持ってきたところからなのか) 着手段階で気づき、事前条件を定義できたおかげで序盤から認識がずれることを防げた。
  • アクティビティ図に 利用者・司書・システム三者を登場させるか議論になった。クライアントに対して業務システムの全体像を理解してもらうためにアクティビティ図を用いるのであれば利用者も登場させた方がよりわかりやすいが、今回はあくまで要求の分析が目的なので、システムを触らない利用者は登場させないことにした。
  • ユースケース図作成後、貸出・返却 のモデル構造についての議論にかなり時間を割いてしまったが、これはロバストネス分析を行う際にやるべきことだったと後で気づいた。ユースケースを書いてて気になったことではあったが、アクティビティ図で図式化されていない部分の話でもあったので「各々が頭の中で構造を想像しながら話し合う」という状況になってしまった。そのような時はひとまず次のフェーズに進み、図を作成してから戻るべきだなあと痛感。

[ロバストネス]

  • アクティビティ図を元にロバストネス図を書いてみた結果、コントローラとなるべき部分の記述が全然足りていないことが発覚した。
  • コントローラが行う処理にどのようなエンティティが必要なのか、かなり時間をかけて悩んだが、「クライアントが特に関心を持っているのはバウンダリ/コントローラ部分。その二つだけしっかり固めてしまい、どういうエンティティが必要かについてはシーケンス図と分析クラス図作成時に確定させるのもありだよ」とアドバイスをもらい、次のフェーズに進むことにした。(実際、それで正解だったように思う)

要件定義フェーズ

  • 最初分析クラス図を書かずにシーケンスを書こうとしていたが、ベテランメンバーに「分析クラス図書いた方が良いよ」と言われて書いてみたところ、シーケンス図のデータの流れが不自然であることが判明してちょっと手戻りした。どのクラスがどのクラスとつながっているべきなのか、シーケンス図では気づけない違和感でも、分析クラス図を書くと気付くことができるなあと感じた。
  • あと30分で時間切れというところで、クラスの繋がりに違和感があることに誰かが気づいた。ロバストネス分析あたりからずっと「貸出リスト」という貸出イベントのコレクションクラスを定義してたんだけど、メンバー間でそのクラスの定義(特定の利用者の貸出なのか、図書館全体の貸出なのか)の認識にずれがあったことが判明。認識合わせをした上で分析クラス図も修正した。あとから考えてみると、確かに話し合いしていて「なんか微妙に話が噛み合ってない?」と感じる局面があった。言葉の定義は、分析の早い段階でもっと慎重に確認し合うべきだなと実感した。
  • 最後の最後になって、「図書館に現物のある本は全て貸出可能という業務ルールなので、貸し出すというユースケース自体には、図書の貸出状態を更新する処理は必要ないんだ」ということに気づいた。(とはいえ、別のユースケースで図書の状態を参照することはあると思うので、今回はシーケンス図に貸出状態更新の処理を含めることにした。) 下記の観点を持つと、分析の際に視界がクリアになるなあと実感した。
    • その処理はそのユースケースに必要なのか
    • もし必要ない場合、他のユースケースとの兼ね合いを踏まえてその処理を実装するかどうか

全体を通して

  • 所要6時間程度で概念モデル~シーケンス図作成までやったが、めちゃくちゃ疲れた。
  • 概念モデル作成段階では、順調そうな雰囲気が漂っていたが、ユースケースを書き始めると途端に概念モデルへの自信を失い、ロバストネス分析で様々な必要なコントローラが抜け落ちていることに気づいた。今までそのような見落としを実装段階まで放置していたから(私の職場では分析もろくに出来ずに実装に入ったりしている)手戻りが頻発するのだなあと痛感した。
  • 今回分析フェーズを経験できて、こっから設計・実装とどんな感じで進んでいくのかが一層気になった。分析自体もまだまだだと思うが、是非分析〜実装までの一連の流れを体験して、実務でも実践できるようになりたい...