見積りツール（Xradian）のでトランザクションファンクションの識別

これまで、データファンクションの取扱について説明しましたのが、ここからはトランザクションファンクションの取扱について説明していきます。

トランザクションファンクションを識別するためには、まず、要素処理を識別する必要があります。
要素処理とは、ユーザの目的にそった業務活動の最小単位で、自己完結し、計測境界アプリケーションを業務に矛盾のない状態保つ処理のことです。 

Xupperでは、処理に関するオブジェクトをいろいろ定義することが可能ですが、Xradianでトランザクションファンクションとして識別する太陽として考えたのは、以下のオブジェクトです。

① プロセス
② デバイス／ＧＵＩ（画面や帳票）
③ フィールド更新仕様タイトル
④ ＤＬＣＰ

① プロセス
Xupperに登録されているプロセス（画面入力系プロセス、画面照会系プロセス、帳票出力系プロセス、バッチ更新系プロセス）をトランザクションファンクションとして識別してはどうかという案です。
本来ＦＰを計測しようとするならば、外部設計（ユーザインタフェースやテーブル設計）が終了していなければ、手順どおりに見積りを実施することは困難です。
しかし、提案時に見積りを実施する必要もありますし、多少、精度は落ちるけど。ザックリどのくらいかを知りたいということもあります。その際、まだ、ユーザインタフェースが確定していないので、見積りできませんとはいえません。
ある程度、大雑把な情報を元見積りを実施する必要があります。
だからといって、何の根拠もない数字を出すわけにはいきません。そこで、ビジネスフロー図を記述し、どのような画面や帳票が必要なのかを整理し、画面や帳票（プロセス）から規模をもつもるという考え方です。
ビジネスフロー図を記述しなくても、画面数や帳票数はある程度わかっているということが多いと思いますので、それらの情報から規模を見積るようにします。（それさえも存在しないということであれば、類似法による見積りか、ＷＢＳによる積算で工数を算出するしか方法はないでしょう・・・）

【プロセス】

② デバイス／ＧＵＩ（画面や帳票）
Xupperに登録されているＧＵＩ設計／デバイス設計のレイアウト情報をトランザクションとして識別してはどうかという案です。
設計が進んできて、ユーザインタフェースが明確になった段階で、どのような画面や帳票が必要となるのかも当然明確になってきますし、レイアウトを作成すれば、どのようなデータ項目に対して処理を実施すればいいのかもわかります。

【ＧＵＩ設計のフォーム】

③ フィールド更新仕様タイトル
XupperのＣＲＵＤマトリックスで、はエンティティとプロセス単位にＣＲＵＤを定義することが可能です。さらに、エンティティの属性単位にどのような更新を行っているのかを更新仕様として定義することもできるようにになっています。
エンティティの属性単位の更新仕様を定義する際には、フィールド更新仕様タイトルというものを登録します。
これは、あるプロセスがあるエンティティに対して更新（アクセス）を行うといった場合、さまざまな更新（アクセス）パターンが存在するはずなので、それぞれの更新（アクセス）パターンに対して名称を付けておくという機能です。
更新（Ｕ）のアクセスを考えても、１通りのアクセスではなく、条件によりさまざまな更新（（締め前更新、締め後の更新等）を行うはずです。また、参照（Ｒ）についても、同様にさまざまな条件での参照（検索）が存在する（全件検索と絞込み検索等））はずです。
それらのアクセスパターンにタイトルを付けて、どのようなアクセスが存在するのかを管理することができます。
このフィールド更新仕様タイトルを要素処理として識別してはどうかという案です。

【ＣＲＵＤマトリックスの更新仕様タイトル】

④ ＤＬＣＰ
XupperAdvancedの機能にＤＬＣＰ（Data Life Cycle Procedure）という機能があります。これは、データに対する処理を定義し、データと処理をカプセル化して管理していくという機能です。
ＤＬＣＰには、ＤＡＰ（Data Access Procedure）とＢＰ（Business Procedure）というのもがあります。ＤＡＰとはデータに対する処理のことで、ＢＰとは処理を制御する処理というふに考えてもらえればいいと思います。
このＤＬＣＰをつかって、画面でそのようなイベントが発生したときに、どのＢＰを呼び出し、どのＤＡＰを使用してデータにアクセスするのかを定義することが可能です。
この画面からの一連のＤＬＣＰの流れを一つの要素処理としてとらえ、トランザクションファンクションとして識別してはどうかという案です。

【ＤＬＣＰ】

それぞれ、一長一短がありますが、設計の過程でより具体化されていくはずですので、それぞれの見積り段階で見積りが実施できるようになっていればいいのではないかと考えます。

例えば、設計の初期段階では、業務フロー図やビジネスルールしか作成されていない状態でしょう。
その場合でも、プロセスの数がわかれば、大まかな規模見積ができるのではないかと思います。

ビジネスフロー図を作成して、どのようなプロセスが必要なのかを洗い出すことができたら、その後に各画面や帳票のレイアウト設計を実施します。
レイアウトを定義すれば、それぞれの画面や帳票でどのようなデータ項目を扱っているのかが明確になりますので、レイアウト上に定義されているデータ項目数をカウントすることにより、DET数を把握することができます。

画面や帳票のレイアウトを作成することにより、システムで管理すべき（管理しなければならない）データ項目が明らかとなりますので、その情報を用いてエンティティ関連図を作成します。
エンティティ関連図が作成できれば、エンティティから内部論理ファイルと外部インタフェースファイルを識別し、ＮＥＳＭＡ法を用いて、ＦＰで規模見積を実施することが可能となります。

画面レイアウト、帳票レイアウト、エンティティ属性が明確になれば、どの画面がどのエンティティ（テーブル）に対して処理をしているのかがほぼ把握できます。
それらの情報をもとに、プロセスとエンティティのＣＲＵＤを定義していきます。
（ちなみに、この方法であれば、ユーザインタフェースをXupperに定義していなくても，ＦＰを見積もることが可能です。）