PressmanのSoftware Engineeringを超訳ななめ読み その８－モデリング続き

みんなから、無慈悲な稲妻を受けないために、
大事そうなところを、超訳＆ななめ読みしている

PressmanのSoftware Engineeringを超訳ななめ読みする

を久々に・・

いままでで、６章が終わっていて、
６章では、モデルについて、以下のタイプのモデリングが挙がっている
　　・シナリオベースモデル
　　・データモデル
　　・クラス指向モデル
　　・フロー指向モデル
　　・振る舞いモデル
６章では、クラス指向まで上がっているので、今日の７章では、フロー指向から

---

■７章　要求モデリング：フロー、振る舞い、パターン、Webアプリ

７．１　要求モデリングのストラテジ

７．２　フロー指向モデリング
　　ＤＦＤの話。まず、コンテキストダイアグラムが載っている
　　７．２．１　データフローモデルを作る
　　７．２．２　コントロールフローモデルを作る
　　７．２．３　コントロールの仕様
　　　コントロール仕様（ＣＳＰＥＣ）と状態図
　　７．２．４　プロセス仕様
　　　決定表が載っている

　ソフトウェアツール：構造化分析

７．３　振る舞いモデル
　７．３．１　ユースケースでイベントを識別する

　７．３．２　状態の表現
　　　状態図とシーケンス図
　　ソフトウェアツール：ＵＭＬによる分析モデル生成

７．４　要求モデリングのためのパターン
　７．４．１　アナリシスパターンの発見

　７．４．２　要求パターンの例：アクチュエーター　－　センサー
　　　パターンが記述されている

７．５　Ｗｅｂアプリのための要求モデリング

　７．５．１　どのくらいの分析で十分？
　７．５．２　要求モデルのインプット
　７．５．３　要求モデルのアウトプット
　　　コンテキストモデル
　　　相互作用モデル
　　　機能モデル
　　　ナビゲーションモデル
　　　コンフィグレーションモデル
　ということで、以下、各モデルについて説明している。

---

以降、設計。
あとは、目次をざっと流す程度でいいですかね・・・

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法（６）

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法（５）
http://blog.goo.ne.jp/xmldtp/e/b805f9f2daa234e99474b532ce819e1c


の続きです。
いま、クラス図はこんなかんじ

で、前回は、画面遷移を書きました。今回は、モデル部分を入れます。

---

■モデル作成手順

・まず、図にセッションを入れます。

・昨日決めた、画面遷移に基づいて、画面から、コントローラーを呼び出し、
　コントローラーにきたら、画面の値を
　　　セッションに入れるか
　　　モデルに渡すか
　考えます(両方の場合もあります）
　そして、モデルを呼び出した場合、わたってきた値を、
　　　画面にセットするか
　　　セッションに入れるか
　考えます。
　これを、全画面遷移し終わるまで、繰り返します。

・その際、モデルを呼び出すには、基本的に
　　　　セッションに入っている値
　　　　呼び出したコントローラーに対応する画面
　　　　他モデルの値（ただし、その前に呼び出されていること）
　のはずです。
　また、画面にセットする値も
　　　　セッションに入っている値
　　　　呼び出したコントローラーに対応する画面
　　　　呼び出したモデルの値
　のはずです。

・モデルが大きかったら、正規化します。

・Partsとして定義した、データの一部分は、モデル上にあるかないか、
　確認します。多くの場合は、正規化した一部になっています
　→モデル上になくても良い

---

■今回のケース

・セッションを作ります。


・画面に沿って、画面のデータを
　　　セッションに入れるか、
　　　モデルに入れるか、考えます。

　問１画面の「次へ」で
　　アンケート回答管理コントローラーの「問１次へ」にはいります。
　　回答実行で登録したいので、
　　　　「問１画面」のデータ「問１」は、セッションに入れます。

　同様に、
　　　問２画面の「次へ」で問２をセッションに、
　　　問３画面の「次へ」で問３をセッションに、
　入れます。

　問４・５画面の「回答実行」で
　　　セッションに入っている「問１、問２、問３」と、
　　　画面項目４、５を元に、アンケート回答データに「追加」します

・ここまでの操作で、図のようになります。

・集計画面に関しては、
　「集計開始」で、アンケート回答データを「検索」して、結果を処理加工し、
　それを「集計結果表示画面」に渡します。
　「アンケート回答データ」に「検索」を追加しました。

・今回は、正規化しなくてもいいかな・・という感じなので、これでやめときます。

---

■アレンジ（テーラリング）

　なお、今回は、正規化しない状態のモデル（Ｘと記す）と、
　　正規化したモデル(xと記す）を作成し、
　モデルＸから、xを呼び出すカタチにしていますが、

　モデルＸを消去し、コントローラーから、xを呼び出す形にしても、
　もちろんいいです。

　また、
　　　モデルＸと、コントローラーのメソッドを一致させたり、
　　　モデルＸと、コントローラーのクラスを一致させたり
　するほうほうもあります。さまざまです。
　好きにアレンジしていいと思います。

---

■注意点

　例えば今回の場合、問１、問２、問３、問４・５と進む画面遷移を
中心に話していますが、問１、問４・５と進む遷移もあります。
　このとき、問２、問３をどうするか？という問題があります。
　もし、問２、問３をクリアし忘れると、前のデータが入ったまま
更新してしまったり、無設定のまま更新してしまったりします。

　更新のメソッドを、問１、問２、問３、問４・５用と、問１、問４・５に
分けたり、問１をセッションにセットするときに、問２、３をクリアしたりと、
方法はいろいろあると思いますが、なんらかの対策を刷る必要はあります。

　このように、複数の画面遷移をする場合、妥当な値がすべてセットされているか、
確認する必要があります。

---

これで、Astah*でのモデル化は終わりました。
あとは、実装に入っていきます。

「ニューヨークの工科大学が作った3DCG初音ミクさんコンサートがすごい」らしい

ここの記事

ニューヨークの工科大学が作った3DCG初音ミクさんコンサートがすごい
http://nyliberty.exblog.jp/20308689/

DDoS攻撃の傾向と対策 － 情報処理２０１３年５月号

　今出ている情報処理学会の会報「情報処理２０１３年５月号」の特集がDDoS攻撃についてなんだけど、傾向と対策がわかって興味深い。最近は、ぼっとを使って攻撃するようで、攻撃手法としては、ざっくり言うと、資源を消費しきってしまうものと、使えなくさせる（例えば、数回ログインをわざとミスって、ログインできなくさせる）モノがあるようだ[1]。

対象別に分けると、以下のモノが挙げられている[1][2]

●回線帯域を狙う
　・Smurf攻撃
　・TCP SYN Flood
　・DNS Amp攻撃

●Ｗｅｂサーバー攻撃
　・TCP Connection Flood
　・HTTP GET Flood
　・Slow Read DoS
　・Slowloris
　・Slow Post Dos

●ルーター、サーバー
　・Teardrop
　・Ping of Death
　・Land
　・Http Range Header DoS攻撃


対策としては、以下のモノが挙げらている[2]
●サイト
　・IPS
　・負荷分散
　・ＷＡＦ
　・Ｗｅｂサーバー
　　　SYN Cookies有効
　　　mod_security,mod_reqtimeout
　・ＣＤＮ
　・ＩＰ　Anycast
　・(対策ではないけど）監視
　　　　トラフィック量
　　　　ＨＴＴＰの応答時間
　　　　ＣＰＵ／メモリ使用量
●ＩＳＰ
　・アクセス制御
　・DDos対策装置
　・通信遮断
　・攻撃パケット破棄
　・特定アドレスの帯域制御
　・（対策ではないけど）可視化、監視

こんなかんじ。
特集では、この内容の詳しい説明、事例などなどが満載している。


＜＜参考文献＞＞
１．寺田真敏:DoS/DDos攻撃とは
　　情報処理 Vol54 No5 pp428-435,情報処理学会,2013

２．倉上弘:DoS／DDoS攻撃対策（２）～高度化するDDoS攻撃と対策サイトの視点から～
　　情報処理 Vol54 No5 pp475-480,情報処理学会,2013

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法（５）

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法（４）
http://blog.goo.ne.jp/xmldtp/e/732a8af6aee4b018f8bd7bc11809728e

の続きです。

いま、ここまできました。

次は、画面遷移です。

---

■画面遷移図

画面遷移図を書くのですが、astah*で書くとなると・・・
しょうがないので、ステートマシン図を使います。
こんなかんじ（アンケート回答）

黒丸がスタートで、画面を状態とします。
問１画面（表示）の「表示」が省略されていると思ってください。
イベントによって遷移します。

---

■チェックポイント

＜＜画面について＞＞
・クラス図に描いたすべての＜＜appview＞＞が、
　ステートマシン図上に、最低１回は、必ずでてこないと、おかしいです。

＜＜画面の遷移について＞＞
・ステートマシン図に書いた画面からいく→に対応するものが、
　クラス図中のメソッドにあるはずです。

　クラス図上のメソッドは、イベント（ボタンクリック）に対応しているのでした。
　そのイベントによって、画面遷移などするのですから、
　ステートマシンの→に対応しているはずです。

　上図では、回答送信完了から出る→の「トップへ」に対応する
　クラス回答送信完了画面のメソッドがありません。
　これが、抜けていることになります

＜＜コントローラーについて＞＞

・コントローラー（アンケート回答管理）のメソッドが、
　ステートマシン図に書いた、画面から出る→に対応する
　（問い１の「次へ」に対応するのが、アンケート回答管理の「問１次へ」）

　ただし、逆はいえない
　ステートマシン図に書いた、画面からいく→に対応するものが、
　コントローラー（アンケート回答管理）のメソッドにあるとは限らない。

・ステートマシン図に書いた、画面からいく→にあって、
　コントローラー（アンケート回答管理）のメソッドにないものは、
　画面だけで処理するもの。

　具体的には、Javascriptで処理するもの
　例でいうと、「課題文表示」（課題文をみる）がそれに当たる
　サーバー側にアクセスせず、ブラウザで表示する。

＜＜画面のメソッドについて＞＞
・ステートマシン図に描いた→に対応しない、
　画面のクラスのメソッドは、初期表示用メソッド等

---

■そして

アンケート集計は、こんなかんじ

次回は、いよいよ、モデルについて

Ｃ＃でExcel－（４）グラフを描く－マクロとの関係

まえに

Ｃ＃でExcel－（３）グラフを描く－折れ線グラフなど
http://blog.goo.ne.jp/xmldtp/e/d1823ec4f1fb379b6297881ea9bc93e4

の最後のほうで、マクロをみると、参考になると書きました。
それについて

---

■何をどう設定すればいいかわからない→マクロで録音

　実際にグラフを作成するには、

chart.ChartType = Excel.XlChartType.xlLineMarkers;
chart.PlotBy = Excel.XlRowCol.xlColumns;

　とか書くのですが、この変数に何を設定すればいいか、
判らないとき、Ｅｘｃｅｌマクロを録音するといいときがあります。

---

■例：散布図

たとえば、以下の表

をこんな

散布図にしたいと思います
系列を行にして、タイトルとラベルをつけています。

---

■まずは、マクロを録音

を選択すると

なダイアログがでで、ＯＫをクリックすると、
マクロ録音開始！
そうしたら、散布図のグラフを作成


系列を行に

タイトルとラベルをつける

できたら、

録音終了

---

■マクロをみる

こんなかんじ

---

■マクロをもとに、修正

前回のソースの「折れ線グラフのチャート指定」を、
マクロをもとに、以下のように修正するとできます。

---

■注意点

・マクロそのものをコピーすればいいのではないです。
　今回の場合、ActiveChartがchartに変わっただけでなく、
　xlValue, xlPrimaryなどを、そのまま打つと、エラーになります。

　そこで、エラーの波線が出たら、ブラウザで検索します。
　すると、マイクロソフトのページに当たったりすると思います。
　今回は、

Chart.Axes メソッド
http://msdn.microsoft.com/ja-jp/library/microsoft.office.tools.excel.chart.axes(v=vs.80).aspx?cs-save-lang=1&cs-lang=csharp#code-snippet-1

がヒットし、その下に、サンプルコードがあるので、それを参考にしました。

・つまり、マクロはあくまでも参考で、あとはネットで調べたりしないといけない
　こともありますが、とっかかりを作ってくれます。

テストやエビデンスの妥当性を、見える化するツールとしてのD-Case（ＧＳＮ）

最近、D-Caseというのが、話題らしい。
研究会の参加が、２０名程度と思っていたのが、５０人以上集まって、会場に入りきれない・・・とか・・

　D-Caseは、具体的にいうと、品質保証をする際に使うもので、
　ある保証したい品質（ゴール）があるとき、その品質を保証するのに、妥当なエビデンスを持っているかを示すものらしい。図によって表現する。

　つまり、「こういうテストをして、こういうエビデンスがあるので、このゴールは達成されていることを保証できる」というように、テストやエビデンスの妥当性を、図によって見える化できる。

　こういうものは、ディペンダビリティ（信頼できることを示す指標、信頼性、可用性等を総合したもの）が高いシステムにおいて、求められる。

　ただ、私のわかっていないのは、D-Caseと、ＧＳＮ（Goal Structuring Notation）の関係。同じに見えるけど・・・
　D-CaseをＧＳＮで書くのか・・？うん、よくわかってないぞ？？

---

　もともとは、アシュアランス（保証）ケースというのがあって、
　そこでは、トゥールミンのモデルに基づいて、
　
　　ある保証したいことを主張(claim)するために、
　　うらずける証拠（evidence)をもってくる

　みたいなカタチで、保証をしていく（専門の人に言ったら、めちゃ怒られそうな説明。ホスティングサービスで、ロリポップを使っている人へ：ロリポおじさんが説明するＩＴ用語レベルの説明です　＾＾；）
　ただしくはISO/IEC 15026-2:2011に載っている・・・らしい。

　で、このアシュアランスケースを可視化する方法の１つとしてＧＳＮがある。
　Ｄ－Ｃａｓｅはこれとどう関係しているのか良くわかんないけど、ＧＳＮを作っているように見える（・・・本気でわかってない　＾＾；）

　そして、最近、このD-Caseを書く、エディタがあるらしい。


D-Case Editor
A Typed Assurance Case Editor
http://www.dependable-os.net/tech/D-CaseEditor/D-Case_Editor_J.html

　

---

　これにより、要求仕様に書かれている要求をゴールとして、このゴールを満たすために、このテストを行って、このエビデンスを得たとＧＳＮで図式化すれば、テスター以外の人にも妥当性が可視化できるというもので、今後、ディペンダブルなシステム以外でも、広く利用されるかもしれない。

”「いつやるの、今でしょ。」－なぜ、未然形に「。」がつく？”の謎が解けた！

あ～、気になる。
国語、あまり得意じゃないです。もの、知らないです。

だから、ついさっきまで、

「いつやるの、今でしょ。」


の最後、「でしょ。」って、「です」の未然形なのに、なぜ、。が付くのか、
気になってしょうがなかった。

mecabで確認！

いつやるの、今でしょ
いつ 名詞,代名詞,一般,*,*,*,いつ,イツ,イツ
やる 動詞,自立,*,*,五段・ラ行,基本形,やる,ヤル,ヤル
の 名詞,非自立,一般,*,*,*,の,ノ,ノ
、 記号,読点,*,*,*,*,、,、,、
今 名詞,副詞可能,*,*,*,*,今,イマ,イマ
でしょ 助動詞,*,*,*,特殊・デス,未然形,です,デショ,デショ
EOS

やっぱり、「でしょ」・・・未然形だ・・・

---

で、さっき、気が付いた！
でしょって、「でしょう」の「う」を省略した形？？

いつやるの、今でしょう。
いつ 名詞,代名詞,一般,*,*,*,いつ,イツ,イツ
やる 動詞,自立,*,*,五段・ラ行,基本形,やる,ヤル,ヤル
の 名詞,非自立,一般,*,*,*,の,ノ,ノ
、 記号,読点,*,*,*,*,、,、,、
今 名詞,副詞可能,*,*,*,*,今,イマ,イマ
でしょ 助動詞,*,*,*,特殊・デス,未然形,です,デショ,デショ
う 助動詞,*,*,*,不変化型,基本形,う,ウ,ウ
。 記号,句点,*,*,*,*,。,。,。

おお、「う」は、基本形になっている。
Wikipediaで調べると、助動詞「う」の終止形は、「う」で、然形の最後が「ろ」「ょ」で終わる助動詞に接続すると書いてある。

でしょは、「ょ」で終わる未然形だから、このかたち！

おお、これかあ・・・やっとわかった（＾＾；）ｖ

グーグルが提唱するZMOTのためのソーシャルマイニング

ビッグデータついでにもう一つ。

ビッグデータというと、Twitter,Facebookなどのソーシャルメディアの
テキストマイニング（ソーシャルマイニング？）が盛んな気がします。

それに華を添える言葉が、ＺＭＯＴですよね。

ＺＭＯＴについては、

「ZMOT」とは？絶対知っておきたい注目のマーケティング用語！
http://smmlab.aainc.co.jp/?p=14104

(以下太字は、上記サイトより引用）
がくわしい。以下、ＺＭＯＴの意味を引用。

2010年にGoogleが提唱した購買意思決定に関するマーケティングモデル。「Zero Moment of Truth」の頭文字を取ったもので、「ジーモット」と呼ばれる。

2004年、米P&G社は『来店したお客様は商品棚を見て、最初の3秒から7秒でどの商品を買うかを決めている。』という独自リサーチから、商品配置や陳列等が購入商品を選択する決定的な瞬間を左右する、「インストア」のマーケティングモデルをFMOT（First Moment of Truth）、「エフモット」と呼んだ。

しかし、インターネットの普及により多くの情報が簡単に入手できるようになったため、消費者は店に行く前の検索や、レビュー等のクチコミ、SNS上の友人からのレコメンドから既に購入商品を決定するようになった。ZMOTとは、こうしたオンライン上での情報収集によって、FMOTの前に実質的な購買意思決定の瞬間があるとした、「プレストア」マーケティングの概念。


つまり、いままでは、お店に来てからが勝負！
今は、お店に来る前が勝負！TwitterやFacebook,Lineでの評判が大事ということでしょうか・・・

こうなってくると、それらソーシャルメディアの分析が大事という論理展開になるんでしょうね。
ビッグデータの出番ですね。

Ｐ．Ｓ　なお、ＺＭＯＴのページは

こちら　http://www.zeromomentoftruth.com/

なので、ビッグデータと来るとベイズ？なのかしら・・

前に、アンスコムのことを書いたけど、
そんなこんなで、ビッグデータをやっている人は、因果関係を示すには、
ベイズを使いたがるのでしょうか・・・
（もちろん、共分散構造分析（ＳＥＭ）も使うけど）

最近のユニシス技報でも

ベイズ法を用いたノイズに頑健な高次元データの推定
http://www.unisys.co.jp/tec_info/tr115/11503.pdf

なんていうのが出ている。

マーケティング、ビッグデータ的には、ベイズの香りをさせないと、いけない時代なんでしょうかね（＾＾；）

---

　特に最近は、「ビッグデータ時代のマーケティング―ベイジアンモデリングの活用」という本が出て、著者の一人は、統計数理研究所長の樋口知之先生(最近、データサイエンティストについていろいろ発言している）なので、今後、ビッグデータなSIerさんに、もっともっと、ベイズ話が浸透しそう・・・（ちなみに、さっきの本、もう一人の著者は、筑波大大学院（東京キャンパスのほう）の佐藤先生）。

　もっとも、この辺の話題は、グラフィカルモデリングとして、近頃、いろいろ議論されているようですね。

　ただ、ビッグデータな人たちは、あんまり、グラフィカルモデリングの話って、取り上げてないような気がするんだけど、どうだろう・・・？？
　ベイズちゃん、グラフィックちゃんなどのめがねっ子萌えキャラができれば、一挙にいくかもしれません！！

ビッグデータを襲うアンスコム

ビッグデータを使って、何らかの予測を行おうとした場合、
予測しようとする値が、複数の要因（変数）がある場合、重回帰分析を使ったりする（ほかのモノ使うときもあるけど）。
このとき、予測式は、でるかもしれない。
では逆に、仮説を立て、いくつかの要因（変数）から、重回帰で予測式が得られるかというと・・・

　重回帰分析だと、多重共線性（multi collinearity：頭を取るとmulti co　マルチコ）があると、
うまく求まらない。
なので、変数間が独立していればいいが、因果関係があったりすると、強い相関が出るので、多重共線性により、うまくいかない。つまり、複雑な因果関係は、重回帰をつかってどうのこうのというのは、無理。

　複雑な因果関係があり、どのような関係で、値が決まってくるか、ある程度見える場合は、共分散構造分析を使う。これだと、因果関係のパス図を書けば、確かめられる（ただし、ＳＰＳＳ　ＡＭＯＳでは書きやすいが、Ｒでこれをやるのは、かなりたいへん）。ビッグデータを使って、何かを確かめたい場合、このような因果関係の複雑なメカニズムを知りたいことも多いだろうから、共分散構造分析は役立つ。

　しかし、共分散構造分析は、その名のとおり、共分散、相関を元に考えている。
　これは、線形の関係が成り立つときに成立する。
　線形の成り立たない２つのモノがあった場合、その相関、共分散は正しく出ない。
　ということは、共分散構造分析では、線形の関係が成り立たないと、分析が正しく出ない。
　(共分散構造分析だけでなく、重回帰でも、線形が成り立たないと、まずい）

　これは、「アンスコム」として知られる。具体的な例は、

　こちら　http://sun.econ.seikei.ac.jp/~inoue/HPtemp/temp3.htm

---

ということは、ビッグデータで何でも解析できるというわけではなく、
重回帰を使う場合は、制限がある（線形＆多重共線性がない）。
共分散構造分析も、線形でないといけない。
（ＳＶＭだと、カーネルトリックを使って線形でないものを取り扱える）

なので、「ビッグデータ使えば、なんでも解析、予測できちゃう！」と
いう考えに、アンスコムは冷や水を浴びせてしまう、それはそれは、まずい概念。
これが知られると、これからビッグデータで金儲けしようという人たちには、
困ったモンなわけだ。

でも、このアンスコムが書かれている本がこれ


アンスコム的な数値例で学ぶ統計的方法23講―異なるデータ構造から同じ解析結果が得られる謎を解く
http://www.amazon.co.jp/gp/product/4817194588


・・・うん、この題名では・・・
・・・ビッグデータは、安泰そうです（＾＾；）

因果関係がないのに相関関係があらわれるケース

がまとめられていたので、メモメモ

■[統計][リスク]因果関係がないのに相関関係があらわれる４つのケースをまとめてみたよ（質問テンプレート付き）
http://d.hatena.ne.jp/takehiko-i-hayashi/20130418/1366232166

（以下太字は、上記サイトより引用）


(1) 偶然によるケース
(2) 因果の流れが「逆」のケース
(3) 因果の上流側に共通の要因があるケース
(4) 因果の合流点において選抜／層別／調整されてしまっているケース


にまとめられるらしい。

D-Caseの超小型人工衛星への適用

ディペンダビリティを見える化する手法？ツールにD-Caseってのがある。
今日、第3回D-Case実証評価研究会のはじめのほうを、慶応の日吉で聞いてきたので、
そのメモメモ

の第三弾、
「D-Caseの超小型人工衛星への適用」

---

・発表内容
　３つの工夫のもとにD-Case作成
　記述結果、インタビュー

・適用事例
　東京大学次世代宇宙システム
　山火事検地
　現在試験フェーズ
　背景：信頼性とコスト
　　信頼性あるところを超えると、急激にコスト
　　D-Caseで情報可視化

・記述の流れ
　V-モデルに沿って
　目的：トレーサビリティ、
　　V-モデルの分解
　　　　分解する観点
　　各ゴールに対して、コンテキスト・えびでんす・モニタ
　　　　保証する観点
　　　　トレーサビリティの観点

・分解する観点
　　段階的に定義
　　抽象的な観点→具体的
　　　段階的にアシュアランスケースを記述
・保証する観点
　　　段階的にアシュアランスケースで保証
・トレーサビリティの観点
　　　情報がトレースできれいるか

記述結果

１Step
　５W1Hを定義→保証条件を定義
　保証する範囲を限定
　　サブシステム定義

２Step
　トップゴールを決める
　アシュアランスケース
　　機能の観点から分解
　　　　ゴール
　　　　最下層：ボトムゴール

３Step
　　記述結果を定義
　　保証する範囲を限定

レビュー結果
　記述結果が理解できるかどうかが大事

D-CaseとSysML／UMLの連携

・実証実験
・D-Case作成

D-CaseとSysML／UMLの連携の実証実験

・実証実験の適用対象としたシステムの概要
　SysMLを用いたシステム開発の事例紹介
　　　　ジェスチャする
　　　　　↓
　　　　Kinectを使って読み込み
　　　　　↓
　　　　PCで処理
　　　　　↓
　　　　ルンバの走り方が変わる

・開発プロセスと成果物
　　分析
　　システム開発
　　ソフト開発
　　製造
　　運用

・分析フェーズ
　　プロジェクトコンテキストの定義
　　　　成果物：プロジェクトコンテキスト
　　　　→D-Case：デモ用で十分
　　ステークホルダー分析
　　　　成果物：ステークホルダーリスト（ユースケース図）
　　　　→D-Case：トップゴールのコンテキスト
　　要求分析
　　　　成果物：要求図、要求テーブル
　　　　　　非機能要求安全性
　　　　→D-Case：ゴールを達成するために満たすべき要求や
　　　　　　　　　どの要求とリンクしているか
　　　　　　　　　ゴール～要求～ブロックのトレーサビリティ確保
　　システムコンテキスト定義
　　　　成果物：システムコンテキスト
　　　　→D-Caseトップゴールのコンテキスト

　　ユースケースの特定
　　　　成果物：SysML：ユースケース図
　　　　→

・システム設計フェーズ
　　ユースケース分析
　　　　成果物：ステートマシン図
　　　　　　　　アクティビティ図
　　　　→D-case：

　　システムアーキテクチャ設計
　　　　成果物：ブロック定義図
　　　　　　　　内部ブロック図
　　　　　　　　構造図
　　　　→D-case：要素を結びつけ？

・ソフトウェア設計フェーズ
　　構造設計
　　　　クラス図

　　振る舞い設計
　　　　ステートマシン図
　　　　→D-case：ゴールの構造と振る舞い？

・製造
　　成果物：部品、パーツ、ソースコード
　　　　→D-case：成果物と？

・検証・妥当性確認とD-Caseの連携
　　　　→D-case：検証・妥当性確認と？

・運用

考察
　D-CaseとSysML／UMLによるモデルベース開発の親和性は高い

・D-CaseとSysML/UML連携の構想
　　作成負荷
　　効果的な連携
　影響分析
　要求の立証カバレッジ分析　　　　
　参照容易性
　　表形式による表示　　　　
　モデルからの展開
　　モデル構造の展開

・実証実験
　　時間がかかった
　論点
　　記載する粒度および重複記載
　　機能充足性の立証
　　機能要求の立証の位置づけは？
　　　　→指針を示さば迷いなくなる
　　ディペンダビリティ属性の定義
　　公開されているサンプルが少ない
　　テンプレート

ディペンダビリティを見える化するD-Caseの話を聞いてきた

ディペンダビリティを見える化する手法？ツールにD-Caseってのがある。
今日、第3回D-Case実証評価研究会のはじめのほうを、慶応の日吉で聞いてきたので、
そのメモメモ

第一弾は、
「D-Case、DEOSへの期待 ～品質説明力の強化に向けて～」
　　IPA　SEC　田丸氏

---

・組み込みソフトウェア開発の課題
　１位：設計品質が２００６年～２０１２年までトップ
　それ以下は、景気によって変わる（新製品／経費削減）

・製品出荷後の不具合発生製品率の推移
　リーマンショック前
　　　４０数パーセントがないと答えた
　　　　　→品質改善された
　その後
　　　なしと答えた人半減
　　　　　→品質悪くなったまま、改善しない
　理由
　　　開発費削減→自分たちで開発して
　　　ベテラン技術者が定年、新入社員増えてきた

・製品出荷後に発生した不具合の原因
　　３分の１はソフトだが、
　　他製品との接続など、
　　　　マーケットに出て、使用環境における不具合
　　　　が増えてきた

・組み込みシステムの変遷
　　バブル前：
　　　　半導体中心（特注のLSI)：電子立国日本
　　バブル崩壊：
　　　　組み込み用マイコン
　　　　　価値の源泉がソフトウェアへ
　　９８年
　　　　OS、ミドルウェア（I-TRON)
　　ITバブル崩壊
　　　　プラットホーム化（BREW、Android）
　　リーマンショック
　　　　つながる時代？
　東芝とルネサスが半導体ベスト１０に残っている

　組み込みXクラウドXモバイル

・「組み込みXクラウドXモバイル」の役割分担
　　　機械系－組み込み系（センサー入力など）
　　　人間系－モバイル系（ヒューマンインターフェース／利用状況）
　　　クラウド系－非リアルタイム処理、データ管理
　システム全体の信頼性は？

・スマホで車を操作
　　車の信頼性とスマホの信頼性は違う

・組み込み、クラウド、モバイルの特性の違い
　　結構、違う（開発の方向性とか）
　　なんか、一工夫しないと、できそうにない

・統合システム関連の対応状況と課題認識
　　組み込み：統合か進む　４～６割
　　　　ビジネスモデル
　　　　全体品質の確保

・電気法品安全法技術基準体系等の見直し
　　「組み込みソフトウェアの安全性」が入ってくる
　　　（国際標準に書いてある）

・消費者教育推進法
　　事業者、事業者団体の努力義務

・消費者事故などの調査機関の設置
　　運輸は事故調査委員会を作ることが法律できまっている
　　消費者庁が設置するもの
　→いままで以上に企業がしっかり作ったということ

・組み込み、クラウド、モバイルの実現に向けて
　全体システムを重視したハザード・リスク分析
　　・ハザードリスク分析のスコープ
　　・ハザード・リスク分析の潜在リスク
　品質の見える化、見せる化
　　見える化、見せる化の対象
　　見える化、見せる化の技術
　　　トレーサビリティマネジメント
　　　アシュアランスケース
　　→D-Case：第三者が内容をみる

・関連する政府など（D-Caseのお客様？）
　ソフトウェア品質説明のための制度ガイドラインの策定
　自動車向け機能安全規格（２６２６２）のガイドラインの整備
　トレーサビリティ管理基盤の開発
　TERAS
　スマートシステム検証技術協会（SVA)
　モバイルIIOT
　利用者TIDAコンソーシアム

・制度ガイドラインの公開について
　　品質説明

---