« 動くシステムを営業段階で示せるか | トップページ | DDDの前に専門性を身につけよう »

2015.08.09

入出力定義と「非対話型業務」の関係

 プログラムの「入出力定義」は、業務システムの論理設計(基本設計)において重要な設計課題である。わかりやすく言えばそれは、対話型処理での画面や帳票のデザイン、およびテーブルの操作様式のことであり、機能定義(プログラム定義)に付随する要素として定義される。

 これらの入出力定義(パネル入出力、印刷入出力、テーブル入出力)は、「業務定義」や「テーブル定義」と密接に関連している(次図)。対話型業務はパネルや印刷物によって支援される過程として記述されるし、テーブル定義を無視してテーブル入出力は定義できないからだ。

 ▼各定義要素の相互関係
20150809a

 実装方針に関係なく、業務システムの論理設計はこのような形式でまとめられる。オブジェクト指向言語を使おうが、関数言語を使おうが、COBOLを使おうが、WEBアプリだろうが、デスクトップアプリだろうが変わることはない。言い換えれば、論理設計の段階では、実装上の事情については出来る限り考慮されないほうがいい(*1)。たとえばクラス図のような特定の実装方針にもとづく図法を用いることは、論理設計段階での「早すぎる実装化」として避けるべきだ。

 さて本題。ここで問題にしたいのは、入出力定義と「非対話型業務」との関係である。非対話型ということはパネル入出力を伴わないということだ。すなわち、ユーザとのやりとりを伴わずに、いつの間にか始まっていつの間にか終わる。そんな、サーバサイドで完結する処理のことである。

 それが「業務」と呼べるものなのかと思われる向きもあるかもしれない。システムはさまざまな業務を支援するわけだが、それらは「一定の役割(職務)を与えられた主体が、システムによって提供される支援機能を利用する過程」として様式化される。その主体が人間であるか機械であるか猫であるかの違いは本質的ではない。機械が担当するとしても業務は業務である。

 X-TEA Modelerでの業務定義の例を見よう。まずは人間が担当する「対話型業務」の例である(次図)。ひとつの業務定義はいくつかの「アクション」で出来ている。アクションのまとまりのことを「業務プロトコル」といい、アクションをツリー状に並べて手順を示す図法を「アクションツリーダイアグラム」という。

 ▼対話型業務の例
20150809b

 図からわかるように、個々のアクション毎にいくつかの「パネル入出力」がリンクされている。ツリービュー上で「機能定義」の下位に並ぶ「パネル入出力定義」のノードを、アクションにドラッグ&ドロップすることで、両者の関連が組み込まれる。

 つづいて、機械(バッチサーバ)が担当する「非対話型業務」の例である。アクションに関連づけられている要素を見てほしい。非対話型なので、パネル入出力ではなく「テーブル入出力」が関連づけられている。機械が担当する業務のアクションは、このような形で定義される。内容的にはいわゆる「システムフロー」に相当する。

 ▼非対話型業務の例
20150809c

 あらためて言うまでもないが、システムの支援対象となる主体の役割(職務)や担当業務をあらかじめ定義しておくことの意義は大きい。「システムの利用のされ方」が明確化されるゆえに、機能やテーブルのデザインの蓋然性が高まるし、せっかく開発したプログラムが使われなかったなんて情けない話もなくなるからだ。X-TEA Modelerを使えば、業務定義を組み合わせた業務フローを「スライドショー」の形式でユーザに示せる。さらに、システム定義ファイルをWEBサーバにアップロードすれば、業務定義を「業務マニュアル」としてブラウザ上で閲覧できたりもする。良いことづくめである。

 にもかかわらず、ほとんどの現場で業務定義はないがしろにされている。せいぜいカジュアルな業務フローがVisioあたりでお絵かきされる程度だ。しかもそれらは量が多いし作るのが大変なわりに、後で見返されることがほとんどなかったりする。

 本来であれば業務フローというものは、「いくつかの業務定義の連係様式」として記述されなければいけない。いっぽう業務定義は機能定義と連係した形で、機能定義はテーブル定義と連係した形で定義される。最初の図で示したように、システムを構成する多彩な定義要素は相互に関連しあっている。そのあり方を構成的に記述するためには、ExcelやVisioのような汎用ツールではなく、専用のエンジニアリングツールが要る。

 なお、これまでのX-TEA Modelerでは、テーブル入出力をアクションに関連づけることが出来なかった。最新版(1.4.22)でそれが可能になったので、非対話型業務を扱いやすくなった。活用してほしい。


*1.ただし、実装基板が提供する「処理パターン」は、論理設計の段階で機能定義をまとめる際に考慮されるべきである。実装効率とともに設計効率を高めるためだ。この意味で処理パターンこそが、論理設計と実装とを一気通貫で合理化するための鍵である。そして、多すぎず少なすぎない気の利いた処理パターンを提供することが、実装基板の重大な役割だ。

|

« 動くシステムを営業段階で示せるか | トップページ | DDDの前に専門性を身につけよう »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 入出力定義と「非対話型業務」の関係:

« 動くシステムを営業段階で示せるか | トップページ | DDDの前に専門性を身につけよう »