» 【第85号】DOAにおける処理の考え方

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第85号】DOAにおける処理の考え方

DRI通信85号「DOAにおける処理の考え方」     2003.10.1
8月と逆転したような9月でしたが、ここに来て秋らしくなってきました。厳しい状況が続きますが、皆様いかがお過ごしですか。
システムの規模をデータの共用される範囲とするならば、それは世界がひとつになるまで拡大しなければ止まないものように思われます。種々のトラブルを耳にするとき、このニーズへの対応力が企業競争力の要因のひとつとして、ますます大きくなっていくように感じられます。
「(情報)処理」という言葉が、いろいろな局面において使われますが、その内容、とくに粒度などが、まちまちとなって誤解が発生することが少なくないようです。以下その整理をDOAの観点から試みました。ご意見など歓迎です。気軽にお寄せください。
■データベースをハブにして
データ中心アプローチとは、それまでのプログラム中心アプローチを改めるべきものとして登場しました。プログラム中心の場合は、一般にその出力を次のプログラムが受け取るバケツリレー方式になりますので、インターフェースがスパゲッティになりやすく、またあるプログラムの変更がその下流のプログラムに次々と波及し保守性が非常に悪くなります。
データ中心の場合は、データベースをハブにして、プログラムはここから入力を受け取り、ここへ出力を返します。一般にデータベースはデータの記憶場所としての役割を果たすものと理解されていますが、むしろ通信の場としての役割の方が重要ではないかと考えられます。これによって各プログラムはデータベース通信場とのインターフェースだけ考えればよいので独立性が高まり保守性が向上します。


■インターフェース先行
このような通信場となるデータベースを設計するには、まず各アプリケーション間のインターフェース(トランザクション/メッセージ)仕様を集めて調整を図ります。調整の対象は主としてそこに含まれるリソース(マスター/コード)データの仕様です。これがアプリケーションによって微妙に食い違っていることが多いからです。この調整にはインターフェースとなる各プログラムの入力と出力しか使いません。したがって「DOAはインターフェース先行」ということができます。入力、出力を決めてから、プログラムのロジックを考えればよいのです。「WHATを決めてからHOWを決める」という無理のない順序になります。
■プロセスの階層
プロセスには階層がありますが、われわれはまず3つの階層を考えます。DOAの処理モデルは組立工業の生産管理の処理モデルと似ているので、これとの対比で階層を示しましょう。
     情報システム           生産管理
レベル1:加工データの生成        :部品から中間部品の製造
レベル2:DBデータからの画面・帳票の生成:部品・中間部品から製品の組立
レベル3:画面・帳票のユーザへの送信   :製品の届先への出荷
プログラムが絡むのは一般にレベル1と2で、レベル3は最近でこそネットワークが使われますが、先ごろまでは郵便、宅配、電話、FAXが主体でした。一般にはプログラムの絡むレベル1と2を一緒に扱うケースが多いようですから、これを分けるのがわれわれのアプローチの特徴かと思われます。レベル1を分けることによって、レベル2の扱いがキットとして用意された部品の組立になって単純化されると考えます。
われわれは、このレベルに対応して、記述するドキュメントを
 レベル1:SPF(Schema Process Flow)チャート
レベル2:データ構造部分図
レベル3:IPF(Information Process Flow)チャート
のように使い分けます。
■実装独立/IT独立
プロセスを扱う際にも、まずは実装独立―特定のハードウエア・OS・DBMS・言語・通信手段に独立−で考えます。レベル1で月次売上金額=Σ出荷金額、出荷金額=単価*出荷数量、などを実装独立に考えることには違和感はないでしょう。実装独立なので、生成された加工データ(中間部品)も加工元データ(部品)と同じ、元のデータベース(部品倉庫)に戻すものとします。レベル2の画面・帳票(製品)については、実装独立に考えることに抵抗のある人が少なくないようです。生産管理の場合、ボディにAを取り付けてからBを取り付けるか、あるいはその逆にするか、またどんな工具を使うかなどでHOWは違い、したがって原価も違いますが、製品WHATとしては同じになります。同様に、実装独立ということで、画面・帳票のWHATまでを考えることにします。
レベル3でも実装独立とは、通信手段は問わず、要するに「その画面・帳票を、何時、誰に届けるか」だけを、まず問題にします。HOWを専門にやってきた人はいらいらするかもしれませんが、実装独立で十分詳細化することに専念し、その後でHOWを考えます。
ユーザは、ビジネス課題を解決するビジネスユーザ(の立場)とシステムを駆動するシステムユーザ(の立場)に分けて考えられますが、ビジネスユーザのニーズを扱うのが実装独立の立場です。問題を単純化し、また変化の激しいITの影響を少なくするためです。
■レベル1の処理
事務システムの加工データはn個の加工元データから1個の加工データを生成するものが主体です。すなわち、一般にy=f(x1、x2、・・)の形式で、月次売上金額のように、加工元データさえ与えれば、単純な合計、平均など汎用ロジックで対応できる簡単な加工データ、また固有ロジックが必要だが、出荷金額=単価*出荷数量のように数式で簡単に書けるものが多々あります。やや複雑なものとして、x1、x2、・・を与えて、加工データyを、テーブルfを参照して求めるもの、また関数f(ストアドプロセジャーによって実装することができる)への代入により求めるものがあります。しかしときにはもっと複雑で、陰関数f(y、x1、x2、・・)=0の形式になる場合もあります。ただしこれらはいずれも実装方式の違いで、実装独立の仕様はSPFチャートにより、データ項目定義として規定できます。
技術アプリでは、連立方程式やLP計算による最適化計算のようなOR問題を解かなければ値が決められないものが多くありますが、事務アプリでの「最適な発注数量を決める」とか「生産計画数量を決める」などは、同じ構造の加工データ決定問題と考えられます。
技術アプリの最適化問題としてまず、「長さ20cmの紐で矩形を作り面積Sを最大にするには」という単純な問題を考えます。縦をa、横をbとすると、S=ab=a(10−a)となり、aを独立変数として最適化計算すると、a=5の正方形が求まります。そこで今度は、事務アプリでの「部品AのサプライヤーSへの今月の発注」の問題を考えます。少なすぎると品切れが、また多すぎると過剰在庫が発生します。発注量aを独立変数として最適量を決めることになります。需要予測や評価関数の設定が難しいため、通常本格的最適化計算は行われませんが、aを意思決定データとして与えて在庫など種々の加工データを計算(シミュレーション)し、エキスパートの判断により決定するのが通常のやり方になります。したがって、一見技術計算と違ったように見えますが、「加工データ計算問題としてその本質はあまり変わらない」と私は考えます。
加工データの1種として、関連チェックデータがあります。x>yをチェックしたければ、c=x−yという加工データを定義し、c>0をチェックすればよい。関連データの数が多ければc=f(x、y、z、・・)を計算しこれをチェックすればよい。通常このcは物理ファイルには登場しません。このためcを考えつかないためか、難しく考える人がたくさんいます。しかしcは概念モデルでは、あるエンティティの立派なデータ項目として定義できます。たとえば品切れを判定するとき、在庫チェックデータ=(在庫数量―安全在庫数量)/安全在庫数量、が在庫エンティティのデータとして定義できます。
ただしチェックデータはその結果によって、メッセージを出力したり、分岐を発生させたりしますので、そのタイミングなど、単なる加工データより複雑な仕様を定義する必要があります。
■レベル2の処理
これはキットとして与えられたデータをアセンブルして、画面・帳票を作るものです。データの供給はDBMSの役割です。これはラインに部品を供給する払出係の機能に相当します。チェックデータの値によって、いわばラインの切り替えが発生しますが、データ項目はすべてそろっていますので、処理の骨格は画面・帳票対応のデータ構造部分図で表現される単純なものとなります。
■レベル3の処理
生成された画面・帳票をユーザに届ける処理、すなわち画面・帳票の用途−誰が、何時、何のために−を規定するレベルです。われわれは極力個人差の出ない記法ということで、IPFチャートを考案して活用しています。
■入力系
問題を分かりやすくするために、ここまではデータが全てデータベースにあるものとして、加工し、アセンブルし、送信する出力系の処理について述べました。入力系とは部品入庫受付に相当する処理です。実装従属の段階では、種々の配慮−これは事前に有限個のパターンを用意して対処できるはず−が必要ですが、実装独立の段階では、加工やチェックは一旦データベースに収まってから行うということで、入力は出力と同じレベル2の処理として扱うことができます。なおこの場合、処理の順序に関して、「加工データよりも加工元データの処理を先行する」という制約を配慮する必要があります。
■レベル4以上の処理
レベル4以上は、処理と言うより業務のくくりの話になります。最も高いレベルは、販売、生産、経理、人事と言った、業務種別と、家電、重電、半導体といった製品大分類の組み合わせからなる事業/部門になります。一般にはこれでは大きすぎるので、この細分を考えます。通常これはシステム/サブシステムなどと呼ばれていますが、基準の設定は難しく、コンセンサスベースで決めるのが実際的かと思われます。
■OOの活用
以上のように、処理のモデルも実装独立の領域は、すべてDOAで表現できるので、DOAの立場からすると、OO(オブジェクト指向)の活用は、レベル2の実装従属の部分に限ることができると考えますが、いかがでしょうか。