Excel仕様書、Java+JS実装、UML、VDM間の関係について － その１：おおざっぱに
http://blog.goo.ne.jp/xmldtp/e/19497a99c73ce73a299879a9eb6c2989
と
Excel仕様書、Java+JS実装、UML、VDM間の関係について － その２：ＳＡ工程
http://blog.goo.ne.jp/xmldtp/e/f42121f37f7c889c87c030d815ce42ac
のつづき。今回はUI工程。ただし、UI工程に入る前に前工程のSA工程
をまとめ（補足？）しておきます。
■ＳＡ工程で、すでに決まっていること
前回までで
【一般に】
・入力ー処理ー出力の処理（アクティビティ）の一連の流れは定義されている
・入力項目、出力項目は定義されている
・その項目をもとに、ＤＢ（テーブル）、ファイルに保存すべきデータが正規化され
概念モデルとして構築されている
これを表現するのは、以下の通り（前回とちょっと書き方違うかもしれないが・・）
【ＵＭＬの場合】
・アクティビティの一連の流れはアクティビティ図で定義されている
・各アクティビティはモデルとして、クラスのメソッドで定義されている
→そのメソッドをどのクラスに入れるのかはフレームワークの考えによる
それが決まれば（例えば１アクティビティ１クラス）、クラス図で表現できる
そのとき、入力項目がメソッドの引数となる可能性が大きい
・正規化された概念モデルは、クラス図に定義されている
【構造化設計の場合】
・アクティビティの一連の流れは業務流れ図（
WFA）で定義されている
同時に末端のＤＦＤにも記載される
各アクティビティの処理内容は、ミニスペックに記述される
・正規化された概念モデルは、ＥＲ図に定義されている
【ＶＤＭ＋＋の場合】
・アクティビティ図１つぶんを１クラスとすると、
各アクティビティは、oparationまたはfunctionとして定義できる
このとき入力は、引数であり、
出力結果はPostで指定される。functionの場合、返り値はRETURNで書かれる
これが操作内容について書かれたＶＤＭである（発表では「データ処理仕様」に相当する。
なお、「発表」とは情報処理学会の全国大会
5A-04エンタプライズ系業務システムの仕様をVDM++で記述する設計手法の提案
http://www.gakkai-web.net/gakkai/ipsj/78program/data/pdf/5A-04.html
を指す。以下同じ。また、この発表（研究）に自分は関与していないので、
「相当する」というのは、自分が勝手に思っていることである）
・その入力、出力の型定義が必要になるが、これは別のＶＤＭクラスで定義するとよい
この定義するＶＤＭを辞書用ＶＤＭと呼ぶことにする。ここで、概念モデルが記述される
（発表中、これは明確には書かれていない。「データ処理仕様」の一部と思われる）
・ＶＤＭはデータにより検証できる。ここでは、単純にoparationを呼び出すだけとする
operationにどのような値を設定するかを定義する。これをテスト用ＶＤＭとよぶ
（発表では、この段階での「テスト仕様」に相当するが、発表は、この段階ではなく、UIでの
テストを言及している）
【ＶＤＭ＋＋と実装との関係】
・操作内容について書かれたＶＤＭのoparationが、モデル部分に相当する
・辞書用ＶＤＭクラスがテーブル定義や制約に相当する
・データによって検証する部分がJUnitのテストに相当する。
■ＵＩ工程 一般に
・アクティビティの入力項目、出力項目は、画面、帳票、ＤＢの
どこから来るか／どこに出すかを決定する
これにより、どのような画面を作ればよいか決定する
→言い換えると、各画面と画面項目が決まる
１アクティビティ１画面とすると美しいが、かならずしもそうはならず
複数のアクティビティが同一画面になることもある
このときは、画面の１ボタンが１アクティビティに対応したりする
・上記画面と画面項目をまとめて、画面レイアウト図を作成する
入出力項目が、画面項目となる
入出力項目の内容により、項目の型（何ケタの整数、文字列等）が決定する
アクティビティを呼び出すために、イベントを発生させる
一般にイベントを発生させるにはボタンをクリックするが、
かならずしもそうでなくてもよい（マウスオーバー、キーボード入力などもあり）
項目とボタンがきまったのでＨＴＭＬで書けば、論理的に画面はできる
適当なＣＳＳを用意すれば、それっぽいレイアウトが完成するので、レイアウト図に貼り付ける
・各画面と、アクティビティの一連の流れから、画面遷移が決定する
（画面入力し、ボタンが押されたら、正常なら、次のアクティビティ（の画面）に遷移するはず・・・
というように考えていくと、アクティビティの一連の流れはＳＡ工程で決まっているので、
画面遷移も決定するはず）
そこで、画面遷移図を作成する
■ＵＩ工程 ＵＭＬ
・上記画面レイアウト図の１画面１クラスとして
画面項目を属性として
ボタン（イベント）をメソッドとし、メソッドがアクティビティを呼び出すとして
クラス図を描き
・上記画面遷移図の画面遷移を状態遷移と考え、状態遷移図（ステートマシン図）を
書くことも可能だが、意味はない
■ＵＩ工程 構造化設計
・上記画面レイアウト図、画面遷移図ができてしまえば、それでＯＫ
■ＵＩ工程 ＶＤＭ＋＋
・上記画面レイアウト図の１画面１クラスとして
画面項目を属性として
ボタン（イベント）をoperationsとし、operations内で、
モデルのクラスをnewし、
モデルのoperationsを呼び出す
画面のＶＤＭを作成する（発表では画面仕様に相当する）。
画面の入力項目の制約は、invになる
・画面遷移図をもとに上記画面のＶＤＭを呼び出すＶＤＭを作成する
これが画面のテスト用ＶＤＭとなる（発表では操作仕様、業務仕様かはっきりしない）。
しかし、これだけでは値が設定されないので、
値を設定した画面テストの値用ＶＤＭ（発表ではテスト仕様）も作成する
■ＵＩ工程ＶＤＭ＋＋と実装との関係
・画面レイアウトを作成した時のＨＴＭＬがビューのもととなる
・画面のＶＤＭがそのビューを受け取り、モデルを呼び出すコントローラーとなり
入力項目の制約が、バリデーションチェックに使われる
・画面のテスト用ＶＤＭ＋画面テストの値用ＶＤＭが結合テストのシナリオになり、
具体的にはseleniumで使える形にされる
・・・こんなかんじかな
アクセス
トータル
ランキング
