「UMLを用いたコンポーネント設計」

■ コンポーネントベース開発でのUMLの意味

　コンポーネントベース開発（以下CBD-Component Based Development）には“コンポーネントを作る”と“コンポーネントを再利用してシステムを作る”という2つの側面がある。CBDのスキームを機能させるためには、「どうやって独立性の高いコンポーネントを作るか」というコンポーネント開発者側のアプローチと、「どのコンポーネントが利用できるかを、いかに早い段階で見出すか」というシステム開発者側のアプローチが必要であり、これらを可能な限り“手順化”し“共有知”とすることが、組織としてCBDを採用しそのメリットを享受するためのキーである。

　従来の部品化再利用というとコードベースが主体であったが、昨今の技術の変化・選択肢の多様化を踏まえると、コードベースではなく設計レベルからコンポーネント化にむけた上記2つのアプローチを取らねば、メリットを享受することができない。

　ラショナル統一プロセスでは、モデリングの標準表記として認知されてきたUMLを使うことで、設計プロセスの“共有知化”を促し、プロセスの中で“手順化”を提示している。

■ ビジネスモデリングからシステムモデリングへ

　コンポーネントを考えたとき、「どう作るか」と同時に、「何をコンポーネント化するか」が重要である。ではその答えはどこから来るのか？ エンタープライズレベルでのCBDのメリットを考えたときに、単なるアルゴリズム的なコンポーネントだけではなく、業務を構成するパーツを再利用する、いわゆる業務コンポーネントが必要である。業務プロセスのどこが共通項であり、各プロジェクトにおいてどれが再利用可能なのかを早期に判断することが重要である。

　ラショナル統一プロセスでは、システム開発での要求定義の前段階、ビジネス工学からプロセスを定義しているが、そこで生成するモデルとして、ビジネスユースケースモデルおよびビジネスオブジェクトモデルを規定し、ビジネスモデルをオブジェクト指向的に捉えるスキームを提示している。さらにこのビジネスを表現する両モデルから、システムモデルを構成する要素への変換手順を規定している。もちろんこのモデル変換は、調整の必要のない決定的なモデルを産みだすものではない。しかし、この手順化により、ソフトウェアアーキテクチャ候補の雛型策定が可能になり、併せて再利用可能な業務コンポーネントの検討が早期に開始できる。

　次のステップとして、各種の要求事項を元にしたソフトウェア設計モデルの確定へと進むことができる。

■ コンポーネント設計の勘所

　コンポーネント設計のポイントは、「(1)Plug-and-Playを可能にする」ことであり、「(2)独立性を高める」ことにある。ここで重要となる設計要素は、インターフェースであり、注目すべきは設計要素間の依存関係である。

　コンポーネントが複数プロジェクトでの検証を経て堅牢なものへと洗練されている過程では、リファクタリングのようなテクニックを駆使して内部構造の変更は避けて通ることができない。ここで、内部実装に依存しない形でコラボレーションをモデル化できるインターフェースが重要となる。

　コンポーネント化するということは、クラスをグループ化することに他ならない。このとき、クラス間の関連（集合-部分、汎化-特化）と依存関係を意識して設計しないと、「物理的にはコンポーネント化した（＝複数のファイルに分けた）が、論理的には全てのコンポーネント（＝すなわちひとつのシステム全体）をひとつの再利用単位として使わざるを得ない」という状況が現れる。この点で、依存関係の設計は重要である。

■ 非機能要件をトレースする

　特定のコンテキストでの問題点を解決する共有知として各種のパターンが議論されている。デザインパターンを共有知のベースとすると、組織体での部品化を行うには、粒度が細かすぎる。実際には、あるアーキテクチャ、ある要素技術、あるシステム要求（機能要求や性能要求）を踏まえて、「それらのパターンが適用された結果」を再利用のベースとしたほうが効果が期待できる。すなわち“パターンが適用された結果のパターン化”が必要である。ラショナル統一プロセスでは、これをメカニズムと呼び、分析クラスの段階から、それが利用されるコンテキストを追跡することで、問題解決ノウハウの共有知化を図っている。

「コンポーネントベース開発（CBD）の実践」
WebSphere Business Components(WSBC)のコンポーネントとデザインパターンの適用

■WSBCが目指すもの

　IBMのWebSphere Business Components（以下WSBC）は、アプリケーション開発にソフトウェア部品を提供することによって開発生産性の向上を狙う。その内容は、ビジネス・コンポーネント群とコンポーネント・サービスツール群を組み合わせたものだ。IBMのサンフランシスコ・プロジェクトで蓄積されたコンポーネント関連技術などをベースとして、新たに体系化されている。

　WSBCが目指すのは、オープンな技術によってコンポーネントベース開発のバリューチェーンをつくることだ。ハードウェアの世界に部品メーカーがあるように、ソフトウェアの世界でも、コンポーネントベースのソフトウェア開発を成功させ、生産効率向上のためのバリューチェーンを作りたい。

　WSBCのコンポーネントは2種類ある。ドメイン内の単機能的なコンポーネントであるBC（Base Components）と、このBCを組み合わせたより粒度の大きなコンポーネントで1つのドメインの機能を持たせたAC（Advanced Components）だ。このBCとACという2種類のコンポーネントモデルで、ソフトウェア部品を組み合わせたアプリケーション開発を実現しようとしている。ところで、コンポーネントを設計するとき、何をコンポーネントとして見るかが重要になってくる。我々が考えているコンポーネントの粒度は、ひと昔前にビジネスオブジェクトと呼ばれていたものに近い。顧客、在庫といったオブジェクトをコンポーネントとして扱っているわけだ。

　現在用意されているコンポーネントとしては、ACでは「OrderCapture」（オーダー管理、オーダー価格算出・与信限度額算出機能等）、「TextAnalyzer」（文書内のテキスト分析、分類機能、分析ルールの生成）の2つが用意されている。

■CBDを支援するツールとルール

　WSBCは、BCとACの2種類のコンポーネントを作成するための強力なツールも提供する。このツールは、UMLモデリング、デザインパターンを使ったコンポーネントを生成を行うだけでなく、コンポーネント開発で重要となる機能外要求を満たす作業を支援する。機能外要求とは、例えばWebシステムに訪れるアクセス数やデータ量に耐えうるパフォーマンスや可用性といった要素だ。この要件を満たさないコンポーネントは、実際には役に立たないものになってしまう。

　また、コンポーネントのカスタマイズにおいて、GUIを担うコンポーネントのカスタマイズはイメージしやすいが、ビジネスロジックの部分は難しいものだ。そのため、コンポーネントのコードを変えなくても、機能を変えられることが、実は重要だ。また、時間が経つとコンポーネントの役割も変わってくる。これに対処するには、クラスのメソッドを変えるのが理想的だ。さらには、継承関係をダイナミックに変更できることも重要だ。例えば、社員、課長、部長がもつ役割（メソッド）は異なる。１人の人物が社員から課長、部長へと昇格する場合、異なるメソッドをもったクラスを継承できれば、コードの変更は最小限になる。WSBCのコンポーネントは、このような思想に基づいて設計されている。

　WSBCは、お客様がコードに手を入れなくてもすむポリシーパターンを用意している。CORBA、EJBといったオブジェクト同士の対話は、相手をよく知らないとつながらない強い関係だ。コンポーネント間のつながりを弱くすることが、他から利用しやすいコンポーネントとなるためのポイントだ。WSBCは、外部とのつながりをXMLでラッピングすることでその解答を得ている。ACでは、外部コンポーネントとの対話をXMLで行う。ACを構成するBCはEJBで対話をしている。BCの実態はCMPとEntity Beanだ。ACはSession Beanである。以上のような理由で、ACは、入力と出力しかない純粋なコンポーネントとなり、外部から利用しやすく、かつ再利用性も高めることができる。

「コンポーネント・コミュニティの形成に向けて」　

■OOTコミュニティの設立

　具体的には、Development Styleに対するスポンサーシップと同時に、技術や事例に関する情報、技術者の啓蒙を図るセミナーの開催などを行っていく。Development Styleとコンポーネントスクエアのコミュニティがコラボレーションすることで、技術情報や経験からのノウハウの共有、コンポーネント流通の促進を目指していく。

■コンポーネント流通のマーケット形成に向けて

　コンポーネントスクエアは、EJBコンポーネントのオープンな流通市場の創設、EJBの普及、EJBコンポーネントの再利用促進、EJBコンポーネントの再利用技術の標準化促進を設立の趣旨としている。ソフトウェア部品の再利用推進が、開発生産性の向上とソフトウェアの信頼性向上、ソフトウェア開発の製造工程における近代化に寄与することを目指す。
　コンポーネントスクエアのマーケットプレイスは、単なるマッチングサイトではない。信頼感のある市場を形成するために、コンポーネントスクエアが定める会員制度を遵守できる法人会員とその企業の社員だけがコンポーネントの売買を行えるルールとなっている。これによって、商品供給や権利許諾における信用、与信供与といった最低限の信頼を確立する。

　会員資格にサプライヤーとバイヤーの区別はなく、会員は随時サプライヤーにもバイヤーにもなれる。法人会員の会費は年間30万円で、法人会員の社員は無制限にユーザー会員として登録が可能だ。法人会員が受けられるサービスは、マーケットプレイスに提供されたコンポーネント商品の購入やマーケットプレイスを通じた商品の販売のほかに、Java/EJBに関する技術情報やコンポーネント商品の導入事例に関する情報の提供を受けられる。
　コンポーネントスクエアで扱う商品は、EJBコンポーネントとそれに付随するソフトウェアやJavaで作成されたサーバサイドのソフトウェアだ。これらは、フレームワーク、パッケージ化されたコンポーネント製品であるコンポーネント・パッケージ、特定のフレームワークやミドルウェアでのみ利用できる特定基盤コンポーネントと、それらに依存しない汎用コンポーネントなどで構成される。そのほかには、アプリケーションサーバや開発ツール等のJavaでの開発・実行に必要なソフトウェアなど、ソフトウェアの生産性向上につながる製品を幅広く扱っていく。

　マーケットプレイス以外にも、コンポーネントスクエアはサービスを提供していく。例えば、社内に有益なコンポーネント部品を蓄積しているにもかかわらず、開発に追われて商品化の時間がない、商品化のノウハウがない、といった課題をもった企業を対象に、コンポーネント部品を商品化するまでのコンサルティングを提供する。さらには、社内のさまざまな部署に蓄積されたコンポーネントをうまく活用したい大企業に対しては、コンポーネント部品の管理やドキュメントの標準化といった作業をコンポーネントスクエアにアウトソースできるサービスも提供予定である。

　会員登録はコンポーネントスクエアのサイトからダウンロードできる会員規約に同意の上、申込書を提出することで手続が完了する。また、法人会員の社員は法人ユーザー会員としてサイト上で登録することが可能だ。

　コンポーネントスクエアは、OOTコミュニティで、成功例だけでなく失敗例も含め、さまざまなノウハウを蓄積して技術者の交流をはかりたい。

Development Style Initialsponsorページ