　しかしこれは最初から派生開発を計画的に、プロダクトエンジニアリング的に開発する場合で、現実は派生部と基本部が混ざっている状態で開発することが多いです。計画的にでなく、結果的にアドホックに派生開発をするというものが多いです。同様にモデルも差分がどこにあるのか全く分からないモデル図になっていることもしばしばです。このような派生開発で、モデリングはどうすればいいのでしょうか。

　このときは、既存のモデル図から前回の図との差分を抽出する必要があります。このときのコツは「図のレイアウトが乱れていて、図が複雑になっているところを見つけること」です。きっとそこが差分になっているでしょう。図のレイアウトをし直していない限り、差分は見つかります。

　レイアウトが汚いからと言って、決してレイアウトをし直して差分を分からなくしないでください。レイアウト情報に重要な情報が入っています。そして差分を見つけたら、それを明示化することを忘れないでください。その後で、部屋の掃除をするように、レイアウトをし直してください。この話題も次回以降の「モデリングの成功、失敗」で紹介していくことになります。

既存開発（改良開発）とモデリング

　新規開発でなく既存システムを改良する開発の際、モデルがない場合やあっても弱い場合があります。このときの対処は、既存部のモデリングをせずに、新規開発部分だけをモデリングして既存部を覆い隠すレガシーラッピングのモデリングと、既存部をモデリングする方法があります。どちらを選ぶかは既存部と改良部のサイズや、将来の改良回数、既存部の品質（もっと正確に言えば、へたくそさ）に依存します。

　モデリングツールを使って、既存のコードからモデルを生成するリバースエンジニアリングの手法がありますが、あまり大きな期待をしない方がいいでしょう。これを実用的に使うためには、あらかじめプログラムを変形させモデル生成しやすいようにしておいて、さらに生成したモデルをプログラムの意図に近いように変形する必要があります。

　このようにプログラムのプリエディットとモデルのポストエディットが必要になります。しかしこれを手作業で行うのは何のためのリバースモデリングかが分からなくなり、愚の骨頂です。しかし、リバースエンジニアリングを使うのはこれしか手はありません。ここまでリバースエンジニアリング機能の面倒くささを強調して悪口を言ってきましたが、もちろん、リバースエンジニアリング機能をドキュメント清書ツールとして使うのは有用です。

　プログラムからのモデル生成について紹介してきましたが、次はドキュメント（システム仕様書やプログラム仕様書、マニュアル、試験仕様書など）からモデルを生成するのはテクニックもコツもあまりありませんので、これは力ずくの方法になりますが、これでモデリングすることは便利です。

　次の問題として、レガシーなモデル図（例. フローチャート、DFD）を最新のオブジェクト指向のモデル図にしたいという要求もあるでしょう。もちろん、レガシーなモデルが悪いわけではありませんが、将来を考えて、最新のモデル図で表現したいという要求があるのは当然だと思います。このときは、きれいなフローチャートやDFDであれば、機械的に変換可能です。しかし汚いフローチャートやDFDのときは苦労をします。機械的変換は可能ですが、生成したモデル図はプログラムコードの方が分かりやすいぐらい、見にくいものになっているでしょう。この場合は諦めて新規に作った方がいいでしょう。