Xradianの個別の機能の説明に入る前に、Xradianを作成（設計）した際の基本的な考え方を少し整理しておきたいと思います。
今回は、「アプリケーション境界の設定」についてです。
前回の「ＩＦＰＵＧ法でのＦＰ見積」でも紹介しましたが、ＦＰ計測を行う上で、アプリケーション境界を設定する必要があります。
アプリケーション境界は、① 計測対象アプリケーションとユーザの境界及び② 計測対象アプリケーションと他のアプリケーションとの境界を意味します。
アプリケーション境界を設定する際の原則としては、① ユーザビューに基づいて設定するということと、② 関連するアプリケーションとの境界は、技術的にではなく、業務機能で設定するということがあります。
Xupperでアプリケーション境界を設定する方法としては、以下の方法が考られます。
① サブシステム
② ビジネスフロー階層
③ アプリケーションエリア
④ サブシステム＋アプリケーションエリア
⑤ ビジネスフロー階層＋アプリケーションエリア
⑥ ＣＲＵＤマトリックス
① サブシステム
プロセスからトランザクションファンクションを識別するために、サブシステムを選択するという考え方（案）です。
【サブシステム】
トランザクションファンクションの規則に「他のトランザクションファンクションと異なること」というものがあります。
プロセス階層図では、同じプロセスを別のサブシステムに重複して定義することはできませんので、サブシステムをアプリケーション境界として考えるようにすれば、重複しないという条件を満足させることができます。
しかし、サブシステムを指定しただけでは、対象のデータファンクションを特定することができないという問題が残ります。
（ＣＲＵＤまで定義してある前提であれば、プロセスがわかれば、ＣＲＵＤ情報から対象となるエンティティ（データ）を特定することは可能ですが・・・）
② ビジネスフロー階層
プロセスからトランザクションファンクションを識別するために、ビジネスフロー階層を選択するという考え方（案）です。
【ビジネスフロー階層】
トランザクションファンクションの規則に「他のトランザクションファンクションと異なること」というものがありますが、ビジネスフロー図では、同じプロセスが複数のビジネスフロー階層に登場してもいいという仕様になっていますので、上記の条件を満足することはできません。
しかし、サブシステムとは異なり、ビジネスフロー図ではデータオブジェクトを定義可能ですので、トランザクションファンクション（プロセス）のみではなく、データファンクション（データオブジェクト）を識別することが可能となります。
（しかし、ビジネスフロー図で定義可能なデータオブジェクトでは、属性（データ項目）の定義を行うことができませんので、データファンクションの複雑度を判定することはできません。）
③ アプリケーション・エリア
エンティティからデータファンクションを識別するために、アプリケーション・エリアを選択するという考え方（案）です。
【アプリケーション・エリア】
ただし、エンティティは異なるアプリケーション・エリアに重複して定義することが可能ですので、アプリケーション・エリアごとに算出した場合、重複して集計してしまう可能性があります。
また、アプリケーション・エリアを指定しただけでは、対象のトランザクションファンクションを特定することができないという問題が残ります。
（ＣＲＵＤまで定義してある前提であれば、エンティティがわかれば、ＣＲＵＤ情報から対象となるプロセスを特定することは可能ですが・・・）
④ サブシステム＋アプリケーションエリア
サブシステムを指定するだけでは、データファンクションを識別できないため、別途アプリケーションエリアを指定するという考え方（案）です。
この方法であれば、サブシステムに存在しているプロセスからトランザクションファンクションを識別し、アプリケーション・エリアに存在しているエンティティからデータファンクションを識別するということが可能となります。
デメリットとしては、見積り計測対象を複数指定しなければいけないということと、サブシステムとアプリケーション・エリアとの整合が取れている保証はない（人間が確認する必要がある）ということです。
⑤ ビジネスフロー階層＋アプリケーションエリア
ビジネスフロー階層を指定するだけでは、データファンクションの複雑度を判定するための、データ項目（DET）を識別できないため、別途アプリケーションエリアを指定するという考え方（案）です。
この方法であれば、サブシステムに存在しているプロセスからトランザクションファンクションを識別し、アプリケーション・エリアに存在しているエンティティからデータファンクションを識別するということが可能となります。
エンティティが識別できれば、エンティティの属性項目からDETを識別することが可能となります。
デメリットとしては、見積り計測対象を複数指定しなければいけないということと、ビジネスフロー図で定義しているデータオブジェクトとエンティティとの整合が取れている保証がないということです。
（仮に、アプリケーション・エリアに登録されているエンティティをデータファンクションとして識別するとすると、ビジネスフロー図に登録されているデータオブジェクトは無視するということになります。）
⑥ ＣＲＵＤマトリックス
エンティティ（データファンクション）およびプロセス（トランザクションファンクション）を識別するために、ＣＲＵＤマトリックスを選択するという考え方（案）です。
【ＣＲＵＤマトリックス】
複数の対象を指定するという方法は、操作性や整合性の問題があるため、できるだけ対象を指定する際は１つのオブジェクトを指定するようにした方がいいと考えています。
しかし、①の方法では、データファンクションの識別が、③の方法ではトランザクションファンクションの識別を行うことができません。
また、②の方法ではトランザクションファンクションとデータファンクションを識別することが可能ではありますが、データファンクションの複雑度を判定することができません。
①の方法でも②の方法でもＣＲＵＤを定義していれば、対象となるトランザクションとデータを識別することが可能となります。
ということは、トランザクションファンクションとデータファンクションをあるオブジェクトを指定して、自動的に識別するためにはどうしてもＣＲＵＤマトリックスを定義する必要があるわけです。
そこで、見積りツール（Xradian）のアプリケーション境界の指定としては、ＣＲＵＤマトリックスを指定するということにしました。
この場合、初期段階でツール（Xradian）で見積もりを行う場合も、ＣＲＵＤマトリックスを指定する必要があります。
Xupperでは、ディフォルトで全体のＣＲＵＤマトリックスを自動で作成しています。全体のＣＲＵＤマトリックスはXupperで定義されているプロセスやエンティティが全て入ってきますので、全体のＣＲＵＤマトリックスを指定して見積りを実施すればいいと思います。
