akon2.00βのよっぱらいの戯言

色しょく是食、食しょく是色 当サイトではアフィリエイトプログラムを利用して商品を紹介しています。

ルール駆動ユースケース

周知のごとく、ユースケースの記述レベルはまちまちである。自然言語で記述しているのだから、レベルを定めることには無理がある。とくにユースケースの粒度を定義しょうというプロジェクトを見受けることがあるが、これは不毛であり時間の無駄なのでやめるべきである。なぜならば、文書の意味的密度は計測不能だからである。計測できないものは粒度を定義できない。
そこでまず、ユースケースの単位はFDDのいうところの「ユーザ機能」とする。これでもまだ記述レベルは一様にならない場合がある。もっと明確な基準が必要である。このためにルール駆動を適用する。ルール駆動では、ひとつの完結したルールをユースケースの単位とする。これでもまだ自然言語で記述すると非形式的である。
ここで、形式的という用語を用いているが、形式的仕様記述言語に対するアレルギー、たとえば数学的素養が必要であることに関して嫌悪を抱く方のために説明する。ここでの形式的とは、数学的に証明可能にするという意味で、書き手に数学の素養を要求するものではない。
さて、形式的に記述するために、「事前条件と事後条件を持つ決定表」を利用し、条件部は二項演算子、処理部にはプログラム式(DIコンテナ名が望ましい)を記述することを提唱する。プログラム式のパースについては、ジェネレータ方式とサーバコンパイル方式が考えられる。
このような詳細なユースケースは記述できないと言う意見があるかもしれない。それは誤解である。このように詳細に記述できないと言うことは、実装できないと言うことである。おそらく、イテレーションしないで、一度に詳細に書き下ろそうするために、詳細化できないものと思われる。もちろん、コンテナ名などは開発の当初は決まっていない。しかし、分析結果としてこのようなコンテナが必要だという意思表明をし、結果としてそのコンテナ名が採用されるかどうかはコミュニケーションの問題、もしくポリシーの問題である。