実践ソフトウェアエンジニアリング第８章の感想

冬休みの読書感想文第3回目。今日は第８章の「要求モデリングの推奨手法」とついでに付録１の「UML入門」について。

要求分析

要求モデリングのゴールは、顧客が何を求めているのかを説明し、その中でソフトウェアが持つべき役割は何であるかを明確にすること。そして受け入れ基準を明確にすること。

分析モデリングの最大の関心ごとは「何を」であって、「どうやって」ではない。

冒頭にさらっと書いてあるこの一文から、「そうそうそうそう」でした。 顧客要求を受け取って、その次の瞬間から「どうやって実現しようか」と考えてしまうエンジニアさんは多いですよね。
ドメイン知識の豊富な優秀なエンジニアさんから「そんな当たり前なことをわざわざ書くまでもない」と言われたことがありました。

分析モデルはシステム技術と設計モデルを橋渡しする

おお～橋渡し、いいですね。この図を見せればいいのか。 
あなたの部下の設計モデルを書く人に、そのあなたの言う”当たり前のこと”も含めて橋渡ししてあげるんだよと。

要求モデリングの原則には、頷きの連続です。
『階層的な構造で詳細を隠蔽しなければならない』
これに耐えられず詳細を記載してしまったモデルのいかに理解しづらいことか～。

詳細に書き込まれたモデルのレビューはなかなかに指摘がしづらいです。きっと間違ったことは書いていないのだろうし（ただし本質部分が定義される前なのでレビューの対象にない）書き込まれた詳細部分を「今はいらない」と言っても納得はしてもらえない。この要求モデリングの原則の項を見せて理解してもらえるかな。

シナリオに基づくモデリング

ユーザーストーリー型とユースケース型の２種類で同じユースケースを書いてあり、これは非常にいい教材だと思いました。こうしてみると情報量がかなり違うことが分かる。

主に文章力及び文章読解力の問題からユーザーストーリーで表現することはないのだけれど、一度２種類でかき分けてみようか。。。 ユーザー ストーリーで書くようにすれば、おのずと開発者にもユーザー視点が身についてくるのではないか？

ユースケースの質問チェックが非常にありがたい。これは理解しやすい！

クラスに基づくモデリング

分析モデルに含めるか判断するチェック事項。これはお恥ずかしながら目から鱗でした。なるほど、こういう基準で分析レベルのモデルを定義していけばいいのか。。。なるほど確かに、単一の属性しか持たないクラスは設計モデルからでよい。これまで多少は含んでいた気がする。

責務の特定（特に操作）には「知識が必要」は納得。業務知識もだし、何を制御する必要があるのかという構造の知識もいる。
知識を持つ人が一人にまとまってはいないので、早い段階でレビューしてもらうか一緒にモデルを書いていかないとですね。

機能のモデリング／振る舞いのモデリング

アクティビティ図はよく書きます。スイムレーンあり・なし両方書きますが、 こうして見るとやはり分析モデルではスイムレーンで表現した方がいいですね。 ひとつしか責務がないレーンがあったりするとつい省略してしまうのですが、 面倒がらずに書こう。 

付録UML入門

UML2.5から、 クラス図、配置図、ユースケース図、 シーケンス図 コミュニケーション図、アクティビティー図、ステートマシン図を 解説してくれている。

正直な感想としては「UMLを解説するのにほぼ文だなｗ」ってとこ。 図と文の関連付けも自分で探さないといけないし、入門者には些か不親切に思えました。このモデルはどういうときに使うよ、くらいでよかったかも？

第8章の感想まとめ

ユースケースの質問チェックが非常に実践的ですぐに活かせそうな内容でした。このままチェックシートにしてユースケースフォーマットの補足資料にしよう。
でもそれよりも要求モデリングの原則の方が響きましたね。そう説明してきているけど、いざ詳細なモデルが出てきてしまったときに、うまく説明できなかったのです。もう一度ちゃんと読み込んで、ここを読んでほしい人が何人か浮かんだので、ディスカッションのネタにしようと思います。

いったんこの3回で終わりますが、また休みのタイミングで続きを書こうと思います。