シリーズ「開発の初めから順番に書いていってみる」の続きです。
今、外部設計の段階で、要求仕様から、詳細設計までの間（ここを外部設計と、ここでは読んでいるわけですが）の手順は、以下の手順で行うと、流れに飛躍がなく説明がつくということを書きました。
（１）入出力の媒体をきめる。
（２）その媒体ごとにフレームワークを決定する。
なければ、入出力方法を決定する。
（３）そのプロセスの起動方法を考える
なければ、起動モジュールを考える。
（４）起動モジュールから、（２）の呼出し手順を考える
→そうすると、処理部分だけ、のこるはず。
（５）その処理部分をどうするか、考える。
（６）そうすると、細分化された入出力、処理部分ができる。
ここで、あわせたいものは、あわせる
→特に画面を、いくつか合わせて１画面にすることが多い
（７）処理部分を、ワーカーさんに渡せるまで落とし込む。
前回までで、この内容について説明しましたが。。。
■実際には、このようにやっているわけではない
実際には、入出力と処理部分に分けるという概念はあるのですが（富士通が公開している開発標準もＵＩとＳＳにわかれている）、実際には、このように、流れるように進んでいるわけではないですい。
というのも、入出力と処理部分をわけて、入出力部分を全部、フレームワークないしは、共通化しないと、入出力部分を勝手にやられて（恣意的に作られて）こまるというのは、実感ではあるのですが、体系的に、意識されているわけではないということと、飛躍のない詳細化の手順が、担当ＳＥの中で明確に意識されていないので、なんとなーく、仕事をこなしてしまうことになります。
で、外部設計の実際は、こんなかんじです。
（あ）フレームワークの確認から、全体的なプログラムの書き方を決める
（い）画面の設計をする
（う）ＤＢの設計をする、（その他外部の設計をする）
（え）プログラムを適当に詳細化し、詳細設計に持っていく
つまり、この間に明確なつながりがなく、そのことが、さまざまな問題を引き起こしています。
ということで、次回から、上記の実際の外部設計の手順に照らして、今まで説明したことと比較して、どこに問題があるのかなどについて、書いていきます。
副詞的世界という話も書いたので、それについても書きたいと思います。
アクセス
トータル
ランキング
