アジャイルモデリング(AM)
公式サイト
モデリング成果物>取り決めモデル

取り決めモデルの概要

by Scott W. Ambler, Copyright 2003

ときには、開発するのがまったく新しい独立したシステムのことがあります。それは稀にみる幸運です。たいていの開発では、既存のレガシー情報と統合したりインターフェースをとったりする必要があるためです。レガシー情報には、既存のデータベースやファイル、既存システム、あるいは再利用可能な真新しいWebサービスといったものがあります。このページでは、レガシーシステム分析についての概要と、よく発生する問題について紹介します。

レガシーシステムを扱わなければならない場合には、開発上の制約が生じます。たいてい、新しいシステムのニーズに合わせてレガシーシステムを変更することは簡単でないため、柔軟性が低下します。たとえば、新しいシステムで必要な情報すべてをレガシーデータから取得できることは多くありません。既存データには新しい要求が反映されていないからです。同じように、再利用できそうな機能をレガシーシステムが実装していても、「あと一歩」であって、完全に事足りるわけではないことがよくあります。

アジャイルモデリング(AM)には、レガシーシステム分析に直接関係する「取り決めモデル (contract model) はきちんと定義しよう」というプラクティスがあります。システムがある情報源にアクセスする必要がある場合には、開発グループと外部のグループの間で「取り決めモデル」(外部インターフェース仕様と呼ばれることもよくあります)を作成しておくべきだ、というのがこのプラクティスの要点です。取り決めモデルの例には、アプリケーションプログラミングインターフェース(API)の詳細ドキュメント、ファイルレイアウト記述、共有データベースについてのXML DTDや物理データモデルがあります。こういったものを私が取り決めモデルと呼んでいるのは、それが実質的に、情報源の所有者とその情報を利用する外部システムの所有者の間の取り決めになっているためです。所有者がシステムを変更するときには、少なくとも事前に全員に通知しておく必要がありますし、できれば変更について相談するべきです。法的な契約と同様に取り決めモデルも、多くの場合、それなりのリソースをつぎ込んで、正確かつ十分に詳細であるよう作成、維持する必要があります。ただしこのとき、身軽な旅をするというAMの原則に準じて、システムの取り決めモデルの数を最低限にするよう気を付けてください。

たいてい、配置モデルの作成中に、利用しなければならない既存の情報源が見つかります。開発対象のシステムがやり取りする情報源それぞれについて、何らかのレガシーシステム分析を行う必要があります。運がよければ、その情報源に関する正確な文書がすでに存在します。その場合には、システムの所有者と話をし、文書に目を通して、その情報源が自分のニーズを満たしているかどうかを判断するだけで分析作業は済みます。ただしたいていは、文書がまったく、あるいはほとんど存在しないか、まるで最新状態に保たれていないことが判明するでしょう。その場合、新システムの開発者かレガシーシステムの所有者、または両方が時間を割いて、既存の情報源の分析を行い、十分な文書を作成する必要があります。このとき、所有者と緊密に協力し、関連するソースコードを詳細に調べたり、既存のソースコードをリバースエンジニアリングして文書を作成するモデリングツールを使ったり、既存の情報源を調べてどう動くかを判断したりして、既存資産を理解することになるでしょう。これは時間のかかる困難な作業になることも珍しくありません。

取り決めモデルの形式としてもっともよく使われるのは、外部システムへのアクセス方法を記述する外部インターフェース(external interface: EI)仕様書です。私がEI仕様書を作成する場合、以下のような情報を含めるようにしています。

  • 識別番号:一意の識別番号。たとえばEI-1701など。

  • 概要:数行または数段落で外部システムインターフェースを記述します。

  • システムの所有者:システムの所有者の名前と連絡先。プロジェクトマネージャと技術に関する連絡先の両方を含みます。

  • 種類:インターフェースの種類。XML、JMS、Java API、フラットファイル転送など。

  • 方向:転送の方向を列挙します。外向き、内向き、双方向など。

  • 頻度:このインターフェースが使われる大体の頻度。週1回、1日500回など。

  • タイミング:インターフェースがいつ使われるかを記述します。たとえば、年中無休、毎晩2時など。

  • 転送速度:分かっている、あるいは要求されている転送速度を列挙します。たとえば、ファイルサイズは平均50メガバイトである、各レコードは125バイトである、など。

  • セキュリティ:セキュリティの問題に関して分かっていることを列挙します。たとえば、ログインが必要である、ファイアウォールで保護されたソースシステムである、SSLが使われている、など。

  • フォーマット:全データ転送のフォーマットについて詳しく記述します。XMLスキーマ定義を参照するだけであったり、ファイルレコードレイアウトを記述したり、CのAPIを記述したりすることが考えられます。このセクションの情報は、具体的なインターフェースによって異なります。

  • 問題点:今後の作業、対処しなければならない事柄などがあれば列挙します。

  • 決定事項:このインターフェースの作成時に決定した重要な事柄があれば列挙します。

EI仕様書の例はhttp://www.ronin-intl.com/downloads/index.htmlからダウンロードすることができます。

 

注: この成果物の説明は『The Object Primer 3rd Edition: Agile Modeling Driven Development with UML 2』より抜粋しました。本ではより詳しく説明しています。


推奨文献

 
Legacy Systems: Transformation Strategies レガシーシステムを再利用可能な高品質の資産に作り変える方法を扱った、非常に優れたレベルの高い本です。
Web上のリソース
  • The Joy of Legacy Data─このエッセイでは、レガシーデータに関して一般的に見られる問題を多数調査しています。

 

その他の文献

アジャイルモデリング(AM)について詳しく知るにはこの本をお薦めします。

 アジャイルモデリング

 

Let Us Help (以下、北米での話ですのでご注意ください)

Ronin International, Inc. continues to help numerous organizations to learn about and hopefully adopt agile techniques and philosophies.  We offer both consulting and training offerings.  In addition we host several sites - Agile Modeling, Agile Database Techniques, UML Modeling Style Guidelines, Enterprise Unified Process (EUP) - that you may find of value.

You might find several of my books to be of interest, including The Object Primer, Agile Modeling, The Elements of UML Style, and Agile Database Techniques.

For more information please contact Michael Vizdos at 866-AT-RONIN (U.S. number) or via e-mail (michael.vizdos@ronin-intl.com).

 

visits since June 8, 2004.