「astah*を使って、開発の要求仕様から、プログラム作成までを、トレーサビリティを保って、どのように開発するかを書いてみる」という、このシリーズ、以下の手順で説明する予定ですが、
(1)作るべきもののユースケースを書く
(2)ユースケースシナリオを書く
(3)ロバストネス分析
(4)バウンダリ(画面)、エンティティ(テーブル等)の属性を埋めていく
(5)バウンダリの項目を元に、画面構成を考える。
(6)(必要があれば)エンティティを正規化して、ER図にする
(7)フレームワークを決定する
(8)画面クラスをソースコードに書き直す
(9)エンティティをDBのテーブルと、DAOに書き直す
(10)コントローラーを書き直す
今回は、「(1)作るべきもののユースケースを書く」について。
■ユースケースを書く
システムを開発する際、コンピューター化したい部分があると思います
(なければ、開発仕様と思わないはず)。
その、コンピューター化したい部分を書きます。
その部分をユースケースとしてあげて、ユースケース(楕円)に関係するヒト(入力データを入れるヒト、出力を受け取るヒト)を、アクター(人型)としてあげて、ユースケースとアクターをつなぎます。
アクターは、ヒトと書きましたが、他システムの場合もあります。
ユースケースは、コンピューター化したい部分=コンピューターが、することになりますので、動詞で書くのがいいのでしょうが、名詞で書いてくる人もいます。
ま、以下のような感じです。
![](https://blogimg.goo.ne.jp/user_image/37/74/42754496a2f16b7b6b52bddd211bb104.jpg)
■ユースケースを先に書くことも
はじめにユースケースを書く、というのがお作法なのかもしれませんが、実際、ユースケースが多くなると、漏れが出たり、複雑になりすぎたりします。
そこで、ユースケースレベルで、アクティビティ図を書いてしまう場合もあります。
本来、アクティビティ図は、ユースケース図を詳細化した、ユースケースシナリオレベルで書くのが、正しいお作法なのでしょうが、それよりも、もっと大きな、ユースケースレベルで書いたほうが、全体像が見やすく、漏れが少なくなる場合があります*。
*漏れが少なくなる理由:アクティビティ図は、時系列的に考えます。なので、作業を順々に考えていき、飛び越すと、気づくことが多いです。一方、ユースケースは、ただひたすら挙げていくだけ(順番関係なし)なので、挙げ忘れることも、あります。
ユースケースレベルでアクティビティを書くと、こんなかんじ。
![](https://blogimg.goo.ne.jp/user_image/14/41/746c2b6077296118e87e9916b6d67d1a.jpg)
とくに、まず、現状を分析して(as-is)、本来こうあるべき(to-be)というのを考え、システム化する場合、まず、
・現状のアクティビティ図を描き、
・そこから、この機能は、コンピューター化すべきというアクティビティを選び
・コンピューター化する部分をユースケースでまとめる
などという場合は、ユースケースレベルのアクティビティから入ることもある。
次回は、ユースケースシナリオ