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

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


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

今回は、「（１）作るべきもののユースケースを書く」について。

---

■ユースケースを書く

　システムを開発する際、コンピューター化したい部分があると思います
　（なければ、開発仕様と思わないはず）。

　その、コンピューター化したい部分を書きます。
　その部分をユースケースとしてあげて、ユースケース（楕円）に関係するヒト（入力データを入れるヒト、出力を受け取るヒト）を、アクター(人型）としてあげて、ユースケースとアクターをつなぎます。

　アクターは、ヒトと書きましたが、他システムの場合もあります。
　ユースケースは、コンピューター化したい部分＝コンピューターが、することになりますので、動詞で書くのがいいのでしょうが、名詞で書いてくる人もいます。

　ま、以下のような感じです。

---

■ユースケースを先に書くことも

　はじめにユースケースを書く、というのがお作法なのかもしれませんが、実際、ユースケースが多くなると、漏れが出たり、複雑になりすぎたりします。

　そこで、ユースケースレベルで、アクティビティ図を書いてしまう場合もあります。
　本来、アクティビティ図は、ユースケース図を詳細化した、ユースケースシナリオレベルで書くのが、正しいお作法なのでしょうが、それよりも、もっと大きな、ユースケースレベルで書いたほうが、全体像が見やすく、漏れが少なくなる場合があります＊。

＊漏れが少なくなる理由：アクティビティ図は、時系列的に考えます。なので、作業を順々に考えていき、飛び越すと、気づくことが多いです。一方、ユースケースは、ただひたすら挙げていくだけ（順番関係なし）なので、挙げ忘れることも、あります。

　ユースケースレベルでアクティビティを書くと、こんなかんじ。



　とくに、まず、現状を分析して(as-is)、本来こうあるべき(to-be)というのを考え、システム化する場合、まず、

　　・現状のアクティビティ図を描き、
　　・そこから、この機能は、コンピューター化すべきというアクティビティを選び
　　・コンピューター化する部分をユースケースでまとめる

などという場合は、ユースケースレベルのアクティビティから入ることもある。

---

次回は、ユースケースシナリオ

11月23日(火)のつぶやき

13:21 from web
東京UHFコンテストに出ると、こんなに、アマチュア無線やってる人って、多かったっけ？と思う。４３０MHｚのFMだと。。。
by xmldtp on Twitter

11月22日(月)のつぶやき

23:33 from web
あとで見る「ブラック企業偏差値ランキング」 http://oskweb.com/blackList.html
by xmldtp on Twitter

GREEも上場企業なんだから、これやっちゃ、やばいよな・・・

ここの痛いニュース

GREEで配信中の「ラブプラス」風のギャルゲー、イラストのトレース発覚
http://blog.livedoor.jp/dqnplus/archives/1568954.html

重ねると、ばっちり一致しますね・・・
これは、まずいよな・・・

astah*を使って、ICONIX風一気通貫システム開発 その１：概要

　いままで、開発のはじめから終わりまでを、何回か書いてきた。
　でも、１つのツールを出来るだけ使って、その操作法を書きながら、一気通貫させる方法は、書いてない。

　そこで、astah*を使って、開発の要求仕様から、プログラム作成までを、トレーサビリティを保って、どのように開発するかを書いてみたいと思う。

　まずは、概要。

　こんな手順になる

（１）astah*の「ユースケース図」を使って、作るべきもののユースケースを書く
　　　（場合によっては、「アクティビティ図」を先に書くことも）

（２）ユースケースシナリオを書く


（３）（ロバストネス分析）
　　　ユースケース図の１ユースケースを１コントロールとし、
　　　コントロールに付随するバウンダリを１個用意して、
　　　ユースケースシナリオにもとづき、エンティティを作成し、
　　　さらに、ユースケースシナリオの内容に基づきメッセージを
　　　コミュニケーション図に記述する

（４）astah*において、バウンダリ、コントロール、エンティティはクラスになっている。
　　　そこで、コントロールの処理を考えながら、必要な入出力を考え、
　　　バウンダリ（画面）、エンティティ（テーブル等）の属性を埋めていく
　　　→コントロールが肥大化している場合、コントロールクラスを、いくつかに分割してもよい

（５）バウンダリの項目を元に、画面構成を考える。
　　　各画面を１クラスとし、画面入出力項目を決め、
　　　画面遷移を考える。
　　　画面遷移(図）は、１画面１状態として、ステートマシン図で記述する

（６）(必要があれば）エンティティを正規化して、ER図にする

（７）フレームワークを決定する

（８）フレームワークに応じて、（５）で作成した画面クラスを、
　　　ソースコードに書き直す

（９）フレームワークや利用するDBに応じて、（６）のエンティティ
　　　(クラスまたはER図）をDBのテーブルと、DAOに書き直す

（１０）フレームワークによって、こういうコントローラーにしろ！という
　　　指定があるので、（３）ないし（４）で作成したコントローラーを、
　　　フレームワークに合うように書き直す

ユースケース駆動のところ、ロバストネス分析をしているところが、ICONIX風。
ただし、その後、ちょっと違うので、ICONIXでなく、ICONIX風とした。

次回から、上記についての説明を書いていきたいと思う。

並列処理を検証する、CSP関連のまとめ

　並列処理関係の検証をするとき、CSPで記述して、確認するけど、その一連＆関係するもののまとめ

---

■CSPで検証する手順

１．CSPで、関係を記述する
　　→状態遷移図なんかを応用して記述できる

２．記述したCSPをType Checkerで確認する
　　→文法ミスを確認してくれる。FDRに直接かけると、エラーだらけの場合、よくわからない

３．FDR2にかける
　　　３－１．まず、読み込ます
　　　３－２．デッドロックフリーとか、詳細化関係(同じかどうか）のチェック
　　　３－３．もし、問題あれば、デバッガでトレース確認
　　　３－４．ちなみに、計算とかもさせられる（Evaluate機能）

４．状態遷移を詳細に見たいのであれば、状態遷移導出ツールProBEが使える

５．Javaでシミュレーションさせたいとなると、JCSPを使う。

---

■CSPと、そのほかのモノとの関係

CSPで記述してFDRで調べる方法も、モデル検査の１つ。
モデル検査としては、他に、SPIN、SMV、UPPAAL、LTSAなどがある。

まず、このちがいについて。

SPIN、SMVとCSPの大きな違いは、前者が、時相論理を使うこと。
時相論理で表現できないような性格のものは、SPIN,SMVでは扱えない。
一方、CSPは、モデルはCSPで記述する（詳細化関係を調べるが、それもCSP）。
時相論理がかけないヒトも（かけないコトも）チェックできる。

LTSAは、FSPという記述言語で状況を記述する。このFSPは、CSPに似ている。
で、LTSAは、LTSっていう図にしてくれるんだけど、あれは、図を楽しむものなの？？
→よくわかってない・・

UPPAALは、そもそも時間概念が扱えるので、かなり違う。

---

■JCSPとJPFについて

　JCSPは、並行システムのシュミレーションをするけど、同じく並行システムを調べるものとして、
JPF（Java PathFinder）がある。

　この違いについて。

　JCSPは、CSP表現したものをJavaでシミュレートしやすくしたもの。
　なので、楽しむことは出来ても、エラーについては、実機確認の域を出ない。

　一方、JPFは、ある程度のケースについて（深さは自分で設定仕様と思えばできるけど、普通デフォルトで使うよな）自動的に検証してくれる。

　たとえば、哲学者の食事問題の戦略について調べようとする。

　CSPで記述し、FDRにかければ、デッドロックするかどうかはわかる。
　このCSP記述を元に、JCSPを記述した場合、対応関係を持ちながら記述することは出来るが、
　楽しめるだけで、必ずしもデッドロックするかどうかはわからない。

　一方、哲学者の食事問題をJavaで記述し（CSPの記述と離れてしまってもよい）
　JPFで検証した場合、ある程度のケースを(場合わけして）検証して、
　デッドロックをちゃんと検出する。

EventBの書き方について

前に、ツールの話は書いたので、今回は、書き方について。

Event-Bは、Bとちがって、２つの部分に分かれる。
MachineとContext（別々のファイルになる）

Contextは、おもにSet（集合）の内容を記述する。記述項目は、こんなかんじ

CONTEXT
EXTENDS
SETS
CONSTANTS
AXIOMS

一方、MACHINEは、Contextを取り込んで、実際にいろんな記述をしていく。項目内容はこんな感じ
MACHINE
(REFINES)
SEES
VARIABLES
INVARIENTS
THEOREMS
EVENT
(VARIANT)
END

このうち、REFINESとVARIANTはリファインメント（あるEvent-B記述をさらに詳細化したもの）で使用します。
SEESで、参照するCONTEXTを指定する。

ってことで、以下、CONTEXTから。

---

■CONTEXTの内容について

CONTEXTは、以下のことを書く。
CONTEXT
EXTENDS
SETS
CONSTANTS
AXIOMS

　つまり、集合と定数という、型とか、固定的な値（変数のように、インスタンスでないもの。クラス定義するようなもの）を宣言する。
　以下、それぞれについてみていく。

●CONTEXT
　CONTEXT　コンテキスト名
　コンテキストの名前を指定する
　
●SETS
　SETS
　　　集合名１;
　　　　：
　　　集合名N

　集合を宣言していく。

●CONSTANTS
　CONSTANTS
　　　定数名１;
　　　　：
　　　定数名N
　定数を「宣言」していく。

●AXIOMS
AXIOMS
ラベル１: 定数１：型１

　ここで、定数の型を指定する。
　型は、NAT1など、あらかじめあるものか、上記SETSで指定したもの

(例）
CONTEXT SampleContext1
SETS
MYSET
CONSTATNTS
val1
AXIOMS
　　axm1 : val1 : MYSET
END

---

■MACHINEの内容について

　実際の記述は、MACHINEでやる。Bとちがい、リファインメントしたものでもなんでも
MACHINE。MACHINEには、以下の内容を書く。

MACHINE
(REFINES)
SEES
VARIABLES
INVARIENTS
THEOREMS
EVENT
(VARIANT)
END

以下、こんなかんじ。
●MACHINE
　MACHINE マシン名

　マシン名を適当に決めて書く

●SEES
　SEES
　　コンテキスト名

　利用するコンテキストを指定する

●VARIABLES
　VARIABLES
　　変数名

　利用する変数を宣言する

●INVARIANTS
　INVARIANTS
　　ラベル名：変数：不変条件
　変数の不変条件をかく。つまり、変数が満たすべき制約を書く。
　ということは、変数の型とか、範囲とか、変数間の関係とか。
　条件をいくつか書くと、条件間のANDとなる
　（ORは条件内にORと書く）

●EVENTS
　イベントをかく。
　はじめに、INITIALIZATIONがあるので、そこに初期化条件を書く。
　BEGINのあとに、
　　　ラベル名：式
　の形。代入は：＝

　INITIALIZATIONを書いたら、つぎから、書きたいイベント（処理）をかく。
　処理自体は、BEGINの中に、同じように書く。

●VARIANT
　変わっていく変数(負のすうにはならない）で、どんどん減少していくもの
　停止性を証明するためには、必要

---

こんなかんじかな。一部しか書いてないけど・・・
まちがってたら、ごめん。

Event-Bのツールのインストールと使い方

　形式仕様記述には、Bメソッドというのがある。これは、どちらかというと、下流よりだが、もっと、上流工程までもサポートしたものとして、Event-Bがある。今日は、そのEvent-Bのお話。

---

■Event-Bのインストール

今回は、Rodin-Platformというのを使う。

（１）まずは、Event-Bのページにアクセス
　　　　http://www.event-b.org/

（２）左側に、Rodin Platformというのがある。それをクリック

（３）まんなからへん（表のInstallationとかかれた桁のなか）に

　　Download the Core: Rodin Platform file for your

　とかかれている。ここのCore以降をクリックすると、ダウンロードページに飛ぶ

（４）Download　Nowとかかれたところをクリックして、ダウンロード

（５）ダウンロードが終わったら解凍

（６）解凍したものの中を見ると、rodin.exeというのがあるから、それをダブルクリックすると
　　　立ち上がる。
　　　　→Eclipseのプラグインってことです。

つぎに、こいつがAtrlierBを使うみたいなので、それをインストールする
はじめに出てくる画面（きたないピンク色の画面。出てこなかった場合、
Help→Welcomeで表示できる）の下のほう（Important Installation notes）
に書いてあるんだけど、

（７）Help → Install New Software....
　　　で、インストール画面を出して

（８）出てきた画面の一番下、
Contact all update sites during install to find required software
のチェックをはずす

（９）一番上、WorkWithのプルダウンのリストを開いて、

Atlier B Provers　・・・（URLが書いてある）・・・

を選択。

（１０）下のリストに、Atlier　Bが出てくるので、
　　それを、チェックしてNext

（１１）あとは、普通のプラグインインストールと同じ

---

■Event-B、コンポーネントの作成

　インストールが終わり、Welcome画面を修了させると、こんなふうに、プロジェクトの画面になる
　右上をクリックして、わざと、全部のパースペクティブがわかるようにしている。
　　Event-B
　　Prove
　　Resource
　の３つのパースペクティブがある。


　この状態で、まずは、作成してみる。

　メニューバーから
　File→New→Event-B　Projectを選択
　出てきたダイアログで、プロジェクト名を適当に入れる。

　プロジェクトが出来たら、コンポーネントをつくる。
　下のように、プロジェクトを右クリック、

　New→Event-Bコンポーネントを選択する。

　出てきたダイアログで、コンポーネント名を入れる（changeMeのところ）
　なお、Event-Bは、Bと違い、Machineのほかに、Contextというのも使う。
　(使わないときもある）。今回は、Machineにする

---

■コンポーネントの編集

そうすると、以下のような画面になる。

このツールは、あらかじめ、こんなふうに大枠が出来ていて、
記入したいところの左側三角形をクリックし、＋の丸囲みを
クリックして、書き込んでいく
（－をクリックすると、その行削除）

そうすると、こんな感じになる

---

■証明

で、証明するには、「Proving」のパースペクティブにして、
チェックマークをクリックする

うまくいくと、チェックになって、そこをクリックすると、
したに、緑のひげくんがでる

だめだと、？になって、そこをクリックすると、
したに、あかいがっかりくんがでる。

---

ツールの使い方は、ここまで

ソフトシステムズ方法論（SSM)

　ソフト・システムズ方法論やソフト戦略思考に書かれている、ソフトシステムズ方法論について、メモメモ。

ちなみに、ここ
ソフトシステム方法論「SSM」とはなんだ（1）
http://www.atmarkit.co.jp/farc/rensai/ssm01/ssm01.html
にも説明がある。

---

■SSMとは

　認識の違いを理解した上で、考え方を修正していく（そして、アコモデートできる落としどことをみつける）方法論

　認識の違いを理解するために、意図的活動モデルを使う
　認識から変革への学習サイクルを循環させる（そうして考え方を修正していくんだね）

---

■SSMのステージモデル（７ステップ）

　はじめに、こんなふうにかんがえたようだ（リンク先もこれが載ってる）

　　　現実世界　　　　　　　　　　　　　　　　システム思考

１、問題状況がある
　　　↓
２．問題状況を表現する　　　→
　　　　　　　　　　　　　　　　　　３、関連する意図的活動システムの基本定義
　　　　　　　　　　　　　　　　　　　　　↓
　　　　　　　　　　　　　　　　　　４、基本定義に名づけられた概念的活動モデル
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　←
５、モデルと現実世界の比較
　　　↓
６、変革（システム的に望ましく、文化的に実行可能）
　　　↓
７、行為（問題状況を改善するための）

---

■もっといいアプローチ

　上記の方法より、こっちのほうがいいよと、チェックランドさんがいっている。

○文化的探索　　　　　　　　　　　　　　　　　　　　○論理的探索
                       現実世界の問題状況
　　　　　　　　　　　　↓　　　　　　↓
　　＜文化としての状況理解＞　　　　　課題・論点
　・介入の分析　　　　　　　　　　　　　　　↓
　　　社会システム分析　　　　　⇔　　関連システム→活動モデル→状況☆
　　　政治システム分析　　　　　　　　　　　↓
　　　　　　↓　　　　　　　　　　　　モデルと現実世界の差異★
　　　　　　　　　　　　　　　　　　　　　　　↓
　　　　　　　　変革：システム的に望ましく、文化的に実行可能
　　　　　　　　　　　　　　↓
　　　　　　　　行為（問題状況を改善するための）

以下、こっちの方法論の、論理的探索、文化的探索のやり方を書きます。
（リンク先は、前者の７ステージに基づいたやり方が書いてあります）

---

■論理的探索の方法

　上記の右側の手順。以下の４段階。１～３が☆に該当、４が★に該当

１．関連システムの選択
　　　２つの関連システムがある
　　　　　基本課業型システム：現実社会に対応
　　　　　論点主体型システム：概念化されたもので、実社会に存在しなくてもOK
　　　→メタファーを使うといいらしいよ・・・まじ？？


２．関連システムの名前付け
　　　名前をつける→基本定義をする
　　　　＊基本定義は入力→変換→アウトプットのプロセスとして表現するみたい。

３．関連システムのモデル化
　　　・基本定義を、CATWOE分析、XYZ分析して、さらに詳細化していく。
　　　　その手順は、以下のとおり

　　３－１．CATWOE（「きゃとふー」でいいの？）分析を考慮して基本定義を記述
　　　　CATWOE分析（以下を決める）
　　　　　・顧客（C)
　　　　　・行為者（A)
　　　　　・変換プロセス（T)
　　　　　・世界観（W)→変換プロセスは、なぜ必要か
　　　　　・所有者（O)→やめさせることができる人と考える
　　　　　・環境制約（E)

　　３－２．XYZ分析によって、主活動を定義する
　　　　　Zを達成するために
　　　　　Yによって
　　　　　Xを行う

　　３－３．関連する他の活動を洗い出す

　　３－４．まとめて、サブシステムに（活動群により）

　　３－５．判定基準を定義＆（サブシステムに）追加する
　　　　　３つの基準がある
　　　　　　　・可動性：ほんとにアウトプットを生産できる？
　　　　　　　・効率性
　　　　　　　・有効性：目標にあっている？

　　３－６．モニターして、コントロールを（サブシステムに）追加する
　　　　　　モニター：監視して
　　　　　　コントロール：制御する

４．モデルと現実世界との比較
　　異なった利害間でアコモデートできる落としどことをみつけるために、比較する。
　　比較方法は、以下のようなものがある。
　　　　・インフォーマルな議論
　　　　・公的な質問
　　　　・モデルを動かし、シナリオを記述
　　　　・現実世界のモデル化

---

■文化的探索の方法

　上記の左側の手順。以下の４段階

１．文化としての状況の理解
　　　リッチピクチャーを書く
　　　　　・状況を伝える
　　　　　・関係性は対処療法的なものは挙げない
　　　　　・文章による説明（凝縮した表現）

２．介入の分析
　　役割分析：以下の３つの役割を特定
　　　　　・依頼者（クライアント）
　　　　　・問題解決者
　　　　　・問題所有者

３．社会システムの分析
　　社会システム＝継続的に変化する、以下の３要素の相互作用
　　　　　・役割
　　　　　・規範
　　　　　・価値

４．政治システムの分析
　　異なる意見がアコモデーションにたどり着くまでのプロセス
　　　→最終的には、「権力の配分」

---

ってかんじならしい。聞き間違い、勘違いがあるかも。あったらごめん。

アスペクトの書き方

昨日、アスペクト指向のAspectJの話を書いた。
そこで、元のソースはいいとして、横断的関心事として記述する、アスペクトの内容について。

---

■手順

　手順は、以下の３ステップで考えるといいかも

（１）今回、どの箇所に割り込ませるかを、ジョインポイント（割り込み可能箇所）から選ぶ

　　　ジョインポイントは、こんなかんじ。

　　　　　・クラスの
　　　　　　　　→staticの初期化：staticinitialization
　　　　　　　↓
　　　　　・コンストラクタの
　　　　　　　　→呼び出し:call
　　　　　　　　→実行：execution
　　　　　　　↓
　　　　　・インスタンスの
　　　　　　　　→事前初期化？：preinitialization
　　　　　　　　→初期化：initialization
　　　　　　　↓
　　　　　・メソッドの
　　　　　　　　→呼び出し：call
　　　　　　　　→実行：execution
　　　　　　　↓
　　　　　・フィールドの
　　　　　　　　→参照：get
　　　　　　　　→代入：set
　　　　　・例外
　　　　　　　　→実行：handler
　　　　　・アドバイス
　　　　　　　　→実行：adviceexecution

　　各クラスやメソッド等の上記位置の割り込ませたいところを選ぶ　　　　　
　　　　　　　　

（２）上記（１）の箇所を、条件などをつけて、記述する（＝ポイントカット記述）
　　　昨日の例、execution(public String Sample.hello(..));
　　　のように、選んだジョインポイントのあとに（）で条件をつける。
　　　条件には、* .. + ! && || などが使える。
　　　また、アドバイスで変数を使えるように、ポイントカット変数を置くこともある。


（３）上記（２）の箇所で行う処理（＝アドバイス）を記述する。
　　　ポイントカットの前に入れるか、後に入れるかの指定
　　　　　（before,after,例外を投げたときafter throwing、
　　　　　　スタブとして実行する＝ジョインポイントの処理をしないaround）
　　　をしたあと、ポイントカットをかいて、そのあと、処理内容を書く。

　　　アドバイスの外部の変数を利用するには、上記ポイントカット変数を使うか、
　　　thisJoinPointという、特殊な変数を使う。

---

■書き方

ポイントカットの書き方に２つあり、１つは昨日例のように、ポイントカットに名前をつけ、

pointcut helloCut():execution(public String Sample.hello(..));

あとで、その名前（ここではhelloCut()）を利用して、ポイントカットを指定する方法、
before() : helloCut()

と、直接ポイントカットを書いてしまう方法

before() : execution(public String Sample.hello(..))

がある。

前者の例でいくと、昨日書いたように、

public aspect アスペクトの名前 {

　pointcut ポイントカット名():ジョインポイント(条件(ポイントカット変数とか）);
　　　　　　：
　　　ポイントカット続く
　　　　　　：


　beforeとかafterとか() : ポイントカット名()
｛

　　　　　アドバイスの処理
　｝
　　　　　　：
　　　　　アドバイスつづく
　　　　　　：
}

となる。

EclipseのAspectJ、AJDTの使い方

アスペクト指向でJavaをやる、AspectJをEclipseでやるプラグイン
AJDTについて、インストールと、使い方

---

■インストール(Eclipseのバージョン3.4の場合）

Eclipseのメニューバーの「ヘルプ｝（help）→
「InstallSoftware」とか、「ソフトウエア更新」を選択すると、

ダイアログが出てくるので、「サイトの追加」、
新しく出てきたダイアログで、

http://archive.eclipse.org/tools/ajdt/34/update

を指定すると、Aspect-Jのやつが、元のダイアログに出てくるので、チェックして、
「インストール」
ライセンスのレビューで、「使用条件の条項に同意します」
で、ひたすらインストールするのを待つ（５５％くらいがとっても長く、そのあと一気にくる）

なお、Eclipseのバージョンが違う場合は、違うのを入れることになる。

---

■Aspect-Jの使い方（プロジェクトを作る）

「ファイル」→「新規」→「プロジェクト」
で出てくるダイアログから、「AspectJ」の（それしかなかったら、＋ボタンをクリックして、広げて）
「AspectJ　Project」をクリック。

次のダイアログでプロジェクト名を入れる。

そんなかんじで、とにかく、最後まで行き、プロジェクトをつくるとき、以下のダイアログがでるかも。

そしたら、「いいえ」をクリックして、とりあえず無視。

---

■Aspect-Jの使い方（元ソースを作る）

ふつうに、そのプロジェクトに、クラスを追加し、以下のようにクラスを作成する

public class Sample {

	public static void main(String[] args)
	{
		Sample s = new Sample();
		System.out.println(s.hello());
	}
	
	public String hello()
	{
		return "HelloAspectJ";
	}
}

これを、ふつーに実行すると、当然、"HelloAspectJ"と表示される。

---

■Aspect-Jの使い方（アスペクト）

そうしたら、パッケージエクスプローラー（左側）で、プロジェクトを選択し、
右クリックで出てくるポップアップダイアログから
「新規」→「その他」を選択、
出てくるダイアログで、「AspectJ」→「Aspect」を選択。
次へをクリックすると、アスペクトのダイアログが出るから、そこに、以下のようにアスペクトを書く

public aspect SampleAspect {
	pointcut helloCut():execution(public String Sample.hello(..));
	
	before() : helloCut()
	{
		System.out.println("Hey!!");
	}
}

---

■Aspect-Jの使い方（実行）

ここで、パッケージエクスプローラー（左側）で、プロジェクトを選択し、
右クリックで出てくるポップアップダイアログから
「実行」→「AspectJ/Java　Application」を選択すると、

アスペクトがウィーブされて、

Hey!!
HelloAspectJ

（Hey!!が前にはいってる）

と表示される。

11月15日(月)のつぶやき

10:50 from web
クラウドは幻滅期に入ったとみていい？先週やってたクラウドコンピューティングExpo２０１０、幕張メッセの中でも辺鄙な９ホール（のみ）、データセンター中心の展示だったし・・・
10:50 from web
「クラウドコンピューティングExpo２０１０（クラウドジャパン秋）」というより、「データセンターと愉快な仲間たち展２０１０（日本におけるクラウドの秋）」という感じだったぞ。
14:05 from web
最近、ネットワークカメラに興味津々・・・といっても、盗撮とかじゃないですよ（＾＾；）
by xmldtp on Twitter

Uppaalの使い方

Uppaal（http://www.uppaal.com/）の使い方を忘れそうなので、メモメモ

---

■編集

（１）立ち上げる
　　→Templateという名前のテンプレートが開く

（２）左側のナビゲーションツリーのDeclarations（日本語化してある場合「宣言」）をクリック
　　→右側の描画ペインが大域情報編集ペインにかわる

（３）大域情報を大域情報編集ペインに記入する
　　　大域クロック変数
　　　大域変数
　　　大域通信チャネル

（４）左側のナビゲーションペインで、「Template」をクリック
　　→描画ペインが表示される

（５）テンプレートの「名前」を変えて、テンプレート名をいれ、
　　　右にパラメータを設定する

（６）ナビゲーション側にある（５）で書き換えた名前をクリック、
　　　すると、下にDeclarations（日本語化してある場合「宣言」）が
　　　でてくるので、それをクリック
　　　→編集画面になるので、局所変数などを宣言する

（７）ナビゲーション側にある（５）で書き換えた名前をクリック
　　　描画ペインに戻るので、ロケーション（上の○に下に星？のやつ）を
　　　クリックして、ロケーションを置く（描画ペインでクリックすると置ける）

（８）続けて、→をクリック、ロケーションの始点をクリックして、終点をクリック
　　　すると、エッジが引ける

（９）太い→で選択できる。それをクリック後、ロケーション（○）をダブルクリックすると
　　　ロケーション編集というダイアログが出る。
　　　ここで、名前や不変条件、初期、アージェント、コミットの指定ができる

（１０）太い→で選択できる。それをクリック後、エッジ（→）をダブルクリックすると、
　　　エッジの編集というダイアログが出る。
　　　そこで、ガードに繊維可能条件、同期に同期通信イベント、更新に変数の更新（代入）を設定する

（１１）全部のロケーションとエッジを書いたら、ナビゲーションペインから「システム宣言」を
　　　クリック、プロセス割り当て編集を行う

　　　P1＝P(1)　のように、プロセス＝テンプレート（引数）を何個か書き、
　　　最後に
　　　System P1,P2,　　のように、System　プロセス,・・・という具合に書く

---

■シュミレーション

（１２）上記で編集が終わったので、シュミレーションを行う。
　シュミレータータブをクリックする。

（１３）左上が、実行可能なものを表示するので、そこを適当にクリックすると、
　　　　右上のオートマトンの状態や、右下のシーケンス図が動く

---

■検証
（１４）べりファイアタブをクリックする
（１５）検証式を「クエリ」に入れると（２番目のボックス）、「概要」（１番目のボックス）に入ってくる
（１６）追加ボタンをクリックすると、次のの検証式を入れられる。
（１６）検査したい検証式をクリックして、一番上の「検査」ボタンをクリックすると、一番下のボックスに結果がでる
（１７）反例トレースを出す場合は、検証のメニューで
　　　　　オプション→診断トレース→いくらか
　　　　を選択して「検査」、その後、「はい」をクリックして、シミュレーションタブをクリックして
　　　　シュミレーションを表示させると、判例とレースが見れる。

Android端末に、MeGooやUbuntu等を載せて、デュアルブートする話

Japan Linux Conference 2010の「MeeGoのAndroidプラットフォームへの移植」で聞いてきたお話。

---

●Android端末の特徴

メモリフラッシュ部分が

　misc
　recovery
　boot
　system
　cache
　userdata

のように分かれていて、recoveryとbootそれぞれに、カーネルイメージ、カーネルパラメータ、initrdが組み込まれている。このinitrdをルートファイルシステムとして利用し、/proc,/dev/,/systemなどをマウントしていく。

---

●移植方法
　したがって、カーネルをどうロードさせるか？ということと、ルートファイルをどこに置くかという問題がある。

・カーネルのロード方法
（１）Boot領域上書き
（２）PC経由からカーネル転送、ロード：fastbootコマンドで、zImageを転送
（３）recovery領域を上書き、リカバリーモードで起動

・ルートファイルシステムの場所
（１）System領域上書き
（２）userdata領域上書き
（３）SDカード（PC上でルートファイルシステムを作る）

---

●Nexus　OneでMeeGoを動かす

　カーネルのロード方法は（２）、ルートファイルシステムの場所は（３）を選択

手順１：MeeGoルートファイルシステムの作成
　　KickStartファイルの作成
　　mic2実行
　　ddでmicroSDにコピー

手順２：カーネルの作成
　　MSM（Qualcomm’s Mobile Station Modem）向けを入手
　　カーネルコンフィグレーションにmahimahi_defconfigを使用
　　　　initrdを使わない、xorgは使う
　　コンパイル

手順３：fastbootでカーネル転送、ロード

---

●その他

Wiki（http://wiki.meego.com/ARM/MSMQSD）に詳しいやり方あり。

---

ちなみに、表題のデュアルブートは、
カーネルのロード方法は（３）、ルートファイルシステムの場所は（３）を選択
すると、

普通に立ち上げると、Android、リカバリーモードだと、新規に入れたOSになる。
（デュアルブート）。
カーネルをUbuntuにすれば、Ubuntuが立ち上がる・・・はず？？

日にちがたっているし、この分野については、まったくのど素人なので、間違ったことかいてたらごめん。

11月14日(日)のつぶやき

15:37 from web
尖閣にこじつけ過ぎだろ（＾＾；）「教えてシェリーちゃん!!!　なぜYouTubeは始まったの？」 http://www.youtube.com/watch?v=ZoYrWL38R_M
by xmldtp on Twitter