ふと思ったんだけど・・
UMLのアクティビティ図自身には、本来、データを記入する部分がない。
そのため、これ自身では、データの流れを示せないため、ここからユースケースにおとして開発にすぐに入ると、データが確定しない。
このデータが確定しないということは、逆に言うと、データが決まらないため、仕様変更になりやすく、下流工程で大きな問題が起こる。
そのため、UMLにはないER図でデータ部分を確定させる。
しかし、もしかりに、ここでアクティビティ図を作らず、データ中心に分析した場合(ER図からできる形になる)、業務の動きを止められないので、業務部分のあいまいさがのこる。このあいまいさから後で、「あ、この業務を忘れていた」ということで、業務を追加され、データ矛盾を引き起こすことがある。
っていうふうにかんがえると、アクティビティ図は、業務の動きをとめ(固定化させ)、承認をとるという役割にはいいかもしれない。
ここで、業務が固定化されれば、データも固定化され、仕様変更になりにくくなる可能性がある。
ってことで、データの動きを止めたい(固定化したい)という目的で、まず、業務を固定化させるという意味で、データ記述のないアクティビティ図を利用するのは、アリだなあ。。