アスペクト指向勉強会(第6回) - Analysis

AOAD

だんだん英語のテキストが斜め読みできるようになってきた気がする... 気だけですけど。(^^;)

Capter 4 Analysis (前回の続き)

Deciding on Theme Responsibilities

目的は Theme が Aspect かどうかを識別すること。

  1. Split the requirement if possible
  2. Dominance means association
  3. Base triggers aspect

Chapter 3 であがったこれらのポイントに次のチェックが加わった。

  • Is the Aspect Crosscutting Enough?
Split Shared Requirements If Possible

特に議論なし。

Dominance Means Association

Theme が Dominant(支配的?) かどうかを判断する方法が2つ紹介されている。

1つは、その Theme が Requirement の振る舞いについてよく知っていること。つまり、if や when 節じゃなくて、本文の述語が Theme ならOK。
例えば、R42: Energy is gained by two units when they find a crystal upon entering a location は、能動態に直すと "gain energy" が本文の述語だから、enter-location じゃなくて track-energy が Dominant。

もう1つは、その Theme を共有する他の Requirement について同じように調べてみて、それらでも Dominant らしかったらOK。
例えば、track-energy は R40 でも R42、R77、R80 でも Dominant らしい。

Base Triggers Aspect

Table 4-2、Table 4-3 でちゃんと Trigger される側になっているよね、という確認。

Is the Aspect Crosscutting Enough?

他の Theme から Trigger される Theme であっても、その状況が1ヶ所だけだったら、わざわざ Aspect にする必要はない。1ヶ所だけだったらとりあえず Aspect にするのを保留しておく。

Make the Association

Theme が Aspect だと識別されたら、Aspect から Base に灰色の矢印(gray arrow)を引き、共有されていた Requirement を Aspect 側に移動する。

P.141 の Crosscut Themes は Base のこと。この crosscut は過去分詞。

Chains of Crosscutting

議論にならなかったけれど、
track-energy -> challenge -> meet-wizard etc.
という連鎖ができていますね。以前 Gohさん が言ってたけど、Aspect と Base は相対的な関係と考えた方がいいかもしれない。

Postpone Some Decisions

共有される Requirement のうち、Aspect と断定できないものについては、判断を延期(posopone)し、破線(dashed-line)で表す。

Postpone した後の Requirement の扱いが一貫していないという指摘あり。

Knowing When You're Done

議論せず。

Planning for Design

次回へ延期。