設計の勉強にユースケース駆動開発実践ガイドを読んだ

私の場合、アプリ開発をする際の設計のやり方がよくわからないというのが、本書を購入するきっかけになった。

クラス設計は、設計がいいのか悪いのか判断する根拠も薄く、これでいいのかいつもモヤモヤしながらやる作業になってしまっている。

本書はそんな経験がものをいうクラス設計について「こういうやり方で設計してみたらどうか」というやり方を提示してくれる。

どういうクラスが必要でどんな責務をもたせるかという設計部分を、経験や勘のみではなく具体的な手順で説明しているという点で、本書は非常に勉強になると思う。

要約

要約すると次の流れでクラス設計を行っていく。

1. 機能要求
2. ドメインモデリング
3. 振る舞い要求
4. ロバストネス分析
5. シーケンス図作成

テストについても語られているのだけれど、私は設計をいかに行うかという観点で本書を読んだので、以降に続くコーディングやテストといった部分は省いた。

各ステップは完璧にしてから先へ進むのではなく、ある程度のところまできたら次のステップに進み、後から改善していくスタイルを取る。各段階でレビューをちゃんとしようねというのが重要で、詳しくは本書を読んでもらいたい。

機能要求

システムが備えるべき要件、これをはっきりさせる。

xxができなければならないとか、ooができるとか、仕様となる部分がスタート点になる。

機能要求をいかに識別するかというのはとても重要なトピックだと思うのだが、本書で紹介されているICONIXプロセスではコアとなる部分ではないのがその理由。

先のステップに進んでいけば自ずと隠れていた機能要求が見つかるので、あまり深く掘り下げても仕方がないのだと思う。

ドメインモデリング

ドメインモデリングとは書いてあるが、要するに用語集+各用語の関係をクラス図っぽく書いたものを作ろうという話である。

機能要求で出てきた名詞を機械的に抽出していけばおおまかにはでき上がるはずで、最初はその大まかなでき上がりで先に進む。時間をかけて完璧に仕上げたとしても、先のステップに進めば矛盾が生じたり、新たに判明することが出てくるので時間をかけすぎても意味がないからだそうだ。

主に用語集としての役割に重きをおいたものであり、クラス図っぽく書くのはあくまで各概念（オブジェクト）間の関係を整理するためのもの。

オブジェクト間の関係（集約とか）がいいか悪いかは、やっぱり先の段階に進めば問題に気づけるというスタンスで、とにかく完璧に仕上げようとせずに進めていく。

振る舞い要求

機能要求を実現するために、どのようなユースケースがあるかを識別していくステップ。

私のざっくりした理解では、手順書・ユーザマニュアルを作成するのに近いのだと思っている。たとえばTODOアプリを作るのであれば、TODOを登録するユースケースが必要で、その手順はフォームにTODOを記入して登録ボタンを押す→システムはバリデーションを行ってTODOをDBに保存するといった感じのシナリオを記述していく。

ユーザがこういう操作をしたらシステムはこういう応答を返す、というのを網羅していく段階。

ロバストネス分析

ユースケース記述をロバストネス図に起こす。

これは、ユースケース記述の検証とドメインモデルとクラス図のマッピングを行うための前処理みたいなステップ。

ユースケース記述をバウンダリ、エンティティ、コントローラに振り分けて作図していく。

それぞれの要素にはつなぎ方にルールがある。それに反する作図になるということは、それ以前の段階で何かしら問題が生じていることを表すので、検証ステップとしても機能する。

シーケンス図作成

ロバストネス図を元にしてオブジェクトに振る舞いを割り当てシーケンス図を作成するステップ。これまでに識別したオブジェクトに振る舞いを割り当てていく。

ここまでくれば大体最初に作ったドメインオブジェクトがクラス図にアップデートされているだろうという感じ。

読みにくい

私にとっては非常によい勉強になった本であるが、同時に非常に読みづらい本でもあった。

そもそも取り扱っている内容が難解である（設計自体が難しい）というのが大きいのだと思うが、私が読みづらいなと思ったのはそこではない。

1. 直訳調である
2. 理論と具体例が混在した展開である
3. ツールを利用した説明が混ざっている

ただでさえややこしい内容なのに、さらに輪をかけていろんなものがごちゃ混ぜになっているので、めちゃくちゃ読みづらかった。翻訳の問題ではなくて、原著の書き方自体が私には合ってないのだと思う。

具体例（インターネット書店のアプリケーション作成）を説明しながら理論の説明が行われているので、「この段階では問題があるが、それは後の章で明らかになる」みたいな流れで説明が書いてあるのがつらい。この段階ではどうするのが正しいのか、それを明らかにしてくれと読みながら何度もツッコミを入れた。

さらにツールを使った説明も混在して盛り込まれるのも、私が読みにくいと思ったポイントだ。UML2.0とSpring Frameworkの話は最後に別立てにしているのだから、それと同じように具体例とツールの話も分けられなかったのだろうか。

私としては非常に勉強になった本だが、評価を3にしているのはひとえに「読みにくい」せいである。せめて理論と具体例とツールの使い方はそれぞれ分けて説明してもらいたかった。

まとめ

どんなクラスが必要で、それぞれどんな役割を持たせるべきか。1つのメソッドしか持たないなんちゃらControllerみたいなクラスを作って、なんか違うんだよなぁと悩んでいた私にとって、この本は1つの光明となった。実際にクラス設計ができるようになっているわけではないのだが、少なくともどうしたらいいんだろうとモヤモヤしている段階から一歩抜け出せたのは確かだと思う。

一方で、本書で書かれているステップをバカ正直にやるのはしんどいなぁというのも思っている。特に、都度ドキュメント（ユースケース記述の部分など）を更新しながら進めていくスタイルは実行するのは難しい（というかやりたくない）。本書ではEnterprise Architectというツールを使うことで、その作業は軽減されると紹介されているが、自分のアプリ制作ではそんなツールを使うほどの規模ではない。仮に使ったとしても結局コードとドキュメントの乖離は生まれるだろう。だからこそ、ドキュメントの更新までやるのは大変だと思っている。

とはいえ、アプリ制作のスタート段階であれば、本書のステップで分析を行い設計していくことは有用だろう。バカ正直に本書に書かれていることすべてを取り込む必要はないはずだ。機能要求と振る舞い要求を分けて捉え、各ステップを経ることで徐々にクラス設計が形になっていくというエッセンスは、自分のアプリ制作に十分活用できるだろう。そういう意味で本書の内容はとても勉強になったと私は思っている。

正直なところ、本書は読みにくいし分厚いし高いし古いし分かりにくい。それに、本書で紹介されている分析の流れについては、すでに似たようなことをやっている人はきっと多いだろう。しかし、そのふわっとした部分を見える形にして提示してくれた内容が、私にとっては非常に勉強になった。

いきなり買うのはかなりためらわれるだろうが、図書館で借りて読んでみるなりして内容を確認してみるといいのではないだろうか。