« 特定ドメイン向け開発環境の意義 | トップページ | アンチパターン「大規模集積回路モデル」 »

2012.07.25

「フィールド値の色」をテーブル定義に組み込む

 売上実績テーブル上の「売価」と「原価」の差額が「粗利(あらり)」であるとして、その値がマイナスならばすべてのパネルや帳票上で赤色で示す――という仕様があるとしよう。これをどのように実装すればいいだろう。

 従来の開発環境であれば「アプリの仕様」として実装されていた。いっぽう、「そのまま実行可能な仕様書」を実現したOSSプラットフォームXEAD Driverでは、拡張された「テーブル定義」に組み込まれる。具体的には、売上実績テーブルの「レコード読取後に実行されるテーブルスクリプト」として次のように記述される(*1)。

01 売上実績_粗利.value = 売上実績_売価.value - 売上実績_原価.value;
02 if (売上実績_粗利.value < 0) {
03   売上実績_粗利.color = 'red';
04 }

 「粗利」は売上実績テーブル上の「仮想フィールド」としてあらかじめ定義されており、その値を設定するためのステップ(1行目)の後に、配色設定のステップ(2~4行目)が置かれている。これで、このフィールドがどのパネルや帳票の上に置かれても、マイナスであれば赤色で示される。まさに"one fact in one place"だ。

 ちなみに特定のアプリ上だけで配色設定したいのであれば、次のように書けばよい。2行目の"instance"は、テーブルスクリプトを起動したアプリ自身を指すオブジェクト変数である。

01 売上実績_粗利.value = 売上実績_売価.value - 売上実績_原価.value;
02 if (instance.functionID == 'ABC100') {
03   if (売上実績_粗利.value < 0) {
04     売上実績_粗利.color = 'red';
05   }
06 }

 なお、仮想フィールドであるかどうかはテーブル定義内で閉じた問題なので、アプリを組む際に意識する必要はない。また、売上実績テーブルを読み込む際に商品マスターから「商品名」を参照するのであれば、あらかじめ「結合フィールド」として登録しておけばよい。アプリ上では、仮想フィールドである「粗利」も、結合フィールドである「商品名」も、あたかも売上実績テーブル上の実フィールドであるかのように扱える。

 つぎに、ビジネスルールの代表ともいえる「フィールド値のバリデーション」の例を示そう。売上実績テーブルの「レコード更新前に実行されるテーブルスクリプト」として次のように書いておけばよい。上記と同様に"instance"変数を使えば特定アプリだけに有効なバリデーションも書けるし、テーブル操作を伴う複雑なバリデーションも自由自在だ。

01 if (受注明細_受注数.value <= 0) {
02   受注明細_受注数.error = '正数値を入力してください';
03 }

 このようにしてさまざまな仕様要素をアプリからテーブル側(データベース側)へ移行するのだが、そのための代表的な工夫が従来は「トリガー」であった。これは上述したテーブルスクリプトに似たしくみなのだが、いろいろと制約がある。DBMS固有の機構であるゆえにDBMS毎に記述様式が異なるという点が制約として目立つが、より大きな問題は、それが実行される際にプログラム域がアプリと切り離されている点だ(次図)。

20120725

 いっぽう、XEAD Driverのテーブルスクリプトは、アプリ上のフィールド変数やinstance変数等と動的にリンクされた形で実行される。それゆえに、UI側の特性であるはずの「フィールド値の色」さえもテーブル定義の一部として扱える。フィールドの表示色など瑣末な話に思われるかもしれないが、それはXEAD Driverのアーキテクチャを理解してもらうための象徴的な例なのである。

 ではそもそも、仕様要素をデータベース側に移行することに何故これほどこだわるのか。他でもない。アプリを「無個性で薄っぺら」なものにするためだ。そうすることで、プラットフォームが想定するパターンにより多くのアプリを類型化できる。

 パターンに収まってしまえばこっちのものだ。XEAD Driverでは、規定パターンのアプリ定義(そのまま実行可能な仕様書)であれば、専用の仕様書エディタを用いて10分程度で作れる。つまり、アプリの「コードレス・プログラミング」が10分程度で完了する。膨大な数のアプリを人海戦術で手作りすることが従来のシステム開発の主要作業だったことを思えば、開発・保守がズッコケそうになるほど楽になる。

 しかし「そのまま実行可能な仕様書」の形でシステムを形成することの最大の特長は、逆説的ながら「移植性の高さ」にある。プラットフォームへの「ロックイン」の心配がないということだ。

 なぜか。システムそのものが「(そのまま実行可能な)整然とした仕様書の集まり」であり続けるためだ。それらの仕様書にもとづいて、移植先のプラットフォームで動作するアプリを粛々と実装する――それが「移植作業」だ。仕様書がアテにならなかったりわかりにくかったり、あるいは「コードが仕様書」であるようなシステムの移植作業のデスマーチぶりを思えば、彼我の差は大きい。


*1.テーブルIDとフィールドIDをアンダーバー("_")でつなぎ、その後ろに.valueや.colorといった属性表現を置けば、テーブルスクリプト内でフィールド値やフィールド色にアクセスするための変数となる。テーブルIDやフィールドIDは通常は半角英数字だが、PostgreSQLではこの例のように全角文字を使える。

|

« 特定ドメイン向け開発環境の意義 | トップページ | アンチパターン「大規模集積回路モデル」 »

コメント

正直、先日のドメイン特化のツールの話について読んだ時に思ったのですが、ドメイン特化しているのを微妙に直して使いたい場合にオープンソースってのは、いいなと思ういます。

もう、ソースは見れるんでしたっけ?

投稿: @mizo432 | 2012.07.25 10:30

github.com/xeadで見れますよ~(^^)

投稿: わたなべ | 2012.07.25 12:48

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 「フィールド値の色」をテーブル定義に組み込む:

« 特定ドメイン向け開発環境の意義 | トップページ | アンチパターン「大規模集積回路モデル」 »