ＣＲＵＤ分析について

ＣＲＵＤマトリックスについて・・・（前置きです）
Xupperの機能にマトリックス分析機能というものがあります。もともとは、ＣＲＵＤマトリックスと呼んでいた機能です。

ＣＲＵＤマトリックスの機能概要としては、エンティティ関連図で整理したエンティティ(データ・テーブル）とビジネスフロー図（もしくはプロセス階層図）で整理したプロセス（機能）との関係をＣＲＵＤで定義するという機能です。

ＣはCreate（作成）、ＲはRead（参照）、ＵはUpdate（更新）、ＤはDelete（削除）を意味しており、どのプロセス（機能）がどのエンティティ（データ・テーブル）に対してどのような処理（アクセス）を行っているかを整理する機能です。

Xupperでは、各プロセス（機能）のＣＲＵＤに対してタイトルを付与できるようになっており、同じＲでも異なる処理を別タイトルで定義するということができるようになっています。（なぜか、Ｒ（参照）も更新仕様タイトルってことで・・・）

Ｒについていえば、あるエンティティ（データ）を参照するパターンというのは複数パターン存在するはずですから、当然複数のタイトルが登録されるということになります。
極端な話エンティティ（データ・テーブル）の各属性（カラム）単位でのアクセスの組み合わせの数だけパターンがあるともいえます。実際には、各種検索条件もありますので、組み合わせで考えれば膨大なパターンになります。 
また、１つのエンティティ（テーブル・データ）のみを参照するわけではなく、複数エンティティ（データ・テーブル）を結合して参照するということが多いと思いますので、さらにＲのパターンとしては多くなる可能性があります。
（ちなみに、Xupperのマトリックス分析では、エンティティ単位にタイトルを登録して処理パターンを識別するという機能になっていますので、複数エンティティを利用する処理の場合は、異なるエンティティに同じタイトルで登録しておく必要があります。）

ＣＲＵＤ分析・・・
エンティティ（データ・テーブル）とプロセス（機能）単位にＣＲＵＤが定義した後は、ＣＲＵＤ分析を行います。
ＣＲＵＤ分析とはエンティティのライフサイクルの分析です。
何をするかといえば、エンティティから見て１つ以上Ｃ・Ｒ・Ｕ・Ｄが定義されているかどうかをまず確認していきます。

チェックの結果当該エンティティに”Ｃ”が定義されていなかった場合、対象のエンティティ（データ）はレコードの追加が存在しないか、その検討が漏れているということになります。
システムの初期導入時にテーブルのレコードが作成され、システム稼動中には追加がないということになります。（基本的にそのようなデータはエンティティとはしないと思いますが・・・）
あるいは、レコードの追加頻度も少ないし、開発工数の関係から追加するプロセス（機能）を実装せず、必要に応じてテーブルに人間の作業で直接レコード追加すれば、足りるといったエンティティ（データ）であるというものが該当します。
上記のように、Ｃが定義されていない理由が明確であれば、そのままでかまいませんが、Ｃが定義されいない理由が不明な場合は、当該エンティティ（データ）の作成処理が漏れているのではないかということを再度検討する必要があります。

Ｒが定義されていないということは、対象のエンティティ（データ）を参照（利用）するプロセス（機能）が存在しないか、その検討が漏れているということになります。
参照されないデータをわざわざ作成したり、更新したりする必要はそもそもありませんので、本当に参照されないデータであれば、不要なデータであるということになります。
本当はどこかで参照（利用）されるが、プロセス（機能）側の分析が漏れているという場合は、再度どのプロセスで参照（利用）されているかということを分析していきます。

Ｕが定義されていないということは、対象のエンティティ（データ）は変更されないということになります。通常のアプリケーションで維持管理対象となっているデータで変更がないということは考えられませんので、これも検討漏れではないかということを再度分析していきます。

Ｄが定義されていないということは、対象のエンティティ（データ）は削除されないという意味になります。
仮に追加が存在するエンティティであった場合は、レコードが追加されるけれども削除はされない状態で、どんどんリソースのみ消費していくということになっていまします。
ユーティリティ等で一括削除するデータであるため、ＣＲＵＤとしては定義されていないという場合は、Ｄが定義されていない場合もあるかもしれません。
Ｄが定義されていない理由が明確であり、システム的に問題がなければ、そのままにしておいてもかまいませんが、なぜ、Ｄが定義されていないのかについて、理由が明確でない場合は、再度、データを削除するプロセス（機能）について検討を行います。 

複数ＣＲＵＤの定義・・・
次に、１つのエンティティに対して複数のＣ・Ｒ・Ｕ・Ｄが定義されている場合です。

Ｃは基本的に１つのプロセスからのみ行われるようにしたほうがいいといわれています。別々のプロセスからCreateを行う必要がある場合も、共通処理として定義し、その処理を個々のプロセス（機能）で共有することが望ましいと考えます。

Ｒについては、複数のＲが定義されても問題はありません。

Ｕについても、基本的に複数のパターンが存在します。条件によって更新するカラムが異なるということが考えられるからです。

Ｄについては、個別のアプリケーションで実施することが多いですが、場合によってはユーティリティを使用したり、バッチで一括で削除するといったことがありますので、必ずしも１箇所でのみ定義されるというわけでもありません。

ただし、ＣＲＵＤについてもエンティティ関連図と同様、論理ＣＲＵＤと物理ＣＲＵＤという考え方を導入することができます。上記のユーティリティやバッチで一括削除というのはどちらかというと物理ＣＲＵＤの話で、論理ＣＲＵＤとしては各プロセス（機能）で実施するという整理を行っていたほうがいいでしょう。また、削除フラグで論理的に削除されたものとみなすという場合も、論理ＣＲＵＤでは削除ですが、物理ＣＲＵＤでは削除フラグを更新という扱いになります。

残念ながら、現在のXupperには論理ＥＲＤと物理ＥＲＤを切り替えて定義するという機能はありますが、論理ＣＲＵＤと物理ＣＲＵＤを切り替えて定義するという機能はりません。現時点でのXupperのマトリックス分析は物理ＣＲＵＤのみに対応しています。これはちょっと細かい議論ですね、すいません・・・。）