« 「わかりやすいシステム」のためにオーディションを | トップページ | 内部記述から外部記述へ »

2007.02.18

「XEADインテグレータ」の開発

 忙殺されて滞っていたXEADの開発作業だが、やっと本格的に再開できる目処が立った。次に取り掛かるのは、XEADコンテンツ同士を統合するためのツールである。

 現在のXEADの弱点として「チーム形態での設計に向かない」という点が挙げられる。残念なことにXEADはシングルユーザしか編集できないツールなのである。この制約を軽減するために、XEADファイル上の各定義要素をターゲットのXEADファイルへ流し込むためのツール「XEADインテグレータ」を開発する。XEADをマルチユーザにするつもりはない。そのためには、UNDO/REDOの機能をはずす必要があって、それはこの種のツールのユーザにとってはつらすぎるからだ。

 「XEADインテグレータ」は想像以上に複雑な処理を行う。たとえば、あるテーブル定義を別のXEADファイルに流し込む場合、テーブル定義に含まれる「テーブルID」がターゲット内で重複しているかどうかをまずチェックする。重複していなければ、{テーブルID+テーブル名}でターゲット内を走査して、定義が既存であるかどうかをチェックする。そうして更新対象の定義が既存であることがわかれば、そこに含まれるフィールド定義も{フィールド定義+フィールド名}で走査しながら置き換える。

 なぜこのようなややこしい手順を踏むかというと、各定義要素が、ユーザには非可視な項目で識別されているためである。上記のチェックに使われる「テーブルID」はアプリ上で可視的なテーブルIDのことで、XEADが内部的に識別子として用いている「テーブル定義テーブル(正確にはテーブル定義のXMLセグメント)」の「ID」ではない(なんてわかりにくい話だろう)。たとえば、あるコンテンツ上の「顧客マスター」のIDと、ターゲット上の「顧客マスター」のIDの値が一致することは保証されていないのである。ゆえに、いちいち{(可視的な)テーブルID+テーブル名}でターゲットでの更新対象を特定し直すという遠回りな手順を踏まねばならない。

 では、なぜXEADでは定義要素の識別子の値を隠しているかというと、テーブルIDとかフィールドIDとか機能IDの値が、設計過程でコロコロ変わるからだ。筆者などは、設計初期にはそれらはブランクのままほっておくことも多い。そんなものをテーブル関連の基礎とするわけにはいかない。これもまた、UNDO/REDOの機能と同様、設計者の便宜をはかるための工夫である。そのための苦労であれば甘受したい。

 XEADファイル同士の統合もできるようにするいっぽうで、代表的なDBMSで作られたデータベースの定義を取り込むリバースエンジニアリング機能もいっしょに組み込むつもりだ。このようにして、ツールに欠けていた要素が補完されてゆくのはうれしい。また、プログラミング三昧に引きこもれるのがうれしかったりもする。

|

« 「わかりやすいシステム」のためにオーディションを | トップページ | 内部記述から外部記述へ »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 「XEADインテグレータ」の開発:

« 「わかりやすいシステム」のためにオーディションを | トップページ | 内部記述から外部記述へ »