« 仕様書でシステムが動く時代へ | トップページ | 酸素濃度と進化爆発と技術革新 »

2009.12.18

続・仕様書でシステムが動く時代へ

 前回の「プログラム仕様書の編集パネル」に続いて「XEAD Application Editor(以下、Editor)」の「テーブル仕様書の編集パネル」を紹介しよう。テーブル定義は、単純なcreate table文によるメタ情報を核にして、そのまわりを拡張定義が取り囲んだような形をしている。

 これをEditorで編集している様子が図1だ。テーブル「商品」に含まれるフィールド「外観」の拡張属性として「画像ファイル」が指定されている。これによって、フィールド値が画像ファイル名とみなされるようになる。つまり、機能が実行されてテーブルからこのフィールドが読み込まれた際には、規定のフォルダからその名前のイメージファイルが探索され、パネル上に表示される。

Img091218_1

 テーブル定義に含まれる要素としてこの他に紹介したいものが「スクリプト」だ(図2)。テーブル操作のいろいろなタイミングで指定のスクリプトを実行できるようになっている。導出属性の設定や入力値の妥当性検査のためのロジック等をJavaScriptの構文で記述できる。テーブル操作も可能なので、想像以上に複雑なロジックを組み込める。

Img091218_2_2

 これらの要素を編集すれば、次のようなテーブル定義ができあがる。前回説明した機能定義もテーブル定義を参照した形で登録される。これらがデータ処理パターン毎に用意されているクラスに読み込まれると、仕様にしたがった機能に変形するわけだ。

Img091218_25

 このしくみを強引にMVCにあてはめて図解すると図3のようになる。テーブル定義やプログラム定義はクラスをなすものではないがそれぞれ「モデル」と「ビュー」に相当し、データ処理パターンのクラスを含むドライバが「コントローラ」に相当する。コントローラがモデルとビューの定義情報をインテグレートして、仕様どおりのデータ処理機能に変形するのである。

Img091218_3

 たわむれにMVCで説明してみたが、XEAD Application Driver/Editorを利用する開発者は、MVCだのクラス構造だのを意識しながら仕様を登録する必要はない。そういうことを心配するのは筆者のような「アプリケーションドライバの開発者」だけでいい。言い換えると、「プログラミング上の諸問題に精通していなければ使えない実装用フレームワーク」は、「回路設計の諸問題に精通していないと感電するエレキギター」みたいなものだ。音楽センスだけあれば扱える楽器、システム設計センスだけあれば扱えるフレームワーク、そういうものが求められている。

|

« 仕様書でシステムが動く時代へ | トップページ | 酸素濃度と進化爆発と技術革新 »

コメント

項目値の妥当性チェック条件などは、ビュー(画面)ではなくモデル側で定義することができるのですね。
これは素敵ですね。項目妥当性条件は、本来、モデルに属するものだと思います。
妥当性条件に違反した場合のエラーメッセージも登録できるのでしょうか。
それに、入力値の整形に関する処理(たとえば、コード値の中の英小文字を大文字に変換する、等)は、モデル側でしょうか、ビュー側でしょうか。
たくさんご質問してすみませんm(_ _)m。

投稿: keis | 2009.12.20 13:12

keisさん

エラー内容に応じたメッセージももちろん指定できます。入力フィールドの拡張タイプとして「漢字」が指定されたなら漢字モード、「カタカナ」が指定されれば半角カナモードでFEPが設定されるようになっていますが、大文字変換についてはテーブル定義内のスクリプトで指定することになりますね。

投稿: わたなべ | 2009.12.21 08:47

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 続・仕様書でシステムが動く時代へ:

« 仕様書でシステムが動く時代へ | トップページ | 酸素濃度と進化爆発と技術革新 »