netail.net

_ ダイス ▲

サイコロを５個振って出た目がポーカーの役になるかどうか，という話になって，それをテストするスクリプトを書いた．素直に確率計算すればいいのに総当り．

結果は，以下の通り．

ファイブカード: 6通り

フォーカード: 150通り

ストレート: 240通り

フルハウス: 300通り

ブタ: 480通り

スリーカード: 1200通り

ツーペア: 1800通り

ワンペア: 3600通り

合計: 7776通り

_ AOSD 2003 ▲

AOSD2003論文読みの２本目．

A. Rashid, A. Moreira, J. Ara\acute{u}jo: ``Modularisation and Composition of Aspectual Requirements'',Proceedings of the 2nd international conference on Aspect-oriented software development, pp.11-20, Boston, Massachusetts, March, 2003.

要求分析で用いられるRequirement Engineering (RE) に，アスペクト指向的なアイディアを導入するという話．複数の要求を横断したような concern をどうやって分離・再構成するかというのが問題らしい．

具体的には，視点（"利害関係者"）ごとにどの Concern が重視されるかを最初に調べる．次に，Concern 間の positive/negative な影響をリストアップし，同時には成立できないような要求(Conflict)に対しては優先順位の決定によって順次解消していく．

Conflict がなくなったら，Concern をプロダクト中の機能・設計・アスペクトといった要素にマッピングしていく．この論文では，要求分析段階での Concern を，"candidate aspect"と呼んでモジュールのアスペクトと区別していた．

で，この筆者らの手法では，要求を XML 形式で，Viewpointごと，およびConcernごとの要求定義を行う．そこから，どの要求が満たされなければならないかという制約＜Constraint＞と，その制約によって何が得られるか＜Outcome＞を記述したComposition Rule を作成する．で，ツールでXMLをparseしてConflictを検出し，ユーザが設定した要求の優先度によって解消を行う．

Viewpoint と Concern という二つの軸で要求を分析するところがアスペクトと似ている．ちなみに，最終的に確定した Concern は，アーキテクチャ，設計，機能（クラスやアスペクト）といった様々な場面に影響する．モジュールとしてのアスペクトを発見するための手法ではない．

_ 読書 ▲

リチャード・S・ワーマン「それは情報ではない」を読了．データ，情報，知識，知恵の区分といった概念的な話から，情報の伝達，コミュニケーション，職場での人間関係まで，有益な示唆を含んでいる．情報の伝え方，という意味では論文の書き方などにも関連してくるので，ちゃんと内容が消化できるまでは手元に置いておくことになりそう．

_ 本 ▲

人に貸してたA.ハント，D.トーマス「達人プログラマー」を返してもらった．アスペクト指向プログラミングに出会った思い出の本である．といっても，単に「ハンプティ・ダンプティは事故死か他殺か」のくだりが読み直したくなっただけだが．