要求から、プログラムまでの階層を考えないことが、開発の混乱を招いている

　っていう表題にしたけど、その具体的な混乱、つまり、アスペクト指向における横断的関心事の切り出しの問題や、デザインパターンの活用の話なんかは、月曜日からはなすこととして、今回は、その階層についての内容。

---

プログラムを考えると、普通プログラムする人が扱えるのは、

　・言語が用意する関数、クラス
　・ＯＳのＡＰＩ
　・入出力のドライバ

である。これより下（ハード寄り、ファーム寄り）は、業務アプリの範疇ではない。

　まあ、これを、「ＯＳ／言語提供モジュール」とでもいいましょうか。。

　そして、ソート、マージ、帳票出力、ＤＢ入出力、ファイル入出力といった、基本的なプログラミング可能な機能がある。これを、「入出力と、基本操作群」とよぼう。
　基本操作に関しては、ここの「Javaで基本操作」に挙げた。

　そして、本来はこの基本操作を利用して、アクティビティ図のアクティビティ、ユースケース図のユースケース、ＤＦＤのプロセスは構成されるはずである。これを、「アクティビティ層」とよぶ。

　そして、業務は要求仕様において、アクティビティないしは、プロセス（＝アクティビティ層）に分解される。

　これを図式化すると、こうなる

業務
　｜＊１
アクティビティ層（＝アクティビティ等）
　｜＊２
入出力と、基本操作群（＝外部設計の世界）
　｜＊３
ＯＳ／言語提供モジュール


　ここで、重要なのは、「基本操作群」で、これに要求が落とし込めるか（つまり、受注というのは、ソート，マージ、編集、入出力を使って表現できるか）ということになる。

　なお、図に＊１、＊２、＊３と書いたが、この変換作業（＊にあたるところ）が、開発の作業になる

＊１：　業務をアクティビティに落とし込むのが要求分析
＊２：　アクティビティを入出力と基本的な操作に落とし込むのが、外部設計
＊３：　入出力と基本的な操作をプログラミングするのが、内部設計＆プログラミング

　で、プログラミングテクニックは、主に＊３のところに関係する。
　ワーカーさんに渡すレベルとは？で書いた、”ワーカーさんに教えておく”という部分は、上記の「基本操作群」部分ということになる（昔はおそわったんだけどね）。

　自動化の場合、＊２の自動化と＊３の自動化は全然意味が違い、＊３はやりやすいけど、＊２は難しい。再利用も同じ。

---

　ってことで、月曜日から、これをもとにしたお話をしようかと思ってます。