RFPからプログラミングまで、シームレスに開発する方法、以下の図
のうち、説明していないのは、⑦のみとなりました。
今回は、その⑦について。
結局、各種定義書によって、ユーザーインターフェースの部分のクラスはある程度自動的につくれて、業務流れ図から、(ビジネス）モデル部分のクラスとメソッドのスケルトンまでは作れるということは書いた。
で、問題は、ビジネスモデルクラスのメソッド内部になる。
ここには、
・データを受け取り
・処理加工し
・データを出力する
ということを書くことになる。
これは、シーケンス図でかけるかというと。。。
引数の値の設定とか、細かいことは書けない。
しかし、細かいことに、業務の重要なことが書かれている。
・A社の場合は、請求書に価格を入れない（理由は聞くな ＾＾；）
とか・・・
なので、そのクラス内部に関しては、業務記述、ユースケースシナリオに記載された内容を基に考えるしかない。しかし、それだと、ユースケースシナリオは、プログラミング可能な書き方で書いてあるとは限らないので、矛盾のないプログラミングがかける保証はない。
ちなみに、DFDのミニスペックは、業務記述に相当すると考えれば、一番詳細化されたメソッドに対しては、プログラムは(ミニスペックから）書ける。
しかし、それより上位のプロセスに関しては、DFDを詳細化するだけで、ミニスペックは普通書かない。ということは、この上位のプロセスで制御構造（IFやWhile）を書かれることがないので（DFDに制御構造を書かないから）、上位のプロセスに対応するメソッド内に対して、制御構造が書けない＝プログラムが書けない。
じゃ、矛盾のないプログラムは書けないかというと、このメソッド内部を、仮にプログラムに対応したフローチャートで書いたとする。これは書けるだろう、プログラムが書けるなら・・・
そして、フローチャートを最終的には、既存のメソッド、言語ライブラリ関数しか使わないレベルまで詳細化して書いたとする。
そーすると、結局、フローチャートが正しいかどうかっていうことが証明できればいいことになる。これはHoare論理の世界になってくる。
ここで、形式仕様とUML,業務が全部つながってくる。
つまり、UMLのクラス図のビジネスメソッド内部に業務を記述することになるが、ここの正確さを期したいのであれば、形式仕様が利用できると・・・全部形式仕様だときついけどね・・・
たぶん、それが、ここの
UMLと形式手法のハイブリッド仕様？
http://monoist.atmarkit.co.jp/fembedded/articles/robocon/etrobocon2009/09/etrobocon09c.html
って、この発言したの、鄭 顕志先生じゃないですか（＠＿＠！）
アクセス
トータル
ランキング
