口蹄疫対策にSaaS － たしかに、突発事故にSaaSは、アリだよな・・・

ここの記事

口蹄疫に対する防疫対策と復興支援に関わる、
現場の被災情報整理にSaaS型システムが大きな力を発揮
http://jp.fujitsu.com/solutions/cloud/casestudies/prefmiyazaki-koutei/

たしかに、口蹄疫のような突発的な事故に対して、SaaSは、アリかも。
持続的に使うわけではないし・・・
もちろん、（スタンドアロンの）Excelもアリだけど、地域間で共有したりするときは、
問題かも（なにが最新かわかんなくなる）

---

ただ、CRMがベストとは限らないけどね。
Google ドキュメントとかMicrosoft Office Web Appsの表計算でもいいかもしれない。

　クラウドが今一歩不調だけど、Googleドキュメントや、Microsoft Office Web Appsから進めていけば、中小企業でもすぐに使い出して、大きなうねりになっていくと思う。はじめっから、「クラウドはPaaSです、GAEやAzureです」みたいな感じにしてしまったのが、失敗した最大の原因じゃないかなあ・・・


　中小企業でも、SkyDriveや、DropBoxは、かなり使っているわけで、
　これはクラウドなわけで、
　そー言うレベルからのアプローチが重要な気がする。

J2EEのちょっとめもめも

めもめも

---

J2EE
問題点：過剰な実装、システム複雑、重い

　　↓＋POJO,アノテーション、DI、PersistentAPI,JAX-WS,JAXB

JavaEE 5
　　EJBコンテナ
　　Webコンテナ：JSP2.1 ,JavaServlet2.4
　　Webサービス
　　XML
　　その他：

AOSD（アスペクト指向による機能追加）を、もうすこし詳しく

　以前、ユースケースとアスペクト指向（機能追加を行うためのアスペクト指向）で書いた、最後の部分が、詳しくなくて、これでは、何を作ればいいか不明なので、手順をもう少し詳しく。

---

（１）追加機能を、ユースケースのextendで示す
　　　　→拡張ポイントを明示

（２）ユースケースシナリオに、その拡張部分のフローを書く

（３）（元のシーケンス図があったら）シーケンス図に
　　　optで、拡張ポイントを明示し
　　　拡張フローを記述する
　　　　→astah*だと、拡張フローをシーケンス図にすれば、
　　　　　クラスにメソッドを追加してくれるハズ

（４）ユースケース実現のクラス図を作成する
　　　　→機能追加する部分のクラス図を作成

（５）ユースケース実現から、ユースケーススライス図を作成する
　　　　→機能追加分中
　　　　　　この機能にしか出てこないクラス＝＞クラスとして残す
　　　　　　共通に出てくるクラス、この機能しか出てこないメソッド＝＞アスペクトとする
　　　　　　共通に出てくるクラス、共通のメソッド＝＞かかれてないはず：（４）で書いてない
　　　　　　　→どっちにしろ、クラスとして残す

（６）ユースケースクラス図のアスペクト部分を記述する

astah*を使って、ICONIX風一気通貫システム開発 その９：画面作成

「astah*を使って、開発の要求仕様から、プログラム作成までを、トレーサビリティを保って、どのように開発するかを書いてみる」という、このシリーズ、以下の手順で説明する予定ですが、

（１）作るべきもののユースケースを書く
（２）ユースケースシナリオを書く
（３）ロバストネス分析
（４）バウンダリ（画面）、エンティティ（テーブル等）の属性を埋めていく
（５）バウンダリの項目を元に、画面構成を考える。
（６）(必要があれば）エンティティを正規化して、ER図にする
（７）フレームワークを決定する
（８）画面クラスをソースコードに書き直す
（９）エンティティをDBのテーブルと、DAOに書き直す
（１０）コントローラーを書き直す

前回、（７）をやったので、今回は、「（８）画面クラスをソースコードに書き直す」について

---

■概要と位置づけ

　（７）までで、外部設計が終わりました。
　ここからは、詳細設計＆コーディングとなります。ただ、画面は詳細設計をするまでもなく、後は作っていけばいいっていう状態です。

　画面遷移は、状態遷移(ステートチャート）に、
　画面の入出力項目は、画面のクラス図の属性に
　画面で起こるイベントは、画面のクラス図のメソッドに

それぞれ記載されているので、それをもとに、画面を作成していけば良いだけです。

---

■たとえば・・・

　Strutsだと、ステートチャート図の状態を画面に、遷移を画面遷移に割り当てていたので、
　struts-config.xmlは、
　　　状態ごとにActionをつくり、
　　　そのActionに対応する画面（Form-bean＆ActionForm)を定義し、
　　　そのActionに対するForwardは、
　　　　　画面に対応する「状態」につながっている遷移
　を書くことになります。

　画面のJSPは、
　画面のクラスの属性に対応する入出力項目をHTMLタグで作成し、
　画面のクラスのメソッドに対応するボタンなどのイベントを発生するものを作ります。

　また、ActionFormは、画面のクラスの属性に対応する入出力項目から、
　Actionメソッドは、画面のメソッドに対応して（すべてが１対１と言うわけではない）
　　作られます。

---

■自動生成

　ここまでいくと、自動生成も考えられます。
　astah*のXMI形式で書き出し、状態遷移図から、struts-config.xml,Actionクラスを、
　クラス図から、ActionFormクラス,JSPを書き出すという方法です。

　astah*のXMLと自動生成の関係は、たぶん、このシリーズではなく、別に書きます。
　(それを書いていると長くなるので）

---

今回は、ここまで

QMLを、はじめたい！ その２ QML版「Hello World」

　昨日からはじめた、シリーズ「QMLを、はじめたい！」。前回は、Qtをインストールしました。
　そこで、今回は、インストールしたQtの中に入っている開発環境、Qt　Creatorを使って、「Hello World」と出るだけのプログラムを作ります（正しくは、作ってくれます）。

　ちなみに、以下のサイトを参考にしています。

Qt Quick 入門 第3回: Hello QML!
http://qt-labs.jp/2010/08/26/hello-qml.html

---

■Qt　Creator立ち上げ

　前回、インストールしたので、下図のように

　　スタート→「Qt　SDK　Nokia　・・・・・」→Qt　Creator
　（・・・・は、いろいろ）

　を選んで、Qt　Creatorを起動します（ちょっと時間かかるかも・・？）

---

■プロジェクトをつくる→ソースできる

　Qt　Creatorが立ち上がったら、
　プルダウンメニュー「ファイル」→「ファイル／プロジェクトの新規作成」

　そうすると、下のようなダイアログが出る。

　左側「他のプロジェクト」
　右側「QMLアプリケーション」を選ぶ
　「選択」をクリック。下図のダイアログが出る

　「名前」に適当なプロジェクト名を入れて、
　(必要ならパスを直す）
　「次へ」をクリック
（ちなみに、名前は「Project1」と入れました）

次のダイアログ（下図）で、「完了」をクリック

以下のように、「Hello World」と表示する画面を作ってくれます。

---

■実行

「Qt　Creator」から、「ビルド」→「実行」を選択

下図のような感じで、実行してくれる

---

今回はここまで・・・

何も編集してないけど・・・

Uppaalにおける検証モデルのつくりかた

■全体像

（１）もとのステートチャート図

（２）時間情報を加えたステートチャート図

（３）検証
　（３）－１　検証モデル
　（３）－２　ツールでの検証
　（３）－３　反例の分析

---

■（３）－１　検証モデルの手順
・環境コンポーネントのモデル化
・時間制約の詳細化
・検証したい性質の定義
　　オブザーバー
　　検証式

---

■（３）－１－１　環境コンポーネントのモデル化
・検証対象コンポーネントとの相互作用があるところを定義
　　→相互作用にかかわる、必要最低限の制御ロジックでいい


■（３）－１－２　時間制約の詳細化

詳細化する前に＝既存データに対するモデル化
・ステートチャートの状態＝ロケーション
・状態遷移＝遷移
・時間制約をモデルで表現するが・・・
　　　デッドロックになる場合がある

詳細化－１：実装に必要になる時間制約の抜けを補充
詳細化－２：検証のための時間制約を追加

●（３）－１－２：補足　時間制約になる、時間要素
・実装段階までには明確化、プログラムに直接反映される時間
　　適切なタイミングでアクションを起こすための時間
　　アルゴリズムの判定要素として使う時間
　　例外判定のための時間

・設計段階では想定するが、プログラムに直接反映しない
　→環境をシミュレーションするもの

・設計段階で想定するが、プログラムにはなく、検証には必要
　→計算時間

・要求側から、こうなっているべきという時間
　→要求仕様に書かれている

●　（３）－１－２：補足　留意点
・時間要素が漏れなく反映されているか
・意に反した非決定的な挙動はないか
・初期値／参照関係は実態とあっているか
・検証対象との相互作用
・実測地なのか、想定値なのか？
・調整可能な時間かどうか？
・インタラクションに直接対応する想定値のみを設定すると、漏れが発生することも
・誤差
　　→センシングする時間がαのとき、５０で分岐→５０ぴったりでなくαの誤差を考慮

---

■（３）－２　ツールでの検証

マニュアル見てやってください

---

■（３）－３　反例の分析

・symblic trace
・concreat trace
・クロック変数の値の変化を確認
・影響を与える範囲を抽出

ハイプサイクルと製品ライフサイクルの関係って、どう思います？

ハイプサイクルは、

「黎明期」「流行期」「反動期」「回復期」「安定期」

ないしは、

黎明期→ピーク期→幻滅期→啓蒙活動期→生産の安定期

のように進みますよね・・・

---

一方製品ライフサイクルは、

導入期、成長期、成熟（市場飽和）期、衰退期

のように進みますよね。

で、この関連

ハイプサイクルの「黎明期」＝製品ライフサイクルの「導入期」

これはいい。また、

ハイプサイクルの「安定期」＝製品ライフサイクルの「成熟期」・「衰退期」

っていうのも、たぶんいいと思う。

のこりの、

ピーク期→幻滅期→啓蒙活動期

が、

製品ライフサイクルの

導入期、成長期、成熟（市場飽和）期

のどこに、位置づくかということ。

---

■ハイプサイクルは、成長急落成熟パターン？
Wikipediaの「製品ライフサイクル」の説明には、

「成長急落成熟パターン」っていうのがある。

これにハイプサイクルを当てはめると、

成長　＝　ピーク期
急落　＝　幻滅期
成熟　＝　啓蒙活動期（・安定期）

っていうことになりそうだ。まとめると、

---

ハイプサイクルは、製品ライフサイクルの代表的パターン、成長急落成熟パターンであり、

製品ライフサイクル　　ハイプサイクル

　導入期　　　　　　　黎明期

　成長期
　　　成長　　　　　　ピーク期
　　　急落　　　　　　幻滅期
　成熟期　　　　　　　啓蒙活動期
　　　　　　　　　　　生産の安定期
　衰退期

といえそうだ。

---

　製品ライフサイクルの成長前期に、参入を始めるのが良いとされるけど、

　ハイプサイクルの場合、
　　　株の買い方（普通、落ちきった後の上がり調子のところで買い）
　と同じと考えると、
　
　つまり、啓蒙活動期に参入を考えるほうがよさそう。

QMLを、はじめたい！ その１ とりあえず、Qtをダウンロード

突然だけど、Qtをはじめてみる。っていうか、QMLをはじめたい。
理由は、かんたんそうで、たのしそうだから
（「簡単そう」の理由については、別のときに書くかも・・・）

まずは、インストールだよね。
Qtをはじめるには、

Qt をはじめよう！ 第1回: Qt をはじめよう！
http://qt-labs.jp/2010/03/15/qt-getting-started.html
からはじめるのが、「ビンボー人には」よさそうだ。
（金持ちの人は、たぶん、「入門 Qt 4プログラミング」から読むんでしょう・・・きっと）

たぶん、第二回　Windows編から、よめってことね！

ここへ、いけと・・・
http://qt.nokia.com/downloads-jp
ご、ごめん。。。よくわかんない（＾＾；）なにを（左と右どっちを）ダウンロードするの？
第二回の説明だと、

　　Qt SDK for Windows のダウンロード* (322 MB)

ってことなので、左をダウンロードした。
（ちなみに、クリックすると、画面が変わり、ブロックした云々でるので、そのブロックを解除して、ダウンロードした。変わった画面で、E-mailとか入力するところは、とりあえず何もしなかった）

時間かかる・・・

ダウンロードが終わったら、そのExeファイルをダブルクリックして実行した。

次からの画面は、ここに書いてあるとおりなんだけど、「コンポーネントの選択」のところ、「Qt Creator」は、文中では「選択した状態にして」とかいてあるけど、そこの図のように、選択するも何も、選択されている状態になっていた。
　Pythonなんたらかんちゃらも、そうなっていた。Symbianはもともとない。Postなんちゃらかんちゃらは、図でも文章でもチェックしてないので、そのまま（チェックしない）にしておいた。

　あとは、同じ。

　おお、Qt　Creatorが動くところまで来た！

　で、次は・・・？


P.S　そうそう、「入門 Qt 4プログラミング」の訳者の杵渕さんは、今、何してるんだろう・・・

12月12日(日)のつぶやき

11:53 from web
中小企業が（コンピューターの）システム化できないのは、会社が（業務的、非コンピューターの）システム（＝手順）を持ってないからだよね!
うん、違うか？システム化できていないから中小企業なのか・・・
by xmldtp on Twitter

ミスユースケース

■ミスユースケースとは

・UMLユースケース図の拡張
　　ミスユーザー：意図しないことをするアクター
　　　　→黒くして、悪者をあらわす。

　　ミスユースケース：意図しない挙動
　　　　必ずしも、悪意があるとは限らない。
　　　　→黒くして、わるいころを示す

　　threatenというステレオタイプで脅威
　　mitigateというステレオタイプで対策

・脅威とその関係者、対策の関係が明確になる

・被害があるかどうかが問題で、悪意の有無は関係ない

・ユースケースは実現するものだが、
　ミスユースケースは、実現しては「いけない」
　　　→ミスユースケースは実現するシステム対象範囲外：ふつう
　　　　そこで、四角で囲わないことが多い

・＜＜欠点＞＞
　具体的に、どうやったら、こうなるのかまではわからない。
　→設計まで落ちないと、じつは何をしたらいいか、はっきりしない。

---

■ミスユースケース記述
　ユースケース記述があるように、ミスユースケースを補完するものとして、
ミスユースケース記述がある。以下の点がユースケースと違う

基本パス／代替パス
　攻撃シナリオを書く

トリガー
　ミスユースケースのきっかけになる事象または状態

前提
　ミスユースケースを可能にするシステム環境

前条件
　ミスユースケースを可能にするシステム受胎

緩和ポイント
　ミスユースが緩和できるポイント

緩和の保証レベル

関連業務ルール
　ミスユースケースにより侵害される可能性のある業務ルール

ミスユーザープロフィール
　想定できること何でも

スコープ
　人とコンピューターで実現？コンピューターだけで実現？

ステークホルダーリスク
　ステークホルダーに対する

技術データのバリエーション

---

■関連研究

・Abusecase（あぶゆーすけーす）
　ユースケースと同じ記法で書いてある。
　→よくわかんなくなってしまう。

・マルアクティビティ、ミスユースアクティビティ
　アクティビティ図に意図しない振る舞いを書く
　攻撃シナリオ、攻撃ポイントを表せる

---

■手順

１．システムの資産を認識する
２．各資産に対するセキュリティゴールを定義
３．ゴールに対する脅威（ミスユースケース）を識別
　システムに被害を与えるステークホルダー（ミスユーザー）
４．脅威のリスクを分析、評価する
５．リスクに対するセキュリティ要求を定義
　（セキュリティユースケース）

12月10日(金)のつぶやき

20:18 from web
astah*に、ニコニコマークのアイコンがあることを、発見したなう
by xmldtp on Twitter

セキュリティ要求分析

■ソフトウエアセキュリティとは？
セキュアな
　→脆弱性がない（セキュリティ機能が入っていればよいわけではない）
　　じゃ、脆弱性をなくすには？
　　　　セキュアプログラミング
　　　　セキュリティテスト　　　　→従来の開発と同じ？
　　　　PDCA
　　ソフトウエア開発と同じ仕組みでセキュリティを上げられるか？
　　　　→従来手法でよければ、こんなにセキュリティで問題になるわけがない

　　　→セキュリティは、非機能要求だから：機能要求より難しい部分がある
　　　　　例：テスト
　　　　　　　機能要求なら、同値分割、境界値分析ができる
　　　　　　　→SQLインジェクションは？？



■セキュリティの問題を、工程ごとにまとめると・・・

・要求仕様
　機能にない、ステークホルダーから聞き出せない、悪意を持った攻撃者の要求？を
　聞き出す／洗い出すのは、困難

・設計
　セキュリティ要求を満たす設計手法は？

・プログラミング
　脆弱性を生じないプログラミング技法は？

・テスト
　安全でないことが確認できるか？
　→新たに生み出された脆弱性に対して、テストできる？

---

■セキュリティ要求分析の種類

　　CC（ISO/IEC１５４０８）
　　SQUARE
　　SDL
　　脅威モデリング
　　UMLの拡張

UMLSeq
　UMLのセキュアシステムの開発のための拡張
　セキュリティのステレオタイプを用いる

SecureUML
　RBACに基づくUMLモデル定義

SDL（Secure　Development　Lifecycle)
　マイクロソフトのセキュアな開発手法
　　　セキュリティPush
　　　　　：１ヶ月ぐらいひたすらセキュリティチェック
　　　脅威モデリング
　　　　　：DFDをもちいた脅威抽出
　　　　　　Strideによる脅威分類
　　　　　　　　S　なりすまし
　　　　　　　　T　改ざん
　　　　　　　　R　否認（商品を買ったのに買わないという等）
　　　　　　　　I　情報の漏洩
　　　　　　　　D　DoS攻撃
　　　　　　　　E　権限昇格
　　　　　　脅威ツリー、DREADによる脅威評価
　　　　　　　　D　潜在的な損害
　　　　　　　　R　再現可能性
　　　　　　　　E　攻撃利用可能性
　　　　　　　　A　影響ユーザー
　　　　　　　　D　発見可能性
　　　など→対策はない

Qtがマルチプラットホームで動く＝KDEがスマートフォンで動くってこと？

さっき、QT Conference Tokyo 2010があったんだけど、
午前中、やたらと、

Qtがマルチプラットホームで動く、
Linuxでも、WindowsでもMacでもSymbianでも、MeeGoでも（ってことはスマートフォンでも）
っていう話をやっていたわけ。

ま、そのときは、ふーんって聞いてたんだけど、

で、お昼は、お弁当が出た（豪勢！ちなみに、３時には、コーヒーとお菓子も用意してあったよ！
いま、お昼に配られたお茶が横にある。これから開けて飲む予定）

で、最後のセッションはぶっちして、あるところに移動。
５：３０になったので、３階で「晩ご飯セット」５００円を食べてた最中に思ったんだけど
（そこは５：３０にならないと、夜再開しないとこなの。
　お昼、お弁当が出たので、その浮いたお金で晩ご飯セット）

Qtがマルチプラットフォームで動く
＝Linuxで開発したQtのアプリが、スマートフォンで動く？？
＝Linuxのデスクトップ環境KDEが、ひょっとして、スマートフォンでも動くのか？？

いや、KDEが、スマートフォンで動いたら、インパクトすごいだろ・・・
もちろん、画面サイズなど、一部手直しは、いるだろうけど・・・

なんか、一部の熱狂的ファン？は、QtをAndroid上で動かそうとしてるらしいし
（公式のプロジェクトではなく、あくまでも有志がやっているようだ・・・）

そーなの？どーなの？？

Qt、すごいかも

　きのう、MeeGo Seminar Winter 2010にいってきて、そこで、
「Qt UI開発技術最新動向」
っていうのを聞いてきた。

Qt（きゅーと）って、むかし、Trolltechがやってた、あのQt（きゅーてぃ）のことみたい。
KDEプロジェクトでつかわれているっていってたから。

でも、むかしのとちがって、超簡単に画面がつくれそう。
っていうのも、Qt４．７から、QtQuickっていうのが入ったらしく、
QMLっていう言語（CSSで指定するの＋JavaScriptでロジックを書くみたいなかんじ。コンパイル不要）
をつかって、画面を簡単に記述できるから。

もちろん、Qt本来の特徴、つまり、C++むけのUIのオープンソースフレームワークであることは」かわらず、MeeGoの一部でもあるけど、他のプラットフォームでも動くという特徴はかわらない。

詳しいことは、もちょっといろいろ聞いてから書くことにする。

12月9日(木)のつぶやき

20:08 from web
Qtって、最近は「きゅーと」って言うんだね！たしか、むかし、「キューティー」って言ってたと思うけど・・・
by xmldtp on Twitter