UML等各種ダイアグラムのエラーチェック体系化（その２９：機能構成図DMM）

シリーズUML等各種ダイアグラムのエラーチェック体系化です。

　現在「いろんなダイアグラムをＲＤＢにいれよう！」化計画、
　をやっていて、
　　・クラス図
　　・ＥＲ図
　　・アクティビティ図
　　・ユースケース図
　　・ＤＦＤ
　をやりました。で、このあとＥＡの成果物（ダイアグラム）にいこうとしています。

　今回は機能構成図（ＤＭＭ）です。

---

■機能構成図（ＤＭＭ）とは
機能構成図（DMM）は、

機能構成図（DMM）
http://www.meti.go.jp/policy/it_policy/ea/gainen/product/dmm/index.html
にある説明のとおりで（以下斜体は上記サイトより引用）

・ 中央に分析の対象とする機能名を書く。
・ レベル0（最上位階層）では、必ず8個をうめる、下位レベルは、最低3個をうめる。
・ 機能の分析なので、機能名は動詞（～をする）、あるいはそれに準ずるものであること。
・ 「管理」など機能の内容があいまいな用語を使用することは避ける。
・ 迷う際は1つ下の階層の機能構成図（DMM）を作成して、バランスをチェックする。
・ 作成した機能構成図（DMM）にリファレンス番号を入れる


は？

こんな図
です。

---

■ＲＤＢにいれる

　ってことで、これは、○×（三目ならべともいう）のように線をかき、真ん中に親の機能名、周りにそれの子の機能名を書きます。
　子の機能を細分化するときは、その機能に→をかいて、また、○×（三目ならべともいう）のように線をかき・・・（以下再帰的に続く）

　ってことは、機能がノード、親と子を結ぶ部分（○Ｘの図間の→、これは、○Ｘの図の真ん中とまわりの関係でもある）がエッジになります。

ただし、ここに書いた、

・リレーション（アーク）の親子において、親１つ、子一個以上の場合（木構造）
　　　→子に親ＩＤを入れておくだけでＯＫ

に相当しますので、エッジの関連部分はいらず、機能名に親機能ＩＤを入れればいいことになります。

なので、ＲＤＢに入れると

機能テーブル（機能ＩＤ，機能名、親機能ＩＤ）

となります（親機能ＩＤがＮＵＬＬのものがトップになります）。

---

■機能構成図（ＤＭＭ）の意義

　このＤＭＭの機能は、プロセスですから、ユースケース図のユースケースからだろうが、アクティビティ図のアクティビティとか、ＤＦＤのプロセスとかから出せます。

　じゃ、いみないじゃーん

　っていうと、それは違います。
　発想が逆で、このＤＭＭを作ってから、アクティビティ図などに展開していきます。

　そこで、ＤＭＭは考えるきっかけ、ドキュメントだと目次に相当していくものです。

　時間的にもアクティビティ図より先に作るものなので、アクティビティ図からつくることはできません。むしろ、ＤＭＭをつくり、それに関連するような形でアクティビティ図を作るといった形になります。

　そーいう、とっかかりの中間成果物として、ＤＭＭの意義があります。

Ｐ．Ｓ　逆に言うと、そのぐらい大きなレベルになると、データ入出力を書ききれない（わからないとはいわないけど）ので、アクティビティ図、ＤＦＤとかはあんまりなじまないのかも？

Eclipseのプラグイン開発でActionSets等クリックしてもGenericしか出ない時

一般にEclipseのプラグインを開発しようとするときは、
ここに書かれるように、

１．プロジェクト作成
２．「依存」タブでプラグイン選択、「拡張」タブで利用するもの新規追加
３．拡張エレメントを適当に設定、classでクラス名記入して参照、
　　その後のダイアログ、テキトーにやるとクラスが出来ているのでそこに記入
４．「ビルド」タブと「ランタイム」タブを設定して、
　　概要タブからエクスポートウィザードを使って配布

すればできる。

　問題は、１はできたのに、２の拡張タブで、本来は、以下の図

のように、ActionSetsを右クリックしたら、Newで、ActionSetとか、作れるものが出てこなきゃいけないのに、

　以下の図

のように、なにをクリックしてもGenericになる場合


【原因】
　たぶん、Eclipse SDKを入れていない
（不完全に入っている。他のプラグインの影響で１はできるが、２は入っていない）

【対応】
Help→Install new softwareで、ダイアログが出てくる。
一番上に設定するWork with（日本語はわからん）を
The Eclipse Project Updates - http://download.eclipse.org/eclipse/updates/3.5
そうすると、下にいくつか出てくるので、
Eclipse SDK
を選択。
あとはてきとーにやって、インストールして再起動すると、ちゃんと上の図のように選択できるようになった。


※Eclipse 3.5 英語版で確認

BPMNでJ-SOXに対応できるか？（ビジネスプロセスモデリングのお話）

　まだ、お勉強中の事項なので、勘違いかもしれない。間違っていたらごめんなさい。

　Ｊ－ＳＯＸのような内部統制および業務監査をすることを考える。
　この場合、業務を図などで書き表す（ビジネスプロセスモデリング）必要があると思う。
　事実、

財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の設定について（意見書）
http://www.fsa.go.jp/singi/singi_kigyou/tosin/20070215.pdf
では、業務流れ図の例が挙がっている（中央ページ５９、右端ページ９２、ＰＤＦページ100/129）

　ところが、この業務流れ図、ＥＡの業務流れ図（ＷＦＡ）には似ているのだが、ビジネスプロセスを記述する標準的な記法、ＢＰＭＮとはちがう。

　なぜか？

---

　ＢＰＭＮの記法をＷｉｋｉｐｅｄｉａで見ると、ＵＭＬのアクティビティ図に似た感じになっている。
　で、ここで問題なのだが、データの表現が、「データオブジェクト」にまとめられている（これも、アクティビティ図と同じ）。

　ところが、監査の場合は、データが存在するというだけでなく、データが何に（紙とかＰＣのハードディスクとか）かかれるのかが重要である。
　というのも、監査は、原始証憑と、実際の業務を付き合わせることによって、正当性を確認する。

　ということは、原始証憑が、どのような形、つまり受注票のような紙になっているのか、ハードディスクに入ってるのか、だれかのＵＳＢメモリに入っていて、持ち出されちゃってるのかということがわかんないと、監査できない（業務との突合せを始められない）。

　なので、業務フロー中に、データが「どのような形で」存在するか、ハードディスクなのか帳票なのか画面表示なのか、そしてそのデータは誰が作成し、どこに保存され、どのように廃棄されるのかが明確になっていないといけない。

---

　ＢＰＭＮは、その辺が、データオブジェクトとなっているだけで明確でないのに対し、
　上記のＪ－ＳＯＸの業務フローも、ＥＡの業務流れ図も、図でハードディスク、帳票とかきわけ、帳票名、ファイル／ＤＢ名をそこに記入するので、明確になっている。
　その辺が大きな違いだし、そこが監査業務を行うことが出来るか出来ないかの決定的な違いとなっている。

　このため、ＢＰＭＮは使われないのではないか？

---

　もっともこれはＢＰＭＮは使えないというわけではなく、ＢＰＭＮの図の決まりにないというだけの話で、データオブジェクトに記入するデータオブジェクト名で、
　　「票」とついたら紙
　　テーブルとついたらＤＢ
のような、名前からメディアが明確になるような決まりを追加すればよい。

　ただ、これに気づかないで、どんどん作成されると、困ったチャンになるような気がする。

　ＢＰＭＮとＢＰＥＬ間には、マッチング方法があるらしく（ま、オープンソースもあるけど）さらにＢＰＥＬからＪａｖａに変換するBPELJとかあるみたいなので、

　ＢＰＭＮ→ＪＡＶＡの関係には、ＵＩを抽象化すれば、いくかもしれない。

　（ってことはアクティビティ図→Ｊａｖａにもいくということ？）
　しかし、最終的にシステムに落とし込むには、データオブジェクトのデータをどーいう形で表現するか、つまりＵＩを具体化しないといけないので、ここがないＢＰＭＮでは、ＵＩ部分までは作れないような気がする（生成されたＪＡＶＡのクラスから、出力、入力クラスを呼び出して、処理を委譲すればいいだけとは言えるかもしれないが・・）

　このへんについて、つづきを別の機会に気が向いたら書く。