私は、ソフトウェアを開発するための努力の分析に使用するソフトウェア メトリクスについて考えていました。オブジェクト指向ソフトウェアに関数ポイントのようなメトリクスを使用することを考えていたとき、興味深い課題/質問に出くわしました。
ビジネス ルール エンジンを考えてみましょう。これは、ビジネス ルールを実行するために必要なコンポーネントで構成されるアプリケーションであり、ビジネス ルールまたは企業ポリシーをビジネス ルール エンジンの構成コードに変換します。私の推測では、ビジネス ルール エンジンのようなアプリケーションの場合、この構成コードも非常に重要になる可能性があります。ただし、実装の観点から考えると、構成コードは基本的に API の一部をインスタンス化します。
では、まず、構成コードを作成するための労力が十分に大きく、それを測定することが理にかなっていると仮定するのは間違っているのでしょうか?
構成コードを測定できる関数ポイントのようなメトリック (またはその他のメトリック) について手がかりを持っている人はいますか?
「構成コード」を作成する労力を測定することは、間違いなく理にかなっています。アプリケーションによっては、構成コードが作業の大部分を占める場合もあります。
特に構成コード用に設計されたメトリックは知りません。すでに多くの構成言語が存在しており、誰でも新しい構成言語を作成できます。おそらく、構成言語が一般的なプログラミング言語にどの程度似ているかを確認し、そのプログラミング言語で機能するメトリックを適応させる必要があります。
BR コードの「構成」コードを呼び出しても、問題は変わりません。(3 本足の犬を何と呼びますか? 何と呼んでも構いません。3 本足の犬です)。
かなりの誇大宣伝を無視すると、ビジネスルールエンジンはただの面白いプログラミング言語です (通常、システムの「ビジネスルール以外の部分」への複雑なインターフェースを備えており、BR のスタッフは実行できません)。この観点から、BR のプログラミングは他の言語と大差ありません。特にファンクション ポイント モデルを購入する場合はそうです (BR エンジンを持っているからといって、レポートを生成するためのコードを書かなくて済むわけではありません!)。
BR の連中が典型的にやろうとしているのは、BR プログラミングは自分の好きなようにできるので安価だと主張することです。彼らが言わないのは、BR のプログラミングは難しいということです。なぜなら、BR ルールを前もってコーディングしないという行為そのものが、「後で BR をコーディングすることができる」という理由で、最初に要件分析を行うことを避けたことを意味するからです。また、BR システムまたはそれがアクセスするデータが、実際に直面している問題に対応できるという保証はありません。(私が本当に嫌いな考え方は、「BR はマネージャーが理解できるようにする...」というものです。本当の BR ルールを見たことがありますか?)
私は Ira と KC に完全に同意します。そのため、アプリケーション内のルールには標準のスクリプト言語のみを使用しています。V8 または seamonkey を使用して JavaScript インタープリターをソフトウェアに組み込み、JS を理解する任意の推定器 (ProjectCodeMeter など) をビジネス ルール コードで使用できます。