シリーズastah*で業務をまとめ、プログラムまでのトレーサビリティを取るのつづきです。
前回、概要を話しました。エンタープライズ系の開発をトレーサビリティをとって行う流れです。
まとめると、こんなかんじ
・ユースケース図
↓
・アクティビティ図
↓
・（ユースケースシナリオ＝astah＊にない）
↓
・アクティビティの構成を示したクラス図
↓ ↓正規化
画面定義、帳票定義 ＥＲ図
今回から、具体論です。
まずは、ユースケース図。
■サンプルケース
サンプルとして、今回、前にも使っていた「基本情報２１年秋 問５」、航空券発券の問題で説明したいと思います。
問題は
ここ(PDF)
http://www.jitec.jp/1_04hanni_sukiru/mondai_kaitou_2009h21_2/2009h21a_fe_pm_qs.pdf
参照（２１ページから）
■ユースケース図
まず、そこに登場する人物や外部システム（アクター）と、その登場人物が行う処理（ユースケース）に関して、ユースケース図にします。
ユースケース図の場合、コンピューターに行わせたい処理を挙げますが、それを、アクターの業務目線で書くのが普通です（たとえば、空席を確認する、顧客情報を登録するとかいう形で挙げる。コンピューター目線だと、空席を表示する、顧客情報を保存するとかになっちゃうけど、こーいう形ではなく、ユーザーの業務をならべる（＝ただし、業務中、コンピューターを使いたい業務を並べる）
ユースケースについての説明は、検索すれば出てくるので、今回は書きません。
■トレーサビリティ
ユースケース図を一番トップに持ってきた場合、これと、アクティビティ図、ユースケースシナリオの間に、追跡可能となる情報があるのですが、それぞれの図の回で説明します。
■astar*での図
こんなかんじ
うしろにastah*とかかれるのは、コミュニティ版だから。
■トピックス－ユースケースの粒度（５月１３日つけたし）
ユースケースに関して、粒度という問題がある。
これについては、以下のように考えている。
＜＜ユースケースとしてあげるユースケースは＞＞
・担当者の上司に、「何々さん（＝担当者）って、なにやっている人？」といって、
答えが上がってくるレベル。
ユースケースシナリオでは、このユースケースについての詳細を書く。
その詳細は、担当者がやる業務についてかかれることになる。
このレベルだと、他アクターとの関連も見えるし、ユースケースシナリオやアクティビティ図との整合性も取れる。
ただし、このレベルだと、細かすぎることもある。
その場合は、いくつかにユースケース図を分けることになる。
そのいくつかに分けた図の目次というか、インデックスとなるユースケース図を作るかどうか？それとも、それはほんとに目次でいいか？ＤＭＭなど、他の図を使うか？っていう話に発展していくけど・・・
ま、それは、今回置いておく（＾＾；）
ってかんじかな。次回は、アクティビティ図。
アクセス
トータル
ランキング
