« 設計とプログラミングの互換性 | トップページ | DB設計が楽しくなければたぶん失敗している »

2011.04.21

開発効率化のための基本戦略「類型化」

 多種多様なプログラム群をどのように類型化するか――これは考える価値のある問題だ。開発すべきプログラムを分類することが、開発作業を効率化するための基本戦略だからだ。的確な分類体系さえあれば、これを起点として素朴なスケルトンやテンプレートの整備から始まって、プログラムの自動生成や動的制御といった高度なしくみまで、多彩な工夫を始められる。

 では、本ブログのテーマである「業務システム」に含まれるプログラムについてはどうか。それらをどのように類型化すればよいのか。このソフトウエア分野は「比較的複雑な構造を持つDBシステムを操作するためのソフトウエア」として性格づけできる。必然的に、プログラムの分類体系には処理されるDB構造のあり方が反映されるだろう。言い換えれば、DB構造を考慮しない限り、開発を効率化するために意味のある類型を想定することは難しい。

 たとえば、DB構造ではなく「UI」に着目してプログラムを類型化することは可能だろうか。可能ではあるだろう。しかし、それで類型を想定できたとしても、それぞれの類型が処理するDBの構造になんらの規定もないとしたら、その体系からDBシステム開発を合理化するための機構が生み出されるとは考えにくい。なにしろ複雑なDB構造を相手にしているのである。DB構造に応じたデータ処理ロジックが機構によって手当されないのでは、効率化の決め手にはなりそうにない。

 では、オブジェクト指向のいわゆる「デザインパターン」ではどうか。それらは有用な知見ではあるが、適用すべき問題のレイヤが異なる。デザインパターンはプログラミングされるべきモジュールのクラス構造に関する指針を与えるものではあるが、モジュールが操作するDBの論理構造までを規定するものではない。UIと同じ理由で、効果は限定的と言わざるを得ない。

 ようするに、プログラムを類型化するために優先的に注目すべき側面は、業務システムにおいては「UI」でも「オブジェクト」でもなく、「DB構造」である。複雑なDB構造を扱うというソフトウエア分野の特性からいっても当然の結論ではある。

 では、どのような手順でDB構造にもとづく類型化を進めたらよいのか。まずはDB構造の位相(トポロジー)を体系化する。つぎに位相の組み合わせの中から慣用的なものを洗い出し、それらにCRUD(テーブル操作の種別)を掛け合わせる。これで「データ処理パターン」がまとまり、それらにUIを対応させれば類型の一覧が出来上がる。

 最終的な目標は、それらの類型にもとづいて自動生成なり動的制御なりの機構をプログラミングすることだ。そのしくみを用いて、必要なデータ処理機能をなるべくプログラミングせずに組み立てるためである。なぜならプログラミングこそが、もっとも手間ひまのかかる作業だからだ。言い換えれば、そのような合理化のための機構を生み出せないとしたら、ソフトウエアの類型に関する知識として有用性があるとはいいがたい。

|

« 設計とプログラミングの互換性 | トップページ | DB設計が楽しくなければたぶん失敗している »

コメント

こんにちは。データモデルのパターンについてはいつも考えているのですが難しい問題です。DB構造の位相(トポロジー)というのは幾つかのエンティティとその間のリレーションのパターン等を指すのでしょうか?
大規模な構造のパターンを見出せれば強いのですがそこまで考えが至りません。
Martin Fowler「アナリシスパターン」は問題設定は似ていますがOOAとODAの違いがあるように思います。
またこのトピックを扱っていただければ嬉しく思います   !

投稿: モノリス20001 | 2011.04.21 13:22

モノリス2001さん

DB構造の位相というのは、私の言う「親子関係」「参照関係」「派生関係」といった、テーブル間の論理関係のことです。どんなに複雑に見えるDB構造も、それらの位相の組み合わせとして整理できる。そして、整理された構造のどの部分を慣用的なものとして切り出して、パターンの基礎とするか。これを判断するのは簡単ではありませんが、検討する意義があります。

「アナリシスパターン」ですか。以前に読んでピンと来なかったのですが、再読してみます(^^;

投稿: わたなべ | 2011.04.22 09:27

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 開発効率化のための基本戦略「類型化」:

« 設計とプログラミングの互換性 | トップページ | DB設計が楽しくなければたぶん失敗している »