▲ このウインドウを閉じる |
Little wealth, little care. |
DOA と一口に言っても、対象領域(立脚点)が違えば、考えかたも違うし、 OOA といっても、おそらく、そうでしょう (SmallTalk を対象にした考えかたもあれば、Java を対象にした やりかた もあるでしょう)。僕自身は、オブジェクト主導に関して、SmallTalk を前提にした青木淳さんの考えかたに共感しています。 世間では、僕は、 DOA の一派だとみなされているようなので、僕は「 DOA + (Data-Oriented Analysis)」という言葉を使っていますが、精確に言うなら、僕の考えかた (T字形 ER手法) は、「言語の形態論」に近い、と思っています。
DOA を一言でまとめる概念は、おそらく、「データの独自性」でしょう。そして、「データの独自性」を、どのように考えるか、という点が、 DOA のなかで、色々の流派が出る理由でしょうね。
いっぽう、T字形 ER手法は、「データの独自性」を、もっと「強い」意味で考えていて、コッド正規形が提示した「data-independence」という考えかたを立脚点にしています。したがって、データ構造を対象にしていますが、プロセス構成(プログラムのアルゴリズム)を対象にしていない。したがって、T字形 ER 手法は、あくまで、データベース設計論のなかで生まれた手法です。
したがって、 DOA と一口に言っても、概念設計 (意味論) を目的とした手法もあれば、データベース設計論としての手法もあります。
しかも、 DOA は、事業のなかで扱われるデータを対象にしていますので、事業のデータを前提にして対比しなければならないでしょうね。 企業向けのシステムを作ることは、「特殊な」形態だと思ったほうが良いでしょう。「特殊」という意味は、そういうシステムでは、「事業の論理」が成立している、ということです。したがって、企業のシステムを対象とするなら、事業を効果的・効率的に進めることを第一義に考えなければならない、ということです。事業過程 (購買過程・生産過程・販売過程・労務過程・財務過程) のなかでおこなわれている仕事を効果的・効率的に実現する方法を導入する、というのが事業のシステム化でしょう。
SE およびプログラマが、コンピュータ技術を、専門家として、第一義に考えることは当然のことなのですが、いっぽうでは、自らの技術が、事業のなかで、どのように貢献できるか、という点も考えなければならない。 エンジニアが自らの技術を最高だと思いあがることは害のない自由ですが、企業向けのシステムを作る際、事業に貢献することを考えない、というのは、技術の専門家として、ethics に抵触する行為です。 (2004年1月23日)
|
▼ このウインドウを閉じる |