UMLの現実的な利用度合い

aojiruさんの書き込み (2004-09-17 15:19) より:
・ユースケース図→アクテビティ図→クラス図、シーケンス図
　と作成していくと、シーケンス図あたりはそれほど複雑でないアプリケーション
　でも、アクティビティごとに逐一作るので、すぐに大量になってしまうように思う
　のですが、現実の開発業務ではそれが当たり前なのでしょうか？

　それとも、似たようなシーケンスは書かないで、以下同文みたいに省略するので
　しょうか？シーケンス図も分析レベルと設計レベルでは粒度が異なりますが、
　特に後者についてはどう管理されているのかな、と思いました。

・シーケンス図はフローチャートとは異なるので、条件分岐とか繰り返しの表記が
　ないようですが、これが必要な場合はどう表現するのでしょうか？

　あとエラー処理（例外処理）が全て入ると見難くなるので、設計レベルの
　シーケンス図の場合は省略して、他のドキュメント（APIドキュメントとか、
　フローチャート？）にすべてを明記する、とか工夫するものなのでしょうか？

UMLは標準化のための道具として十分意味があるとは思うのですが、
具体的に詰めるとローカルルールが必要になり、運用面で強制力というか
一貫性を持たせにくいような気もしています、、、

aojiruさんの書き込み (2004-09-17 15:19) より:
はじめまして

・シーケンス図はフローチャートとは異なるので、条件分岐とか繰り返しの表記が
　ないようですが、これが必要な場合はどう表現するのでしょうか？

ukさんの書き込み (2004-09-17 16:39) より:
ユースケースの後に作成するアクティビティ図は何を記述したものでしょうか。
アクティビティ図は目的が特定されているものではないので、何を定義しているかを書いて
もらわないと答えようがありません。

七味唐辛子さんの書き込み (2004-09-17 16:45) より:


条件分岐とか繰り返しは　　メッセージラベルに　に記述できませんか　
線の上に表示されるやつです

aojiruさんの書き込み (2004-09-17 17:23) より:
アクティビティ図ですが、ユースケースのアクターから見てアプリケーションの
各操作ごとに作成するということなので、例えば、XXX検索処理、XXX登録処理、
XXX更新処理などについて、各々の入力条件とか出力値依存の遷移などが存在すると
先ずそれだけでアクティビティ図がたくさんできると思います。

そこからシーケンス図を各アクティビティごとに作るので、特にクラス名や
メソッド名などに落とした設計レベルのシーケンス図になると、量も多く、内容的に
似たようなシーケンスも出てくるのでは、と思いました。

ukさんの書き込み (2004-09-17 17:44) より:
[「ということなので、」というのはどこに書いてあることでしょうか。「アクティビティ」の単位は何になるのでしょうか?「各操作ごと」に作るアクティビティ図というのが想像つかないもので。

私の場合、基本的にシーケンス図はユースケース(場合によってはイベントフロー)ごとに作ります。よっぽど複雑なアプリケーションでなければ、粒度が小さすぎませんか?