セイコーエプソンの萩原さんと、モデルを使って派生開発の変更指示をうまく表現できない、という課題を議論しました。考えのメモです。
派生開発における「変更指示」
日本の組込み開発でよく使われる手法である清水さんの「派生開発」(XDDP)ですが、派生前の状態に対して「変更指示」を文書化します。
ソースコードレベルであれば問題は少ないのですが、構造に対しての修正は大域的になり、うまく表現しにくくなります。これをモデルで扱いたい、というのが問題です。
Before/After の問題点
まず考えられるのは、Before と After を示す方法です。
ここから実際の変更を行うのはとても観察力が必要！例えて言えば、間違い探しになってしまいます。
例えば astah などでは diff をとる機能もありますが、もっといい方法はないでしょうか？普通は「赤ペン」を入れたいところ。
さらに言うと、せっかくなので、__「変更を表現するモデル」__があるとよいのに！変更を表現するのが目的のモデルとそれを使ったビュー。
この表現の必要性をアーキテクチャの観点から言ってみる
「アーキテクチャ記述」という何か、という話で、2000 IEEE1471（ISO/IEC42010）という標準モデルがあります。そこには、「ビュー」と「ビューポイント」が定義されていて（『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ 参照）
- __「ステークホルダー」毎に「関心事」__があり、
- __「ビューポイント」は１つ以上の「関心事」__をカバーする。
となっています。要は、モデルは誰かの関心事毎にビューポイントに従って記述される。派生開発にとって「変更」は明らかに関心事であるから、「変更を示すビュー」、そしてそのモデル表現は必要だといえる。
解決案
しかし、現在、この「変更を示すモデル」を真正面から扱ったものを、ぼくは知らない。。。。赤ペンで書くのもよいでしょう。そして、Before/After を示すのもよいでしょう。しかし、もうちょっとフォーマルに（UML程度のセミフォーマルに）扱えるとよいのに。__「変更を表現するモデル」__があるとよいのに。
というのが問題です。では、次に解の試案です。
（補記1：クラス図を例にしましたが、状態遷移図やアクティビティ図、シーケンス図など、もっといろんな図で使えるとよいと思っています。また、派生開発の現場ではC言語が多く使われるかもしれません。ここでは例としてUMLクラスを使ったオブジェクト指向的表現となっていますが、クラスを「ファイル」、操作を「関数」、属性を「変数」と読み替えてC言語でも使えるものがよいと思っています。）
（補記2：今年の派生開発カンファレンスに、基調講演という大役を頂きました。日本のアジャイルの話をしようと思います。）