フレームワークは外部設計時に決める必要があり、それを修正すると、コストが高い

　で、フレームワークとデザインパターンの違いで何が言いたかったかというと、
　フレームワークは入出力を決定してしまうものが多い（Ｗｅｂでやるとか、クライアントベースとか・・・）。

　ということは、ユーザーインターフェース決定前に、どのフレームワークを使うかを決め、そのフレームワークの範囲内のＧＵＩで行わないと、コストが高くなる。たとえば、Ｓｔｒｕｔｓなら、タグが用意されているものなら開発コストは低減するが、Ｆｌａｓｈ使わないと表示できないようなコンテンツなら、はじめっから、ＦｌａｓｈベースでＲＥＳＴで開発するフレームワークを使わないと、逆に開発コストは高くなる（めんどっちくなる）。

　一方、デザインパターンは、詳細設計レベルの話なので、外部設計のときには、意識しなくてもよい。
　さらに、仮にデザインパターンを利用しなくても、フレームワークほど、開発コストは高くない。なぜなら、開発の場合、上流工程の変更ほど、コストがかかるので、上流（ＵＩ）のフレームワークの変更のほうが、開発コストは高くなるはずである。

　なので、リスク面から考えると、デザインパターンより、フレームワークを教えて、「こういうユーザーインターフェースにしなさいよ、それ以外の画面に変えようとすると、このフレームワークでは（ハリウッドの法則もきいてくるし）大変だよ！」ということを伝えるべきなんだろうな・・・

・・・だれに？新人？
・・・というより、お客さんだよね。
Ｗｅｂだと、こういう画面にしないと、コストが高くなるよって！

東証より、大証・ＪＡＳＤＡＣ＋地方取引所をクラウドにするほうが・・・

　そうそう、
佐藤一郎：Ｗｅｂ日記
http://home.att.ne.jp/sigma/satoh/diary.html
を昨日取り上げたので、それを読んで思ったけど、このブログで書き忘れてたことを１つ

2008年11月2日の日記で（以下斜体は上記サイトより引用）


先日、東証のシステムはクラウドコンピューティングに移行できるかと聞かれたのですが、株取引はリアルタイム処理が必要なのでローカル側で実行すべきなので、クラウドコンピューティングには不向きです。


とありましたが、クラウドなら、東証より、大証とＪＡＳＤＡＣ＋地方取引所のほうが、向いてるんじゃないかな・・・

・大証とＪＡＳＤＡＣ、２つの証券取引所の共通部分を１つの計算センターで処理する
　　　→計算センターにアクセスして処理
　　　　これに関しては、大証のものを使う？
　　　　・・・って簡単な話じゃない？

・その計算センターが、分散処理することもあるけど、分散先は見えないようにする。

・もちろん将来は、共通部分だけでなく、全業務、そして、札証や福証も乗り入れるように、

・そしてもっと将来には、商品も加えていけば、総合取引所構想にも弾みがつきそうな気が・・


　・・・甘いか（＾＾；）

　でも、そーやって、計算センター部分の合理化＆クラウド化とかしないと、地方の取引所は。。。どーなんでしょう（＾＾；）