川村渇真の「知性の泉」

オブジェクト指向時代の情報資源管理


オブジェクト指向技術で情報資源管理の実現方法も変わる

 オブジェクト指向技術を採用した開発ツールが、次第に普及してきた。情報資源管理を実現する方法として、オブジェクト指向技術を無視できなくなりつつある。しかし、オブジェクト指向データベースが普及レベルに達していないなど、現実の環境はまだ整っていない。それでも今後の主流となるのは確かなので、オブジェクト指向技術を利用できる時代の情報資源管理をまとめてみよう。
 オブジェクト指向技術を用いた場合も、情報資源管理を実現するための設計ポイントは変わらない。以下の3点が、もっとも重要な項目である。

情報資源管理を実現するための設計3項目
・1. 重要データは深くデータ分析して、共通のデータベースに保存する
・2. 業務システム向けのインターフェースを用意し、それ経由でアクセスする
・3. 分析したデータは、ツールできちんと管理する

 これら3つの設計ポイントは同じだが、実現方法である中身は、オブジェクト指向技術を利用する場合としない場合でかなり異なる。順番に解説しよう。

項目1:オブジェクト指向データベースに共通データを保存する

 共通データベースに関する部分では、使用するデータベースのタイプが変わる。現在はリレーショナル型を使うしかない状況だが、オブジェクト指向データベースに置き換えたほうがよい。
 オブジェクト指向データベースは、オブジェクト間の関連を保ったままオブジェクトとして保存できる点が最大の特徴である。このような形式だと、オブジェクト指向のプログラミング言語との相性も良い。また、設計段階からオブジェクト指向技術を採用したとき、実装段階で余分な設計を考える必要がない。
 リレーショナル型だと、オブジェクト自体およびオブジェクト間の関連まで含めたデータを、リレーショナルの形式に変換して保存する必要がある。もちろん、データを読み込む場合にも、関連まで含めてオブジェクトに復元しなければならない。そうなると、構築するシステム上で余分な処理が発生し、開発の負荷が増すだけでなく、バグも発生しやすい。
 共通データベースに入れるデータの分析に関しては、情報資源管理とオブジェクト指向でさほど変わらない。データ中心アプローチもオブジェクト指向も、扱う対象物を中心に考えるからだ。しかし、実装段階の設計では、処理の部分をどのように実現するかで、オブジェクト指向と他の方法では異なる。オブジェクト指向ならクラスとして作り、処理をメソッドに入れる。また、継承機能を利用することで、似たようなクラスを階層的に定義する。細かな処理の入れ場所をどのクラスにするのか十分に検討し、重複や矛盾しないように処理を分散しなければならない。
 共通データベースに入れるデータは、定義したクラスのオブジェクトなので、そのまま保存すると、プログラムの動作中にしか使わない余計な値も含まれる。設計段階では必要な項目だけを定義し、残りの項目はプログラムの中で定義することになる。必要な項目だけをデータベースに保存する仕組みを、何らの形で規定しなければならない。決めるだけなので難しい問題ではないだろう。このような機能は、オブジェクト指向データベースが中心となってサポートすべきものだ。
 消費税率のような重要値も、共通データベースに入れて管理する。これも専用のクラスとして実現し、値を読み出したり変更するメソッドを加える。このような値の管理も、情報資源管理では必須である。

項目2:業務システム向けのインターフェース・クラスを用意する

 情報資源管理では、共通データベースを利用する業務システムごとに、アクセス用のインターフェースを用意する。オブジェクト指向技術を利用する場合には、インターフェースをクラスとして実現すればよい。
 インターフェース用のクラスは、対象となる業務システムから共通データベースをアクセスするために用意する。どのようなアクセスが必要か分析し、クラス内のメソッドとして加える。対象となるレコードを検索したり、前後のレコードをゲットするとか、業務システムで求める機能を付ける。
 インターフェース用のクラス内では、業務システムからのアクセスを仲介する形で、共通データベースのデータにアクセスする。共通データベースの構造が変わっても、インターフェース用のクラス内で吸収し、業務システム側からは変わっていないように見せるためだ。インターフェース用のクラスは、業務システムと共通データベースの間に置いて、両者を分離する役目を持つ。
 このような仕組みのため、業務システム側から見ると、インターフェース用クラスと共通データベースは一体化している。インターフェース用クラスから見えないフィールドが、見えるフィールドと関連していれば、インターフェース用クラス内で自動的に更新処理を用意する。もちろん、自動的に更新して良いかは業務レベルで判断することなので、分析や設計の段階で決めておかなければならない。
 共通データベースと業務システムとの依存性を低く保つためには、インターフェース用のクラスを業務システムごとに分ける。たとえデータや機能が同じであってもだ。この実現はオブジェクト指向なら簡単で、共通のインターフェース用クラスを最初に作り、そのサブクラスとして各業務システム用に追加すれば済む。業務システムごとに略号を付けるのが一般的なので、サブクラスにも業務略号を付けて識別しやすく作る。
 インターフェース用のクラスを用意する部分は、オブジェクト指向データベースで強力にサポートしてほしい。このような機能こそ、変更に強いシステムを構築するためには、本当に役立つ機能なのだ。

項目3:統合された管理ツールで設計内容の全体を把握する

 オブジェクト指向技術を利用して設計すると、数多くのクラスを定義する形になる。クラス内にはデータだけでなくメソッドも入り、クラスの継承などでメソッドが分散する傾向が強い。このような仕組みだと、システムの設計内容が把握にづらくなる。加えて、構築するシステムの機能が拡大する傾向もあるので、もはや手作業で管理するのは非常に面倒だ。やはり、設計内容をツールで管理するのが望ましい。
 オブジェクト指向の開発では、UMLを用いて分析や設計を行う。UMLも手で描くのは大変なので、描画を含んだ設計ツールを用いるのは当然の選択だ。せっかく設計ツールを用いるのだから、オブジェクト指向データベースが連携した新しい統合ツールが望ましい。新ツールでは、どのクラスを共通データベースに保存し、どれがインターフェース用クラスなのかはもちろん、エラー処理などがどのクラスに入っているのか、細かく把握できなければならない。
 このように統合されたツールがあると、フィールド定義が重複しないように管理したり、加工やエラーの処理を適切なクラスに割り振ったり、全体として最適化した設計が可能になる。構築するシステムが大規模で複雑なほど、威力を発揮するはずだ。
 管理ツールを内蔵した統合開発環境では、無駄な入力も最小限に押さえる。UMLで入力したクラスとデータは、オブジェクト指向データベースのフィールドとして自動的に反映する。また、プログラムのソースの大枠やデータ定義も自動生成し、本当に必要な処理と一時データだけを書くだけにする。これらは連携していて、元の変更が関係箇所に反映しなければ意味はない。
 つまり、オブジェクト指向技術を利用した情報資源管理では、データだけでなく細かな処理まで含め、どんなものがどこにあるのかを把握できるようにする。データも処理もクラスとして設計するので、管理ツールは「クラス・ディクショナリ」と呼べばよいだろう。UMLを描く機能が設計の中心となるので、その機能がクラス・ディクショナリと深く関連する構造になる。

 ここまで説明した内容だが、非常に深く分析したわけではないので、細部には小さな問題が残っている可能性もある。ただし、もしあったとしても、たいていは解決可能だろう。
 以上のようなツールがあれば、データや処理を細かく分散して、最適なクラスへと入れられる。全体としては、より理想的な形でシステムを構築できる可能性が増す。その条件となるのが、クラス・ディクショナリを内蔵してオブジェクト指向データベースに連携し、分析からプログラミングまでをサポートする統合開発環境だ。非常に残念だが、このようなツールはまだ登場していない。これから開発するツールは、この程度のレベルを達成してほしい。

(1998年5月10日)


下の飾り