プログラマーにとっての『UMLっぽい何か』
April 1, 2013 - プログラミング
わりと普遍的な話題だったので便乗です。
とか、
- UMLは設計の技法ではない
- 頭の中を整理するため、あるいは人と共有する際の表現技法である
UMLの厳密な書式ルールには全くこだわりはなく、大まかなイメージだけ伝われば、細かい部分は口頭でフォローすれば十分だと考えていています。そういう意味ではUMLを正しく使っているとは言えないのかも知れませんが、それはそれでいいんじゃないのと。
は、まったくもって同意見で、「UML」という”なんだか面倒くさそうなイメージ”を捨てて、コードを整理もしくは伝達する補足的なものとして扱うことが大事だと思います。UMLを本を読んできっちり勉強する必要もなくて、英会話が完璧な文法に則る必要がないのと基本的に同じだと思います。
所謂SEが用いるUMLではなくプログラマーにとってのUMLは、もっとくだけたもので良いのです。
いつやるか
どのフェーズでこの図の作成にとりかかるかが問題になると思いますが、自分の場合は以下の場合に作成を試みることが多いです。
（主にクラス図作成の場合を想定しています。）
1. プロトタイプ的に作り始めたコードが、ある程度育ってきて全体が見えづらいと感じた時
これは自分のために作成するもの。なのでUMLのルールに準拠する必要はありませんので、どちらかといえば書き捨て型といえます。
（※ドキュメントの無いコードを読む場合も書き捨て型で作成します。）
そして、この図をもとに設計を見なおしたりします。
2. 自分が作ったコードを他の誰かが読む時
これは他人のために作成するもの。すでに設計が固まった段階のコードを追いかける上での補足情報になります。
完全にUML準拠する必要はないでしょうが、ある程度は従ったほうが余計な誤解もなくなるかもしれません。1である程度整理ができているのでこの段階での作成は非常にそれ程苦ではないはずです。
どちらの場合もコードありきで、後追いでの図形作成になります。注意すべきなのは、図にすべての情報を詰め込むわけではなく、必要最低限の情報に留めることで図をシンプルに保つことは必要です。
とまぁ、これくらいシンプルなルールであれば、普段の開発フローに取り入れることはさほど大きなコストではないと考えます。多くの人はこれくらいのことはやっているんじゃないかとは思いますが、先のブログでも書かれている通り表立って議論されることはあまりないように感じます。
図を描くためのツール
図形作成のためにいちいちastah*やExcel()のようなアプリケーションを立ち上げるのは面倒ですよね。
Google Driveの「図形描画」や「プレゼンテーション」がオススメです。きっちりUML準拠の図を作成するわけではないので、クラス図(もどき)ならこれで十分ですし、共有も簡単です。シーケンス図はちょっと書きづらいかもしれませんが、そんな時はノートやホワイトボードに書いたものを写真に撮って適当な場所で共有すればOKでしょう。
ところで、オブジェクト指向の場合ではなく、（純粋）関数型の場合はどうなのでしょうかね。数式？