見積りツール（Xradian）でのトランザクションファンクションのタイプ判定

今回は、見積りツール（Xradian）でのトランザクションファンクションのタイプの判定について説明していきます。

前回の「見積りツール（Xradian）のトランザクションファンクションの識別」では、見積りツール（Xradian）で何をトランザクションファンクションとして識別するかについて説明しましたが、トランザクションファクションには、外部入力（ＥＩ）、外部出力（ＥＯ）、外部照会（ＥＱ）の３種類存在します。

何をデータファンクションとして識別するのかということを検討した後は、識別したトランザクションファンクションのタイプが、外部入力（ＥＩ）、外部出力（ＥＯ）、外部照会（ＥＱ） なのかをどうやって判定するのかについて検討する必要があります。

外部入力（ＥＩ）、外部出力（ＥＯ）、外部照会（ＥＱ）の条件については、「ＩＦＰＵＧ法でのＦＰ算出」にて説明しましたが、再度簡単に説明しますと、外部入力（ＥＩ）というのは外部からの入力処理ということになります。ここでいう外部とは、システムの外という意味です。（あくまで主役は計測対象のシステム／アプリケーションです。）
外部出力（ＥＯ）と外部照会（ＥＱ）というのは、外部に情報（データ）を提供するという意味では同じですが、外部出力（ＥＯ）は演算等の処理を実施するが、外部照会（ＥＱ）はそりが存在しないよいう違いがあります。

トランザクションファンクションのタイプ判定については、結局のところ、何をトランザクションファンクションとして識別するかに依存します。
なぜならば、各オブジェクトによってそのプロパティ（持っている特性）が異なるため、タイプ度判定のために利用可能な情報が異なるからです。

以前、「見積りツール（Xradian）でのトランザクションファンクションの識別」で何をトランザクションファクションとして識別するかについて、以下の案を検討してきました。

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

① プロセス 
Xupperのプロセスをトランザクションファンクションとして識別しようという場合は、プロセスのタイプでトランザクションファンクションのタイプを判定するようになっています。
プロセスのタイプですが、Xupperでは以下のタイプが存在します。

・画面入力系プロセス
・画面照会系プロセス
・帳票出力系プロセス
・バッチ更新系プロセス　　です。

このプロセスタイプをもとに、トランザクションファンクションのタイプを判定していこうという案です。

必ずしも、ＣＭＰの定義にはあわないと思いますが、開発の初期段階でわかる範囲で見積りを実施する場合は、ある程度の割り切りも必要だと考え、以下のように分類しています。

【図】プロセスタイプ別のトランザクションファンクションのタイプ判定

② デバイス／ＧＵＩ（画面や帳票） 
XupperのデバイスやＧＵＩフォームをトランザクションファンクションとして識別しようという場合ですが、デバイスやＧＵＩフォームとプロセスタイプからトランザクションファンクションのタイプを判定しています。

<<デバイス>>
デバイスについては、以下のデバイスタイプが存在します。

・画面
・ウインドウ
・帳票
・ＨＴＭＬ
・フレーム

また、デバイスは基本的にプロセスに定義されるという構造になっていますので、デバイスからみてプロセスが特定できるようになっています。（⇒プロセスタイプを特定できる）
そこでデバイスタイプとプロセスタイプから、以下のようにトランザクションタイプを判定しています。
（ＨＴＭＬやフレームについても対象外としています。）

【図】デバイスのトランザクションファンクションのタイプ判定

<<ＧＵＩフォーム>>
Xupperにはデバイス設計とは別にＧＵＩ設計の機能があり、デバイス設計の機能ではなくＧＵＩ設計の機能を用いて画面の入出力を定義することがあります。
この場合、ＧＵＩフォームをトランザクションファンクションとして識別するということになりますが、ＧＵＩフォームにはデバイスタイプのようなタイプが存在しません。
ＧＵＩフォームに存在するのは、MainフォームかMainフォームでないかの区分だけです。
Mainフォームというのが、データ入力を行ったり、照会を行ったりするフォームで、Mainフォーム以外のＧＵＩフォームはコード選択画面やダイアログのような補助的なフォームという扱いになります。
そこでMainフォームかどうかということとプロセスタイプから、以下のようにトランザクションタイプを判定しています。

【図 】ＧＵＩフォームのトランザクションファンクションのタイプ判定

③ フィールド更新仕様タイトル 
Xupperのフィールド更新仕様タイトルをトランザクションファンクションとして識別しようという場合ですが、ＣＲＵＤ種別とプロセスタイプからトランザクションファンクションのタイプを判定しています。
Xupperのフィールド更新仕様タイトルのＣＲＵＤ種別には、以下のタイプが存在します。

Ｃ：追加
Ｒ：参照
Ｕ：更新
Ｄ：削除

また、ある更新仕様タイトルの種別としてＣＲＵＤ種別の中から任意のタイプを複数選択して定義することができるようになっています。
そこで、ＣＵＤが一つでも定義されている更新仕様タイトルは、どのプロセスタイプに定義されていようとも、外部入力（ＥＩ）として判定します。
（アプリケーション境界内の内部論理ファイルを維持管理しているトランザクションとして識別します。）
フィールド更新仕様タイトルのＣＲＵＤ種別としてＲ：参照のみ定義されているものを、以下の組合せでタイプ判定を行っています。

【図】フィールド更新仕様のトランザクションファンクションのタイプ判定

④ ＤＬＣＰ 
Xupperのフィールド更新仕様タイトルをトランザクションファンクションとして識別しようという場合ですが、ＣＲＵＤ種別とプロセスタイプからトランザクションファンクションのタイプを判定しています。

Xupperでは、ＤＬＣＰ定義の機能を用いてデータに対する処理を定義していくことができます。また、ＤＬＣＰにはＤＡＰとＢＰとがあり、データに対する処理をＤＡＰ（DataAccessProcedure）、ＤＡＰの制御を行う処理のことをＢＰと呼んでいます。

ＤＡＰとはデータに対するアクセス部品（入出力パラメータ付きのＳＱＬ文）のことであり、以下の種類が存在します。

Ｃ：追加
Ｒ：参照
Ｕ：更新
Ｄ：削除

基本的にＢＰの中からＤＡＰを呼び出して処理を定義することになりますが、当該処理がどのようなＤＡＰを呼び出しているかによってトランザクションファンクションのタイプを判定します。
あるＢＰは複数のＤＡＰを任意に呼び出して処理定義することが可能ですので、ＢＰ前提からみると、ＣＲＵＤ種別が複数存在しうるということになります。
そこで、ＣＵＤタイプのＤＡＰを一つでも利用しているＤＬＣＰは、どのプロセスタイプに定義されていようとも、外部入力（ＥＩ）として判定します。
（アプリケーション境界内の内部論理ファイルを維持管理しているトランザクションとして識別します。）
ＤＬＣＰ（ＢＰ）が藻日出しているＤＡＰのＣＲＵＤ種別がＲ：参照のみ定義されているものを、ＥＯもしくはＥＱとしてタイプ判定を行っています。

【図】ＤＬＣＰのトランザクションファンクションのタイプ判定

ＤＬＣＰのＥＯ／ＥＱの判定は、ＤＬＣＰ（ＤＡＰ）の中に“Statement”（演算処理の記述）が存在するか否かで判定します。
“Statement”（演算処理の記述）が存在する場合はＥＯ、存在しない場合はＥＱとして判定します。

<<コンボボックスのファンクションの認識について>>
XupperのＧＵＩ設計の機能でコンボボックスの定義を行えますが、その際にＤＬＣＰを定義するかどうかにより、ＥＱかどうかを判定することができます。
単に、固定値をコンボボックスに表示するといった場合は、データ項目がアプリケーション境界を跨るといえませんので、ファンクションとしては認識しません。
しかし、コンボボックスのOnClickイベントにＤＬＣＰを定義し、マスタから情報を読み込むという定義を行っていれば、ファンクション（ＥＱ）として認識することとなります。