那須です
皆さんは開発をする際、きちんと仕様書を書かれていますか?私は、普段開発をする際、きちんとしたドキュメントを作る機会が少なくなっていたのですが、現在手がけているプロジェクトがそこそこの規模を持っており、使い捨て前提のフリーハンドで書いた仕様書だけでは仕様の理解が追いつかなくなっています。
そのため、最近JUDEでユースケース図を描くようにしました。個人的にはユースケース図というと
- クライアントと認識をあわせるためのツール
- エンジニアに全体の理解を促すためのツール
という印象で、ユースケース図からユースケースを作り、そこからクラス図などをおこしていくものと考えていました。ですが、今のプロジェクトでは、ユースケース図を使い、そのまま実装レベルで使えるような工夫をしています。今回は、そのことをちょっとまとめておきたいと思います。
前提
応用がきかない場合もあると思いますので、あらかじめ前提を述べておきます。似たような環境でしたら、大丈夫とは思いますが。
- プログラミング言語: PHP5
- フレームワーク: Symfony
- 開発エンジニアは、全員Symfony経験者
ユースケースからプログラム設計へ
さて、↑のユースケース図は、トラックバック機能を模したユースケース図です。特徴として、ユースケースをパッケージで囲んでいます。このパッケージは、そのままSymfonyのモジュールとなります。そして、ユースケースが アクション(メソッド)となります。と、これだけです。まあ、大したことはないのですが、モジュールとアクションで処理が分別されるようなWebアプリケーションでは、これだけでもかなり有用と考えています。
記号の意味
| 記号 | 実装上の意味 | 備考 |
|---|---|---|
| パッケージ (タブのついた長方形) |
モジュール | |
| ユースケース (楕円) |
アクション | |
| ユースケース同士の誘導可能関連 (矢印) |
Webのリンク | TB一覧にTB削除処理に リンクするボタンがある等を示唆する |
| ユースケース同士の誘導未定関連 (直線) |
関連 | ノートなどで関連の意味を示唆し 意味づけをする |
| 依存 (破線矢印) |
そのパッケージを利用するアクターを示唆する | ※ホントは普通に関連(直線)でやりたかったのですが アクターとパッケージは関連付けができないための代替策 |
最後に
とまあ、勝手にユースケースを拡張してWebアプリケーション開発に使いやすいようにしているのですが、いかがでしたでしょうか。他にもモジュール間で”継承”記号を使ったりしているのですが、Symfonyでは、モジュールを継承することがないため、あまり意味を成していません。まだまだ不完全な形ではありますが、現在私が行っている試みとして、ここまでを紹介したいと思います。
超短期開発を求められる場合でも、この程度のドキュメントであればそれほど時間を使わず作ることができるため、これをもっともっと洗練させることで、クライアントとの認識のズレを最小限にしつつ、エンジニアにそのまま開発をしてもらうということができるようにしていきたいと考えています。
