アスペクト指向の愉快な利用方法とか

アスペクト指向のこの前のつづき

---

■ポイントカットの応用（この前の続き）
・within　～　call－－
　～から呼び出される－－

・フィールドにアクセスされたときに、ポイントカット
　　get
　　set

■アスペクト指向の愉快な利用方法：

・モックとして使う
　aroundアドバイスは、そのまま帰ってくるので、ダミーモジュールに使うところを、
　aroundアドバイスに変えてしまえば、本体に対して修正などしないで、
　aroundアドバイスを作るだけで、テストができる。

・静的な解析declare errorで、ポイントカットを使って、コンパイルエラーを出す

■さらにすごいこと：存在しないメソッドを後から追加できる
　　インタータイプ宣言：修正せずにメソッド、コンストラクタ、フィールドを追加できる
　　declare句による宣言：修正せずに継承関係を変更できる
　　　　→ただし、変更した結果、実装すべきメソッドがない等の矛盾が生じてはいけない
　　　　→実行順番を指定したい場合は、優先順位の指定をする
　　　　　　→declear precedence
　　特権アスペクト：privileged：privateでも勝手に見えてしまう。

■アノテーションとしても書ける
　また、アノテーションをポイントカットにできる。


■アスペクトの問題点
・テストはどうなるの？
・アスペクト指向の設計方法は？
　　　→表記、手順は？

■他の言語のアスペクト指向
・aspectC http://research.msrg.utoronto.ca/ACC
・aspectC++ http://www.aspectc.org/

SEMATについての感想

　昨日、SEA　Forumに行ってきて、SEMATについて平鍋氏のお話を聞いてきたことは、
　昨日のブログに書いた。
　今日は、その感想。

　正直なところ、SEMATは、何をどこまで作って、どれが、日本の私たちに、どれくらい影響があるのか、よくわからなかった。実は、ここが一番知りたいところなのだが・・・

　つまり、SEAMATは、(以下斜体は、昨日も引用した、平鍋さんのブログ「SEMAT.org にて「ソフトウェア工学再建」運動が開始」から引用）


確かな理論と、証明された原則(principles)とベストプラクティス(best practices)の上にソフトウェア工学を再構築(refound)したい、そのプロセスを支援したい。


っていうと、根本原理からどんどん発展させて、現在のソフトウエア工学を、体系化して見せてくれるような気がしてしまう。

　根本原理から、現在のソフトウエア工学を体系化すると、
・チャーチ＝チューリングのテーゼから、まず、原始帰納的関数を出してきて、
・それから、スパゲティプログラム（N）は、Whileプログラムに書き換えられるよ！
・プロセスやデータを複合していき、オブジェクトという概念を出してきて、
・ソフトウエアの正しさを説明して（部分完全性と停止性）：ここじゃないかも？
・それから、コンポーネントを説明して、パターンに行き
・フレームワークにきて
・開発方法論になって
・マネージメントになる？？
てなかんじなのかしら・・・

だけど、なんかそういうことをするんじゃなくって、議論の土台となる、「共通のものさし」を作るみたいだ。そういう風に聞こえた。

　体系化なら、実務上、それを仕事に当てはめていけるから便利なんだけど、ものさしを作られても、直接日本には、インパクトないかも？たとえば、日本においては、ISO27001より、ISMSのほうが、なじみ深いように、世界的にものさしを作っても、まずJIS化しないと・・・

---

　ただ、その後の議論では・・・
　うーん、日本の学会や、偉い人たちの間では、ちょっと、いや、とっても、体系化は難しいかな？という気がした。

　たとえば、「どうして、OCLなんだ！VDMのほうがずっといい」みたいな意見が出たけど、
　そもそも、OCLとVDMは、形式仕様だけど、適用範囲がちがう。

　OCLを使うときは、クラスを再利用したり、関連をチェックしたいような場合に、
　定義するもので、だから、不変条件と、陰仕様しかかけない。
　　メソッドの内部の記述は出来ない。
　　だから、OCLの場合は、テストデータのイメージとして、これで合っているかどうか
　とかの確認が主になる。

　一方VDMは、自分の考えたやり方で合っているかどうかを確かめたいときに使う。
　陽仕様で書けるので、自分の処理方法をそのまま書ける。
　一方VDM++であっても、インターフェースとか、（あれ、パッケージもなかった？）
　クラス関係の表現力は弱い。弱くっても、単に考えを確認する程度なので、ま、これでいい

　実際、VDMで検証するより、直接、Javaで書いてしまったほうがいい
　という考えもある。これが、アジャイルになる。
　VDMで検証しても、Javaに直すときにバグが入る可能性があるから、
　それなら、直接コードを書き
　　　事前条件は、エラーチェックで
　　　自分の考えはメソッド内に
　　　事後条件は、JUnitのアサーションで
　　　不変条件は、JUnitで処理前と処理後にアサーションで
　確認するというものだ（さらに、JMLで形式仕様を書いてもいいけど）

　ただ、上記のアジャイルは、開発言語が決まっている場合に有効ではあるが、言語が複数あったり、決まっていない場合は、Javaでやっていいの？ということになるから、すぐに確かめられるVDMがいいかもしれない。


　現場的には、このように、形式仕様を持ち出すとしても

　　OCL　VDM　アジャイル＋JML

　と、ちょっと考えただけでもあるし、さらに、話題になっていた、自動車などで、厳密に定義をするんなら、上記のものではだめで、（停止性を保障したいときがある。この場合、バリアント条件がかけないといけない）、EventBやBを使うことになる。

　問題は、現場的には、
　　　・このうち、どれを使えばいいの？
　　　・どーやって適用するの？

というのが、体系的に判りたいわけで、望んでいるのは、まさにこれなわけだ。
だけど、そーいう、どの場合にどう、という話にならずに、どっちがいい論争になり、まさに、ファッション化してましたねえ・・・

---

　あ、そーいう意味では、ステートチャート（ステートマシン）図の話も、気がめいるものだった。。。

　イベントドリブンの場合ステートチャート図を描くのが当たり前であり、フィリピンの人はすぐに思いつくのに、日本のエンジニアは、まったく通じず、総当たりテストしているという発言だ。

　それに対し、平鍋さんが、「いや、必ずしもそうじゃないし、状態爆発しちゃうことがあるでしょ」と正しいツッコミをいれても、まだ無視して、その話を・・・

　うーん・・・これが、日本の上層部の実態なのねえ・・

　まず、イベントドリブンの場合、ステートチャートを書くのは一般的かもしれないが、ステートチャートは、

　　・並行動作が見えにくい→ここで、場合が抜ける可能性がある
　　・ステートチャート図を描いたとしても、網羅性は保障されない

　そこで、前者において、とくに、メッセージが介在しているときなどは、シーケンス図で全体を捕らえる。で、イベントドリブンでも、シーケンス図で理解できてしまう場合もある。このようなときは、わざわざ、ステートチャート図をおこさない。
　→シーケンス図からステートチャート(ステートマシン）図を読み替えられるので

　また、後者で記述したように、ステートマシン図を書いたとしても、線１本抜けてても、ちょっと気づきにくいときがある。なので、ステートチャートで書いても、網羅してるかどうかまではわからない。これが、状態遷移「表」なら、まだマトリックスにするのでありなんだけど、状態爆発の可能性がある。っていうか、ステートをまともにあつかったら、爆発する。
　そこで、SPINやSMVといった、モデル検査にもっていくことになる。

　ただ、あんまりにも大きいものは、細かな部分を隠してしまって、フレームワーク化してしまう。
　フレームワーク化されると、１イベント分しかかかないので、次のイベント処理しかかけない。
　そうなると、ステートチャートを描いても（１イベント分なので）意味がなくなってしまう。
　フレームワークにおいて、イベントが隠れているかどうかを見るには、CSP（プロセス代数）とか使って、詳細化関係を確認すればいいけど、その場合、ステートチャート図より、構造図のほうが、CSP化しやすい。

　ってことで、日本の場合、

・フレームワークのアーキをしている人は少なく、フレームワークから呼び出される
　一部イベント部分を書いている人は、１イベントのステートマシン図を書いても意味
　ないから、書かない→ステートマシンを書かなくても、仕事になる

・どっちかというと、シーケンス図を描いたら、もう、大づかみにコーディングに
　入ってしまう。

ので、必ずしも、ステートマシン図が必要なのではなく、どのような開発の場合は必須で、どのようなときは、イベントドリブンでも、ステートマシン図を必ずしも必要としていないかの体系わけができないといけない。
　で、現場的には、その体系図のほうが、ほしい。

　なんだけど、永遠と、日本だめだめ説なのだ（フィリピンの人は、たぶん、開発経験が少ないので、教条的に、イベントドリブンと来たら、ステートマシンと答えたのだろう）。

　そもそも、総当りで全てテストしている会社としか、お付き合いがないようだと、あんまりいい会社とは付き合ってないんじゃないかなあ？今、直行表くらい、知ってるだろ・・・仕分けされそうな情報処理試験でも出てくるくらいだから・・・

---

　ってことで、仮に体系化されても、日本の上層に受け入れられにくいかもねえ・・

　むしろ、日本でだれかが体系化して、たとえば、astah*で作ったUMLから、その場に合ったシュミレーションや、検証ができるようになったほうが、インパクトでかい気がする。

　ま、そのうち、この体系は書くだろうから、意外と、SEMATより、このブログのほうが影響力強くなるかも？？（なわきゃーないか・・・）

事業仕分けで情報処理技術者試験はどうなる？

ここのスラッシュドットの記事
事業仕分けで情報処理技術者試験はどうなる？
http://slashdot.jp/it/10/11/29/086243.shtml

民営化が有力なようですが、民営化したら、たぶん、受けないな・・・
民間資格だったら、CCNAとかオラクルマスターのほうが、いいわけでしょ。

価格をあげたら、お金持ちしか受験できなくなる。
たとえば、民間資格のように、１回の試験に３万円したら、
会社受験でない場合以外、受けなくなる・・・

そーすると、技術者を図る標準がなくなる。

受益者は業界というより、転職する場合の転職者だから、雇用にも差し支えてくるわけで
（ほかの民間資格は、とても高い上、維持費もかかるので、貧乏人は受けられない）

それに、実務経験がなくても試験慣れしているから受かるのが、問題なら、

　　無線技士・通信士関連の国家試験なんか、めちゃくちゃ問題になるよな
　　（過去問が、結構そのまま出るため、過去問対策すると、受かる）
　　司法試験とかも、問題じゃないですかね・・・（受験生は、実務してないはず）

このまま行くと、国立大学の入試とかも、「手書きは古い」ってことで、センター試験で統一
（大学院の博士課程入試も、コンピューター試験　＾＾；）
センター試験も、民営化できるので、河合塾とか代ゼミが実施するんでしょうかね・・・


・・・ところで、事業仕分けって、めちゃくちゃ無駄だと思うんだけど、
　事業仕分けは、仕分けしないの？

　あ、選挙のときに、仕分け人をことごとく、落とせばいい、それで、仕分けしてるってこと？

astah*の平鍋氏が語るSEMATについて

　SEA　Forumに出席してきた。今回は、astah*のチェンジビジョンの平鍋氏が語るSEMAT。
　ちなみに、SEMATについては、平鍋氏が、ブログに書いている。

SEMAT.org にて「ソフトウェア工学再建」運動が開始
http://blogs.itmedia.co.jp/hiranabe/2010/02/sematorg-2a87.html

　ということが、あらかじめ、SEA　Forumの申し込みメールに記載されている。
　（なお、以下斜体は、上記サイトより引用）

日時：１１月２９日　１８：３０～２０：３０
場所：文京区民センター　３ーB会議室

内容

・Call For Actionについて


今日のソフトウェア工学は未成熟なプラクティス(immature practices)によって重大に阻害されて(gravely hampered)いる。

言葉の流行が多く、工学というよりファッション業界のようだ。
広く受け入れられ、確立された、理論的基礎がない。
方法論が乱立している。
産業界と学会のギャップが大きい。


・Vision　Statementについて
　→章建ての説明

Purposes and scope(目的と範囲)
The vision(ビジョン)
The kernel(カーネル)
The goals(ゴール)
The principles(原則)
One-year milestones(1年のマイルストン)


・signatories(署名している人たち)について
　→一人ひとり、みていきました。

・The　Semat　Diamondについて
　ここの図

・その他
　　学会と産業界
　　現在の状況
　　　　ユニバーサル：７つの単語→２３２のプラクティス
　　　　カーネルランゲージ：１４のユースケース
　　　　セオリー：論理・代数的なものと、エンピリカル的なものにわかれる

・SEMAT批判について

・質疑応答

---

これについて感想は、また今度書く。長くなるから・・・

「光の道」って、ほんとにいいの？スマホのレスポンスよくするほうが、良くね？

　「光の道」って、話題ですよね。
　ここ
光の道
http://www.otsuka-shokai.co.jp/words/hikari-no-michi.html
によると、光の道をやるために必要なことは２つ

（１）離島、山間部にも、ブロードバンドを！
（２）今、利用していない人をブロードバンドに！

　（１）は、お金をかければ可能。まあ、そもそも、ブロードバンドなら光ファイバでなくても、WIMAXでもいい気もする。まあ、お金の問題だから、やる気なら、政府が支援すればいい。

　でもね、（２）の問題、つまり、「ブロードバンドでなくても、困んないんだけど・・・」という人がいっぱいいて、ブロードバンドに、みんな、しない・・・ってのが、今の問題なわけ。

　うん。たしかにこまんない。うち、YahooのADSL　８メガだけど、なんにも、困んない。
　ゲームとか、動画を盛んに見る人でなければ、困んないんじゃないかなあ？

　みんな、困んないから、移行しないなら、（１）で一生懸命お金かけて引いても、まったくの無駄ってことに・・・

---

　そもそも、光の道は、結局、固定のお話ですよね。

　でも、今って、ケータイやスマホの方が、重要なわけで、
　そっちのレスポンスをあげるほうが、先なんじゃないかなあ・・・

　つまり、光の道をやるより、iPhoneの
ホリエモンの苦言にソフトバンク孫社長が返答「私の命をかけて必ずドコモを超える」
http://getnews.jp/archives/86117
の問題や、ドコモのXperiaもふくめ、スマートフォンの速度向上に力を入れるほうが、いいんじゃないかなあ・・・
　そっちのほうが、効果的なお金の使い方だと思う。

　スマホの速度を上げるには、もう、たぶん、今のケータイ周波数や技術ではいっぱいいっぱいだろうから、もっと、上の周波数（3.4～3.6GHz）を使い、LTE Advanced(4G)を検討すべきだし、そーいうことにお金をかけるべきだと思う。

　スマホでも、データカードでも、LTE Advancedばっちり！というのなら、パソコンにデータカードつければ、光の道と同じことが出来るわけだから・・・

　そっちのほうが、波及効果も大きいし、意義あると思うんだけど、
　なんで、そーいうことを議論せずに、光の道にこだわるんだろう。

　２０１５年ごろじゃあ、たぶん、光ファイバやWIMAXも時代遅れで、
　時代はLTE Advanced＆WiMAX2(4G)になるよねえ・・

尖閣ビデオはだめでも、これはOKなの？「＜テロ資料流出＞公安情報出版」

ここのニュース
＜テロ資料流出＞公安情報出版　個人情報削除せず
http://headlines.yahoo.co.jp/hl?a=20101127-00000024-mai-soci

えー（＠＿＠！）
尖閣ビデオとちがって、これこそ、秘密に管理してるもんだから、
秘匿性は高いわけで、それを流出しちゃったら、
それこそ、公務員の守秘義務違反とかで、問題になるんじゃないの？・・・

と思ったら
(以下斜体は上記サイトより引用）

　警視庁はデータについて、「調査中」として内部資料とは認めていない。第三書館の北川明社長は「警察が内部資料と認めていない以上、出版する権利はある。


そっか、本物と認めてしまうと、秘密がばれちゃうから、認められない。
でも、本物でないのなら、それは、秘密にしておく必要はない。
秘密じゃないなら、出版してもいい？？

うーん、なんか変だけど、なんか論理が通ってる気もする・・・
うーん？？？

11月26日(金)のつぶやき

12:05 from web
小日本＝こにぽん 「萌えキャラ『日本鬼子』に続き『小日本』が決定　日本人が萌えちゃってどうするの？」 http://getnews.jp/archives/86263
12:09 from web
あとでみる 「日本鬼子のイメージソングができた！　早速“歌ってみた”まで」 http://getnews.jp/archives/85359
12:30 from web
「ナイナイ岡村が復帰、すでに収録に参加」なんだって http://news.livedoor.com/article/detail/5165538/
by xmldtp on Twitter

情報セキュリティ国際評価基準(Common Criteria)

　今日のお勉強は、世界的な、セキュリティ評価規準CC、ISO/IEC15408（JIS化(JISX5070)は、追いついていない）について。

　CCは、３つのパートと、評価手法（CEM：せむ）にわかれてる。
　　Part1：概念と一般化モデル
　　Part2：セキュリティ機能要件
　　Part3：セキュリティ保証要件

　　共通評価手法（CEM)

---

■Part1:概念と一般化モデル

ここでは、４つのことが述べられている
　・一般モデル
　・コモンクライテリアの要件と評価結果
　・プロテクションプロファイルの仕様
　・セキュリティターゲットの仕様

　この中で大事なのが、「セキュリティターゲットの仕様」。
　こんな感じでまとめる。
個人情報処理システムアプリケーションST
https://www.ipa.go.jp/security/jisec/jisec_system_st.html

　これを作るのに、プロテクションプロファイルを使ったりする。

　プロテクションプロファイルの例は、
こんなかんじ
http://www.ipa.go.jp/security/jisec/certified_pps/pp_list.html

---

■Part2：セキュリティ機能要件
　以下の１１クラスに分類されたセキュリティ機能要件のカタログ
　１１個には、相互に依存性があり、それが明記されている
　拡張も可能

＜＜１１個の要件＞＞
　　　・セキュリティ監査（FAU)
　　　・通信（FCO)
　　　・暗号サポート（FCS)
　　　・利用者データ保護（FDP)
　　　・識別と認証（FIA)
　　　・セキュリティ管理（FMT)
　　　・プライバシー（FPR)
　　　・TOEセキュリティ機能の保護（FPT)
　　　・資源利用（FRU)
　　　・TOEアクセス（FTA)
　　　・高信頼パス・チャネル（FTP)

※TOE：Target of Evaluation：評価対象（＝対象となる製品、情報システム）
※機能クラスはFで始まる３文字の英字で示す。

---

■Part3：セキュリティ保証要件

　開発者のアクション、評価者のアクションが書かれている
　どんなエビデンスを残すかが書かれている。
　それらアクションを、どれだけ確認したかの保証をEALで行う（１～７まで）
　　　→EAL3以上でないと、開発中にセキュアにやっていることが保証できない
　　　　　：あとからドキュメントつけたしができる
　保証要件は、８クラスに分類できる

＜＜８クラス＞＞
　　　・プロテクションプロファイル評価（APE)
　　　・セキュリティターゲット評価（ASE)
　　　・開発（ADV)
　　　・テスト（ATE)
　　　・ガイダンス文書（AGD)　→　マニュアルのこと
　　　・ライフサイクルサポート（ALC)　→　構成管理＋欠陥修正など
　　　・脆弱性（AVA)
　　　・統合（ACO)
　　　
※保証クラスは、Aで始まる３文字
※８つのクラスに対し、それぞれに対して、EALのレベルに応じて、なにをすべきかという話がある。
※Part3にはこのほかに、統合保証パッケージ（CAP)、付属書の話がある。

---

■全体像：開発ライフサイクル

・計画・設計
　　セキュリティターゲット（ST)を決める★←STの雛形のPP利用
　　　　　セキュリティ目標
　　　　　機能要件、要約仕様
　　　　　保証要件、保証手段

・開発・検査
　　　各種ドキュメント、エビデンス


・搬送／設置


★セキュリティターゲットの決め方
　ST概論：TOEを特定
　適合主張：保証レベル、適合状況を特定
　　　↓
　セキュリティ課題定義
　　　　連携
　　　　組織のセキュリティ上申
　　　　運用環境の前提条件
　　　↓
　セキュリティ対策方針
　　　　TOEへのセキュリティ対策
　　　　運用環境のセキュリティ対策
　　　↓
　セキュリティ要件
　　　　機能要件（SFR)
　　　　保証要件（SAR)
　　　↓
　TOE要約仕様
　　　　TOEがどのように、SFRを満たすかの要約仕様

---

■具体的な進め方

３者間の話

評価申請者：評価してもらう側
評価機関　：評価を実施し、問題あれば所見を出す。
　　　　　　それに対し、評価申請者が対応、
　　　　　　最終的に評価報告書を作成し、
　　　　　　認証機関に認証依頼する
認証機関　：IPA
　　　　　　認証報告書作成し、認証する
　　　　　　認証登録、認証書・認証マークを発行

★評価申請者からみると、どういうフェーズになるの？

（１）意思決定

（２）申請準備

（３）証拠準備

（４）評価対応

（５）認証

-------------------１回での対応はここまで

（６）保証維持

（７）機能・保証拡張


参考になりそうなサイト？

はじめての認証
http://www.ipa.go.jp/security/jisec/application/application_1.html

新人に、OSIの７層を１時間で教える羽目になり・・・

　教えた内容の原稿

---

■むかしむかし、パソコンが２台ありました。
　２つのパソコンをむすびたい。
　　　Aのパソコンの入力→Bのパソコンの出力
　　　Bのパソコンの入力→Aのパソコンの出力

　にすると、Aのパソコンの入力はBのパソコンに出力され、
　Bのパソコンの入力はAに出力され、相互に通信できました。

　めでたしめでたし・・・

---

■じゃあ、世界中のパソコンを結ぶには？

　世界中のパソコンの入力と出力を・・・→むり
　そもそも、世界中のパソコンの環境が違う

　そこで！
　異なる環境でも、世界中のパソコンがつながるように、きまりをつくった
　→その１つが、OSIの７階層モデル

---

■OSI７階層モデル

　パソコンで動くアプリケーションで、通信を考える場合、２種類の話がある。

（A)あるパソコンから、世界中のパソコンに、データをおくりたーい！
（B)パソコンに送られてきたデータを、あるアプリケーションにとどけたーい！

（A)の話は、
　　　（１）まず、世界というまえに、通信線に信号が乗らないと、話にならんでしょ
　　　（２）世界というまえに、ご近所さんに知られないとまずいでしょ
　　　（３）その上で、世界との通信だったりする・・・

（B)の話は
　　　（４）Aで届いた信号を、アプリ(が使ってるポート）に届ける
　　　（５）アプリで利用開始、終了を宣言する（オープンクローズ）
　　　（６）アプリで使えるように、コード変換、構造変換する
　　　（７）で、実際にアプリにつかう

というように、細かく分けられる。これらを、

　　　（１）物理層
　　　（２）データリンク層
　　　（３）ネットワーク層
　　　（４）トランスポート層
　　　（５）セッション層
　　　（６）プレゼンテーション層
　　　（７）アプリケーション層

とわけて、それぞれの決まりをきめたのが、OSIの７階層モデル。

---

■事例研究

　最近のインターネット構成で考える。

（１）物理層
　　ツイステッドペア（より対線）ケーブルが多く使われる。１０BASE-T
　　なーんて言うと、「光の道」を推進しているヒトから、怒られる？
　　電気的には、マンチェスタ符号化を使う
　　昔は、リピーターというのがあった

（２）データリンク
　イーサネットが中心（イーサネットは、本当は物理まで含んだ広い範囲だけど、
　まあ、データリンク層といってよい・・）
　複数ポート接続するために、スイッチを使う
　昔は、ブリッジというのがあった

（３）ネットワーク層
　IP（インターネットプロトコル）を使う。IPアドレスを使って、世界中に振り分ける。
　ルーターによって、世界中に信号を振り分ける
　複数ポートのルーター機能を持ったものが、L3スイッチである

（４）トランスポート層
　TCPを利用したものが多いけど、一部UDP

（５）セッション層
　バークレーSocketが中心

（６）プレゼンテーション層
　いろいろ、コード変換とか

（７）アプリケーション層
　ｆｔｐとか、メールとか、いろんなアプリがある

astah*を使って、ICONIX風一気通貫システム開発 その４：ロバストネス分析

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

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

前回、（２）をやったので、今回は、「（３）ロバストネス分析」について。

---

■ロバストネス分析とは

　ロバストネス分析の説明は、ここにあるとおり。
　つまり、MVCみたいに、システムを

　　バウンダリ：ユーザーとの入出力
　　コントロール：バウンダリとエンティティをつなぎ処理する
　　エンティティ：保存すべきデータを管理しておく

の３つにわけます。

　このバウンダリ、コントロール、エンティティは、３つの層と考えられ、
　　・同じ層の間
　　・お隣さんとの層の間
　とは、やりとりできますが、
　　・間を離れた層の間
　では、やりとり「できません」

　つまり、バウンダリから、エンティティには、アクセス「できません」

　これを、コミュニケーション図という形にまとめるのが、バウンダリ分析です。かんたんにいっちゃうと・・・

---

■本日のミッション

　したがって、今日やるべき、ミッションは、前に書いたユースケース

　とユースケースシナリオをもとに、バウンダリ分析をして、

　なコミュニケーション図を作ることです（上記例は受注のみ）。

---

■作り方

（１）ユースケース図は、コンピューターに「処理させたいこと」を書いているはずです。
　　　ってことは、これは、処理＝コントロールになります。
　　　ってことで、各ユースケースを「～処理」という形にして、
　　　迷わずコントロールにしましょう。


　　　例：ユースケース：受注する→受注処理(コントロール）


（２）ユースケースシナリオを見てください。それに、画面入力・画面出力はありますか？
　　　あれば、「～画面」として、バウンダリを書きましょう（～はユースケース名）
　　　帳票も出力するのであれば、帳票のバウンダリも作ります。
　　　
　　　例：ユースケース：受注する→受注画面（バウンダリ）

（３）引き続き、ユースケースシナリオを見てください。

　　　画面から入力されたもの＋保存されているデータを元に、
　　　何らかの処理をして、
　　　画面、帳票、保存すべきデータに出力

　　　しているはずです。このとき、保存されている、すべきデータがエンティティとなります。
　　　エンティティはたいてい名詞ですが、名詞が全てではなく、
　　　ひとつひとつが区別して、管理できるものです。

　　　なにかと、一緒になっていているようなものは、属性です
　（「なにか」が、エンティティかも？）

　　　ってことで、ユースケースシナリオの名詞に着目し、
　　　　　・保存すべきデータで
　　　　　・ひとつひとつ区別でき、管理すべきもの
　　　をエンティティとしてあげて、記述します

　　　なお、処理をしたり、保存しなくてよいデータを作成している場合、
　　　それはコントロールです
　　　　　他のユースケース名でなく（コントロールになることなく）、
　　　　　重要で、かつ独立したものは、コントロールとして挙げておいていいです。
　　　　　→挙げなくてもいいです。当コントロールクラスのメソッドにしますから・・・


（４）今書いた、コントロール、バウンダリ、エンティティに線を引きます。
　　　バウンダリ　－　コントロール　－　エンティティ１
　　　　　　　　　　　　　　　　　　－　エンティティ２
　　　　　　　　　　　　　　　　　　　　　：

　　　のような感じで、線が引かれると思います。


（５）メッセージを記入します。
　　　ユースケースシナリオが、ここに書くことを意識している場合は、
　　　たぶん、ユースケース１つ１つをぺたぺた貼ればいい感じだと思います
　　　（Enterprise Architectのシナリオなどの場合）

こんでできあがり。

---

　受注画面とか、めちゃくちゃ大雑把！と思うかもしれないけど、
とりあえず、これでいい。次回、詳しく書きます。

11月25日(木)のつぶやき

12:52 from web
「広告価格つり上げ、関係者指摘　グーグル、ヤフー提携」だって http://www.asahi.com/digital/internet/TKY201011250166.html
21:12 from web
VDMやBの不変条件がZの公理なのかしら？
by xmldtp on Twitter

Z その１

今日は、形式仕様のZ
Z/Eves（ぜっといーぶす）証明器を使ってやる話です。
Zは、公理的集合論に基づいている。

---

■基本的な書き方

スキーマを組み合わせて、システムができる。
→スキーマが記述単位＝仕様記述の単位

仕様記述の単位
　公理
　状態スキーマ
　操作スキーマ

---

■具体的な、スキーマの書き方

スキーマ名-------------------------------
| 状態変数：型
||変数？型　　　　　　　　　　　？は入力を示す
----------------------------------
|　事後状態’＝　事前状態＋・・・・　　状態の操作
----------------------------------

みたいな感じで書く。
ちなみに、　変数！　で出力

例

Hello-----------
|a:Z　　　　　　　　　Zは整数
|b:N　　　　　　　　　Nは自然数
-----------------
｜a' = a+b aにbをたしたものを、a'とする
-----------------

---

■Δ

スキーマをもってきて、りようすることができる。
上のHelloを使いたい場合

world------------------
|ΔHello;c:N
-----------------------
｜c'=a'+b+c
-----------------------

ΔHelloとやると、Helloで定義した、a,b,やa',b'が使える

---

■Ξ（ぐざい）

変化しないことを示す。
world------------------
|ΞHello;c:N
-----------------------
｜c'=a'+b+c
-----------------------
値を参照しかしないときなど・・・

---

■Z/EVES

メイン画面から、Editボタンをクリック。

NewParagraphを選ぶ→入力画面がでてくる

・「Box　Drawing」を使って、箱の線を描く

・箱の中の文字をキーボードから入力する

・入力したら、「File」ボタンをクリック、Doneをクリックすると、
　元のダイアログに入力される

・Commandのcheck all paragraphを選択すると、チェックしてくれる
　→左側に、YとかNとか出る。

・エラーがあるとき、そこをクリックして、右ボタン
　→Show　errorsでエラー表示

・メイン画面File→saveでセーブできる

---

とりあえず、ここまで

astah*を使って、ICONIX風一気通貫システム開発 その３：ユースケースシナリオ

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

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

前回、（１）をやったので、今回は、「（２）ユースケースシナリオを書く」について。

---

■ユースケースシナリオを書く

　ユースケース図を描いたら、各ユースケースに対して、処理概要とか、処理内容等、ユースケースシナリオと呼ばれるものを書きます。

　astah*の場合、（コミュニティ版ではなく、お金を払った）UML版、プロフェッショナル版などだと、ユースケースを右クリックして、ポップアップメニューを出すと、ユースケース記述（シナリオ）が書けるメニューがでてくるので、それを選ぶと、表示されます。

　なお、Enterprise Architectだと、シナリオとして、ユースケースシナリオが書けるけど、かわりに、アクティビティ図で書くこともある。

　ユースケースシナリオとして、書く内容は、

ユースケース記述
http://www.atmarkit.co.jp/aig/04biz/usecasedescription.html

　に書いてある。だいたい、こんなことを書く

・ユースケース名
・基本系列・代替系列
・事前条件・事後条件

以下、くわしくみていく。

---

■基本系列・代替系列

　基本系列は、正常系の処理を書くことになる
　代替系列は、正常系ではないものを書くんだけど、このとき、例外がある場合と、ない場合がある。ない場合は、例外も混ぜて書いていい。

　たとえば、

・ログインすると表示される
・アカウントがない場合は、アカウント作成
・ログイン名とパスワードが間違っていたら、エラー表示

の場合、基本系列と代替系列、例外とある場合は、

基本系列
　　・ログインすると表示される
代替系列
　　・アカウントがない場合は、アカウント作成
例外
　　・ログイン名とパスワードが間違っていたら、エラー表示

となり、例外がない場合は、
　
基本系列
　　・ログインすると表示される
代替系列
　　・アカウントがない場合は、アカウント作成
　　・ログイン名とパスワードが間違っていたら、エラー表示

または、
　
基本系列
　　・ログインすると表示される
　　・アカウントがない場合は、アカウント作成
代替系列
　　・ログイン名とパスワードが間違っていたら、エラー表示

ってなかんじなのかしら・・・
（どっちになるかは、書き手とか、会社の考えなのかしら？）

基本系列は、箇条書きで番号を振っていき、その番号に対応する形つまり、

　　基本形列番号－枝番

で、代替系列を書くと、あとの工程（ロバストネス分析）で楽になる

---

■事前条件・事後条件

　事前条件、事後条件は、検証で言う事前・事後条件と、ちと違う場合がある（同じ意味に使う人もいる）

　ユースケースシナリオなど、UML関係で言う場合は、

ユースケースを実行する前の状態

（上記斜体は、上記サイトより引用）

だが、検証をやっている人にとっては、事前条件とは、

不変条件を満たすため、その処理を行う前に、満たさなければならない「条件」だ。

ちなみに、不変条件とは、常に満たさなければならない性質ということになる。
ここで言う性質とは、値の範囲や、クラス間の関係などをさす。

---

■検証で言う事前条件と、UML関係でいう事前条件の違いの例

「象を冷蔵庫に入れる」というユースケースを考える。

●UML関係だと、冷蔵庫に入れる前の「状態」を書くのだから、事前条件は、

・象を捕まえておくこと

になる。

この場合、象さえ捕まえれば、冷蔵庫には、「入れられる」

●一方、検証の世界でいう事前条件を考える。

冷蔵庫には、入れられる容量というものがある。
これ以上入れようとしても、入れなれない。これは、常に成り立つので、不変条件。

・不変条件：
　　０＜＝冷蔵庫に入っているもの　＜＝　冷蔵庫の収納容量

象を冷蔵庫に入れる場合、不変条件を満たすために

入れようとしているものの容量
　　＋現在の冷蔵庫に入っているもの　＜＝　冷蔵庫の収納容量

とならなくては成らない。これが、事前条件。
したがって、冷蔵庫が冷凍倉庫のように、大きいものなら入るけど、
家庭用の冷蔵庫の場合、収納容量がそんなにないので、

この場合、象を捕まえても、冷蔵庫には、「入らない」
　　→事前条件違反

---

■事前条件・事後条件と、実装との関係

　したがって、検証における事前条件は、
　　　実装時、処理開始前に行う、エラーチェック項目

　となり、検証における事後条件は、
　　　実装時、JUnitなどのアサーションで確認すべき、テスト項目

　となる。


　一方、UML関係の事前条件は、
　　　処理の前後関係を示す程度である。

　事後条件は、
　　　テスト項目にしてもいいかもしれない。

　DbC（契約による設計）の場合は、どっちかというと、検証よりにしないとまずいか？
　ま、どっちよりに書くかは、会社や書き手、上司のセンスなどによって、異なる。
　ただ、検証よりのほうが、実装のとき、こまらないね。

---

こんなかんじかしらね・・・
次回は、ロバストネス分析

11月24日(水)のつぶやき

16:33 from web
あとでよむ：Amazonクラウドに対応したオープンソース動画配信プラットフォーム「Kaltura 3.0」リリース http://sourceforge.jp/magazine/10/11/22/0344242
by xmldtp on Twitter

KJ法

今日は、KJ法

---

■KJ法の手順

以下の手順
　　１．紙片作り

　　２．グループ編成
　　 ２－１．グループ化
　　 ２－２．表札作り
　　 ２－３．空間展開（一段展開）
　　 ２－４．空間展開（二段展開）
　　 ２－５．空間展開（輪どり：わどり）
　　 ２－６．空間配置

　　３．A型図解

　　４．B型文章化

---

■１．紙片作り

　発言を紙に書く。
　１つのことを、１枚に書く
　多くのことを盛り込みすぎない

---

■２．グループ編成

２－１）似ているものを集めていき、グループ化する
　離れ猿：グルーピングするとき、無理に入れなくてもいい。
　　　　　１枚だけ残しておく（離れ猿）でもいい

・悪い例
　表面的類似性であつめてはいけない
　　→同じ言葉を使っている

　既成概念で集めない

　物語を作るように集めてはいけない

２－２）表札作り
　グループに表札（タイトル）をつける。
　さらにおおきなグループにわけて、それにも表札をつける

２－３）空間展開（一段展開）
　類似しているものを近くに置く

２－４）空間展開（二段展開）
　はらわた出し

２－５）空間展開（輪どり）
　ステレオタイプを考えるらしい？？
　とにかく、グループを輪で囲むんだよ。

２－６）空間配置
　輪どりしたグループをさらに大きく、グループ化する
　

---

■３．A型図解

　２－６の空間配置を、決まった図形で、関係を書いていく

---

■４．B型文章化
　３でまとめた図を文章にする