VDMのお勉強－その６ VDMを書こう！ VDM-SL版概略

超久々に、シリーズ「VDMのお勉強」。

前回は、overtureを使って、VDM－SLの骨格を出力させた。
こんな感じ

module HelloVDM
exports all
definitions 

	state StateName of
 
-- TODO Define state here
	end 

	types 
-- TODO Define types here
	values 
-- TODO Define values here
	functions 
-- TODO Define functions here
	operations 
-- TODO Define operations here
end HelloVDM

今回は、書く中身について、概略。

---

■とにかく、サンプルコード
名前を入力したら、
　”Hello ”＋名前＋”!!"
と出力する処理、Helloを定義すると、こんなかんじ

module HelloVDM
exports all
definitions 

types 
--	ここに、レコードの型とか書くけど、今回は使わない

values 
state StateName of
-- 	ここに、状態として、
-- state HelloVDM管理 of 
-- 	変数 : 型という形で書いていくけど、今回は使わない

-- 	不変条件
--		inv mk_HelloModule管理(変数１,変数２・・・) == 
-- 		以降、不変条件を並べるけど、今回は使わない
--	初期化
--		init HelloVDMデータ == HelloVDMデータ
--                   = mk_HelloVDM管理(変数１の初期値,変数２の初期値・・・)
--	という形で書いていくけど、今回は使わないので書かない
end 


functions 
-- 関数を書くところ。今回は使わない。

operations
Hello : seq of char ==> seq of char
Hello(名前) ==
(
	return "Hello " ^ 名前 ^ "!!"
)

-- 事前条件：
pre len 名前 > 0;

-- 事後条件：
-- post 条件式だが、今回は特にない


end HelloVDM

---

■そして

　このソースを、
VDMのお勉強－その４　使い方
http://blog.goo.ne.jp/xmldtp/e/e08a21fa14c65253fa145563935571bb
で書いたツールを立ち上げて、ファイルを追加し、
実行用のパネルをひらいて、

init
print Hello("vdm")

と入力すると、

"Hello vdm!!"

と返ってくる。

---

細かい話の前に、同じコトをVDM++でもやってみる。

DIとアスペクト指向の共通点と相違点

　DIとアスペクト指向は、似ているところもある。

　どちらも、後から実体を注入することが出来る点だ。
　DIは、「依存性の注入」なので、出来るのはもちろんだけど、
　アスペクト指向でも、aroundとかを使うと、後からプログラムの実体を入れることが出来る。

---

　しかし、決定的な違いがある。

　DIは、実体を後から入れるが、構造は、前もってinterfaceで定義し、実体とインターフェースの関係を、設定ファイル（Springだとbean-conf.xml,Seasar2の場合diconファイル）で記述してしまう点だ。したがって、注入するクラスは、このインターフェースの構造に従う＝束縛される。

　一方、アスペクト指向は、インタータイプ宣言などにより、利用するメソッドや属性を追加させ、構造を変えてしまうことも出来る＝束縛されない。

---

　このような「アスペクト指向の何でも出来てしまう自由」は、（自己責任という名において）危険性と紙一重の関係にあり、あまりにひどい変更を行ってしまうと、コンパイルエラーになることすらありえる。

　したがって、フレームワークの「ハリウッドの法則」のような、拘束をかけたい場合は、自由なアスペクト指向ではない、DIのほうが向いている。

---

　ここで、昨日の状態遷移との問題がある。

　アスペクト指向では、遷移すら変えてしまう。優先順位を間違えれば、遷移の順序も変えてしまうし、ポイントカットをミスれば、不必要なときに呼び出しをしてしまったりする。
　このことは、派生開発などにアスペクト指向を使うことに対して、障害となる。

　アスペクト指向を利用すれば、構造も振る舞いも変えられる。
　そこで、これを利用して、既存のシステムに機能追加をすることが考えられる。
　しかしこの場合、設計上で想定しなかった遷移が起こる可能性がある。
　この点をどうするかを考えないといけない。