サーバーサイド JAVA ビジネスアプリケーションフレームワーク 「Ｌｉｂｒａ」 システム開発構想 株式会社トータルソフト 下郡 禎之 Copyright (c) 2004 Totalsoft co,.ltd.(JAPAN). Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". 1 研究開発の目的及び動機 1.1 動機 ビジネスアプリケーション開発の生産性向上および品質確保の観点から、昨今の開発 では、フレームワークを活用したプロジェクトが主流となっている。フレームワーク とは、アプリケーションを構築する上での「枠組み」 「ルール」であり、アプリケーシ ョンの構造となるものである。 有力なベンダーの大半は、自社製フレームワークを開発・保有しているが、中小のソ フトウェアハウスで、自社製フレームワークを開発・保有している会社は少ないのが 現状であり、エンドユーザーから直接システム開発を受注するために不利な面のひと つと考える。 弊社は、２０００年４月より、現在 Web システムの主流となっているサーバーサイド Java の開発を始め、受託形態によるフレームワーク開発や、他社製フレームワークの カスタマイズ等の開発実績を持っている。しかし、それらの著作権は発注会社等が保 有しており、弊社が自由に利用できる権利を保有していない。 一方、他社製フレームワークを利用する場合、要求を満たすためにカスタマイズが必 要であっても、制約があり自由なカスタマイズができない場合が多い。また開発受注 の場面では、フレームワーク導入コストがかかるため受託価格面で不利となる。 そこで、弊社に蓄積できた技術を活用して、弊社が自由に利用、カスタマイズできる フレームワークを開発したいと考えた。 1.2 オープンソース ２０００年５月に Apache Software Foundation に寄贈され Jakarta プロジェクトの Struts フレームワークが近年着目されている。Struts は、MVC モデルに基づくフレ ームワークである。MVC モデルとは、アプリケーションをビュー、コントロール、モ デルという３つで構成するという考え方である。 ビューとは画面等のマンマシンインターフェース部分、モデルとはビジネスロジック 部分、コントロールとはビューとモデルを操作する部分である。 Struts は、上記のビュー、コントロールの部分を標準化したフレームワークであり、 機能も充実していることから、採用するプロジェクトが急激に増えている。 また、Struts はオープンソースであり、そのコードがすべて公開されている。もし要 求に合わない部分があれば、開発者はソースを変更することもできる。また、発注側 にとっては、ソース利用のコストがかからないため、開発コスト削減ができるという メリットがある。 フレームワークは、アプリケーションの基盤となるものであるから、オープンソース であるメリットは大きいといえる。 弊社が開発したいと考えるフレームワークは、この Struts から呼び出されるものであ り、主にモデル部分を司るフレームワークである。これをオープンソースとすること で、品質さえよければ、広く使ってもらえるものにすることができるのではないかと 考えている。 また、経験上、出来合いのフレームワークが担当するプロジェクトに完全適合するこ とは稀であり、一部適合しにくい部分があることが多いと考える。オープンソースで あれば、利用する側に十分なスキルセットを持つアーキテクトが存在することを前提 として、そのプロジェクトに適合するようカスタマイズすることが可能である。 上記の結果として、弊社のような他の中小ソフトウェアハウスが、直接エンドユーザ ーからシステム開発を受託する際の一助となることを期待している。 2 研究開発の内容 2.1 オブジェクト指向開発 弊社が開発したいと考えるフレームワークは、オブジェクト指向開発に基づくフレー ムワークである。オブジェクト指向開発論については、様々なものが提唱されている が、今回開発するフレームワークは、要求開発においてはビジネスルールアプローチ、 実装においてはテスト駆動手法を基盤とするものとしたい。また、開発プロセスとし ては、統一プロセス（４つのフェーズからなるスパイラル型開発プロセス）を簡略化 した（アジャイルモデリングの一種と呼べるかもしれない）プロセスによる開発を想 定している。 なお、開発のリスクを軽減する観点から、開発するフレームワーク第１版は、若干メ インターゲットとするプロジェクトを限定する。以下のとおり。 1. 中規模あるいは小規模、要員のスキルセットは十分であるが、スケジュールが タイトなプロジェクト 2. 中規模、一部にオブジェクト指向開発を行った要員はいるものの、大半の要員 はオブジェクト指向開発に十分に慣れていないプロジェクト 上記にもとづき、このフレームワーク第１版は、POJO により開発し、シングルデー タベースサーバーを前提とする。２フェーズコミット JDBC は利用しない。 一般に、分散データベース構成とすべき根拠となるのは、スケーラビリティの確保、 可用性の確保、パフォーマンスの向上等であるが、分散データベースとすることでプ ロジェクトの難易度（考慮すべき事項が増加する、技術的に難しい）が高まるし、分 散データベースを実現する製品の調達費用、ハードウェア等イニシャルコストが増加 する。システム開発に対する投資は、それによって生み出される価値によって決めら れるべきことであるから、プロジェクトの難易度を上げ（リスクを増大させ） 、イニシ ャルコストを引き上げてでも行うべき案件というのは、本来十分な開発資源（時間、 コスト、十分な技術力を持った要員等）をあてるべきと考えるからである。 分散データベースを利用しないのであれば、J2EE であるべき理由が薄れる。それで あれば POJO であってよいと考えた。 一方、オブジェクト指向開発は、要求、分析、設計、実装、テストの４フェーズで構 成すると言われているが、このうち、分析と設計との間にギャップが存在すると指摘 されている。このギャップをうめる方策についても、今回の開発を通じ提示したいと 考えている。 このギャップを埋めつつ、上流工程の成果物と実施のソースコードの見通しを良くす る。上流工程成果物のこの部分に書いてあることは、ソースのこの部分であるという ことが明確に関連付けられ、トレースがとれるようにする。 今回のフレームワークは、技術的な難易度を抑える一方、開発工程を簡略化し、保守 性・拡張性を高めることを主目的としている。 2.2 ビジネスルールアプローチ ビジネスルールアプローチとは、ビジネスプロセスを構成する経験則、業務手順、業 務ポリシーであるビジネスルールに着目し、それに基づきアプリケーションを開発す る考え方である。 ビジネスルールは、大きく次の３つからなる。 1. 概念（用語） 2. 事実 3. （狭義の）ルール（制約・ガイドライン、計算式、推論等） 細かな説明は省くが、概念（用語）の収集から、データモデル、コード・区分値が洗 い出される。これらは、データベース項目定義書、コードブック等の形式で表される。 事実の収集からは、必要となる機能が洗い出され、それに基づき画面、帳票設計が行 える。これらは、画面、帳票項目定義書等として表される。 狭義のルールの収集からは、ビジネスロジックとメッセージが洗い出される。そのう ち、メッセージはメッセージ集等として表される。 これまでの開発の経験から、上記の成果物、すなわちデータベース項目定義書、コー ドブック等の内容が決まれば、ほぼ自動的にコーディングできるクラスが多数あるこ とがわかっている。これらを自動コーディングする方法論とツールを開発することで 開発効率が改善すると考えている。 これによって、本来開発者がもっとも注力すべきもの、すなわちビジネスロジックに 資源を集中できると思う。 2.3 テスト駆動手法 実際の開発では、テストに多くの工数が割かれる。テスト項目数を減らすことは、品 質の確保の観点から不適であると考えるが、テストの効率化が行えれば、生産効率を あげることができる。 弊社は、各段階のテストのうち、プログラムテスト（モジュールテスト）をさらに重 視したいと考えている。上記のテストは、テストフェーズの最初に行われるテストで あり、本来このテストで発見すべきバグが発見できないために、後続のテストで多数 のバグが発見され、その結果、残り期間・工数が逼迫するという場面をよく見かける。 テストは、準備、実施、評価の３段階をへる。プログラムテスト、モジュールテスト の場合、準備段階でドライバ（起動するためのプログラム）やスタブ（呼び出すモジ ュールが完成していない場合、その動きを模したダミーとなるプログラムを作成する） を作らなければならないケースが大半となり、そのためややもするとそれらのコーデ ィングを行う工数が不足するために、テストがおざなりになるという事態となる。 ドライバやスタブは、フレームワークによってアプリケーション構造を規定すれば、 共通化することが可能と考えており、それによってテスト準備の工数が削減できるこ とを期待している。品質向上にも資すると思う。 また、評価（報告書作成）もかなりの工数をかけていることが多く、これらも自動化 することで効率化できると思われる。 一般のテスト実施ツールは、実施に重点を置いているが、今回のフレームワークでは 準備、評価に重点をおく。 2.4 分析と設計のギャップ 分析フェーズでは、分析モデルによるモデリングが行われる。これは、前述したビジ ネスルールのうち、概念（用語）をひとつのかたまりとして、事実、ルールに基づき その間の関係を表すモデルを作成することである。 それに対し、設計フェーズは、分析モデルを詳細化するモデリング（設計モデル）で あると説明されるが、実際はこの段階でアーキテクチャーの考慮をする必要があり、 単純に詳細化できない。 このギャップが生じる理由として、次の点に着目した。 1. 分析モデルと設計モデルの抽象度（細かさ）の差 2. アーキテクチャーの配慮、とりわけオブジェクト指向言語とリレーショナルデ ータベースのアーキテクチャーの差異（インピーダンスミスマッチ） 3. パフォーマンスに対する配慮 これらによるギャップをうめる解決策として、以下の３つの方策を講じる。 1. プレゼンテーション、サービス、ドメインモデル、インテグレーションの４層 による構造 2. ドメインモデル内に、テーブルモデルーエンティティツリー概念を導入し、メ モリ展開したツリーの問い合わせ機能の実現 3. JOIN を伴う問い合わせ文が利用可能である O-R マッピング（EJB を利用せ ず POJO で実現する。 ） 2.5 テーブルモデルーエンティティツリー概念 永続化情報は、リレーショナルデータベースではテーブルという概念で表現される。 一方、オブジェクト指向では、エンティティという概念となる。 エンティティは、分析モデルの段階では、実際の値をあまり考慮せず、ひとつのもの として考えられることが多い。それに対し、設計モデルの段階では、実際の値とりわ け主キーの値を考慮し、複数存在することを念頭においてモデリングしなければなら ない。 そこで、分析モデルで扱うモデルと、設計モデルで扱うエンティティをそのままの構 造で実装したらよいのではないかと考えた。 リレーショナルデータベースのアーキテクチャーで説明すると、モデルはテーブルで あり、エンティティはレコードである。テーブルとレコードとそのリレーションを構 造化してメモリに展開するという考えである。 テーブルはモデルオブジェクトとしてメモリ展開し、レコードはエンティティオブジ ェクトとしてメモリ展開する。リレーションは木構造によって表し、木構造を実現す るロジックは共通化する。 ドメインモデルとテーブルモデルーエンティティツリーの概念図 ドメインモデル ｴﾝﾃｨﾃｨ ｴﾝﾃｨﾃｨ ｴﾝﾃｨﾃｨ ﾃｰﾌﾞﾙﾓﾃﾞﾙ ｴﾝﾃｨﾃｨ ｴﾝﾃｨﾃｨ ｴﾝﾃｨﾃｨ ﾃｰﾌﾞﾙﾓﾃﾞﾙ ﾃｰﾌﾞﾙﾓﾃﾞﾙ ｴﾝﾃｨﾃｨ ｴﾝﾃｨﾃｨ ｴﾝﾃｨﾃｨ これによって、分析モデルのメッセージ（オブジェクト間のやりとり）はそのまま残 し、モデルとエンティティおよびエンティティとエンティティとの間のメッセージを 明らかにする作業が、設計モデルを作成する作業となる。 上記の図で説明すると、実線の矢印を明らかにする作業が分析モデリングであり、点 線の矢印を明らかにする作業が設計モデリングである。 分析モデリングと設計モデリングで明らかにすべき事項を明確化することで、分析と 設計のギャップをうめる。 なお、ビジネスアプリケーション、とりわけ複雑な業務を扱うシステムの場合、テー ブルモデルとエンティティの階層が深くなりがちで、検索を行う場合等、開発の難易 度をあげることがよくある。そこで、ドメインモデルからテーブルモデル、エンティ ティを検索しやすくする機構を準備する。 2.6 O-R マッピング リレーショナルデータベースに問い合わせを行うと、表形式で結果が返ってくる。そ れに対し、オブジェクト指向言語では、テーブル毎かつレコード毎にエンティティオ ブジェクトを作成し、それに基づいてコーディングする必要がある。 戻ってくる型と、利用したい型が異なることから、その差異（インピーダンスミスマ ッチと呼ばれる）を吸収する仕組みが必要となる。 これを解決する方法が O-R マッピングである。 今回のフレームワークでは、JOIN をかけた問い合わせの結果セットから、問い合わ せ SQL とモデル定義、エンティティ定義を解析し、既に説明したテーブルモデルーエ ンティティツリーの構造をもったオブジェクトを自動生成する。 永続化、すなわちデータベースへの挿入、更新、削除については、SQL の自動生成と 自動実行を行う。 これにより、データベース製品の特性に応じた最適な SQL を記述することでパフォー マンス向上に一定の成果があると考える。また、一般の O-R マッピング製品は、単テ ーブル参照（JOIN ができない）のものが多く、今回開発するフレームワークは JOIN が可能なためデータベースアクセス回数を減らせる。これもパフォーマンス改善に効 果がある。 さらに、問い合わせ手続き（コード） 、永続化手続き（コード）が共通化されるため、 コーディング量が少なくなると考えている。 2.7 その他 1. プレゼンテーションロジックとビジネスロジックの分離 前述の Struts は、ビューサイドすなわちプレゼンテーションロジックを司る フレームワークである。それに対し、今回開発するフレームワークは、モデル すなわちビジネスロジックを司るフレームワークである。 一般にプレゼンテーションロジックとビジネスロジックは分離した方が、保守 の観点から優れているとされており、これを分離する仕組みを作成する。 具体的には、Sun Microsystems 社が提唱する J2EE パターン（エンタープラ イズ領域における Java の推奨設計モデル）のビジネスデリゲートパターンと セッションファサードパターンの実装である。 この機能は先進的なフレームワークでは、すでに実現している。しかし、今回 は J2EE を使用せず（EJB を使用せず）この機能を実現したいと考えている。 J2EE（EJB）を動作させるためには、 （高価な）アプリケーションサーバー（ソ フトウェア）を購入しなければため、導入コストが高くなる傾向がある。そこ でフリー（無料）のアプリケーションサーバーでも同様機能を実現するよう考 えており、導入コスト削減が可能になる。 また、ビジネスデリゲータは、前述したテストドライバ・スタブとして利用で きるようにする。これにより、プレゼンテーション部とビジネスロジック部の 開発およびテストを完全に分離できる。チーム開発の運営において有効である。 2. トランザクション制御 前述のビジネスデリゲートで、データベースのトランザクション処理を共通処 理する。これにより、品質の確保と開発効率の改善が見込める。 （尤も大半のフレームワークでこの機能は実現しているので、これは優位性に は該当しないと思われる。 ） 3. 例外処理と運用ログの標準化 システム運用を考慮し、例外処理と運用ログの標準化する。これらはポリシー として定義し、個別プロジェクト毎の要求の差異を吸収するとともに、実装の 工数を削減する。 例外処理については、ほとんどのフレームワークで対応しているが、ポリシー を設定できるものは少ない。大半は、ポリシーに相当する部分をプロジェクト の都度実装している。 運用ログについて標準化しているフレームワークは少ない。 4. バッチ（ディレードバッチを含む） バッチ起動を行うドライバを作成する。これにより、ビジネスロジックを共通 化しつつ、オンラインとバッチ双方の実行を可能にする。 レガシー開発では、オンラインの処理とバッチの処理は、内容が同一であって もアーキテクチャーの差異から別プログラムとなることも多かった。これによ り、同一の機能をオンライン・バッチ両方作成しなければならない場合、開発 工数減となる。 バッチを想定したフレームワークは、メインフレームベンダーが保有している ことが多く、特に優位と考えてはいない。必要機能なため実現するという考え である。 3 主要部分の構造 3.1 プレゼンテーションコントローラ Struts の Action オブジェクト、または、バッチ起動ドライバから呼び出される。 3.2 ビジネスデリゲータ プレゼンテーション層のクライアントとビジネスロジックとの結合度を弱める機 能。検索やアクセスという永続化に関する詳細や、ビジネスロジックの実装の詳 細を隠蔽する。 この部分でトランザクションの管理を行う。 プレゼンテーション層に対するテストスタブ、ビジネス層に対するテストドライ バとして機能する。 3.3 サービスファサード ビジネスロジックのコンポーネントは複数存在することが多く、それらの複雑な 相互作用を隠蔽することで、プレゼンテーション側に単純なインターフェースを 提供する機能。 親クラスでデータベーストランザクション処理等、ビジネスロジックで発生した 例外の処理を行う。子クラスは機能ごとに個別実装となる。 3.4 ドメインモデル セッションファサードから呼び出される。機能ごとに個別実装する。 3.5 モデル・エンティティビルダー データベースアクセサーから取得した結果セットの情報をもとに、モデル・エン ティティを作成する。 3.6 テーブルモデル・エンティティ テーブルモデル：エンティティの集合なるオブジェクト。再帰構造を持つ。 エンティティ：データベースの１レコードを表すオブジェクト。再帰構造を持つ。 双方とも、基底クラスを提供する。子クラスについては、自動コーディングする。 3.7 データベースアクセサー 問い合わせクエリーを実行して、データベースから結果セットを取得する。 永続化を行う機構である。 3.8 バッチドライバー バッチ処理の場合、プレゼンテーションコントローラを起動する。 ただし、バッチの場合、パフォーマンスを重視して、バッチドライバ内でデータ ベーストランザクション管理を行う。 以 上
© Copyright 2024 Paperzz
