はじめに
最近、設計レビューをしてると、大量のシーケンス図が書かれた設計書をレビューの場に持ってこられるときがある。
構成としては、最初に適当なクラス図らしきものが1つあり、それ以外は百前後のシーケンス図がある、という感じ。
クラス図があるので、オブジェクト指向なのかと思いきや、とてもそうとは思えないクラス図で、そこからは何の設計意図も読み取れず、クラス図だけではレビューが成立しないことが多い。
クラス図と合わせて、百前後のシーケンスを見ていけば何となく分かるが、これだけ大量に見ないと分からないのって設計書なのか？と疑問に感じてるので、自分の考えをまとめてみる。
ダメな静的構造図
静的構造図として、クラス図があるが、これがどう考えてもオブジェクト指向初心者、というか何もかじっていない人が描いたのが見え見え。
クラス名が、何とか制御とか、何とか管理とか。こういうクラス名がつく場合って、大抵の場合はオブジェクト指向になってなくて(あくまでも傾向であって絶対ではない)、処理を分解して抽出された物をクラスに当てはめてるだけ。当然、多重度も1対1ばかりになってしまっている。オブジェクト指向からほど遠い。
そして、クラスにはprivate属性のメンバー変数があるが、getterメソッドも併せて存在してる。そして、他のクラスからgetterを通してメンバー変数を取得させて、取得したクラスではif文とかで、何か判断して処理させてる。
隠蔽してないし、単なるグローバル変数と一緒。
これから読み取れる設計意図は、処理を分割しました、とあるグローバル変数相当のprivateメンバー変数はみんなでアクセスして使います、という意図かな(皮肉を込めて)。
この時点でレビューというより、教育モードに移行。
静的構造図のあるべき姿
クラス図は静的構造図なので、そのソフトウェアがどういう構造なのか、そして何を意図してそういう構造なのかを相手に伝える事が必要。
オブジェクト指向なら、データはここで保持し、そのデータに関する処理はそこで隠蔽されている、とかそういう事が図を通して理解出来ることが重要だと思う。クラス間の関係も、ロール名だったり、色々表現できるし、ここはデザインパターンの何とかパターンを用いるとかあれば、話もしやすい。
アプローチとしては、これから作ろうとしている対象は何か？というwhatをクラス図で表現できるとよい。クラス図を作成する際にどんな処理でというhowを考え過ぎると、処理が先行して抽出されてしまい、クラス図がおかしくなる傾向にあると思う。whatがクラス図で明確になったところで、それをどう作るのかというhowに取り掛かり、そこでデザインパターンやら駆使して、非機能要求だったり、保守性だったりを考慮して、テクニックを施せば良いと思う。
オブジェクト図を使って、クラス図を補足するのも良いだろう。
ダメな動的構造図
で、静的構造の意図が読み取れないクラス図をベースに、こういう処理をするよっていうのがシーケンス図だけで表現されている。いつどのオブジェクトがgetter呼んで、何目的でその変数使うのかを、一生懸命シーケンス図で表現してる。レビューの効率が悪過ぎる。
それを指摘すると、じぁ、その変数の使用目的と、何に使うのかを整理しますって言われるが、いや、そもそもクラス構成がダメだからそれを整理しても、ゴチャゴチャなのがわかるだけだし、このまま実装してもテスト大変だし、バグまみれになる姿が容易に想像つく。保守性も悪く、仕様変更にも苦労するだろう。
動的構造図のあるべき姿
シーケンス図って、クラス図の様な静的構造図を元に、オブジェクト間の協調動作を表現して、この構造で設計が成立するか？を考えるもので、設計というよりは、クラス図を検証するという方が近いのではないかと思う。勿論、設計行為ではあるけれど、あくまでもどちらかと言えばという点で。
だから、大量のシーケンス図がある時点で、静的構造図で十分表現しきれてない、つまり設計が不十分なのだと思う。
動的構造図の一つに状態遷移図があるが、ちゃんと静的構造を書けてれば、どこに状態遷移が必要かはある程度明確になっているはず。処理先行で考えた適当なクラス図とシーケンス図からは、状態遷移が必要なことは見えてこないケースがほとんど。なぜならば、各クラスが持つメンバー変数がフラグとして使われ、それをシーケンス図で表現してるから、状態遷移で設計するという考えに行きつかないのだと思う。
まとめ
オブジェクト指向をベースに話を進めてきたが、オブジェクト指向というより、そもそもの設計という事を知らないんだと思う。
新入社員の時から、この辺の教育をOJTでしっかりやっていかないと、ソフトウェア業界やばいと思う。
ソフトウェアは、素人が適当に作ってもそれっぽく動いてしまうっていうところがいい面でもあり、悪い面でもあると思う。
少なくとも、ソフトウェア業界でお金をもらって仕事してる以上はしっかり教育受けて(勉強して)、しっかりしたソフトウェアを作れるようにしないと。