将来体系設計プロセス-業務プロセスの抽象化

127回、128回でEEM(Entity Event Matrix:情報分析図)とDAM(DataAbstraction Matrix:情報抽象化表)を取り上げました。

それぞれ現行体系で、共通業務として複数の府省の独自の処理をまとめるために抽象化して最小公倍数的な機能を持たせて記述するために採用した抽象化の技法でした。それぞれDAMが各府省の独自のデータ項目を共通のデータ項目とするために抽象化、EEMはトランザクション出力情報に必要なマスターファイルのデータの関係付けを行い、業務と情報の妥当性を確認するものでした。
現行体系では現状を把握するために使用しましたが、将来体系の情報分析図としてEEM1をもとにEEM2へ拡張して作成します。今回はこの抽象化概念を取り上げようと
思います。
EEM2の作成の位置づけは将来体系のDMM(Diamond Mandara Matrix:機能構成図)
→DFD(Data Flow Diagram:情報機能関連図)を作成後、DAM (Data Abstraction
Matrix:情報抽象化表)をより抽象度を高めで作成し、EEM2(Entity Event Matrix
2)の作成となります。その後、WFA(Work Flow Architecture:業務流れ図)→
情報モデルとしての情報体系整理図の作成順序になります。

EEM2を話す前に将来体系のDAMを取り上げましょう。EEM1で共通業務として複数の府省を整理するためにデータフィールド名称を統一する話をしました。
例えば、承認者を○○承認者や××承認者、あるいは○○課長と言うように各府省で同じ機能でも全く違った名称で使用されていたフィールド名称を“承認者”というようなフィールド名称に統一することです。この考え方をEEMのトランザクションプロセスと組み合わせるとモット大胆な抽象化が可能となります。
例えば、「申請受付処理」、「申請承認・却下処理」、「申請許諾回答処理」があったとしましょう。各処理で承認者がいるはずです。そうしますと、フィールド名称は申請受付承認者、申請承認・却下承認者、申請許諾回答承認者という風に3種類のフィールド名称が必要になります。しかし、ここに処理コードを入れると1つの名称でよいことになります。“承認者”というフィールド名称にして、処理タイプコードとして、各処理コードをそれぞれ“01”、“02”、“03”を設けることによって、01の処理をしているプログラムは同じ承認者のデータ
フィールドを扱っていても“申請受付承認者”を扱っていることを意味することが可能になります。同様に、承認者という名称フィールドに加え、全く別の担当者や監督者、管理者、社員等人にまつわる名称がたくさん出てきます。
ただ、ある処理では“承認者”と“監督者” を使用するが、別の処理では“社員”と“管理者”しか使用しないという状況があります。
このような場合の抽象化は人タイプコードを設けてフィールド名称を“担当者”、“監督者”等にまとめ、人タイプコードを“H1”、“H2”と言う風にコード付けします。そうすると処理タイプコードと人タイプコードのマトリックステーブルを作成しておけば、ファイルのフィールド項目は格段に抽象化された項目で処理が可能となります。
このことはプログラム作成において単純なI/Oで処理ロジックを作成できるとともに、ユーザーはマトリクスのメンテナンスのみでシステム維持・管理の容易なシステム運用を可能とすることになります。
EEM2の構造はこの抽象化されたデータフィールド項目を立軸にとり、横軸にトランザクション処理を配置することでトランザクション処理にデータ項目の関係を関連付けた設計書が出来上がります。
実際の将来体系ではEEM1までの作成で完了になり、EEM2の拡張は行われていませんでした。
概念としては、非常にすばらしいのですが、設計者が追いついていけないところに原因があったようです。
第135回はここで終了します。
今回は「将来体系設計プロセス-業務プロセス設計の抽象化」を取り上げました。
次回は「移行計画の作成」をとりあげます。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする