OOAとDOAを併用した最適な分析／設計パターン：JavaのDBアクセスを極める（3）（2/3 ページ）

[吉田知史 著, 安間裕 監修，アクセンチュア・テクノロジー・ソリューションズ]

「OOAとDOA併用に伴うインピーダンスミスマッチ」に起因する問題

　インピーダンスミスマッチからは、どのような問題が発生するのでしょうか？ 代表的な問題は、OOAで設計した部分とDOAで設計した部分との間のインターフェイスを設計する作業の難易度が高くなり、それ故、出来上がった設計が正しいかどうかを検証することも難しくなるということです。

　ここでは、第1回「JavaとDBのデータモデルはナゼすれ違う？」で説明した「開発手法の違いによるインピーダンスミスマッチ」の内容に触れながら、具体的にどのような問題があるのかを説明します。

（1）データモデリングにおける基本思想の違い

　データモデリングにおける基本思想の違いを以下の表にまとめます。

観点	OOA	DOA
「何をベースに定義するか？」という観点から	業務的な振る舞いの視点からデータをとらえる（業務駆動型）	業務要件から必要とされるデータに重きを置いてアプローチする（データ駆動型）
システムとしての最適化を行う観点から	オブジェクト指向における考え方（汎化など）を用いることで、拡張性やメンテナンス性のよいデータモデルを分析・検討し、定義する	データベースとしての物理的なテーブルの構造が（正規化などにより）最適化されるようにデータモデルを分析・検討し、定義する
表2　OOAとDOAのデータモデリングにおける基本思想の違い

　上記の違いから最終的に出来上がるデータモデルの作りも異なってしまうため、これらのインターフェイス部分の設計は複雑になります。

（2）OOAとDOAのデータ構造のギャップ

　OOAで作成されるデータモデルとDOAで作成されるデータモデルでは、データ保持方法が異なります。前者は関連する情報を1つのオブジェクトにまとめて保持しますが、後者は関連する情報を複数の表に分割して保持することがあります。このようなデータ構造のギャップがあるため、OOAで作成されるデータモデルとDOAで作成されるデータモデルを対応付けるには非常に手間がかかります。

（3）開発組織におけるギャップ

　OOAとDOAとのミスマッチは非常に重要な問題ですが、この部分が軽視されてしまうケースがあります。例えば、「ビジネスロジックをOOAで設計」し、「データベースをDOAで設計」する場合、別のチームや組織に分かれて作業をすることがあります。それらのチーム間のコミュニケーションギャップから設計上の不整合が発生し、作業が手戻りすることがあります。特に会社や作業場所が異なるなど、チーム間での距離が大きいとこういった問題が発生しやすくなります。

問題の影響を小さくするための方法

　OOAとDOAを併用して、永続化処理の分析・設計を行う際、インピーダンスミスマッチに起因する問題の影響を小さくするには何が有効でしょうか。

　図2　永続化処理設計におけるインピーダンスミスマッチ

　第一に必要なのは「入念な準備」です。つまり、OOAとDOAを併用して永続化処理の分析・設計を行うに当たっては、「永続化処理分析・設計をどのようなプロセスで実施するかを決める」ことが必要です。そして、プロセスを決めるためには、さらに以下の作業を事前に行う必要があります。

• 永続化処理にはどのような分析・設計項目があるのかを把握する
• 永続化処理に関する分析・設計項目をOOA・DOA間でどのように分担するか決定する

　ここでは、これらの作業について具体的な例を紹介しつつ説明します。

Point

• OOAとDOA併用に伴うインピーダンスミスマッチに起因して、OOAで設計した部分とDOAで設計した部分との間でのインターフェイスの設計と設計内容の検証が難しくなる。
• この問題の影響を小さくするためには、永続化処理分析・設計のプロセスを適切に決めることが第一に重要である。

（次ページに続く）