設計者の発言

業務システム開発とデータモデリングに関する語り

「フィーチャ・オプション」のモデルと実装

 「フィーチャ・オプション」のパターンにもとづくモデルと実装を、「システム構成(設備)管理」の名称でモデルライブラリに追加した。6テーブルしか含まれていないシンプルなモデルだが、「評価式」に関する興味深い論点が含まれている(図1)。

 ▼図1.フィーチャ・オプションのモデル

20200416_1

 企業はさまざまな設備を利用するが、それらを設備情報として一括管理しようとすると困った問題が生じる。種々雑多な設備毎に、管理したい属性の一覧がまるで違ってくるのだ。たとえばサーバマシンやPCであればOSやCPUを管理したいだろうし、ある種のソフトウエアであればバージョンを管理したいだろうし、電源装置であればまた独特な管理属性があるだろう。

 そこで、それらの設備をいくつかの「タイプ(モジュールタイプ)」に分類して、それぞれのタイプ毎で管理したい属性の一覧を決定することを考える。上掲はこれを意図したモデルで、このモデリングパターンは「フィーチャ・オプション」と呼ばれる。個々の設備は、それぞれのタイプ(モジュールタイプ)が指定された「モジュール」として、属性の具体値とセットにした形で登録される。

 個々のモジュールを登録する際の、属性の具体値に対する「妥当性検査」について考えてみよう。関連する管理属性がどんな値をとるべきかはタイプ毎に決まると考えていい。では、その判定ロジックをどのように組み込めばいいのだろう。モデルに含まれるテーブル「モジュールタイプ別管理属性」上のフィールド「評価式」が、その判定ロジックに相当する。妥当性検査の仕様がデータとして登録されるということだ。

 評価式の実際例を3つ挙げよう。List(),Range()はこの評価式体系における予約語で、それぞれリスト検査、範囲検査であることを示している。いずれの予約語も含まない場合はスクリプト検査とみなされる。

(1)タイプA/属性Xに対するリスト検査(100,200,300のいずれか)

List(100,200,300)

(2)タイプA/属性Yに対する範囲検査(1~2000までの1ずつ増分する数値)

Range(1,2000,1) //増分値1は省略可

(3)タイプA/属性Zに対するスクリプト検査

valueOfYYY = optionValue['YYY']; //属性Yの文字値

valueOfYYY = Number(valueOfYYY.replace(/,/g, '')); //コンマ除去された数値

if (valueOfYYY <= 1500

 && AT032_VLOPTION.value != 'White'

 && AT032_VLOPTION.value != 'Black') {

 AT032_VLOPTION.error

  = '属性Yが1,500以下の場合、WhiteかBlackのみ有効です。';

}

 これらがテーブルから読み出され、保守用プログラムで動的に適用される。正しくない値を入力すると図2のようにエラーが示される。

▼図2.「評価式」にもとづいて示される妥当性検査エラー

20200416_2

 この例で保守されようとしているモジュール(モジュールA1)にはタイプAのモジュールタイプが設定されており、このタイプにはあらかじめ3つの属性(X,Y,Z)が定義されている。そして(3)のコードは、属性Zに指定された属性値(*1)の妥当性検査において、Yの属性値(*2)が関係していることを示している。このように、他の属性値が関わる複雑な判定ロジックも表現できるのがスクリプト検査の特徴だ。

 繰り返すが、上記の判定ロジックがRDB上に「データ」として格納されている点に注意してほしい。妥当性検査(ビジネスルール)は、かつてはアプリ上のコードとして組み込まれることが多かった。しかしそのやり方ではアプリが厚くなって保守性が低下するので、妥当性検査をテーブルの拡張定義(あるいはドメインクラス)として置けばいいと考えるのが最近のトレンドである。しかしこの例で適用される検査仕様はさらにその先を行っていて、そのテーブル上のデータとして登録されているのである。なんとも不思議な感じがしないだろうか。

 では、この「評価式」の維持・管理は誰の職掌なのだろう。システムの立ち上げ時には開発者がまとめ、運用に入ってからはユーザ自身によって維持されると考えたらいい。登録したい設備の点数が多いとしてもタイプはそれほど増えないだろうから、既存の評価式を真似しながら新規のタイプをゆっくり増やせばよい。ユーザにはハードルが高いと思われるかもしれない。しかし、タイプを新規追加する度にテーブル上の妥当性検査を作り替える面倒を考えれば、評価式としてデータ化してしまうやり方には合理性がある。

 妥当性検査の仕様をデータとして保持することの不思議な面白さをわかってもらうためにも、ダウンロードしてモデルを眺めて、実装版を動かしてみることをお勧めする。前記事で紹介した新刊書でも詳しく説明されているので、参考にしてほしい。

 

*1.AT032_VLOPTION.valueの変数で得られる

*2.optionValue['YYY']の配列要素として得られる。YYYは属性Yの属性コード