ウィリアムのいたずらの開発日記

ウィリアムのいたずらが、コンピューター関係について、思ったことを好き勝手に書いているブログです。

astah*で業務をまとめ、プログラムまでのトレーサビリティを取る-その3 アクティビティ図

2010-05-13 12:03:06 | Twitter


 シリーズastah*で業務をまとめ、プログラムまでのトレーサビリティを取るのつづきです。

 エンタープライズ系の開発をトレーサビリティをとって行う流れをまとめるとこんなかんじ。

  ・ユースケース図
     ↓
  ・アクティビティ図
     ↓
  ・(ユースケースシナリオ=astah*にない)
     ↓
  ・アクティビティの構成を示したクラス図
    ↓           ↓正規化
   画面定義、帳票定義   ER図


前回ユースケースについて書きました(粒度について、今日付け加えておきました)。

 今日は、アクティビティ図。




■アクティビティ図

 アクティビティ図は、スイムレーンのあるものを使うことを考えます。
 で業務の流れを、関連する人(スイムレーン)に分けて書くのが、アクティビティ図になります。

 この場合、アクティビティをどうとるか?という粒度の話になりますけど、2種類考えられます。

(1)ユースケースをそのまま並べる
  ユースケース間の関連、手順を調べるのに使います。
  ユースケースシナリオの事前条件、事後条件を明確にするのに役立ちます。

(2)ユースケースを1段落として記述する
  前回のユースケースの粒度(今日つけたし)たところに書きましたけど、担当者の手順は、
  ユースケースより一段深いレベルにあたります。
  このレベルで書く場合があります。
  これは、ユースケースシナリオの基本シナリオ等のシナリオに対応します。

 どちらのレベルで書くか、また分けることに意味があるか((1)と(2)がほぼ同じという業務もある))など、まあ、バリエーションはあります。どっちも重要です。どっちで書いてもいいです。ただ、トレーサビリティを考える場合、どちらのレベルで書いているかを意識しないと、ユースケースシナリオとの対応がとれなくなってきます。




■astar*での図

「基本情報21年秋 問5」をもとに、astah*で作ってみました。
(上記(1)のユースケースを並べたレベル)






■トレーサビリティ

・ユースケースに出てくるアクターが、アクティビティのスイムレーンに現れているはず

 逆に、アクティビティのスイムレーンは、必ずしもユースケースのアクターになっているわけではない。
 上の例の顧客のように、コンピューター化されないけど、手順として必要な場合があるので。


・ユースケースに出てくるユースケースは、アクティビティ図のアクティビティと
     同じか(上記(1)のケース)
   または
     詳細化されたもの(上記(2)のケース)
 となっている。

っていうかんじ。厳密にトレーサビリティを取るなら、(1)を書き、その(1)のアクティビティそれぞれについて(2)の図を1つづつ書けば、トレーサビリティが取れるってことになる。




次回は、ユースケースシナリオ

ジャンル:
ウェブログ
この記事についてブログを書く
この記事をはてなブックマークに追加
« ホリエモン、年内にもメルマ... | トップ | 5月13日(木)のつぶやき »
最近の画像もっと見る

あわせて読む