« テーブル操作と業務ロジックの連動制御 | トップページ | フレームワークとドメイン特化基盤 »

2016.03.01

X-TEA Driverが1.3にリリースアップ

 「仕様書をそのまま動作させる」ための、業務システム向けのOSS開発基盤X-TEA Driver/Editor1.3を公開した。1.2から1.3へのリリースアップにともなって比較的大きな改修がなされており、移行手順等も含め、ここで説明しておきたい。

 主な改定項目としては、パスワードのハッシュ過程の強化、Table Evaluator機能の組込み、テーブル定義の範囲KEYの廃止、クロスチェッカーの廃止、の4項目である。それぞれについて説明しよう。

■パスワードのハッシュ過程の強化

 旧版では特定アルゴリズムでログインパスワードをハッシュ化していたのだが、その過程を可変にした。具体的には、システム定義の「その他の設定」にある「ハッシュ方式」で、アルゴリズム、エクステンド回数、ソルト値の利用を指定できるようになった。これらを組み合わせた複雑な方式を設定すれば、ハッシュコード値からのパスワードの推測がほとんど不可能になる。

 「ハッシュ方式」の導入にともなって、ユーザがパスワードを忘れた場合に、ランダム文字列で再設定してユーザにメール通知できるようにした。通知されたパスワードでログインした直後に、自分用のパスワードに再設定することが前提である。

 この改修にともなってパスワード桁数を伸ばしたので、移行作業が要る。既存システムの「ユーザ定義テーブル(ZT020)」の「パスワード(TXPASSWORD)」について、フィールド長を32桁から50桁に拡張してほしい。32桁のままだと、ハッシュ方式を明示的に指定した場合に、どうやってもログインできなくなる(デフォルトのハッシュ方式のままで使う限りは問題ない)。

■Table Evaluator機能の組込み

 旧版において、テーブル操作用関数として「Table Operator」が提供されていたが、業務ロジックに連動するテーブル操作用関数「Table Evaluator」をあらたに搭載した。これらの関数の違いや使い分けについては、前回記事を参照してほしい。

 「Table Evaluator」については、「花束問題」最新実装版のWEB API定義(BF100,CF200,CF210)内で使われているので、参考になるだろう。じっさいに使ってみれば、業務ロジックを「アプリ上の記述」としてではなく「テーブルの拡張定義」として配置することの意義を実感できるはずだ。

 この項目について移行作業はとくに要らないが、Table Operatorを使っている既存のスクリプトの中では、Table Evaluatorを使ったほうがスマートになる可能性がある。試してみてほしい。

■テーブル定義の範囲KEYの廃止

 ある種のテーブル定義には「有効期間」や「有効範囲」が含まれることがある。各レコードはその範囲においてだけ有効で、それ以外のタイミングを基準として検索した場合、そのレコードが存在しないかのように扱われなければいけない。この複雑な検索処理を簡略化するために、X-TEA Driverのテーブル定義にはこれまで「範囲KEY」の属性が用意されていた。

 ところが、いろいろな事例に接しているうちに、その機構が前提とする制約が気になってきた。「範囲の起点」を表す項目が一次識別子に含まれていなければいけないという制約がその最たるもので、それが属性項目として置かれていたらせっかくの機構が使えない。また、条件にしたがって検索条件を変えることもできないし、有効なレコードが存在していなかった場合に、関連するマスター上の標準値を返したいといったケースもある。

 制約が多いわりに、「範囲KEY」のしくみが基盤の内部構造を広範囲にわたって複雑にしているという事情もある。そうまでしてがんばっても、けっきょくあれこれと制約がつきまとう。そんな機構にこだわっても、基盤の発展の足かせにしかならない。今回、そのように判断した次第である。

 便利そうなわりに制約の多さゆえに「範囲KEY」があまり活用されていないことがわかっているのだが、既存システム定義からその設定をはずすための移行作業が必要になる。範囲KEY指定されているテーブルについて、システム内でそれを結合テーブルとしているすべてのテーブルからそれを除去し、テーブルスクリプトによって動的検索されるように書き換える。そのうえで、旧版のEditorを使って、範囲KEYの設定をはずしてほしい。

■クロスチェッカーの廃止

 たとえば、ある顧客レコードを削除しようとして、その顧客レコードを結合している受注レコードが存在しているならば、削除が禁止されなければいけない。削除に限らず、結合テーブルとの整合性が失われるような更新も禁止されなければいけない。

 このようなバリデーションのことを私は「逆方向バリデーション」と呼んでいるのだが、これを自動実行するための機構(クロスチェッカー)を廃止した。今回のリリースアップの中で最大の改修である。

 逆方向バリデーションの自動化の何が問題だったのか。汎用クラスとして独立しているので、逆方向バリデーションのための機構がX-TEA Driverの内部構造をことさら複雑にしているということはない。ところが、AWS等のクラウド環境で動かすと、自動逆バリデーションにともなうオーバーヘッドが気になってきた。とくに、さまざまなテーブルによって結合されているマスター系テーブルの更新処理において顕著である。それはまさに、膨大なシステム定義を分析して、必要なロジックを動的に構築しているゆえだ。また、「範囲KEY」と同様に、逆バリデーションについても個別のロジックが求められるケースがあることもわかってきた。

 そこで、逆方向バリデーションのためのロジックは、クロスチェッカーが自動生成して実行するのではなく、テーブルスクリプトとしてテーブル毎に個別に記述しておく、という方針にした。やはりどんなに手間がかかろうと、逆方向バリデーションは、システム設計者にとってれっきとしたエンジニアリング課題として扱われるべきなのだろう。

 結果的に、そのためのスクリプトを補完する移行作業が必要になる。とくに手間がかかりそうなのが、既存のテーブル定義について「削除前検査」のスクリプトを組み込む作業だろう。そこで、X-TEA Editorで「削除前のスクリプト」を追加すると、必要なステップの初期値が結合定義にもとづいて自動設定されるようにしてある。

■所感

 今回の改修を通じて、とくに範囲KEYとクロスチェッカーの廃止に関して、未来を見通すことの難しさを思い知った。私はX-TEA Driverを「いろいろな問題を暗黙的に対処してくれる開発基盤」として開発してきたのだが、多少やり過ぎたと反省している。

 すなわち、ある種の問題が開発基盤によって暗黙的に対処されるようになると、その問題に対する開発者にとっての「コントロール感」が低下する。開発が楽になるとしても、場合によってはストレスがたまる。ようするに、「基盤による自動化」と「開発者によるコントロール感」がバランスされていることは、開発基盤の重要な評価項目なのである。

 それにしても、それらの機構を廃止するために、大量のコードを削除したときの心地よさを想像してもらえるだろうか。基盤の改修作業では、ふつうはステップ数が増えてゆくものなのだが、今回は、長年かけて積み上げたコードがバッサリと削られた。しかし徒労感はない。長年かけて積み上げた腹のぜい肉を落としたような爽快感があるばかりだ(そんな経験はないが)。

|

« テーブル操作と業務ロジックの連動制御 | トップページ | フレームワークとドメイン特化基盤 »

コメント

いつも勉強させて頂いています。
いつもは書籍を読ませて頂いていますが、今回、はじめてDriverをインストールしてみました。目的は、基本設計とは何なのか、詳細設計とは何なのか、について何か渡辺さんの解釈が見えるのではないかと思ったからです。
結果は、正直、明確なことは分かりませんでした。まだ少ししか見れていないせいかも知れませんが(花束のネット販売が手ごろかと思って、まずは見ています)、正直ModelerとDriverを分けなくてもいけるんじゃないかと思ってしまいました。
まだ見えていない部分がたくさんあるんだとは思うのですが、渡辺さんの思う、詳細設計にしかない要素、ModelerとDriverを別にしなければいけない理由がありましたら、ぜひ教えて頂きたいです。
よろしくお願いいたします。

投稿: くまきち | 2017.06.25 23:03

くまきちさん

いい質問ですね。私がいちいちModelerでモデルをまとめていることには理由があります。Modelerの内容は「図面表現」が中心です。Driver上の詳細設計だけでは、複雑なシステムの全貌を把握しにくい。そのため、多少の重複感を感じながらも図面をModelerでまとめています。

ただし、Modelerでは語られているがDriverでは語られない情報が存在します。Modelerにおける「業務定義」と、その連係を示す「業務フロー(DFD)」は、Driver上の記述では欠落しています。

つまり、システムの動作形式を表す仕様情報には、「システムをどのように使うことが想定されているか」は含まれません。当然といえば当然なのですが、そこらへんについてはシステム仕様の外側で用意しなければいけない。そういうわけで、別途Modelerでモデルをまとめる作業が欠かせません。

投稿: わたなべ | 2017.06.30 08:41

回答、ありがとうございます。

業務定義がModelerに含まれるが、Driverには含まれないことは了解ですし、納得です。
逆に、Driverにしか含まれない、かつModelerには含めない方が良いとお考えの要素はありますでしょうか?

宜しければ、お考えを聞いてみたいです。
よろしくお願いします。

投稿: くまきち | 2017.07.02 23:32

そのような要素は確かにあります。たとえば、Driver上ではQF010A,QF010BやQF110,QF111,QF112のIDで置かれている機能定義が、Modeler上ではそれぞれQF010とQF110として置かれていたりします。これはModeler上での機能定義が「論理定義」であり、Driver上での機能定義が実装上の粒度を反映した「物理定義」であるゆえです。

他にも、Driver上では存在するテーブル定義がModeler上では存在していないケースもあります。複雑な処理の過程で必要になるワークテーブルやビューのようなものは、やはり「実装上の要請」とみなして、Modeler上では無視しておいたほうがよさそうです。

ModelerとDriverの双方の記述を用意することは効果的ですが、細かいレベルで一致させようとすると保守コストがかさむため、「ふわっとした感じで矛盾なく対応させる」ことが大事なんだと思います。これも良い質問ですね。ありがとうございます。

投稿: わたなべ | 2017.07.03 08:18

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: X-TEA Driverが1.3にリリースアップ:

« テーブル操作と業務ロジックの連動制御 | トップページ | フレームワークとドメイン特化基盤 »