前に書いた、「生物の構造と、要求から、プログラムまでの階層を比較すると、わかりやすいかも！」というところで、ソフトの場合は、基本操作からアクティビティまで、ソースコードとしてかきます。この問題や発展の可能性は、今後、別の回で書きます。ってかいていたので、その話についてかきます。
■なんでもソースに落としてしまうところに問題がある
結局、ソフトの場合、入出力もライブラリも、足し算引き算も、ソートやマージといったある程度まとまった話も、さらには受注票作成といった業務も、全部、ソースコード上に落とされる。
っていうことは、「ソースを見れば分かる。JavaDocに入出力はすべてかかれるから便利」って主張する人もいるだろうけど、現実問題、なんでもごちゃごちゃ、恣意的にかけてしまって、何がなんだか分からなくしてしまう危険がある。
たとえば、ある人は、StrutsのActionの中で、JDBCのドライバから呼び出して、ユーザー名、パスワードをリテラルで設定して、SQLを発行することができる。
その一方で、ある人はDBアクセスライブラリを作成し、それは、モデルからのアクセスに限定し、Actionでは、モデルをアクセスするという形にもできる。
このとき、モデルをPOJOにしておけば、モデル単体でのテストや再利用ができる。
このどっちも書くことが可能というか、混在させることすら可能である。
実際には、ここまでひどくはないにしろ、やはり、恣意的に分けられる部分があって、そのことが、バグを招いたりしてしまっている。
■いっそのこと、外部仕様は、全部見える化＝＞自動生成にしてしまえば。。
なんで、外部仕様は、
・全部見える化してしまい、
・ドキュメントから自動生成したコードをリンクする、
・修正時は仕様書を直して再度リンク、
・個別プログラミングは、外部仕様書から呼ばれる関数部分のみ
ってできると、楽になってくると思う。
入出力部分に関して、ドキュメントから関数自動生成という話は、まあいいとおもう（というか、いつか、自動生成については、まとめて書くので、そのときに）
問題となるのは、ライブラリや入出力、詳細設計で書かれる関数をよびだすところを書く部分。
１つの考えとしては、Accessのマクロ画面のように、かけるというもの。
他には、詳細のドキュメントのように書く方法。。
フローチャートを書いてしまう方法。。。
いろいろありそうだが、このへん、つまり、図でもってプログラミングできるという分野が、今後発展する可能性がありそうな気がする。
そうして、外部設計が見える化してくると、あとは詳細部分のコーディングになるので、ある程度はなしが見やすくなるし、図式化することによって、（図の制限があるから）恣意的にやれる部分が減り、品質の安定にも役立つと思う。
っていうのが、問題の発展と可能性。
で、この話は、その前の要求から、プログラムまでの階層を考えないことが、開発の混乱を招いているを受けた話で、さらにその話の中で、アスペクト指向における横断的関心事の切り出しの問題や、デザインパターンの活用の話なんかは、月曜日からはなすこととして、と書いておきながら、書いてないので、このシリーズ？の次回は、その辺の話を書きます（って、いつ書くか分からないけど。。）
アクセス
トータル
ランキング
