さて、派生開発の「変更」をどうモデル化するか。。。前回までのあらすじはこちら。
デルタの導入
欲しいものは、「修正」そのものをストレートに表現することです。なので、クラスの「修正」を表すステレオタイプ、《delta》を導入します。これは、クラスに対する変更指示そのものを示すクラスです。赤ペンで書くことを、少々フォーマルにして、このクラスの中に情報として書いて行きます。さらに、サブとなるステレオタイプ、《add》, 《delete》, 《modify》も導入。
- デルタ: 《delta》
- 追加: 《add》
- 削除: 《delete》
- 変更: 《modify》
この 3 つに分け、変更を表現します。変更を「クラス」として閉じ込める分けです。さらに、この変更指示は、上位の変更要求に対応するはずです。この変更要求を「要求」（UMLでは《requirement》、SysMLの要求図で使う「要求要素」)と結ぶと、さらにトレーサビリティが分かりやすくなるでしょう。
記述例
簡単な例です。
- 赤ペンで表現した場合
- デルタ記法
もっと大きなモデルだと、見た目はこんな感じになる。
こう考えると、デルタの領域に中心の設計モデルとは「別に」、パターンやアーキテクチャが見つけられないか、と考えている。
例えば、
- 変更が変更前のアーキテクチャを横断して入る「レイヤー縦断デルタ」パターン
- 局所的な変更で収まる「エンカプスレーテド・デルタ」パターン
などなど、想像している。
考察
デルタ、という要素を定義することで、「変更」をダイレクトにモデル化してみた。さらに、要求要素との関係も示すことで、変更意図をトレースすることができる。
astah を使って書いているが、この書き方はクラス図にしか使えない（「《delta》クラス」はクラス図にしか置けない）。できれば、他の図、例えば状態遷移図、アクティビティ図などでも使いたいだろう。その場合、「《delta》状態」、「《delta》アクティビティ」などモデル要素を作って行くのだろうか？
実務的には、クラスでなく操作や属性（関数や変数）に直接、変更指示を書きたくなると思う。その場合、《delta》クラスでなくさらに細かい粒度に対応しないといけない。しかし、クラス図の依存関係矢印は、直接操作に引けないのであった。。。。
対応方法として、「ノート」要素を使ってしまう手もあると思う。これが実践的かもしれない。上記1,2の両方の問題を一気に解決できる。
しかし、形式化からはずれてしまう。。。
あとがき
今日は、「派生開発カンファレンス」が開かれます。（私、基調講演を仰せつかりました）。ぼくは派生開発に関しては素人なのですが、なんとかこの案を叩いてくれることで実用的なモデルを使った派生開発の一歩になればと思っています。
(※ 5/16 追記：パターンを考察してみた。)