« 要件を要件として深追いしてはいけない | トップページ | プロセス論の時代からコンテンツの時代へ »

2005.12.24

システムの論理設計を構造化するための視点

 業務システムの論理設計を構造化するためのさまざまな視点がある。それらの意味合いを区別しないままに設計情報を漫然と眺めるだけでは、読み手として重要な項目を読み落とすし、設計者として複雑膨大な設計情報を「分割して統治」することにも失敗する。 「CONCEPTWARE/財務管理」をとりあげて、システムのあり方を眺めるためのいろいろな視点を見てみよう。

◆業務フローの視点で眺める

CONCEPTWARE1

 XEADにおいてシステム定義は、ツリービュー上の「業務フロー」、「職種別担当業務」、「サーバーモジュール」の3つのまとまりとして示される。ひとつめのまとまりの「業務フロー」の下位には、「CONCEPTWARE/財務管理」では「現預金口座管理の流れ」、「手形管理の流れ」、「売上収益回収の流れ」といった16個の要素(ノード)が並んでいる。それぞれのノードを選択すると、データフローダイアグラム(DFD)でまとめられた「業務(後述)の連係様式」が示される。

 そのまとまりは、データモデリングツールなどで「サブジェクトエリア」と呼ばれる単位に相当する。サブジェクトエリアは、業務のまとまりやそれらのスムースな連係を考えやすくするためのユーザ(業務管理者)よりの視点である。データモデルはサブジェクトエリアよりも、後述する「サブシステム」という単位で眺めたほうがより工学的な情報が読み取れるので便利だ。

◆職種と業務の視点で眺める

CONCEPTWARE2

 2つめのまとまりである「職種別担当業務」の下位には「取引先管理者」、「決算管理者」、「部門管理者」等12個の「職種」がが並んでいる。「職種」は一定の業務上の権限と役割を示すまとまりで、ひとりの職員はひとつの職種を担当するか、複数の職種を兼任する。

 「取引先管理者」の下には「ログインとログアウト」の他に「取引先情報の登録」、「銀行情報の登録」が並んでいる。それらは「取引先管理者」が担当する「業務」である。ひとつの職種が担当する業務の数として3個というのは少なめだ。「CONCEPTWARE/財務管理」では他の職種も合わせると92個の業務が定義されているので、ひとつの職種あたり平均で8個ほどの業務が担当されていることになる。

 XEADのツリービュー上で個々の業務(業務定義)のノードを選択すると、「その仕事を開始すべき事態」を意味する「イベント」や、「アクションツリー」と筆者が呼んでいる記法で仕事の手順(業務マニュアル)が示される。これらが筆者が言う「業務システムの三要素」のひとつの「業務モデル」に相当する。そして個々の業務定義は、上述したDFDにおける「プロセス」にリンクされている。

 いわゆる「メニュー」というのは職種毎に用意されるソフトウエアだ。たとえば取引先管理者がシステムにログインすると「取引先管理者メニュー」が現れる。そこには「取引先情報の登録」と「銀行情報の登録」を遂行するための機能だけが並ぶはずだ。取引先管理者はそれらの仕事しか担当していないのだから、そのために必要な機能だけが並んでいればよい。それ以外の機能に入り込めるようなメニューになっているとしたら、使い勝手から言っても機密上から言っても問題である。

◆機能と帳簿の視点で眺める

CONCEPTWARE3

 3つめのまとまりである「サーバーモジュール」は「コンピュータ上のソフトウエア」くらいの意味の言葉だ。その下位にはここでは「セッション管理」、「共通リソース管理」、「仕訳データ管理」等の19個の要素が並んでいる。これらの要素毎に、下位ノードとして「データ構成」、「機能構成」が並んでいる。それらが「業務システムの三要素」の残りのふたつである「データモデル」と「機能モデル」に相当する。「サーバーモジュール」はシステム定義全体で情報量がいちばん多い部分で、全体の7割程度を占める。

 なにしろ情報量が多いため、「サーバーモジュールのあり方をまとめるのがシステム設計の仕事」と勘違いされがちだ。上述した職種および個々の仕事の定義やそれらの連係様式までを含めてまとめることで、ようやく「業務システムのシステム設計」は完遂される。ここらへんはコンピュータ上のソフトウエアだけで完結するタイプのシステムと大きく異なる点だ。業務システムは想像以上にコンピュータの外側への「社会的な広がり」をともなっていて、そのあり方を無視できない。

 じっさいXEADにおいて、機能定義に含まれるパネル入出力定義(UI)は、上述した業務定義の個々の手順にリンクされる。このツールを用いる限り、業務定義は機能定義がまとまるまでは完成しないし、機能定義は業務定義にリンクされるまでは妥当性や必要性が不明のままだ。システムの仕様は、「仕事の進め方」と「帳簿組織のあり方(データモデル)」と「機能のあり方」とが統合された結果として成立する。XEADはそんな現実路線のシステム観を背景にもつツールだ。

◆アクセス制限にもとづくモジュール分割

 サーバーモジュールがいくつかに分割されたとき、それらは「サブシステム」と呼ばれることが多い。サーバーモジュールをどんなサブシステムの組み合わせとするかは、システム設計において決定的に重大である。その良し悪しがシステムの開発や保守フェーズの効率に大きな影響を与えるからだ。「CONCEPTWARE/財務管理」には、テーブル定義が79個、機能定義が262個含まれるが、上述したようにそれらが「セッション管理」をはじめとした19個のサブシステムとしてブロック化されている。

 それらのサブシステムをどんな基準で切り出せばよいのだろう。業務のまとまりや部署や職種毎に切り出せばよいと考える設計者が少なくない。しかし業務のまとまり(サブジェクトエリア)は上述したようにユーザよりの視点であって、複数のサブジェクトエリアに関連するはずのデータや機能もふつうに存在するのでアテにならない。また、職種のまとまりも組織体制の変更にともなって変化しやすいので基準としてアテにならない(組織変更に応じてサブシステム構成までを変更するなんてたまらない)。そこで「アクセス制限」と呼ばれる工学的基準で切り出すことを「三要素分析法」では推奨している。

 個々のサブシステムはいくつかのテーブル定義といくつかの機能定義を保持するが、それらの機能定義がサブシステム内のテーブル(内部テーブル)やサブシステム内の機能(内部機能)のみを利用するわけではない。次の図のように、サブシステムAに含まれる機能fa2が外部テーブルtb1を利用したり、サブシステムBに含まれる機能fb1が外部機能fa1を利用したりもする。

subsystems

 ただし、うまくサブシステム分割された場合には、この図のように内部テーブルであれば追加・参照・更新・削除(CRUD)のすべての操作がなされるいっぽう、外部テーブルであれば参照(R)しかされない形になる。どうしても外部テーブルを追加・更新・削除(CUD)させたいなら、機能fa1のような関数を用意したうえで、機能fb1などから外部機能として利用してもらえばよい。

 このように考慮されたシステムにおいては、サブシステム間での越境的な追加・更新・削除(CUD)が存在しないことになる。結果的に、テーブルのレイアウトや扱い方が変更された場合の影響を最小限に抑えられる。あるテーブルを利用している他のサブシステムの機能はせいぜいそれを参照するだけだからだ。オブジェクト指向プログラミングでのアクセス制限やカプセル化の考え方と似ていて面白い。

conceptware4

 なお、XEADのデータモデルはサブシステム単位で示される(この図は「セッション管理」のサブシステムでの例)。その上にはテーブル毎のサブシステム内のCRUDが集約的に示されている。内部テーブル(青色)と外部テーブル(灰色)が色分けされているため、色の違いとCRUDの「ゆらぎ具合」を眺めることで、サブシステムの性格を読み取りやすい。この例以外についても「CONCEPTWARE/財務管理」の実物で確かめてみてほしい。

◆「構造」を提供するのが設計支援ツールの役割

 以上、3つの「構造化基準」を紹介した。「仕事が連係する様子を眺めるための業務のまとまり」、「担当者の権限や能力に応じた業務のまとまり」、「開発や保守の効率を考慮したデータや機能のまとまり」のそれぞれが、固有の問題意識にもとづいていることがわかると思う。

 システム定義の情報量は膨大であり、しかもシステム定義を眺める人々の立場も多彩である。それぞれの読み手がその問題意識にしたがってシステムのあり方を評価できるように、各定義要素はさまざまな基準にもとづいて構造化される必要がある。そのような多様な基準にもとづく「構造」を設計者に提供するのが、設計支援ツールの重要な役割だ。

|

« 要件を要件として深追いしてはいけない | トップページ | プロセス論の時代からコンテンツの時代へ »

コメント

DFDという用語が出てきますが、渡辺さんの
DFDはいわゆる旧来からのゲーン・サーソンや
ヨードン・デマルコ流のDFDとは違いますよね。
経済産業省あたりが、この旧来式DFDがDOA
の標準仕様書であり、今でも開発現場で通常使用さてているかのように誤解しているふしがあります。
ですので、(以前からと同じことを言って恐縮
ですが)何か別の呼称をつけるか「旧来のもの
とは違う」ことを強調していただけると良いの
ではないでしょうか?
勝手な意見で申し訳ありません。

投稿: motomura | 2005.12.27 14:11

本村さんもご存知のように、日本ではデマルコらの「構造化分析/設計(SA/SD)」が「DOA」と呼称されて大規模に実施された経緯から、今でもDFDとDOAとが結びつけられることが多くて困ります。

三要素分析法でのDFDがオードソックスなものと違っている点はそれなりに強調しているつもりなのですが、いっそのこと「プロセス連係図」とかなんとか呼び変えてもいいかもしれませんね。

投稿: わたなべ | 2005.12.28 08:30

日経BP社から、「特別編集 証言とキーワードで読み解く 情報システム2006」というのが
日経コンピュータや日経情報ストラテジーとともに送付されています。
このキーワードの中に”DOA”というのがあるのですが、DFDでの分析結果からER図を作るという渡辺さんもご存知のように佐藤正美さん(SDI)が誤ったやり方として何年も前から指摘しているやり方で紹介されています。
隣のページにうちの会社の広告が掲載されて
いるもので当社の仕業と勘違いされて実は迷惑しています(^^;)

投稿: motomura | 2005.12.28 10:22

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: システムの論理設計を構造化するための視点:

« 要件を要件として深追いしてはいけない | トップページ | プロセス論の時代からコンテンツの時代へ »