長瀬嘉秀のソフトウェア開発最新事情（4） 長瀬嘉秀 テクノロジックアート 2003/4/26

ソフトウェアの開発手法を巡る動きが活発化している。ウォーターフォール型開発手法の神話はすでに崩れ去ったのか？ 反復型開発手法の雄「RUP」は果たして定着するのか？ アジャイル開発プロセスの思想が一時的なブームに終わってしまう可能性はないか？ 開発手法の潮流を観察し続ける長瀬氏の連載コラム。（編集局）

第4回 システム設計、実装、テストの手順

　第3回 「『典型的なOO開発』と『XP』のプロセス比較」では、UMLモデリングを活用したコンポーネントベース開発とXP（エクストリームプログラミング）を比較しながら、開発プロセスの相違点を探る試みを行った。とはいえ、前回は、「要件定義」「システム分析」まで進んだ段階で紙幅が尽きてしまったので、今回は、「システム設計」から「実装」「テスト」まで一気に終わらせようと思う（ただし、XPは設計が実装の中に含まれるので、フェイズ分けは行わないことをお断りしておく）

システム設計フェイズにおける相違点

　

　システム設計ではシステム分析の結果である論理的な設計に、実装技術を取り込んでいく。このフェイズで、アーキテクチャと論理的な設計が合わさることになる（図1）。

図1 モデリングから実装の流れ

■コンポーネントベース開発プロセスではこうなる

　コンポーネントベース開発では、まずコンポーネント仕様を作成する。ここでは、図2のような見積コンポーネントを参考にする。

図2 分析フェイズのコンポーネント仕様例

　設計フェイズでは、アーキテクチャ設計を適用する前にシステム分析のコンポーネント仕様の構成を明確にしていく。ここではマーチン・ファウラーが提唱する「アーキテクチャのレイヤ化」を採用し、以下のステレオタイプを用いる。

• <<Presentation>>（ユーザーインターフェイス）
  
• <<Domain>>（ビジネスロジック）
  
• <<DataSource>>（データ）

　図2の見積もりコンポーネントのうち、ビジネスプロセス「見積結果通知」とそのサブプロセス「見積結果選択」「見積通知選択」は、<<Domain>>に、コンポーネント内部のデータである「見積もり」「見積明細」「顧客」「商品」は、そのアクセス経路を分析し、コンポーネント化された<<DataSource>>に分類する。

図3 コンポーネント仕様にコンポーネントの「特性」を導入していく

　一方、アーキテクチャ設計はどうなるだろうか。簡単な例を示す（図4）。

図4 アーキテクチャ設計

　クライアントには、WebブラウザにInternet Explorler、アプリケーションサーバにBEA WebLogic Server（以下WebLogic）を採用した。WebLogicでは、Servletでクライアントのリクエストを受け、セッションBeanを活用する。ビジネスロジックはJavaのクラスとして作成する。データベースはエンティティBeanを介して、Oracleにアクセスする。システムも全体的な構成は、クライアント、アプリケーションサーバ、データベースサーバの3層に分かれている。

　このようなアーキテクチャ設計を図3のように分類したコンポーネント仕様に適用していく。このような作業を「マッピング」と呼ぶ。

ちょっと一言

従来のオブジェクト指向分析／設計方法論には、マッピングという考え方はなかった。つまり、これまでは、論理モデルにアーキテクチャ情報を入れ込み、実装モデルであるクラス図を書いていくという手順を踏んでいたのである。しかし、この方法では、作業が進むに従ってクラス図が修正されていってしまうため、論理モデルで設計したクラスが、実装段階でどんなクラスになったのかをトレースすることが難しい。結局、このようなEvolution（発展）型の開発手法では、続々と巻き起こる仕様変更のあらしに耐えられないのだ。 　 　これに対して、マッピングによる開発手法は「Model Driven Architecture（MDA：モデル駆動型アーキテクチャ）」と呼ばれ、最新の開発アプローチとして注目を集めている。 　 　MDAは、Object Management Group（OMG）がUMLに続く最新の開発技術として標準化を推進している技術である。近い将来、ほぼすべてのUMLモデリングツールは、MDAをベースとしたモデリング・プロセスを取り込んでいくだろう。マッピングの記述方法が標準化されれば、一度マッピングを定義するだけでツールが自動的に動作可能なコードを生成するという非常に便利な開発のフローが生じるからだ。 　 　実際、組み込みシステムの分野では、「Executable UML」として実証されているが、MDAの普及でビジネスシステムの分野でも、モデルからコード生成の自動化という夢は実現可能になる。MDAは、コードのスケルトンを生成するのではなく、UMLモデルからすぐさま実行できるコードとロジックさえも生成できるとする技術なのである。

　図5では、<<Domain>>ステレオタイプの「見積結果通知」をセッションBeanに、「見積結果選択」「見積連絡先選択」をJavaのクラスに、<<DataSource>>の「見積もり」「商品」をエンティティBeanとして実装したものを表している。なお、HTML／JSPによる画面や、Servletによるリクエスト制御は、画面設計や画面遷移などのドキュメントを用意し、開発していく。UMLだけで、すべての設計ができるわけではない。

図5 J2EEのマッピング例

　コンポーネントのマッピングに加えてデータ部分のマッピングも必要になる。例えば、UMLによるオブジェクトモデルからリレーショナル・データベース（RDB）へのマッピングは、O-R（オブジェクト-リレーション）マッピングと呼ばれている。

図6 O-R（オブジェクト-リレーション）マッピング

　データ中心の方法論では、E-R図によるデータベースの設計を先に行い、オブジェクトにするという方法を示しているが、UMLによる方法論ではまったく違う。オブジェクトモデルから先に考えるのである。システムの中心部分はあくまでデータベースではなく、J2EEのクラス構造だからである。

実装フェイズにおける相違点

　

■コンポーネントベース開発プロセスではこうなる

　コンポーネントベース開発では、マッピングを基にコーディングを行っていく。例えば、「見積通知内容選択」は次のようになる。

EstimateResultNoticeBean.java

import javax.ejb.*; public class EstimateResultNoticeBean implements SessionBean {           //見積結果選択           public void targetResultSelect(){}           //見積通知先選択                      public void targetCustomerSelect(){}      public EstimateResultNoticeBean() {}   public void ejbRemove() {}   public void ejbActivate() {}   public void ejbPassivate() {}   public void setSessionContext(SessionContext sc) {} }

■アジャイル開発プロセス（XP）ではこうなる

　一方、XPではストーリーカードをタスクカードに分割した後、計画に従って実装を行っていく。プログラミングの手順の中に設計が含まれるのである。ここでは、XPの核となっているTest Driven Development（TDD：テスト駆動開発）を見ていこう。

図7 Test Driven Development（TDD：テスト駆動開発）

　TDDでは、ものすごく細かいサイクルで、「テスト→コンパイル→動作→リファクタリング」を繰り返しながら開発作業を進める。このサイクルは、1時間に何回も繰り返す場合もある。最初にテストコードを作成し、コードを記述し、コンパイルを行い、テストを実行する。始めは、ターゲットとなるクラスを作成していないので、エラーの赤バーがJUnitに表示されるだろう。

　ここで、ターゲットのクラスを作成していくことが設計作業に相当する。クラス構造を決定したり、機能をどのクラスやメソッドに持たせるかを考え、コードを作成していく。UMLによる設計図を書くよりも早くコードができてくる。もちろん、XPではペアプログラミングが基本なので、設計もペアでレビューすることになる。

◆

　以上、2回にわたって、2つの異なる開発プロセスを比較しながら、開発プロセスの具体的な手順を見てきた。これらのプロセスの詳細手順を説明することはできなかったが、大まかな流れは理解できたのではないかと思う。コンポーネントベース開発の詳細については、テクノロジックアートのWebサイトで参照できる。また、TDDについては、現在ケント・ベックの書籍の翻訳が進んでおり、もうすぐ出版される予定である（『テスト駆動開発』、ケント・ベック著、テクノロジックアート訳、長瀬嘉秀監訳、ピアソン・エデュケーション）。
　
　開発プロセスは、採用する企業や適用するプロジェクトなどの性格、過去から続く企業文化などによって、逐次カスタマイズすることが求められる。1つの開発プロセスで、あらゆるシステム形態（組み込み、ビジネス）、さまざまな実装技術（J2EE、Java単体、.NET）、エンジニアのスキルなどをカバーすることは到底できない。状況に応じて、開発プロセス自身を変化させなくては成功する成果物を得ることはできないのである。

プロフィール

長瀬嘉秀（ながせ よしひで） 1986年東京理科大学理学部応用数学科卒業後、朝日新聞社を経て、1989年株式会社テクノロジックアートを設立。OSF（Open Software Foundation）のテクニカルコンサルタントとしてDCE関連のオープンシステムの推進を行う。OSF日本ベンダ協議会DCE技術検討委員会の主査。現在、株式会社テクノロジックアート代表取締役。著書に「分散コンピューティング環境 DCE」（共著、共立出版）、「ソフトウェアパターン再考」（共著、日科技連出版社）、「コンポーネントモデリングガイド」（共著、ピアソン・エデュケーション）など多数。また「独習UML」（監訳、翔泳社）、「XP エクストリーム・プログラミング入門」（監訳、ピアソン・エデュケーション）、「UMLコンポーネント設計」（監訳、ピアソン・エデュケーション）、「入門Cocoa」（監訳、オライリー・ジャパン）、「Webサービス エッセンシャルズ」（監訳、オライリー・ジャパン）など海外の最新テクノロジに関する書籍の翻訳作業も精力的に行う。

Java会議室でご意見、ご感想を募集中

IT Architect 連載記事一覧