昨日、
Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法（１）
http://blog.goo.ne.jp/xmldtp/e/ca9cc98062afa09603680042d6dc8f86
で書いた話の続きなんだけど、今日は大事なところなので、
進捗をゆっくり、その代わり、丁寧に話す。
昨日、
（１）ユースケースに対して、そのアクティビティを書いて、
要求を明示するよねえ
→ユースケース図、アクティビティ図
（２）そのアクティビティに対し、入出力を明示し
（ここが入出力設計、ＵＩ）
をやった。実は、（３）、（４）を飛ばして
（５）アクティビティ図の入出力に対する部分がＶｉｅｗとなり、
クラス図（ＥＲ図に相当する）ところが、モデル（ＤＡＯ）になり
アクティビティは、Ｖｉｅｗを受ける部分にあたるので、コントローラーとなる。
→コントローラーが
クラスとなるか(Struts,Actionクラス）
メソッドとなるか(CakePHP,Zendなど）
は、フレームワークやアーキテクチャによる
これで、アーキテクチャに基づいたクラス、メソッド割がきまる。
の途中までをやると、やりやすい（理由は（４）を説明するときに言う）
ので、今日は（５）の途中まで
■Viewのクラスを作る
昨日、アクティビティ図を作った。
そのとき、オブジェクトノードを入れた。
そのオブジェクトノードをクラス図に描く。
画面はステレオタイプをＶｉｅｗとし、
データ部分（ＤＢのテーブルとか）は、ステレオタイプをＭｏｄｅｌとしよう。
そうすると、まず、こんな形に書ける。
![]()
■Viewのデータを入れる
次に、入出力するデータを、とりあえず、全部入れる。
アンケート画面は、問１〜問５まであった
なので、こんなカタチ
![]()
集計結果表示画面は、
問１〜問４まで：円グラフ
問５：棒グラフ
問２、問３については、思う、思わないをクロス集計
（きのうの、間違えていました。問２と問３のクロス集計です）
ここで、サーバー側でグラフをビットマップで作り、表示する手もあるけど、
今回は、そうではなく、クライアント側に数値を送り、それをＧＵＩで組み立てるとする。
そうすると、必要な数字は
問１を円グラフにするには、
問１Ａの人数、問１Ｂの人数がわかればできる
問２を円グラフにするには
問２Ａの人数、問２Ｂの人数がわかればできる
(総数は、問１Ａの数と一致するはず、しなければ無回答）
問３を円グラフにするには
問３Ａの人数、問３Ｂの人数がわかればできる
(総数は、問１Ａの数と一致するはず、しなければ無回答）
問４を円グラフにするには
問４Ａの人数、問４Ｂの人数、問４Ｃの人数がわかればできる
(総数は、問１Ａ＋Ｂの数と一致するはず、しなければ無回答）
問５を棒グラフにするには
問５Ａ、Ｂ，Ｃ，Ｄ，Ｅ，Ｆ．Ｇ．Ｈの各人数がわかればできる
(総数は、問１Ａ＋Ｂの数と一致するはず、しなければ無回答）
問２、問３のクロス集計を作るには、
（１）問２Ａかつ問３Ａ
（２）問２Ａかつ問３Ｂ
（３）問２Ｂかつ問３Ａ
（４）問２Ｂかつ問３Ｂ
の人が判ればできる。
そして、（１）〜（４）がわかれば、
問２の円グラフ、問３で円グラフの人も計算でもとまるのでいらない。
まとめると、これだけの値がいる
・問１Ａの人数、問１Ｂの人数
・問２Ａかつ問３Ａ、問２Ａかつ問３Ｂ、問２Ｂかつ問３Ａ、問２Ｂかつ問３Ｂ
・問４Ａの人数、問４Ｂの人数、問４Ｃの人数
・問５Ａ、Ｂ，Ｃ，Ｄ，Ｅ，Ｆ．Ｇ．Ｈの人数
ただし、それぞれ持っていると、大変なので、配列にしてもっている
問１[0]は、問１Ａの人数、問１[1]は、Ｂの人数
問２３[0]は問２Ａかつ問３Ａ、問２３[1]は問２Ａかつ問３Ｂ・・・
で、こんなかんじになる
![]()
今回、送信完了と、集計画面では何も送らないので
属性は入れない
（一般には、集計画面で、表示したいアンケートを選んだりするが、
今回は１種類しかアンケートがないので）
ということで、こんなかんじ。
![]()
■Ｖｉｅｗにメソッドを追加する
Viewにメソッドを追加する。
メソッドは、アクションを起こすところ
＝結果として、イベントを起こすところ
＝多くは、ボタンをおしたり（場合によってはタイマーもありだけど）
となる。
ということは、アクティビティ図で、画面から、システムに行くところは、必ず
メソッドになる。そして、これは、ボタンをおしたときなどのアクションに結び付く
（実装上、メソッドとしてJavascriptの関数で書くか、FormタグのSubmitボタンに
なるかは、この時点では決めなくて良い）
今回は、あとあとの若干の理由から、「初期表示」も入れる
また、結果表示画面は、初期表示より、結果表示のほうがいいので、そうした
（ここで、メソッド名は、正直、どうでもよい。かっちょ良いのにしてくれ）
こんなかんじになる。
![]()
■画面分割
ここで、１画面で表示しきれない、表示しないほうがいい場合は、画面分割する。
集計結果表示画面は、いいとして、アンケート画面は、このままだと困る。
問１で、「いいえ」と答えた人は、問４に飛ばないといけない。
問２と問３を同時にだしてしまうと、問２に答える前に
日本の「卵かけ御飯」が「絶対に危険な食べ物」に選ばれる…中国
http://blog.livedoor.jp/dqnplus/archives/1758248.html
を見られてしまう可能性がある→その場合、問２の意味なし
問２と問３は分離しないといけない。そして、後に戻れないようにする。
結果として、こういう画面割りにしないといけない
問１
問２
問３
問４・５（４と５は一緒の画面でいい）
そこで、Ｖｉｅｗの画面を分割する。
分割は（かっこ内は、問１画面の例）、
・分割した画面のクラスを作る（問１画面クラス）
・分割した画面で表示（入力）する項目をつける（属性問１を追加）
・もとの画面（アンケート画面）から、
分割した画面の属性を削除（アンケート画面の属性問１を削除）
分割した画面を集約か、コンポジションかにして、線を結ぶ
・分割した画面（問１画面クラス）にメソッドを追加する
→その画面で起こすアクション
この結果、
・もとの画面の属性が全てなくなれば（今回はそのケース）
その画面は抽象的にまとめたもので、実装の必要はない
このとき、元の画面（アンケート画面）のメソッドは、
集約した＝分割した画面のメソッドのどこかに対応する
はず（アンケート画面の回答実行＝問４・５の回答実行）
１個でも属性が残れば、
その画面は必要になる
これらの処理をして、必要となった画面を、
appview（でもdispでもなんでもいい、viewと区別する）という
ステレオタイプに変えておく。あとで判りやすくするため
結果、こうなる
![]()
今回は「受注明細」のような画面のかたまりや、
「年月日」といった、型の話は出てこなかった。
その操作は、次回、はなそう。
それと、「集約」でも「コンポジット」でもどっちでもいい
と書いたけど、実は、分けられる（その上で、今回は集約を使っている）
その理由も書くかも？
さらに、その後で、コントローラーなんだけど、コントローラーに行く前に、
（４）その後、ＭＶＣアーキテクチャを採用したとすると、
なんかのフレームワークを決めて、
を説明する。ここで、「初期画面」を入れた謎などが、解ける
んだけど・・・ここまではいかないかな？
Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法（１）
http://blog.goo.ne.jp/xmldtp/e/ca9cc98062afa09603680042d6dc8f86
で書いた話の続きなんだけど、今日は大事なところなので、
進捗をゆっくり、その代わり、丁寧に話す。
昨日、
（１）ユースケースに対して、そのアクティビティを書いて、
要求を明示するよねえ
→ユースケース図、アクティビティ図
（２）そのアクティビティに対し、入出力を明示し
（ここが入出力設計、ＵＩ）
をやった。実は、（３）、（４）を飛ばして
（５）アクティビティ図の入出力に対する部分がＶｉｅｗとなり、
クラス図（ＥＲ図に相当する）ところが、モデル（ＤＡＯ）になり
アクティビティは、Ｖｉｅｗを受ける部分にあたるので、コントローラーとなる。
→コントローラーが
クラスとなるか(Struts,Actionクラス）
メソッドとなるか(CakePHP,Zendなど）
は、フレームワークやアーキテクチャによる
これで、アーキテクチャに基づいたクラス、メソッド割がきまる。
の途中までをやると、やりやすい（理由は（４）を説明するときに言う）
ので、今日は（５）の途中まで
■Viewのクラスを作る
昨日、アクティビティ図を作った。
そのとき、オブジェクトノードを入れた。
そのオブジェクトノードをクラス図に描く。
画面はステレオタイプをＶｉｅｗとし、
データ部分（ＤＢのテーブルとか）は、ステレオタイプをＭｏｄｅｌとしよう。
そうすると、まず、こんな形に書ける。
■Viewのデータを入れる
次に、入出力するデータを、とりあえず、全部入れる。
アンケート画面は、問１〜問５まであった
なので、こんなカタチ
集計結果表示画面は、
問１〜問４まで：円グラフ
問５：棒グラフ
問２、問３については、思う、思わないをクロス集計
（きのうの、間違えていました。問２と問３のクロス集計です）
ここで、サーバー側でグラフをビットマップで作り、表示する手もあるけど、
今回は、そうではなく、クライアント側に数値を送り、それをＧＵＩで組み立てるとする。
そうすると、必要な数字は
問１を円グラフにするには、
問１Ａの人数、問１Ｂの人数がわかればできる
問２を円グラフにするには
問２Ａの人数、問２Ｂの人数がわかればできる
(総数は、問１Ａの数と一致するはず、しなければ無回答）
問３を円グラフにするには
問３Ａの人数、問３Ｂの人数がわかればできる
(総数は、問１Ａの数と一致するはず、しなければ無回答）
問４を円グラフにするには
問４Ａの人数、問４Ｂの人数、問４Ｃの人数がわかればできる
(総数は、問１Ａ＋Ｂの数と一致するはず、しなければ無回答）
問５を棒グラフにするには
問５Ａ、Ｂ，Ｃ，Ｄ，Ｅ，Ｆ．Ｇ．Ｈの各人数がわかればできる
(総数は、問１Ａ＋Ｂの数と一致するはず、しなければ無回答）
問２、問３のクロス集計を作るには、
（１）問２Ａかつ問３Ａ
（２）問２Ａかつ問３Ｂ
（３）問２Ｂかつ問３Ａ
（４）問２Ｂかつ問３Ｂ
の人が判ればできる。
そして、（１）〜（４）がわかれば、
問２の円グラフ、問３で円グラフの人も計算でもとまるのでいらない。
まとめると、これだけの値がいる
・問１Ａの人数、問１Ｂの人数
・問２Ａかつ問３Ａ、問２Ａかつ問３Ｂ、問２Ｂかつ問３Ａ、問２Ｂかつ問３Ｂ
・問４Ａの人数、問４Ｂの人数、問４Ｃの人数
・問５Ａ、Ｂ，Ｃ，Ｄ，Ｅ，Ｆ．Ｇ．Ｈの人数
ただし、それぞれ持っていると、大変なので、配列にしてもっている
問１[0]は、問１Ａの人数、問１[1]は、Ｂの人数
問２３[0]は問２Ａかつ問３Ａ、問２３[1]は問２Ａかつ問３Ｂ・・・
で、こんなかんじになる
今回、送信完了と、集計画面では何も送らないので
属性は入れない
（一般には、集計画面で、表示したいアンケートを選んだりするが、
今回は１種類しかアンケートがないので）
ということで、こんなかんじ。
■Ｖｉｅｗにメソッドを追加する
Viewにメソッドを追加する。
メソッドは、アクションを起こすところ
＝結果として、イベントを起こすところ
＝多くは、ボタンをおしたり（場合によってはタイマーもありだけど）
となる。
ということは、アクティビティ図で、画面から、システムに行くところは、必ず
メソッドになる。そして、これは、ボタンをおしたときなどのアクションに結び付く
（実装上、メソッドとしてJavascriptの関数で書くか、FormタグのSubmitボタンに
なるかは、この時点では決めなくて良い）
今回は、あとあとの若干の理由から、「初期表示」も入れる
また、結果表示画面は、初期表示より、結果表示のほうがいいので、そうした
（ここで、メソッド名は、正直、どうでもよい。かっちょ良いのにしてくれ）
こんなかんじになる。
■画面分割
ここで、１画面で表示しきれない、表示しないほうがいい場合は、画面分割する。
集計結果表示画面は、いいとして、アンケート画面は、このままだと困る。
問１で、「いいえ」と答えた人は、問４に飛ばないといけない。
問２と問３を同時にだしてしまうと、問２に答える前に
日本の「卵かけ御飯」が「絶対に危険な食べ物」に選ばれる…中国
http://blog.livedoor.jp/dqnplus/archives/1758248.html
を見られてしまう可能性がある→その場合、問２の意味なし
問２と問３は分離しないといけない。そして、後に戻れないようにする。
結果として、こういう画面割りにしないといけない
問１
問２
問３
問４・５（４と５は一緒の画面でいい）
そこで、Ｖｉｅｗの画面を分割する。
分割は（かっこ内は、問１画面の例）、
・分割した画面のクラスを作る（問１画面クラス）
・分割した画面で表示（入力）する項目をつける（属性問１を追加）
・もとの画面（アンケート画面）から、
分割した画面の属性を削除（アンケート画面の属性問１を削除）
分割した画面を集約か、コンポジションかにして、線を結ぶ
・分割した画面（問１画面クラス）にメソッドを追加する
→その画面で起こすアクション
この結果、
・もとの画面の属性が全てなくなれば（今回はそのケース）
その画面は抽象的にまとめたもので、実装の必要はない
このとき、元の画面（アンケート画面）のメソッドは、
集約した＝分割した画面のメソッドのどこかに対応する
はず（アンケート画面の回答実行＝問４・５の回答実行）
１個でも属性が残れば、
その画面は必要になる
これらの処理をして、必要となった画面を、
appview（でもdispでもなんでもいい、viewと区別する）という
ステレオタイプに変えておく。あとで判りやすくするため
結果、こうなる
今回は「受注明細」のような画面のかたまりや、
「年月日」といった、型の話は出てこなかった。
その操作は、次回、はなそう。
それと、「集約」でも「コンポジット」でもどっちでもいい
と書いたけど、実は、分けられる（その上で、今回は集約を使っている）
その理由も書くかも？
さらに、その後で、コントローラーなんだけど、コントローラーに行く前に、
（４）その後、ＭＶＣアーキテクチャを採用したとすると、
なんかのフレームワークを決めて、
を説明する。ここで、「初期画面」を入れた謎などが、解ける
んだけど・・・ここまではいかないかな？