身も蓋もない言い方
設計は沼であり、大事な仕事・作業・人間生活にかかることであればちゃんと武装して臨むべき。
UMLは可視化ツール
クラスを中心としたソースコードを書けば、対応するUMLは半ば機械的に生成できる。 UMLは地図であって、極地的な地形であってもとりあえずそのままに書けてしまう。
良い設計は、コンセプトを伴ったパターンを持つことが一種指標に思える。 例えば、クラス図は汎化を表現できるが、以下のように指向するとよい設計につながる。
- あるデスクトップアプリケーションのデータ書き込み処理は、同じデータを固定長レイアウト、JSON形式、CSV形式の３パターンで表現する。
- ３パターンの形式を決定するのは、書き込み時にGUI指定する。それ以外のファイル書き込み時のハンドリングはすべて共通。
- それぞれの派生クラスを「生成」し、後続のファイル書き込み処理に、書き込みデータ供給の共通インタフェースを通じて処理をさせる。
こう言葉で書くとながったらしいことを、UMLは記号化してくれる。 しかし、この複雑さを簡略化はしてくれず、説明を端折ると謎の図になる。
実装パターンを豊富に知っているのであれば、思いつくままパズルの要領でつなぎ合わせて６，７個ぐらいの概念を同時に入れたところで依存性の糸の絡まり具合を可視化し、ここは切れるとかこの概念は相性が悪そうだとかを診断するためのツールになる。
初学者にとってのUML
まだ学生の頃にカリキュラムとしてUMLを触れた当時は価値がわからなかった。 簡単なMVCモデルの１画面をクラス図に書いただけで整理の必要が全くなかったのが一番の原因だが、 複雑なものを表現したとしても、知見不足で書いてみたのでは結局わからずじまいだったかもしれない。
そもそも、UML関連の学習コンテンツは説明が悪いことが多い。 「集約とは、集めて持つことである」「包含とは内部にオブジェクトを隠ぺいして持つことである」「依存はそのクラスを使っていることである」 と定義はわかるのが、なんのために依存するとか、この構造を持つことで特定の処理時にパターン化できるとか、ケーススタディ的な学びがUMLと一緒にできる例についに出会うことはなかった。 「設計とかコーディングのときに気づき内省しものにせよ」と寿司職人さながらのマインドはまだしも、UMLは握ってモチベーションに駆られるかの観点から題材の悪さしか印象にない。
設計とUML
UMLは良くも悪くも可視化ツールだ。 なので、パターンとコンセプトのある設計を表現してみて確からしさを検証するための手遊びの道具であり、 実際の実装や他の図と反復しながら多角的に検証したり、豊富なナレッジベースを並べてみて組み合わせを評価するのが一番道具として生きると考えている。 もし、UMLがしっくりこないとか意味が解らないのであれば、少し仕事や勉強から逸れたことをして、思い切り複雑で新しいことをしたときにでも思い出して無理やり書いてみるとどうだろうか。
