IBM® Rational® モデリング製品を使用すると、UML 言語全体またはそのサブセットを使用して、豊富な概念モデルを作成することができます。 パターンや変換などのモデル・ベースの自動化を使用して、モデルの定義および洗練のいくつかの点を自動化したり、さらに追加の変換を適用してコードを生成したりすることもできます。概念モデルから値を得たら、その概念モデルを廃棄し、任意の UML 表記のダイアグラムを使用した、よりアジャイルなコード編集手法を使用することができます。
概念モデル・シード具象モデルでは、アプリケーションの作成方法をさまざまな手法または視点から選択することができ、1 つの設計上の問題を複数の観点から眺めることができます。 通常、概念モデルは初期の段階で使用されます。最初に多くの判断や設計が必要になりますが、プロジェクトが進行するにつれて、開発面での制御や信頼保証といった開発者に託される部分が多くなります。 概念モデル・シード具象モデルは、開発ライフ・サイクルの変更の多いフェーズで役に立ちます。 コードまたはテキストによる仕様文書よりも、低コストでかつ整合性の高い方法で、モデルを変更することができます。 初期段階での概念モデリングはプロジェクトのリスクを軽減させることができ、よりよい開発結果を得るという点でも付加価値があるが、反復型開発プロセスで概念モデルを維持する負荷は受け入れられないという場合は、この手法を採用してください。 この手法は、開発プロセスで反復型の方式を使用している場合に採用してください。
この手法では、概念モデルを利用することによって、プロジェクトのリスクを限定的なものにすることができます。 概念モデルでは、複数のタイプのダイアグラムを作成することができます。これらのダイアグラムを使用すると、問題が視覚化されて見とおしおよび理解が深まり、その問題ドメインに対して複数の異なるアーキテクチャー手法を試すことができます。 概念モデルは、より正確にプロジェクトを評価するための確かな基礎ともなります。さらに、コード生成変換を使用することによって、 プロジェクトの最初の反復においてかなりの量のハンド・コーディングを省くことができます。 この手法ではアーキテクトおよび上級管理者が全体像を伝達して確認することができ、開発者はアプリケーションを設計する際にその全体像を参考にすることができます。 この手法では、チームが顧客の視点で問題を理解し、プロセスに対するソリューションを提案することもできます。
概念モデル・シード具象モデルでは、開発プロセスの最初にブレーンストーミングが行われ、 上級管理者および開発者が問題をさまざまな方向から理解することができます。 しかし、モデルの価値は一時的なものと見なされ、初期プロセスの後には廃棄されます。 この手法は、具象モデル駆動型開発のアジャイル手法よりも多くの初期投資が必要になります。この手法では、概念モデリング言語の知識および使用のほか、開発の初期フェーズにおける概念モデリング成果物の変更の調整および管理能力が必要になるためです。初期状態でのガバナンスは高い状態にありますが、開発者がコーディングを進め、 開発面で自己決定できるようになるにつれて非常に低くなります。