目次
はじめに
この記事は、とあるプチ勉強会の中で、演習的に ICONIXプロセス を実践してみた記録です。
ICONIXプロセス・ユースケース駆動開発について学びたい方は ユースケース駆動開発実践ガイド をぜひ読んでみてください。
ざっくり概要を知りたい方は、よろしければ以下の記事もご活用ください。
https://zenn.dev/tomoeine/articles/2babb554aa0478
序文
きっかけは、宮崎のコワーキングスペース ATOMica で作業していたとある日のこと。
その日は、誕生日プレゼントとしていただいたばかりの「ユースケース駆動開発実践ガイド」を傍らに置いて作業していました。(Nさんありがとうございます!)
そこに通りがかった宮崎を代表するつよつよエンジニアEさんが「こういうテーマのプチ勉強会したいよね」と。
これはやるしかない!
ということで宮崎IT関連勉強会の Slack で参加者を募り、勉強会開催に漕ぎ着けたのでした。
第1回は、私が本を読んだアウトプットとして書いた 前段のまとめ記事 を話の入口にしつつ、Eさん&Kさんがどんどん話を拡げてくださり、ICONIXプロセスに加えてテスト駆動やDDDの話を「なるほど、なるほど」とお勉強させていただきました。
そして、本記事本題の第2回。
5人が集まりました。
今回はざっくり、「実際に何か手を動かしたいよね〜」と話していましたが、ノーテーマ。
その場で案を募ったところ、Iさんから「居酒屋のボトルキープを管理するアプリという以前からのアイデアがあるんだけどどう?」とご提案が。
そこで、前回同様Eさん&Kさんに講師をしていただきながら、IさんをドメインエキスパートとしてICONIXプロセスを進めてみる会となったのでした。
ICONIXプロセスの実践
さあ、ここからがこの記事の本題です。
モデルを洗い出す
まずはドメインエキスパートのIさんに、ざっくりとした要求をヒアリングします
要求
|
|
この要求を元に、以下のモデルを洗い出しました。
この時点ではのモデルはドラフト版で、後で修正します。
- restaurant(居酒屋やスナックの店舗)
- customer(ボトルキープするお客さん)
- kept_bottle(キープされたボトル)
ここで洗い出したモデルは、後のフェーズでもずっと使う「用語集」にもなります(DDDで言う「ユビキタス言語」)。
ユースケース図を書く
ユースケース駆動開発実践ガイドの中では「ユースケース記述の書き方」を中心に説明されていますが、これは各ユースケースを詳細に説明するためのもの ユースケースを洗い出すために、まずはユースケース図を作ります。
ユースケース作成にあたり、さらに詳しく要求を洗い出していきます。
さらに詳しい要求
|
|
後々クラス名としてそのまま使えるようにと英語でモデル名を命名していましたが、日本語のユースケースの中で使うのは結構難しいですね。。
二重の定義になってはしまいますが、はじめは日本語でモデル名を決めて、最終的なクラス図にアップデートするときに英語に訳していく方が扱いやすいのかなぁと思いました。
そして作成したユースケース図がこちら。
ユースケース図(ドラフト版)
更新しやすいように PlantUML でも作成。(後日)
ここでさっそく、モデルに修正が必要なことに気付きました。
そう、サービスを管理する「administrator」が必要だったのです。
更新されたモデル
- restaurant(居酒屋やスナックの店舗)
- customer(ボトルキープするお客さん)
- kept_bottle(キープされたボトル)
- administrator(サービス管理者)
このユースケース図もまだドラフト版です。 以降のユースケース記述・ロバストネス図を踏まえて修正していきます。
ユースケース記述を書く
次は各々のユースケースについてユースケース記述を書きます。
勉強会では時間がないので(この記事全体のプロセスで2時間・・・!)、「ボトルをキープする」という、このサービスの核となるユースケースについて作成することにしました。
ここまでのディスカッションの中でメンバー内でのサービスイメージは共通化されているし、そんなに難しくないはず・・・
と思っていたら、出るわ出るわ不明点w
さらにディスカッションを重ね、システムに求める挙動を明確にしてきました。
「ボトルをキープする」に関するさらに詳しい要求
|
|
ユースケース記述「ボトルをキープする」
以下のポイントに気をつけながら作成していきます。 - ユーザーとシステムの両側を記述する - 基本コースと代替コースを記述する
こちらも文字で転記しておきます。(後日)
|
|
当日は、ホワイトボードに書いてしまったため後から修正できずに苦しみましたw
ユースケース記述あたりからは、PCで作業してモニターに映す方が捗りそうです。
ロバストネス図を書く
慣れない作業で、みんなで頭を捻りながらなんとか作成。 ここでまたさらに、不明点が出てくる・・・ 特に「具体的にどんな画面なんだっけ?」という認識がメンバー間で統一されていないために混乱が起きました。 というわけで、簡単なワイヤーをホワイトボードに書きながら、画面への要求を固めていきます。
「ボトルをキープする」の画面に関する要求
|
|
ロバストネス図「ボトルをキープする」
特に以下の点に留意して作成します。
- バウンダリ(画面)、エンティティ、コントローラの3種類のオブジェクトを描く
- バウンダリとエンティティを名詞、コントローラを動詞として扱い、「名詞-名詞」で繋がらないようにする(「名詞-動詞」「動詞-動詞」はOK)
こちらも PlantUML で再度。
勉強会ではいきなり図を書き始めてアワアワと混乱しましたが、PlantUML で書いてみて、最初にオブジェクトを洗い出しておけば書きやすかったのかーと気付きました。次回に生かそう。
まとめ・感想
さてはて、ここまでやってみると、ユースケース図もユースケース記述にも若干の不足がありますね!
また、モデルにも属性や振る舞いを追記していけそうです。
この修正作業は、次回開催時にみんなでやっていこうと思います。
おわりに
勉強会に参加してくださった皆さん、特にみんなを導いてくれた Eさん・Kさんありがとうございます!
そしてこの勉強会のきっかけとなった「ユースケース駆動開発実践ガイド」を贈ってくださったNさんにも改めてお礼申し上げます。
第3回は5月かな?
開催後はまた記事にするつもりです。頑張ります。