» 【第95号】メタとメタメタ(続き)

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第95号】メタとメタメタ(続き)

DRI通信95号「メタとメタメタ(続き)」       2004.8.2
冷夏の反対は、暑夏というのでしょうか、熱夏というのでしょうか、大変な暑さですが、皆様お元気ですか。
第2回DOA+初心者向け講座(7月14日@ゆうぽうと、講師:佐藤正美&椿)は約100名の参加をいただき無事終了いたしました。分科会での議論、DOA各流派の違いなどを紹介したため、一部中級以上の内容が混じってしまい心配しましたが、ほぼ「有意義」とのアンケートをいただき、「ほっ」といたしました。
第6回DOA+OOP分科会(7月21日@住友電工)ではセントラルコンピュータサービスの三河様からDOAとOOを繋ぐ開発方法論Coupについて、上流にXupper、下流にKonesaを使うケースでの紹介がありました。BFD(Business Flow Diagram)からユースケース経由ロバストネス図を作るところがOO的ということでした。
先月「メタとメタメタ」としてシステム・コンポーネントを概念と物理、DB側とIO側、データと生成プロセスに分け考察しました。メタはDOAで、メタメタはOOで再利用を図るのが適切ではないか、との考えからですが、OOに詳しい方々からも貴重なご意見をいただきました。
■識者のご意見
たとえば、
佐藤英人氏(東京国際大学):「メタメタとメタの関係はクラス−インスタンスの関係です。メタメタデータとパラメータ化されたプログラム(椿氏のメタメタプロセス)を対応付けて考える、という意見に全面的に賛成です。個々のプログラムは、このメタメタ
データに対する値(メタデータ=上記パラメータの値)を読み込んで動くエンジンに
置き換えることができます。問題は、メタメタデータとして何を用意すれば十\n分かという点にあると思います。」
細川努氏(日本総研):「大変興味深く拝読させていただきました。しかしオブジェクト指向で、定義域の明確化やデータ属性の標準化をやってもいいはず。OOもDOAもテクニックの違いだから、お互いいいところ取りするのは大いに結構ではなないか。」


萩本順三氏:属性をメタ化、メタメタ化するのは非常に興味を持つ内容でした。
属性の標準化については、スピードが要求されている今日、そこに行き着くまでの分析アプローチに工夫が必要だと考えています。
戸田忠良氏(戸田ソフトウエアオフィス):「メタデータは第一次抽象化モデルをベースに、アプリケーションの個性を記述するもの。メタメタデータは更に第二次抽象化モデルをベースにしたもので、その記述内容は実装独立になるが、メタデータを扱うリポジトリ設計において、不可避的に登場する。このメタメタデータにカプセル化されるプロセス集合が適切にデザインされれば、それは第二次抽象化モデルによる汎用処理ソフトのベースになり、システムの作り方を大きく変えるはず。メタデータに示される第一次抽象化は、プログラムからデータを独立させ、データベースを生み出した。今回議論のメタメタデータという第二次抽象化は、対象業務の違いを超えて汎用なデータ構造を生み出すはずである。特に物理と概念の分離をきちんと行うことが大切と思う」
などでした。
■メタメタレベルでデータとプロセスを対応付ける
結局、メタレベルでのプログラムの再利用は難しく、メタメタレベルでデータと(生成)プロセスを対応付ける考え方には、原則的に賛同いただけたように受け取りました。したがって業務仕様(What)を概念リポジトリ中に、「メタメタデータ−メタデータ対」として記述し、効率や操作性にかかわる実装仕様(How & Where)を実装リポジトリ中に記述し、エンジンはこれを参照して動くとする、われわれのアーキテクチャはほぼ認められたように思われました。問題は実装環境を業務横断にどのようにモデル化し、その標準パラメータをいかに用意するかだと思われます。
実装独立の業務仕様をいかに実装につなぐか。そのギャップを、従来メタレベルのプログラミングによってつないでいたため、レガシーの属人的保守地獄を招いていたわけですが、メタレベルはデータ管理のみとし、プログラムは「有限個に収まるメタメタデータおよびメタメタプロセス」で対応すべきことがはっきりしたと私には見えます。
ただここで、断っておくべきことは、「メタレベルプログラムを一切作らない」とがんばる必要はない、銀行のATMなどでは、相変わらず丁寧な手作りが残るかと思います。オートクチュールはそれなりに残る。しかし大部分、できれば95%は、メタレベルプログラムレスとする。やはり工業製品プレタポルテは自動化で作る。これによって、レガシーの発生を抑える。これが目標ではないかと思われます。
また、メタレベルプログラムレスと言っても、自動生成ならば、これに手を入れることなく隠蔽して扱う限りかまわない、と考えます。いわゆるコンパイル方式はインタープリーティング方式と同等と考えられるからです。
■システム開発業務もひとつのアプリケーション
私がメタとメタメタを考えた動機は、システム開発という業務そのものがひとつのアプリケーションであり、そこで扱うデータはメタデータなので、メタデータから成るデータモデル図や業務フロー図などを分析したことに始まります。これによって、メタメタレベルのエンティティタイプとして、エンティティタイプ、属性、業務ドメイン、システム、業務プロセス、画面・帳票、画面・帳票データ、やそれらの関連が見えてきました。またそれらの属性として、たとえばエンティティタイプについては、リソース・イベント・要約などの分類、属性については桁数、KEY機能、参照KEY機能、加工データ機能、必須区分など、また参照KEYについては対応するKEY、加工データについては加工ロジックや加工元データ関連などが見えてきたわけです。
■メタメタレベルのプログラム
こうして従来個々のメタデータについて書いていた多くのロジックを、メタメタデータについて1回書けば済むことがわかってきました。たとえば受注品番(参照KEY)が品番として登録されているか、顧客(参照KEY)が取引先として登録されているかなどの、いわゆる参照整合性チェックは、「参照KEYについてのKEY有無チェックのロジック」を1個用意すれば、それで済むわけです。また、エンティティレコードの管理についても、生死だけでなく、妊娠中/誕生前、成人後、墓入れ済みなどに相当するステイタスコードを設定し、それごとのロジックを用意すれば、個々のエンティティタイプごとにDLCPといった管理プログラムを用意する必要は、ごく例外的なものを除き、なくなると考えられます。
したがって、前述したように、実装環境のモデル化、たとえば画面のパターンとして、単票、一覧表、マトリックス、ヘッダ・デテイルなどをどれだけきめ細かく用意しこれを選択してもらうかなどが、プログラムレスを実現するための今後の課題となると考えます。