EEM-その2

前回はEEM(Entity Event Matrix)の設計の考え方を取り上 げました。
今回はEEMの中で紹介されている抽象化のためのモデルである「EEM2」を取り上げます。

 前回取り上げましたEEMモデルはEEM1といい、業務プロセスにおけるイベント情報(=トランザクション情報)とスタンディング情報(=マスター情報)の情報フローの関係をそのまま記述する手法でした。
このEEM1に対して、EEM2はEEM1の発展系で、イベント情報の抽象化とトランザクション処理の抽象化を図った設計モデルです。
こう申し上げても何のことやら分りませんので、まず、“抽象化”の概念を掴んでみましょう。

 (1)データ属性の抽象化
  抽象化ですから、より観念的な捉え方ですので、人を例にとって説明を加えてみま しょう。
“松井秀樹”、“鈴木一郎”という名前の捉え方は具体的な捉え方ですが、“野球選手”といえば抽象的になります。この表現を“人”という名称で括るともっと観念的な上位レベルの抽象化が出来ます。

この考え方を受発注業務に適用してみましょう。
受注業務の処理は受注伝票を受付け、承認する受注担当者があり、在庫がない場合に商品を発注承認する発注担当者、仕入商品の受入・検収の承認をする検収担当者というように、それぞれの事態としての承認者がいて、職務として配置されているわけです。
情報システムで捉えますと、マスターファイルであるスタンディング情報にこれらの担当者名である“受注担当”、“発注担当”といった属性名(=フィールド項目名)が組み込まれています。この属性名を抽象化すると“承認者”という属性名称で抽象化すれば1つのフィールド項目で整理でき、スタンディング情報の属性項目は非常にシンプルに設計できます。

具体的なマスターファイルの構築の観点では“承認者”の項目テーブル作り、各業務の承認者を登録しておき、担当の業務処理をするとき、“承認者”テーブルから該当の業務承認者を取り出すようにすれば良いわけです。この業務処理とはトランザクション処理のことですので、トランザクションシャリの抽象化と関連付けてみましょう。

 (2)トランザクション処理の抽象化
 トランザクション処理は受注、発注、検収といったイベント、すなわち人の介入(=入力)によって発生します。このときのイベント情報の承認者属性名には“受注担当者”、“発注担当者”、“検収担当者”がそのイベント毎にスタンディング情報から抽出されてくる必要があります。
ということは、イベントによって具体的な属性が決まるのですから、トランザクション処理のタイプ毎に存在する属性を抽象化し、スタンディング情報のレコードとして持てば良いことになります。
たとえば、イベント情報として、「組織番号」、「組織名」、「承認者」が必要としますと、スタンディング情報としては「イベントコード」、「組織番号」、 「組織名」、「承認者」の形式でイベントコード毎の具体的属性を持ったレコードがあれば、イベント情報との連携が取れることになります。
このようにして設計されたシステムは“ワンライティングシステム”を構築できます。

というのは、イベントが発生するとき、イベントコードと追加項目を入力または自動認識するシステムにしますと、スタンディング情報から必要とする具体的な項目は自動的に抽出することが可能になるからです。
少し、ソフトウエアエンジニアリング的思考の強い話になりました。

経済産業省の電子政府の設計ではこのEEMが取り上げられていましたので紹介しました。
第60回はここで終了します。EEMの抽象化設計の考え方を取り上げました。
次回は、最近の世界のシステム設計の中心的存在であるオブジェクト設計を取り上げます。

シェアする

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

フォローする