|
| DOA+に期待するもの |
| |
2003年12月12日
東京国際大学教授 堀内 一
|
 今日の情報システム開発で求められるものは、組織間や企業間で業務プロセス連携を可能とする基盤である。その基盤は、ソフトウェア開発の生産性だけでなく、情報やビジネスプロセスモデルの共有を可能とするものでなければならない。
これまでの、ソフトウエア開発方法論の変遷は、「便宜追求」の技術開発と、それらの整合性確保を目的とする「統制」のとせめぎ合いの歴史であった。
例えば、７０年代メインフレームによる基幹業務システムの急拡大に対しては、８０年代前半に「システム再構築」の牽制が入った。８０年代中頃からのクライアントサーバによる分散システムに対しては、全社的なデータ体系の確立とデータ基盤の確立を通じた統制の役割が求められた。ＤＯＡ（データ中心設計）は、その時代にデータ基盤に基づくシステム開発方法論であった。
さらに、９０年代半ばからのオブジェクト指向による分散的な開発手法に対しても、新たな統制手段が求められており、その一つが今日話題となっているEA(Enterprise
Architecture）である。そのアーキテクチャを遵守しながらシステム開発を行う基盤としてデータ基盤が再度認識されているといえる。
ＤＯＡへの新たな認識が求められており、「ＤＯＡ＋コンソーシアム」への高まりも、それを反映しているといえる。
ソフトウエア構成概念も時代と共に変化し、プロセス指向のＰＯＡ（プロセス・オリエンテッド・アプローチ）からデータ資源基盤を中心に考えるＤＯＡへ、さらに、データ固有な処理をカプセル化したオブジェクト指向へと移った。
オブジェクト指向で、今日求められているものは、独自のマナーで構築されている「My
Object」を脱して、ビジネスや業務に対応したアプリケーションレベルでの本格的なオブジェクトとコンポーネントの共有である。そのためには現存するコンポーネントやオブジェクトに基づく、あるいはその裏づけをもつモデルの開発と共有のための基盤及び方法論が必要となる。
その点で、現在は「モデル中心（Model Oriented）」の時代にあるといえる。既に述べたように、モデル共有は社内ではなく、企業間で実現されなければならない。eコマースだけでなく、企業間を連携させるレジストリやリポジトリの役割も重要性をもってきた。
「モデル共有」を可能するためには、ＵＭＬなどの標準モデル言語を使うだけでなく、モデルに組み込むべき共有の「モデル要素」や「情報要素」の共有そのものを進めなければならない。
次の４つの共有が必要となる。
（１）共通情報要素（コード、基本情報など）
（２）共通モデル要素（パターン、モデリング観点など）
（３）共通モデル化機能（ＵＭＬ）
（４）ベストプラクティス
「共通情報要素」共有を実現するためには、既に制定されている規範的情報要素の遵守が必須となる。例えば、「企業コード」一つをとっても、ＩＳＯ６５２３の存在を知る人は少ない。この他、「性別」、「単位」、「時間」などＩＳＯで標準として規定されている情報要素は多い。多くの開発者はこれを知らないのか使用しようとしないが、標準として確立されているものがあれば、それへの準拠を求めることが重要である。
「共通モデル化要素」の共有とは、例えば、標準的な「モデリングパターン」や「モデル化観点」の共有をさす。ＩＳＯにＲＭ−ＯＤＰ（分散オブジェクト参照モデル）がある。、企業観点、情報観点計算観点、工学観点、技術観点などを規定している。モデル共有のためにはモデリング観点の共有が必須である。
そのような共有の情報要素に基づいて、それぞれのオブジェクトを定義することを狙ったＩＳＯ規格にISO/IEC11179
(MDR: Meta Data Registry)がある（ISO/IEC JTC1 SC32担当の規格）。同規格では、データ項目（Data
Element）は、次のようなメタオブジェクトを介して定義される。
MDRメタオブジェクト インスタンスの例
Data Element Concept（データ項目概念）： 「氏名」
Conceptual Domain（概念域）： 「日本人名」
Value Domain （値域）： 「堀内 一」
Value Domain（値域）には、予め、規格化された値が登録される。
共有可能なオブジェクトは、これと同じように、標準的なValueをベースにして定義されなければならない。言い換えれば、ベースとなる基本オブジェクトは、必ず標準的なValue
Domainを持たなければならない。
そこで、改めて、今、ＤＯＡに求めるべきものは
（１）規範的情報要素とモデル化要素に従ったモデルの共有性確保
（２）ビジネス連携基盤の確保
（３）ＲＤＢとオブジェクト指向プラットホーム（Ｊ２ＥＥなど）開発環境の有機的活用
（４）既存資産と新技術の融合（レガシーの救済）
である。ＤＯＡは８０年代の機能指向（構造化手法）のアンチテーゼとして登場した。それまで、ソフトウエア構造に合わせてデータ構造を設計していたが、逆に、ソフトウエア構造をデータ構造にあわせ、データ構造を共有資源として整備した。ある調査によれば、ＣＯＢＯＬプログラムの９０％は実現したい個別処理（プレゼンテーション部分とビジネスロジック）以外の部分を記述している。ミドルウエアを利用することにより、この９０％部分はなくすことが可能である。
世の中ではＤＯＡ vs. OOというような風潮があるが、ＤＯＡはＯＯと対立するものではない。ＯＯを実施する前提として共有データ基盤の整備は大前提である。ＤＯＡは既存の情報要素及びデータ固有の処理を共有資源（データ資源）として重視する理念である。これはプログラミングパラダイムに影響されるものではない。８０年代のデータ指向、９０年代後半からのオブジェクト指向に続き、これからはモデル指向である。モデル及びソフトウエア要素の再利用が強く求められる時代であるからこそ、遠回りに見えても、データ基盤の整備は必須である。そのためには、既存レガシーソフトウェアに対する配慮も必須となる。EAを論じるならば、レガシーへの対処を避けることはできない。
最後に、「ＤＯＡ＋コンソーシアム」には次のことを期待する。
（１）情報基盤整備（ＥＡ含む）方法の確立
（２）実装に依存しないシステム要求を、情報資源基盤に基づき定義する手法の標準化
（３）標準情報要素のレジストリ（メタデータレジストリ）構築と活用促進
（４）共通モデル化要素のレジストリ構築
（５）共通モデル(ベストプラクティス）の共有とレジストリ構築
（６）オープンで提案型活動を望む |
 |
|
