PR

企業情報システム開発の目的は美しい芸術作品を作ることではない。ビジネス上有益な情報を生み出すことだ。純粋なオブジェクト指向は考え方としては美しいかもしれないが,そこにこだわっては企業情報システムの使命を果たせない。アプリケーションが使われる現場をきちんと見極めて現実に即した分析や設計,実装を心がけることが大切である。

(本誌)

フレームワーク
フレームワークはアプリケーションの骨格であり,おおまかな処理の流れを決めるものだ。複数のクラスが連携し合って一つの処理を進める。開発者は,アプリケーション固有の処理のみを実装する。これをフレームワークが用意するものと入れ替えることで,アプリケーションを開発する。実際には,フレームワークが提供するクラスを継承して実装する(本誌)。
図1●フレームワークを利用したWebアプリケーションの例
主要なクラス関係を示している。網掛けされているものは,フレームワークが提供する基底クラスやコンポーネントである。ServletBaseとHtmlTableHandlerは,ユーザー・インタフェースやサーバーとのデータの受け渡しを担当する。中央のHtmlFormは,ビジネス・ロジックを実装する部分だ。右のQueryAgentやClientRowSet,QueryActionは,データベース・アクセスを司る。開発者は,アプリケーション固有の部分だけ実装すればよい。それが白抜きの部分である。なおHtmlTableHandlerとClientRowSetは,CustomFormの中で利用される。一つのCustomFormに対して,HtmlTableHanderとClientRowSetは複数存在し得る。

 J2EE(Java 2 Platform, Enterprise Edition)は,複雑なアーキテクチャと実践的でないデータモデルという二つの問題を抱えている。どちらも,小手先の工夫では解決できない。これらを解消し企業情報システム開発を成功させるには,根本的な発想の転換が必要である。

 ここで,二つの問題を整理しておこう。一つ目のJ2EEのアーキテクチャの複雑さは,さまざまな技術の集合体であることに起因する。それぞれを深く理解し,適切に利用するのは難しい。

 もう一つのデータモデルの問題は,純粋なオブジェクト指向と企業情報システムで広く使われているリレーショナル・データベース(RDB)のデータモデルの違いから生じる。データ変換の手間が発生し,生産性が落ちる。インピーダンス・ミスマッチと呼ばれる問題である。

 このような現実に対処する適切な方法論は,いまだ存在しない。米Sun Microsystems社は「Enterprise BluePrints」というお手本を用意しているが,実システムに使うには理想論的すぎて非現実的だ。

実装ポイントを局所化する

 J2EEベースのシステムをEnterprise BluePrintsに沿って実装すると,コーディング量が多く構造も複雑になる。単純なWebアプリケーションでも,Enterprise BluePrintsに準拠した手法で実装すると相当な規模に達してしまう。

 この問題には,学術的な設計パターンでは対処できない。現実的な解決策を考える必要がある。その一つとして,フレームワークの利用が挙げられる。

 フレームワークは,アプリケーションに共通する基盤の部分を実装したソフトウェア部品である(イラスト)。いわば,アプリケーションのひな型だ。アプリケーションの開発者は,フレームワークの作法に従って独自の機能だけを実装する。

 具体例を見てみよう。図1[拡大表示]は,フレームワークを使って構築したWebアプリケーションの例である。ここでは,筆者が開発の責任者を務める「WebWorkBench DeveloperCafe」というフレームワークを利用している。

 開発者が実際にコーディングする必要がある個所は,白抜きで示された部分だけである。図1では,画面表示を記述するJSP(JavaServer Pages)ファイルと,CustomForm,CustomQueryActionという二つのクラスである。

 JSPファイルは,ユーザー・インタフェースを担う。画面表示は,システムの種類や利用局面によって変わる。当然,アプリケーションごとに画面を開発する必要がある。

 アプリケーション固有の振る舞いを実装するクラスがCustomFormである。フレームワークが提供するHtmlFormクラスを継承して作成する。フレームワークの動作に必要なデータや振る舞いはすべてHtmlFormが持っており,差分だけをCustomFormに記述する形となる。アプリケーションに特有のロジックなどを記述する。

 もう一つのCustomQueryActionは,各アプリケーションで必要なデータの操作を担当するクラスである。データベースに発行するクエリー(SELECT文)や,永続化の対象となるテーブルがどれかなど,いくつかのプロパティを持つ。振る舞いも一部持っている。例えばデータのトランザクション管理の中で,アプリケーションに固有の部分である。

フレームワークが複雑さを解消する

 フレームワークを利用すると,J2EEの複雑さをかなり解消できる。具体的には,(1)人的資源の問題,(2)保守性の問題,(3)生産性の問題だ。

 フレームワークは多くの場合,J2EEの技術を組み合わせて作られている。これをひな型として利用すれば,スキルのそれほど高くない技術者も比較的容易に開発作業を進められる。つまり(1)の問題を解消できる。

 またフレームワークは,システムを均質化しやすい。設計の大枠を決めてしまうし,実装個所を局所化するからだ。これで(2)の問題にも悩まなくて済む。

 (3)の問題も解決できる。フレームワークが担当する部分の設計や分析,実装の手間が省けるからだ。

 ただし,フレームワークならどんなものでもよいわけではない。ここで述べた三つの問題を解決するには,フレームワークの中でも機能の豊富なものを選択する必要がある。

 フレームワークの種類はさまざまある。多くのアプリケーションに共通するごく基本的な機能しか持たないものから,そのままで一つのアプリケーションになりそうなほど豊富な機能を作り込んでいるものまで幅広い。機能を基本的なものに抑えていればフレームワークの汎用性は高まるが,開発者が作り込む部分が多いためJ2EEが抱える問題は残り続ける。その点機能が豊富なフレームワークは適用範囲が限られるが,システム開発にかかるコストは削減できる。

長尾 寿宏 Toshihiro Nagao

テンアートニ 第一事業部執行役員,プロダクト開発グループマネージャー
1986年,コンピュータと無縁な早稲田大学社会科学部を卒業。最初の職場で初めてコンピュータと出会う。汎用機とCOBOLに始まり,ダウンサイジング,オープン化,Web化と激しく変化する環境の中でシステム開発の現場に身を置く。1998年テンアートニに入社,数々のJava+Webシステム開発プロジェクトのリーダーを務めながら,Java開発基盤の整備を推進。同社のWebアプリケーション構築フレームワーク製品「WebWorkBench DeveloperCafe」の開発責任者である。