シリーズastah*で業務をまとめ、プログラムまでのトレーサビリティを取るのつづきです。
エンタープライズ系の開発をトレーサビリティをとって行う流れをまとめるとこんなかんじ。
・ユースケース図
↓
・アクティビティ図
↓
・（ユースケースシナリオ＝astah＊にない）
↓
・アクティビティの構成を示したクラス図
↓ ↓正規化
画面定義、帳票定義 ＥＲ図
前回ユースケースについて書きました（粒度について、今日付け加えておきました）。
今日は、アクティビティ図。
■アクティビティ図
アクティビティ図は、スイムレーンのあるものを使うことを考えます。
で業務の流れを、関連する人（スイムレーン）に分けて書くのが、アクティビティ図になります。
この場合、アクティビティをどうとるか？という粒度の話になりますけど、２種類考えられます。
（１）ユースケースをそのまま並べる
ユースケース間の関連、手順を調べるのに使います。
ユースケースシナリオの事前条件、事後条件を明確にするのに役立ちます。
（２）ユースケースを１段落として記述する
前回のユースケースの粒度（今日つけたし）たところに書きましたけど、担当者の手順は、
ユースケースより一段深いレベルにあたります。
このレベルで書く場合があります。
これは、ユースケースシナリオの基本シナリオ等のシナリオに対応します。
どちらのレベルで書くか、また分けることに意味があるか（（１）と（２）がほぼ同じという業務もある））など、まあ、バリエーションはあります。どっちも重要です。どっちで書いてもいいです。ただ、トレーサビリティを考える場合、どちらのレベルで書いているかを意識しないと、ユースケースシナリオとの対応がとれなくなってきます。
■astar*での図
「基本情報２１年秋 問５」をもとに、astah*で作ってみました。
(上記（１）のユースケースを並べたレベル）
■トレーサビリティ
・ユースケースに出てくるアクターが、アクティビティのスイムレーンに現れているはず
逆に、アクティビティのスイムレーンは、必ずしもユースケースのアクターになっているわけではない。
上の例の顧客のように、コンピューター化されないけど、手順として必要な場合があるので。
・ユースケースに出てくるユースケースは、アクティビティ図のアクティビティと
同じか（上記（１）のケース）
または
詳細化されたもの（上記（２）のケース）
となっている。
っていうかんじ。厳密にトレーサビリティを取るなら、（１）を書き、その（１）のアクティビティそれぞれについて（２）の図を１つづつ書けば、トレーサビリティが取れるってことになる。
次回は、ユースケースシナリオ
アクセス
トータル
ランキング
