ここのはなし
id:10229384668 screen_name:masayh
シーケンス図では順序を書く。これでは手続きはかけても関数型は表現できない、クラウドのeventual consistencyも表現できない。UMLはもうモデル表現としてはかなり終わりに近いと思います。
だけど、ＵＭＬというのは、ふつう、目的に合わせて、アイデアをまとめるものであって、
それだけで、自動生成させようとしたり、わざわざ、適用不可能とわかっている図を
目的外利用したりすることは、ないんじゃないかな。。。今、ＵＭＬを使っている人は・・
たとえば、ユースケース図からは、当たり前だけど、プログラムもテストも自動生成できない。
ユースケース「シナリオ」になると、このシナリオからテストケース、テストデータは作れるし
(書き方によっては自動生成も）、プログラムも自動生成できる場合はある。
でも、ユースケースシナリオは文であり、ＵＭＬではない（そもそも、図ではない）。
だけど、ユースケースシナリオの目次として、ユースケースとその関係者を出して、
アイデアをまとめるにはいい。その目的（他にも目的はあるが）のときに、ユースケース図を使う。
同様に、シーケンス図のときには、シーケンスな、つまり、順序だったものの関連を
書くのに使い、おもにシーケンスが必要な、複数オブジェクト間のプロトコルのやり取り
をかく。やりとりをかくので、このデータをどうセットするかという情報は、詳しく書かない
（なので、この部分のプログラムは自動生成できない）
ということで、シーケンスになっていないものは、シーケンス図で書かない。
シーケンスになっていても、シーケンスよりかオブジェクトが重要なときは、
コラボレーション図で表現し、もう、順序はわからないというときは、
ステートチャート図で、イベントに注目して書くべきなのかしら・・・
ってな使い分けを普通すると思うなあ・・・
なので、シーケンスになっていないものを、「シーケンス図が悪い」という批判は、しない気がする・・・
・・・のは、気のせい？
アクセス
トータル
ランキング
