いままで、「ＵＭＬや自動生成、形式仕様の接点としてのツールをＪＵＮＩＴっぽくして考えると。。。」で、昨日要件（業務手順）仕様を作成する際、ＵＭＬで作成し、自動生成を行えるようにして、さらに形式仕様のよさである仕様の矛盾をチェックするという利点を生かすには、どうしたらよいか？という話を書きました。で、その方法として、
・アクティビティ図を、階層的に書き、一番下の階層は、既存ライブラリか、基本機能という
あらかじめ定義されているもので書く
・アクティビティ図に、入力、出力の引数＝プロパティをいれる
ということでした。
今日のお話は、アクティビティ図からユースケース図（プロパティ入り）をつくり、その（プロパティ入り）ユースケース図とＩＢＭのＤＦＤの４点セットとの関係について書きたいと思います。
■アクティビティ図からユースケース図に
アクティビティ図のアクティビティをもとに、それを、レーン関係なしに、コンピューターで処理するところを、ユースケースにして、（おもに）データ入力するところに、アクターを置いたのが、ユースケース図になります。
極論ですが、アクティビティ図に、「コンピューター」というレーンをつくって、そのレーンに対して、線が入ってきた場合、その線を入れてきた元（のレーン）をアクターにすると、つくれますけど、そこまでしなくても。。。（＾＾）
（逆にそのほうが、考えやすいかも ＾＾；）
ということは、アクティビティ図にプロパティを入れるなら、ユースケースにも，プロパティを入れて、入力出力を明確にしないといけません。そして、ユースケースも階層的に定義して、一番下のユースケースは、既存ライブラリか、基本機能という、あらかじめ定義されているユースケースで書くことになります。
■（プロパティ入り）ユースケース図とＤＦＤの４点セット
とすると、この（プロパティ入り）ユースケース図は、
・ユースケース図
・ユースケースのプロパティ＝入出力部分
・そのユースケースを説明する、下位のユースケース図
という形になります（全部そろった場合）
で、ここで、それと、ＤＦＤとの関係をみてみましょう。
ここ
要求定義の方法論を知る【前編】
DOA型要件定義の実際
http://itpro.nikkeibp.co.jp/article/COLUMN/20060804/245233/?ST=enterprise&P=2
に、ＤＯＡの場合のＤＦＤの４点セットっていうのが載ってます。
その場合、
・ＤＦＤ
・「データストア記述」 データストアに含まれるデータ項目をリストアップ
・「データフロー記述」データフローに含まれるデータ項目をリストアップ
・「処理機能記述」プロセスの内容を「入力－処理－出力」の形式で記述
の４点をセットにするそうです。
では、上記ユースケース図からこのＤＦＤの４点セットが変換できれば、
・ＤＦＤ４点セットとＵＭＬのプロパティつきは、等価な作業ということになり
・逆にいうと、プロパティの入っていない現行の要求分析は、入出力チェックしてない分、
ＩＢＭＤＯＡより危険
という結果になります。
■プロパティ入りユースケース図からＤＦＤの４点セットへの変換
では、変換してみましょう。
１．永続性のあるデータを抽出する
プロパティ入りユースケース図、
・ユースケース図
・ユースケースのプロパティ＝入出力部分
・そのユースケースを説明する、下位のユースケース図
の「ユースケースのプロパティ」の入出力のうち、永続性のあるデータをエンティティ
とします。永続性のあるデータとは、パソコンの電気を切ったとき、その情報が無く
なったら、こまるものです。
たとえば、受注データは、パソコン切れたら無くなったって言ったらこまります。
そんなんで、これは、永続性のあるデータです。
一方、あるユースケースに渡すフラグなどは、そのユースケースの処理が終わってしまったら、もういりません。こういうのは、永続性のないデータ（テンポラリなデータ）です。
２．永続性のあるデータを正規化する
１のデータを正規化します。正規化の方法は、ここやここに書いたので省略
３．そこで出てきたエンティティを、ユースケースとユースケースの間にいれると、ＤＦＤができます。。
→って、そんなに簡単に行かないんですけど、結局、そうなります。
４．２の結果、エンティティに含まれるデータ項目というのが出てきますので、それが、データストア項目になってきます。
５．プロパティから、引数で渡さなくていい（データストアから取ってくればいい）項目を抜き、データストアにアクセスするために必要な項目がある場合（ファイル名など）、それを追加すると、データフロー記述になります。
６．「そのユースケースを説明する、下位のユースケース図」は、「処理機能記述」になります。
ということで、ＤＦＤ４点セットは、ユースケース図にプロパティ（データ入出力）を入れれば、変形可能になります。
ということは、逆にいうと、アクティビティ図とユースケース図、それにＥＲ図だけでいくと、（データフロー記述が無いので、実際にそのデータがわたってこない危険があるので）危険があるのですが、それでも、ＵＭＬのほうが、メリットがあるケースがあります。
特にアジャイルなどでは。。。
それについては、別の機会にかきます。
以下自分へのメモ
その際に使う資料
http://itpro.nikkeibp.co.jp/article/COLUMN/20060807/245276/?ST=enterprise&P=3
それは，「要件定義には十分な時間をかけるべき」ということだ。実際，日本IBMで請け負った近年の大規模プロジェクトでは，20～25％のコスト・期間を要件定義に当てている。小規模・短納期開発であれば，30％以上を要件定義にかけてもよいだろう。
実際には８０％くらいのこともおおい＝＞つまり、仕様が決まった時点で、結合テストに入っていないといけない。
アクセス
トータル
ランキング
