OOAとDOAを併用した最適な分析／設計パターン：JavaのDBアクセスを極める（3）（3/3 ページ）
Webシステムが主流となり、データベース・アプリケーションはJavaやC#といったオブジェクト指向言語で開発することが多くなった。しかし、データベース設計はオブジェクト指向モデルとうまくかみ合わず、データモデル設計に苦労するエンジニアは少なくない。本連載は、オブジェクト指向モデルとデータベースモデルのインピーダンスミスマッチに対応するテクニックを紹介する。（編集局）
（1）永続化処理にはどのような分析・設計項目があるのかを把握する
永続化処理に関する必要な分析・設計項目を洗い出します。この分析・設計は単にデータを永続化することについてだけでなく、コネクション管理やエラーハンドリングなど実装上必要となる機能についても漏れなく行う必要があります。具体的な項目としては、以下のようなものがあります。
- 業務トランザクション処理を設計する
データベース・トランザクション処理を利用し、業務トランザクション処理を設計する - エラーハンドリング
トランザクション処理利用時のエラーハンドリングを設計する - エンティティ・クラスの設計
ビジネスロジックで扱う業務データモデルに準じたエンティティ・クラスを設計する - データベースの論理設計
データベース上のエンティティ・属性を設計する - データベースの物理設計
テーブルのディスク配置・パフォーマンスに関する設計を行う - データベース問い合わせ処理の要件をまとめる
データベースに対してどのような問い合わせ処理が必要かをまとめる - データベース問い合わせ処理を設計する
データベース問い合わせ処理（select、update、insert）を設計する - O／Rマッピングを設計する
データベースのデータモデルと業務データモデルとのマッピングを設計する - データベース・トランザクション処理を設計する
begin()、commit()、rollback()、end()などのトランザクション処理用メソッドを設計する。コネクションプールなどのコネクション制御アーキテクチャも設計する
（2）永続化処理に関する分析・設計項目をOOA・DOA間でどのように分担するか決定する
作業分担の決定に当たっては、利用する実装技術（言語やアーキテクチャ）を考慮に入れる必要があります。例えば以下のような分担が考えられます。
| 分析・設計項目 | 利用するアプローチ | |
|---|---|---|
| ビジネスロジック・レイヤに関する項目 | ・業務トランザクション処理を設計する ・エラーハンドリングを設計する ・エンティティ・クラスを設計する ・データベース問い合わせ処理の要件をまとめる |
OOAを利用する |
| データベース・レイヤに関する項目 | ・データベースの論理設計を行う ・データベースの物理設計を行う ・ORマッピングを設計する ・データベース問い合わせ処理を設計する ・データベース・トランザクション処理を設計する |
DOAを利用する |
| 表3 OOAとDOAの役割分担 | ||
（3）永続化処理分析・設計をどのようなプロセスで実施するかを決める
永続化処理に関する分析・設計項目を洗い出し、それらの分担を決定した後に、設計作業のプロセスを策定します。ここではポイントを3つ提示します。
データモデルにおいてOOA・DOAのどちらが主導するかを決める
「OOAを用いて作成するデータモデル」に合わせて「DOAを用いて作成するデータモデル」を作るのか、あるいはその逆なのかというルールを決めます。場合によってはルールを混在させる必要もあるでしょうが、特別の事情がなければ設計ルールに一貫性を保つことで、作業者に設計の進め方を理解させやすくなります。
OOA・DOAそれぞれを用いて作成したデータモデルの対応をまとめた文書を作成する
「OOAを用いて作成したデータモデル」と「DOAを用いて作成したデータモデル」の間の対応を表形式などにまとめた文書を作成すると、設計の不整合を防止することに効果があります。それぞれの作成者間のコミュニケーションツールとして利用したり、設計内容の整合性をチェックする際に利用したりすることができます。
適切なタイミングでOOAとDOA間の整合性をチェックする
OOAとDOAのそれぞれを用いて行った設計が整合性を保っていることをチェックする必要があります。設計終了段階だけでなく、設計作業にかける負担を考慮しつつ、中間段階でのチェックの実施も検討する必要があります。
以上、OOAとDOAを併用して永続化処理を分析・設計する際に発生する問題の影響を小さくするための手段として、システムを構築する前に「永続化処理の分析・設計プロセス」を規定することの必要性を取り上げ、そのプロセスを規定するうえで考慮すべきポイントをまとめました。
最後に、ここで述べた内容は設計規約などに盛り込み、開発プロジェクト内で同意を得ることによって実際の作業に反映されるようになります。このことは、プロジェクトが複数の会社から構成されたり、各チームの作業場所が異なっていたりする場合には特に重要です。
Point
- 永続化処理の分析・設計項目を洗い出す際は、データの永続化そのものだけでなく、コネクション管理やエラーハンドリングなど実装上必要となる機能も漏れなく取り上げねばならない。
- 永続化処理に関する分析・設計項目の分担を決定する際は、利用する実装技術（言語やアーキテクチャに）を考慮する必要がある。
- 永続化処理分析・設計のプロセスを決める際は、「データモデルにおいてOOA・DOAのどちらが主導するか」「OOA・DOAそれぞれに則ったデータモデルの対応をまとめた文書の様式と運用方法」「OOAとDOAそれぞれを用いた設計の整合性をチェックするタイミング」を内容に盛り込む必要がある。
まとめ
今回はOOAとDOAというアプローチが異なる設計手法を併用する場合の問題と、その影響を小さくする方法について説明しました。DOAはリレーショナル・データベースとの親和性が高く、リレーショナル・データベースの普及に合わせて広まりました。今回の記事もデータベースはリレーショナル・データベースに軸足を置いた内容でしたが、次回は「RDB／OODB／XMLDBで比較する永続化設計」というテーマで、RDB／OODB／XMLDBそれぞれのデータベースを使ったシステムの設計、実装時の留意点、優位性に関して実装例を通して比較・解説します。（次回に続く）
筆者紹介
アクセンチュアから生まれた、企業改革のためのシステム開発を手掛けるエンジニア集団。安間裕が代表取締役社長を務める。諏訪勇紀はJavaに精通しSI上流での分析／設計を得意とするシニア・システム・アナリスト。
Copyright © ITmedia, Inc. All Rights Reserved.