Java最新版に新たな脆弱性情報－また、アップデートするの（－＿－；）

Java最新版に新たな脆弱性情報
http://www.itmedia.co.jp/news/articles/1301/21/news022.html


え～、このまえしたばっかじゃん・・・
またするの～

そんなになってくると・・・

必要なければJavaは無効に――今後も攻撃は続くと米機関が予想
http://www.itmedia.co.jp/enterprise/articles/1301/16/news036.html

ってことだよね・・・

クラス図で漏れる関係（制約・条件）について

クラス図は、クラスとリンク、属性、振る舞い（メソッド）が書かれている。
この間の関係について、クラス図に書かれているかどうかを考える。
なお、「書かれている」とは、標準的な記法で、メモ・コメントを含まない。


・クラス間の関係＝リンクとして書いてある

・クラスと属性＝自分のクラス内の属性は、クラスの中に書かれている
　　　　　　　他クラスと、自分のクラスの属性と関係があれば、リンクが引かれる
　　→書かれている

・属性間の関係・制約＝書かれていない（漏れる）
　　　例：大人数、子供数は０以上で、価格は、大人数＊大人単価＋子供数＊子供単価
　　　　　→不変条件になってくる

・属性とメソッドの関係＝書かれていない（漏れる）
　　　具体的には、事前条件、事後条件にあたる
　　　例：退会する（あるひと）
　　　　　→事前条件：ある人は、会のメンバーにいるはず
　　　　　→事後条件：ある人は、会のメンバーにいないはず

・メソッド間の関係＝書かれていない（漏れる）
　　　具体的には、並列可能条件などになる
　　　　例：プロセスＡとプロセスＢは、同時に起動してはいけない

チェックすることはAssertionsで

---

■形式仕様で検証できるもの

このうち、形式仕様で検証できるものについて考える。

クラスと属性は、クラス表現できるものならばＯＫ
クラス間の関係は、最悪不変条件で表現できる。

ということは、事前条件、事後条件、不変条件が記述できれば、
メソッド間の関係以外はチェックできる。
ＢやＶＤＭは、ＯＫということになる。


Alloyは、
sig：クラス
sigの中に、属性値を表現できる
属性間の不変条件は、factで書ける

メソッドはfun（帰り値が集合）やpred(predicate：真偽)で記述できる？

アジャイルの背景には、開発生産性の向上がある

シリーズ化してしまいつつある

情報処理における学会と産業界というのは、かなり距離がある。
したがって、２つの間に関連性がありながら、
学界的に「それは違う」と排除してしまい、
産業界的にも、学界的にも、豊かな研究分野・実践を
踏みにじってしまうことがある。


前回の最後にこう書いた。


ただ、参考資料の４４シートの話は、こういう風な流れにはなっていない。
つまり、もう一つのお話がのこっているんだけど、それについては、またこんど。


ここで出てくる、参考資料とは、

~ トヨタ カンバン方式に学ぶ ~
ITシステム開発・管理への適用と実践技法
2. リーン・ソフトウェア開発　
http://www.metabolics.co.jp/SoftwareProcess/SRC040903/LSD02.pdf


で、このシリーズの前回の話は、

「アジャイルでやるのは、下流工程にならないと、問題が見えないことがあるから」

だった。しかし、その参考資料の４４ページにあるのは、

「アジャイルでやるのは、生産性が高くなり、リスクが下がったから」

となっている。
もちろん、この理由は正しい。
今日は、こっちの理由についてみてみる。

---

■実務上は、大学で教えるより、もっと簡単にプログラムが作れる。

なぜか。

　　　　フレームワークを使って開発するから。

フレームワークは、結構、いろんなことをやってくれる。
共通なメソッドなども使える
さらに、ビューは１からコーディングしなくても、
画面レイアウトをＨＴＭＬで作成すると、
それが流用できる。

ってなことで、簡単にプログラムが作れる。
CakePHPだと、すごく簡単にできるときもある。

10分で作るCakePHPアプリ アプリケーション編
http://moyashi.jp/cake/cake_app.html

実務上、そんなに簡単なシステムはありえない。
しかし、Railsっぽい話を教えないと、今の現場の感性とは、
合わない気がする。
（ＭＤＡとRailsを関連付けて話す必要があるはず）


また、フレームワークだと、修正のさいでも影響範囲は限定される。

ってなことで、生産性が上がった。

---

■大学は、実務上、一番大切なことを「教えることはできない」

一般にフレームワーク開発において、一番大切なことは

　　「ハリウッドの法則」

だ。

　　「私を呼び出すな、必要なら私から呼び出す」

ってことだ。

つまり、フレームワークから呼び出すので、フレームワークが対応していないような
イベントなどを制御するのは、とてもむずかしいというか、やっちゃいけない
ことになる。なので、フレームワークを使った場合、最適なＧＵＩなどが存在し、
それに逆らわなければ生産性があがるが、逆らえば生産性はとてつもなく下がるのだ。

だから、フレームワークが大事で、それに設計はもちろん、要求までも左右される。

・・・なんてこと、大学では口が裂けてもいえない。

まず、「ハリウッドの法則」って、論文が出ていない（たぶん、詳しく調べてないけど）
論文がない、著名な先生の本になっていない＝大学でそんなこと、教えられないでしょ！

次に、これを認めてしまうと、要求は、フレームワークというプログラミング手法に
影響を受けることになる。
こんなことは、認められない。

要求の権威、ロバートソン（だんなさんでも、おくさんでもいいけど）
はむしろ逆のことを言っている

要求は、実装にひきづられてはいけない。
要求は「何を」を定義するので「どうやって」は定義してはいけない

---

■現実は、フレームワーク導入はかなり早く決まり・・

しかし、例えばスマホ＆ＰＣ同時開発の場合、ネイティブアプリより、
ＨＴＭＬ５で作ったほうが早い。
機種によって切り分けるのはＣＳＳ３でやったほうがはやい。
なので、ＨＴＭＬ５＆ＣＳＳ３と決めてしまうと、
使い勝手とレスポンス等がびみょ～に影響を受けてしまう。

現実的には、フレームワーク導入は、ＲＦＰ中、ないしはそれに対する提案書作成時
等、かなり早く決まってしまい、フレームワーク前提で、使い勝手とかを考えることも
（ことが？）多い。


つまり、現実的には

生産性向上・費用低減
　　→フレームワーク採用（それ前提で費用見積もり）
　　　　→使い勝手、処理スピードなど非機能要求に影響

という構図になっている。

だけど、そんなことはいえない。
要求の前に設計方針を決めることなんて、やっちゃいけないことになっている。

大学では、デザインパターンは教えても、
フレームワークはあんまり教えない。
それは、こんなところに理由があるのかもしれない。

---

ここで、要求→設計という流れを話したが、
実は、大学のソフトウェア工学の教育方法と
現場との違いは、根本的な相違点がある。
それは、


パターンっていうのは、計算機工学の考え方の基本なんだよ！
http://blog.goo.ne.jp/xmldtp/e/0cf44129a90e47cefa3ac5d3d7a04f75


に書いたことでもあるんだけど、

ダック・タイピングを認めるか否か

が決定的な違いになる。大学の教育は、抽象から演繹的に落としていき、具体になっていく。
それに対し、現在の開発は、ダッグタイピングを認め、帰納的、ないしはアブダクションによって意思決定していくことが多い（たぶん、演繹的に考えるより多い）

それについては、次回書く予定。