第2回 コンポーネントの再利用、できていますか?要求仕様のボトルネックを探る

» 2004年03月19日 12時00分 公開
[今村智,ボーランド]

 開発者はブラックボックスを嫌うため、他人の作ったコードをそのまま使いたがらない、という声を開発者“以外”の人が口にするのを良く聞きます。その結果、コンポーネントの再利用がなかなかうまくできないとされているのですが、果たして原因は開発者の言い分とされるそれだけでしょうか? 今回はコンポーネントの再利用を促進するノウハウについて、要求仕様の観点から考えてみたいと思います。なお、今回対象とするのは、再利用がなかなか実現されていない、業務ロジックを実装したコンポーネントです。

(1)Java(J2EE)の登場で再利用の夢は実現したか?

 EJB(Enterprise JavaBeans)が登場し、各種アプリケーションサーバがサポートを開始することで、サーバサイドのビジネスロジックをコンポーネントとして広く流通させようとする動きが2000年頃から徐々に出始めました。その結果、部品の再利用が可能になると期待されたのですが、実際にはどうだったのでしょうか? ビジネスロジックの再利用可能な部分が増えることで、開発生産性が向上し、品質の向上を容易に得ることができるわけですから、開発者の期待はいやがうえにも高まったものですが。

 同時に、Javaの広がりとともに、フレームワークという言葉がITの世界で一般的に使われるようになりました。フレームワークとして、多くの有償製品やオープンソース製品が登場しています。中には、あるタイプのアプリケーション構築時には必ず使用されるフレームワークもあります。ただし、フレームワークはあくまでフレームワークです。ビジネスロジックを実装しているわけではありません。もちろん、フレームワークの再利用は非常に有用ですし、コンポーネントの再利用を考える時には、フレームワークの再利用を外して考えることはできません。

 しかしながら、フレームワーク、コンポーネントという言葉だけが広まり、これらを特定の文脈の中で適切に理解している方は非常に少ないと感じています。

(2)要求とシステムアーキテクチャの関係

 ここで、今回の文脈の中でのコンポーネント、フレームワークといった言葉の定義を行いたいと思います。背景としては、J2EEによる業務システムの構築をイメージしていますが、読者の皆さんが通常置かれている文脈に変換されても理解の妨げにはならないと思います。

ALT 図1 要求とソフトウェア・アーキテクチャの関係

 図1は、ソフトウェアへの要求と、システムアーキテクチャの構成要素との関係を図示したものです。もちろん、それぞれの境界にはあいまいなものも存在するわけですが、おおよそ、このようになっているととらえてください。

 簡単に説明しますと、非機能要求を実現するために、システムで使用するハードウェア、OS、ミドルウェア、フレームワークを選定、設計を行います。また機能要求とそれを補う形での用語集などから、コンポーネント、ドメインモデル、ライブラリを設計していくことになります。

<フレームワーク>

 フレームワークとは、ここでは、コンポーネントを上手に実行するための仕組みと考えてください。つまり、業務ロジックの開発者に対して、「このインターフェイスを実装して、ルールに従った設定情報を登録してくれれば、その設定情報に従ってあなたの書いたプログラムコードを実行してあげますよ」という枠組みを規定したテンプレートといえます。ですから、アプリケーションサーバが提供するEJBコンテナやWebコンテナと呼ばれるような、Webクライアントからのリクエストを受けて、業務ロジックコードへリクエストを中継してくれるようなものもフレームワークと呼びますし、StrutsのようなWebコンテナ上で、さらに細かな制御を行うためのものなど、色々なレベルのフレームワークが存在します。もちろん、サーバサイドに限らず、クライアントPC上で、画面内の処理要求(画面内イベントメッセージ)を制御するフレームワークもあります。

<コンポーネント>

 コンポーネントは、フレームワークが定めたインターフェイスを実装し、単独またはほかのコンポーネントと連携することで機能要求を実現しますが、その内部では、必要なドメインオブジェクトやライブラリ類を使用しています。コンポーネントは、「こんなときには私を呼んでくださいね」とフレームワークに対してお願いをしておきます。

<ライブラリ>

 ライブラリは、基本的には特定のフレームワークには依存せずに、自身の機能をAPIとして公開しています。ライブラリは、その利用者側が、明示的に利用を宣言し、ライブラリの機能を呼び出します。

<機能要求の構造>

 ここで、少し視点を変えて、機能要求の構造を整理したいと思います。要求は、図2に示すような階層構造で整理することが可能です。

ALT 図2 要求の構造

 例えば、サマリー要求(ビジネス要求)の例としては、「オンラインショッピングサービスを提供する」というようなものがあり、それらの具体的なサービス内容であるユーザー目的要求としては、例えば「会員情報を登録する」「商品を探す」「商品を注文する」などがあります。さらにこれらを実現する手段、つまりシステム要求(機能要求)として、「ユーザー認証」「商品検索」「メール送信」などが定義されていきます。この例におけるユースケース記述およびユースケース図を図3に示します。

ユーザー目的要求 システム要求
1. ユーザーは、商品検索条件を指定する

2. システムは、検索条件に基づいて商品を検索し、結果一覧を応答する

3. ユーザーは、検索結果一覧から、任意の商品を選択し、商品詳細情報を要求する

4. システムは、指定された商品の詳細情報を検索し、応答する
HOW? 1. システムは、指定された検索条件が正しいことを確認し、商品テーブルの検索を実行する

2. システムは、検索結果をソート条件にしたがって並び替える

3. システムは、一覧表示に必要なデータを整形し、応答する
HOW? 1. システムは、指定された検索条件が正しいことを確認し、商品詳細テーブルの検索を実行する

2. システムは、検索結果を整形し、応答する

ALT 図3 要求の構造例

 このように、ユースケース記述は要求を構造化するために非常に有効であり、ユースケース図はその構造を俯瞰するのに適しています。ただし、ユースケース図にはアクター(この例ではユーザ)との相互作用は表現されないため、正しい理解にはユースケース記述(またはこれに相当する記述)は欠かせません。ユースケース図を一生懸命作図して、肝心のユースケース記述がぼろぼろというケースを非常に多く見かけますが、むしろユースケース図はオマケ程度に考えても差し支えありませんのでご注意ください。

 話を元に戻しますと、要求の構造化によって、ユーザがシステムに求めるもの(WHAT)と、それを実現するためのシステムの機能(HOW)が整理されます。この構造化がきちんとされることが、コンポーネント再利用においても非常に重要な意味を持つことになるのです。

(3)コンポーネントの再利用に必要なもの

 以上、要求のタイプ(機能、非機能)とシステムアーキテクチャの関係、機能要求の構造を整理しました。いまさらいうまでもありませんが、図1に示したとおり、システムアーキテクチャは階層構造です。階層構造は「各層がその直下の層にのみ依存する」ことを意味します。

 したがって、コンポーネントの再利用を実現するには、直下に存在するフレームワークが同じでなければなりません。もちろん、同一ソフトウェアのフレームワークだけではなく、同一仕様に準拠したフレームワークであればソフトウェアは別でもよいということもありえます。先に例として挙げたEJBコンテナや、Webコンテナはまさにこれを狙ったものです。ただし残念ながら、実際にはアプリケーションサーバ製品ごとに微妙な違いがあり、その微妙な違いの部分を使ってしまうと、完全な互換性を得ることが難しいのは皆さんご存じのとおりです。

 フレームワークは同一のものを使うと決めたとして、次に必要なことは、コンポーネントが自分たちのニーズを満たしているかを確認することです。

 問題は、この“ニーズを満たしているかを確認する”ことが非常に難しく、真剣に行おうとすると非常にコストがかかることにあります。実際には「確認コストが無駄になる(調査した結果、コンポーネントは使えない)かもしれない」と思った時点で確認作業を行うことすらやめてしまうことの方が多いのではないでしょうか。また、実際に調査を行った場合でも、個別の機能をみる限りでは使えそうだが、複数の機能間での連携を考えていくとやはり使えない、ということも珍しくありません。

 これらの問題を解決するためにコンポーネント提供者は、コンポーネントが実現している要求を2つのレベルで開示する必要があります。2つのレベルとは、図2の要求の構造の中の、「ユーザー目的要求レベル」「システム要求レベル」です。要求のレベルとしては、さらに上位(抽象度が高い)にビジネス要求レベル、またはサマリー要求レベルと呼ばれるものがありますが、通常これらは、コンポーネントが実現している機能(what)とその方法(how)には直接関係がありません。

ALT 図4 要求レベルと確認担当

 図4は、各要求レベルとそれに対応する確認担当を表しています。

 ユーザー要求レベルは、ユーザーがシステムに何を求めるかを表したものです。そして、システム要求レベルは、システムがユーザー要求をどのように実現するかを表したものです。ユーザーは、コンポーネントのユーザー目的要求レベルの仕様を確認し、自分の要求をコンポーネントが満たしているか否かを判断します。開発者はコンポーネントのシステム要求レベルの仕様を確認し、ユーザー目的要求が自分たちの望む方法で実現されているか否かを判断します。このような2段階の確認を行って初めて、コンポーネントの再利用を決めることができるのです。

 さらに必要なのは、コンポーネントに関連する非機能要求の開示です。これには、前提とするフレームワークについての説明や、パフォーマンス、開発者にとっての拡張性(コンポーネントの機能拡張)、システムにとっての拡張性(スケーラビリティへの対応)が含まれます。

 以上を簡単に整理すると、コンポーネントの再利用を実現していくためには、

「共通のフレームワークの利用≒共通の非機能要求」

「機能要求の適切な構造化と、コンポーネントが実現するユーザー目的要求、システム要求の開示」

が必要であるということになります。

(4)コンポーネントの粒度

 コンポーネントの粒度は、常に、コンポーネント化を考える人の悩みの種でしょう。これに対する明確な回答は、私自身持ち合わせていません。ただ、今までの経験からいえることはユーザー目的要求またはシステム要求のどちらかの粒度で作成しており、再利用のニーズがどのレベルの要求に対するものかで適切な粒度が決まるということです。つまり、当たり前のことですが、再利用のニーズがあって初めて適切な粒度が判明するということです。ですから、再利用のニーズもない(明らかでない)のにコンポーネントの粒度で悩むことはせずに、そのような場合は単なるクラスライブラリや関数ライブラリとしておく方が、後に再利用のニーズが明らかになったときにも対応が容易なのです。


 プロジェクトごとに、似たような機能をいつも作っている人、また、毎回そのような要求仕様を1から書き起こし、提示している人、あるいは、これから社内資産としてのコンポーネントの整理を行っていこうとされている人は、まず、これらの条件を満たせるかどうかを確認してみてください。あなたのプロジェクトチームが再利用に対する心情面での問題をクリアしたとしても、要求に関するこれらの条件をクリアしない限り、コンポーネントの再利用は実現できないでしょう。世の中には、全く同じ要求というものは存在しません。結局、どこまで妥協(既存コンポーネントの仕様に合わせる)できるかということに焦点が絞られるのですが、皆さんのプロジェクトではいかがでしょうか?

プロフィール

今村智(いまむらさとし)

 メインフレームでの証券取引所データリアルタイム配信システム開発を経験後、数々のオブジェクト指向での企業情報システム開発を経て、ソフトウェア開発に関わる方々を少しでもハッピーにすべく、要求開発・管理、ソフトウェア開発プロセス構築に関する啓蒙、コンサルティングに従事。


Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ