« 「データモデルなきアジャイル」の危うさ | トップページ | デザインパターンそのものをプログラミングする »

2012.08.29

業務システム向けのデザインパターン

 業務システム向けの有用なデザインパターンをいくつか紹介しよう。それらを設計上のイディオムとして覚えておけば、設計作業を効率化できる。

 なお「デザインパターン」はもともとはクラス構造を設計するために広まったもので、IteratorやObserverといった数々の有用なイディオムが知られている。ところがそれらの知識は、業務システムのアプリを設計する場合にはほとんど役に立たない。なぜならその際に問題になるのは、(1)どのようなDB構造に対する処理か、(2)どのようなUIをともなう処理であるか、の2点だからだ。

 言い換えると、業務システムのアプリを設計する際に「クラス構造」を考える必要にせまられているとすれば、設計・開発環境による支援がショボ過ぎる。まるで、受注生産の工作機械を設計するときにボルトやネジの設計から始めているようなものだ。上述した2点の設計要素さえ押さえれば(それだけでも簡単なことではない)、一気通貫に実装まで持っていける――それくらいの支援がなければ、業務システムのように複雑膨大なソフトウエアの開発・保守など合理化できるものではない。

 というわけでここでは、適用対象を「クラス構造」のレベルからより高級な「業務システム向けアプリの仕様」のレベルに引き上げた強力なデザインパターン(アプリケーションパターン)を紹介したい。シンプルなパターンから順を追って説明しよう。

■明細一括表示と単票保守

 まず、aをPKとしてb,cを属性とするテーブルAに次の4件のタプルが存在するとしよう。

[A] {a}, b,  c
   100 30 1,000
   200 10 1,200
   300 20 1,500
   400 10 1,500

 これらのタプル上の項目値を一括表示するパネル機能のデザインパターンが「明細一括表示」である。次図のように、検索条件で絞り込んで対象レコードを表示できる。ユーザがそれらのいずれかの行を選択するかボタン(機能キー)を押すかすれば、別の機能が起動されることになる。

20120829_1_2

 このパターンはさまざまな機能へ展開するためのハブとなるもので、ログイン後に示される「メニュー」に並ぶ機能の多くはこのタイプだ。この「明細一括表示」に「単票保守(単票形式でCRUDするためのパネル)」のデザインパターンを連係させることで、次のようにデータを照会・保守するための一続きの機能になる。単純だが、多くのマスターメンテナンスはこれらの組み合わせとして設計できる。

20120829_2_2

■明細一括保守とバッチレコード処理

 上述の「明細一括表示」のパターンをもう少し発展させてみよう。一括表示するだけでなく、それらを「一括更新」するためのデザインパターンだ。次図のように一覧し、さらにユーザによってチェックされたレコードが第2画面で更新モードで一覧されるというもので、私が「明細一括保守」と呼ぶパターンである。

20120829_3

 便利そうに見えるが、じつはこのデザインパターンはこれだけの処理としてはあまり使い道がない。「一覧して一括保守する」だけのデータ処理要件が案外少ないためだ。このパターンが威力を発揮するのは、一次テーブルが参照テーブルを伴っていて、一次テーブルの更新処理と同時に参照テーブルへの追加処理が起こるケースである。この形のデータ処理要件が業務システムではときどき現れる。

 処理の動きを形式化して説明しよう。一次テーブル(A)が参照関係をともなうモデルが次のようだとする。インスタンスとしては、Aの1行目がDの1行目に対応するいっぽう、Aの2~4行目の3件のタプルのdの値がヌル(つまり関連するDのタプルが存在しない状況)である。

[D] {d}, e
+  122 6,000

└─…[A] {a}, b, c,  d
      100 30 1,000 122
      200 10 1,200 (null)
      300 20 1,500 (null)
      400 10 1,500 (null)

 これらのうち、dの値がヌルであるようなAの3タプルをパネル上で一覧して、それらすべてについて内部でb順にソートして、bの値が同じもの同士を「バッチ(まとまり)」の処理単位とする。そのうえで、それらの処理単位毎に参照テーブルDのタプルを新規追加する。同時に、追加されたタプルの一次キー(d,自動採番項目)の値を、対応するAタプルに設定して更新する。結果的に、データ状況は次のようになる。

[D] {d}, e
+  122 6,000
|  123 9,500 ←追加
|  124 9,500 ←追加

└─…[A] {a}, b, c,  d
      100 30 1,000 122
      200 10 1,200 123 ←更新
      300 20 1,500 124 ←更新
      400 10 1,500 123 ←更新

 この一連の追加・更新処理の結果、Aの2行目と4行目がDの2行目に、また、Aの3行目がDの3行目に「新たに関連づけられた」ことになる。この過程を引き起こすUIを示そう(次図)。第2画面にはDの項目eの値を指定するための入力用カラムも置かれている。ここで更新ボタンを押せば、上掲の追加・更新処理が起こる。

20120829_4

 ここで、dの値がヌルであるようなAタプルを選択的に更新するだけではなく、それらのAタプルがbの値毎にまとめられてDタプルを生み出す「新たなまとまり(バッチ)」を成している点に注意してほしい。この独特な処理要件を組み込める点にこそ、このデザインパターンの強みがある。これを私は「明細一括保守」がオプショナルに提供する処理様式としてとくに「バッチレコード処理」と呼び、この処理様式における参照テーブルDをその役割上「バッチテーブル」と呼んでいる。

 これだけの説明ではこのパターンの意義をわかってもらえない恐れがあるので、次回で実際的な例を使ってもういちど説明しよう。また、パターンにもとづく実装上の工夫(メタプログラミング)の威力についても説明しよう。(次回記事に続く)

|

« 「データモデルなきアジャイル」の危うさ | トップページ | デザインパターンそのものをプログラミングする »

コメント

>(1)どのようなDB構造に対する処理か、(2)どのようなUIをともなう処理であるか、の2点だからだ。

似ている機能において「業務ロジックの共通化」を行うケースがよくありますが、このような「業務共通部品」の設計も一つの課題ではないでしょうか。

投稿: hongcz | 2012.08.30 17:07

言われるとおりです。その際に大事なのは、これが「個別案件」においてではなく、「開発環境」において既に解決されているべき課題だという点です。さらに、コードを書かずにアプリを組めるような形で、それらは整備されるべきなんですよね。

投稿: わたなべ | 2012.08.31 07:28

>これが「個別案件」においてではなく、「開発環境」において既に解決されているべき課題だという点です。

業務ロジックというものは、「個別案件」を分析・設計するなかで初めて明らかになるものだと思いますが、それがどうして「開発環境」において既に解決されているべき課題になれるのでしょうか。ちなみに「業務ロジック」とは「販売価格算出ロジック」、「在庫品引き当てロジック」等を想定しています。

投稿: hongcz | 2012.08.31 09:08

なるほど。私がコメントを読み間違っていました(^^;

開発環境のレベルで済ませておくべきなのは、この記事にあるような要素の整備で、個々の業務ロジックについては、言われるように個別案件でしか扱えませんよね。それらのパターン整備についてはまた別のアプローチが要るでしょう。私が有効だと考えているのは、業種別のモデルライブラリ(動く業務システムのライブラリ)です。

投稿: わたなべ | 2012.08.31 13:36

>業種別のモデルライブラリ(動く業務システムのライブラリ)
「業種別のモデルライブラリ」とパッケージソフトの違いはなんでしょうか。

投稿: hongcz | 2012.09.01 12:17

パッケージソフトの中で、以下の要件を満たすものが業務システムのモデルライブラリであると私は位置づけています。

・オープンソースである
・設計情報(データモデル、仕様書、業務マニュアル)が添付されている
・カスタマイズしやすい形で実装されている

投稿: わたなべ | 2012.09.01 15:53

業務システム向けのデザインパターン、というとエンティティに近い層の業務ロジックをイメージしてしまいました。
例えば、、複雑なバリデーション・制約条件。複数の属性から導かれる属性。DDDで言うところの「ドメインモデル」

このエントリで述べられているのは「エンティティに依らないUIの処理分類」だと理解しました。
業務システムには画面が沢山存在しますが、エンティティをイテレータ的・メタプログラミング的に扱う視点で見る考え方ですよね。
しかし、この設計概念は適切で簡潔で広く通じる呼び名がまだ無いんですよね。。。

投稿: hiu | 2012.09.03 10:28

hongcz様、hui様
仰っていることよくわかります。
私も渡辺さんの勉強会で同じ質問をしました。
ことUIだけに関していえば画面の多様性とノンプログラミングスタイルは常にトレードオフの関係にあると思います。どこで見切るかの問題だと思いますが・・・
あとは、1,2割のはみ出した画面に関してどういう実装方法を取るかだと思います。
またお二人が言われている、ビジネスロジックの部分をこのフレームワークの延長線上でどう実現するかは検討すべき事項だと思いますね

投稿: 大西 | 2012.09.03 17:53

重要な知識なんですがねぇ。正式には何と呼べばいいんでしょうかね(^^;

投稿: わたなべ | 2012.09.03 21:29

そう言う呼称は付けたもん勝ちなんででっち上げればいいと思いますよ。
欧米人はそういうのうまいですねえ

投稿: 大西 | 2012.09.04 17:23

大西さん

私には「デザインパターン」がいちばんしっくりくるんですがねえ。いっぽう、OOPで言うところのデザインパターンは「コーディングパターン」じゃんかと思ったりします(^^;

投稿: わたなべ | 2012.09.04 19:18

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 業務システム向けのデザインパターン:

« 「データモデルなきアジャイル」の危うさ | トップページ | デザインパターンそのものをプログラミングする »