UML等各種ダイアグラムのエラーチェック体系化（その３：UML等→Strutsでの開発の流れ）

　シリーズ、 「UML等各種ダイアグラムのエラーチェック体系化」です。
　前回ではダイアグラムの検証法について、概要を説明しました。おおきくわけると、こんな感じ。

・ダイアグラムの入力に関するチェック
　　　→入力時矛盾チェック
　　　　　＝入力データが前工程で作成されていて、利用可能になっているか

・ダイアグラムの処理に関するチェック
　　　→検証
　　　　　＝入力データと出力データの変換の妥当性、正当性

・ダイアグラムの出力に関するチェック
　　　→出力時：成果物矛盾チェック
　　　　　＝作成した成果物が、他の成果物の記述と矛盾してないかどうか

で、このうち、お手軽に出来るのが、実質、項目一致チェックである、「入力時矛盾チェック」。
そこで、この「入力時矛盾チェック」でどれくらいの効果があるのかを見てみようって
いうのが、これからのお話。

---

　なんだけど、その前に、開発で使われるダイアグラムについて考えたとき、
上記のチェックは、具体的に何を指すのかがわからないと、今後の話に支障を
きたすので、ここで、それを確認しておきましょうというわけ。

　で、さらにその前に、そもそも「開発で使われるダイアグラム」ってなに？
　ってことになりそうなので、UML等→Strutsを使った開発におけるダイアグラムをまとめますかにょ。

　っていうのが、今回と次回のおだい。

---

　で、考えると、開発の流れは、

（１）登場人物の整理

（２）登場人物にかかわる業務の流れを確認

（３）そのうち、コンピューター化する範囲を確認
　　　　　→ここで機能がでてくる

（４）機能ごとの入出力確認

（５）画面入出力から永続性項目取り出し（変換）→正規化→DB定義作成

（６）画面からフレームワーク決定→クラス決定

ここでStrutsを利用する場合
（７）画面遷移図、画面一覧→ActionForm,Action決定

（８）ActionForm,Action決定→struts-config.xml

（９）プログラミング

となっていく。あと、テストがあるけど、ここで話をきる。

---

で、次回は、この開発の流れと、図の関係を書きます。

任天堂、マリオで行き詰ったステージをコンピューターが自動でクリアする機能導入

ここの痛いニュース
任天堂宮本氏、マリオで行き詰ったステージをコンピューターが自動でクリアしてくれる機能を導入
http://blog.livedoor.jp/dqnplus/archives/1274995.html
この「コンピューターが自動でクリアしてくれる機能」をDemo Playというそうなんだけど、

たぶん、任天堂としては、「公式クリア方式」として、このDemo Playで、クリア方法を示して、
ほかにも、クリアする攻略法を用意しておいて、「ヘビーユーザーさんは、他の華麗なクリア方法をみつけて、
自慢してくださいね！」って形にするんだろうな。。。

そーすると、ヘビーユーザーも初心者も両方たのしめる。
さらに、Demo Playも、はじめ１つのクリア方法を入れておき、あとでいくつものクリア方法を紹介していくということで、ずーっとそのゲームの鮮度を失わせず楽しんでもらえると・・・


・・・そーなってくると、任天堂が攻略法を示しちゃうことになるから・・・

・・・攻略本を出してる出版社は、どーするの？？・・・

やっぱ、Demo Playの「みどころ」の紹介？？

ゲームが、映画に、なっていくう・・・（＾＾；）