フレームワークの構想 5日目

アクティビティをサービスレベルの粒度とするほうが管理がしやすいかもしれない。それともユースケースレベルの粒度がいいかもしれない。ユースケースを実行できるアクターはシステムユースケースを作成した時点で決まるので、その定義に基づいて設定していけばよいので、設計から実装に落としやすいというメリットがあると思う。1ユースケース＝1サービスで設計していることを思うと、ここでなんだかんだ言っていたサービスレベルの粒度やユースケースレベルの粒度というのは、つまり同じことを言っていたのかもしれない。ということで、サービスレベルの粒度でアクティビティを設定することにする。
たとえば、グループカンパニーがあり、全社に同じアプリケーションを導入する。アプリケーションの運用管理者は、各会社の運用管理者を任命しその会社内のすべてのアクセス権を与える。各会社の運用管理者は自分の会社のアクセス権はあるが、ほかの会社のアクセス権はなくほかの会社の情報を見ることはできないようにする。経費精算はその会社の全社員が行うことができ、経理処理は経理部の社員のみ行うことができるようにしたいという要件が当然ながらあると思う。それをこのフレームワークでどのように解決していくかを考えてみよう。
まず、アクティビティを定義することから始めてみよう。アクティビティは「勘定区分を保守する」、「経理精算申請をする」、「経理処理をする」という3つが導出された。
また、ロールとしては、「管理者」、「経理担当者」、「社員」が導出される。
グループとしては組織グループである「会社A」、「経理部（会社A）」、「その他の部署（会社A）」、「会社B」、「経理部（会社B）」、「その他部署（会社B）」が導出された。その他の部署というのは、とても大雑把だが、もっと組織に即したグループが導出されるかもしれいない。
あと、役割グループである「管理グループ」、「経理グループ」、「社員グループ」が導出される。
役割グループの「管理グループ」は「管理者」ロールに、「経理グループ」は「経理担当者」ロールに、「社員グループ」は「社員」ロールに割り当てられる。
組織は再帰的に割り当てることができ、「経理グループ」には、「経理部（会社A）」と「経理部（会社B）」が、「社員グループ」には、すべての組織グループが割り当てられる。
ユーザーとしては、会社Aの経理部にはA,B,Cさん、その他の部署にはD,E,Fさん、会社Bの経理部にはG,H,Iさん、その他の部署にはJ,K,Lさんが所属している。