きのうの、UMLのアクティビティ図の文章化の必要性と方法に、従来、プロパティといって引数が入っていないのに入れた理由について、ちょっとかいておきます。
このシリーズの前回の話で、こんなことが書いてありました。
●主語がおかしいものはないか？
２．２．２．１．２ 製造部は資材を入庫する
ほんとう？？倉庫係じゃなくって？？などという話。
前回は、倉庫係が、製造部の中にあるのでＯＫとしましたが、これ、倉庫係は、倉庫部っていうところにあったとします（ちょっと変だけど、会社によっては、そんなのもあるかもしんない）
そうすると、そのあたりは、
２．２．２．１ 資材がない場合
２．２．２．１．１ 製造部は資材を発注する
２．２．２．１．２ 倉庫部は資材を入庫する
２．２．２．２ 資材がある場合
で、これで、あと、倉庫部というレーンをつくって、そこに、資材入庫というアクティビティを書けばＯＫです。図も問題ありません。。。
でも、この業務、無理です。
倉庫部が入庫するとき、検品するはずです。ところが、発注データ（発注票）は、製造部から倉庫部にわたってないので、検品（＝発注データと納品されたものが一緒かどうかの確認は）できません。
どうして、こんなことが起こっちゃったかといえば、わかりきった作業なので、発注データ送付という業務は、無意識に抜けたんだと思います。
でも、もし、この発注データを送るというアクティビティが抜けてしまえば、その機能は後から追加しないといけないということになります。これを指摘するには、アクティビティが動作する際、必要な情報がすべてそろっているか、確認することです。
今のことを言い換えると、あるアクティビティを行うのに、必要な情報は十分足りているかどうかのチェックをしていないと、アクティビティを抜いてしまい、機能追加という危険性があります。
ところが、情報を記入しないアクティビティ図では、このチェックはできません。
さらに、上の偉い人は、情報が足りているかどうかすら、分からないことがあります。
ウィリアムのいたずらに仕事を依頼する人は、よくこんなことをいいます。
「足りてないもの、ほかに必要な情報があったら、すぐ言ってください」
この言葉を裏返しにすると、「わたしは、仕事を頼んでいるけど、仕事に、どんなことが必要になるか分かっていません」ということになります。結構、このケースが多いです。
ということは、アクティビティ図に加えて、（入力）情報が足りているかどうかのチェックが必要です。しかし、偉い人が、このアクティビティについて説明する場合、自分も、情報について分かってないので、その部分は書けません（作業手順だけなら言えるけど）。
形式仕様言語の場合、メソッドの引数、つまり、入力情報が足りているかどうかのチェックをしているため、このような情報が足りないということは、エラーとなって分かります。
でも、逆に言うと、メソッドの引数がわからないと、つまり、ちゃんと定義できないと、書けません。そしたら、いつまでたってもたたき台ができません。
そこで、前のケースでは、普通のアクティビティ図のように、アクティビティだけを描くのもＯＫ，そこが完結すれば、青くなります。そしてさらに、情報についてチェックするため、プロパティをつけて、そのプロパティで、入力引数と出力について、定義し、そのプロパティも問題なければ、白色になるという２段階の方法にしています。
アクセス
トータル
ランキング
