RASの具体的な内容を見ていこう。前述したように，RASの実体はアセットの属性情報を記述するXMLドキュメントの構造を定義したXMLスキーマである。その構造を図4に示した。
|
|
|
図4●RASの構造 RASは，アセットの基本情報を記述する「コアRAS」と拡張情報を記述する「プロファイル」で構成する。コアRASはさらに分類情報，個々の成果物の情報，作業内容，他アセットとの関連情報の4つのセクションから成る [画像のクリックで拡大表示] |
RASは，基本的な属性情報を記述するための「コアRAS」と，拡張的な属性情報を記述するための「プロファイル」という2つの部分から成る。RASによるアセットの再利用に取り組むには，まずコアRASの内容をしっかり理解することが重要だ。
コアRASは4つのセクションで構成する。（１）アセットを分類・検索するための情報や適用領域を記述する「Classification」，（２）アセットを構成する個々の成果物の名前や種類などを記述する「Solution」，（３）アセットを利用する際に，どんな作業を実施する必要があるのかを示す「Usage」，そして（４）当該のアセットと関連する他のアセットの情報を記述する「RelatedAsset」である。（１）～（３）の3つのセクションについては，それぞれに関連する詳細な属性情報を記述するための要素（各セクションの細目に相当）がいくつか定義されている（詳しくは後述）。
一方，プロファイルは，成果物の種類に応じた固有の属性情報を記述するためのものだ。実体はコアRASと同様，属性情報を記述するXMLドキュメントの構造を定義したXMLスキーマである。
「RAS 2.1版」では，コンポーネント用の「デフォルト・コンポーネント・プロファイル」と，Webサービス用の「デフォルト・Webサービス・プロファイル」が用意されている。フレームワーク用とパターン用のデフォルト・プロファイルは，RASの今後のバージョンで規定される予定だ。なお，必要に応じて属性情報を追加して記述したい場合は，拡張用のデフォルト・プロファイルを使う。
コアRASの4セクション
ここで，RASで規定されたXMLスキーマの全体像を示すUMLモデルを図5に示した。少し複雑に見えるかもしれないが，図の中央の上部にある「アセット（Asset）」に対して，コアRASの4つのセクションと，それぞれに関連する要素，およびプロファイルをクラス図として表現したもの，と考えると分かりやすいだろう。個々のクラス名や，各クラスが備える属性名が，マニフェスト・ファイルのXMLタグを表している。
|
|
|
図5●RASで規定されたXMLスキーマの全体を表すUMLモデル 「アセット（Asset）」に対して，コアRASの4つのセクションと，それぞれに関連する要素，およびプロファイルの関連をクラス図で示している [画像のクリックで拡大表示] |
以下では，4つのセクションを個別に解説していく。ただし，説明に使用するUMLモデルは概要レベルのものであり，実際にはさらに詳細なレベルのモデルがあることを念頭に置いて読んでいただきたい。
（１）Classification
アセットは通常，様々な“見方”で分類できる。例えば，どんな業種のシステムに適用するアセットなのかという見方（ビジネス・ドメイン）では，「銀行向け」，「保険会社向け」，「証券会社向け」などと分類できる。一方，どんな技術を採用したアセットなのかという見方（テクノロジ・ドメイン）では，「J2EE（Java2 Platform，Enterprise Edition）1.4」，「.NET1.1」などと分類できるだろう。
Classificationセクションでは，このようにアセットをきちんと分類して，効率的に検索するための情報を記述する。関連する要素として，「Context」と「Descriptor／DescriptorGroup」を持つ（図6）。
|
|
|
図6●Classificationセクションの構造を表すクラス図 効率的にアセットを検索できるようにするための分類情報を記述するセクション。関連する要素として「Context」と「Descriptor／DescriptorGroup」がある |
Contextは，アセットを分類するときの見方と，それぞれの見方におけるカテゴリーを定義するもの。上記の例では，「ビジネス・ドメイン」という見方には，「銀行向け」，「保険会社向け」といったカテゴリーが存在することになる。マニフェスト・ファイルでは，Contextのタグは，見方の数だけ宣言される。
一方，Descriptorは，Contextのより詳細な情報，通常はアセットの特徴や品質などを記述する。これにより，アセットを検索する際の効率をより高めることができる。
「DescriptorGroup」は，関連する複数のDescriptorをまとめるためのものだ。図を見ると分かるように，DescriptorGroupのクラスには「reference」属性がある。これにより，アセットが参照する外部のドキュメントを示すことができる。
（２）Solution
Solutionセクションでは，アセットを構成する成果物に関する情報を具体的に記述する（図7）。
|
|
|
図7●Solutionセクションの構造を表すクラス図 アセットを構成する成果物に関する情報を記述するセクション。関連する要素として，成果物の名称や種別を示す「Artifact／ArtifactType」や「ArtifactContext」などがある |
関連する要素として「Artifact（成果物）／ArtifactType」などを持つ。「Artifact」には成果物の名前などを，ArtifactTypeには成果物の種別を記述する。例えば，Artifactの「name」属性に「xx分析モデル」と記述し，ArtifactTypeに「ユースケース（Use Case）」と記述する，という具合だ。こうすることで，個々の成果物の意味を明確に示すことができる。Artifactの「version」属性に，ソフトウエアの構成管理に利用するバージョン情報を記述することも可能だ。
図を見ると分かるように，Artifactは他のArtifactを含んだり，他のArtifactと依存関係を持つことができる。また「ArtifactContext」と呼ぶ要素によって，そのArtifactと特定のContextを関連付けることができる。これにより，その成果物がどのようなカテゴリに位置づけられるのかが分かる。さらに，「VariabilityPoint」と呼ぶ要素によって，その成果物が再利用される際に変更されることを想定している個所を記述することも可能だ。こうした構造は，成果物をパッケージ化する際の粒度や変更容易性，意味の明確性などを高めるものと言える。
（３）Usage
Usageセクションでは，アセットを再利用する際に行うべき作業（Activity）を記述する。「Activity」は特定のContextに関連付けられ，どのような場面における作業であるかが示される。Activityが他のActivityを参照することもあるため，再帰構造を持っている。
Activityには関連する要素が3つある。個々の成果物にかかわる作業内容を記述する「ArtifactActivity」，作業を行う場面や前提，理由付けなどの情報を記述する「ContextRef」，アセット全体にかかわる作業内容を記述する「AssetActivity」である（図8）。
|
|
|
図8●Usageセクションの構造を表すクラス図 アセットを再利用する際に行うべき作業の内容や手順を記述するセクション。関連する要素として「ArtifactActivity」，「ContextRef」，「AssetActivity」がある |
具体例を示そう。例えばコアのEJBコンポーネントの再利用を考える場合，上記3つの要素の内容は以下のようになる。AssetActivityは「テスト用サーバーに.warファイルを展開する」，ContextRefは「2台でバックアップ構成を組んでいるWebアプリケーション・サーバーを使用する際に」，ArtifactActivityには「test.htmlというファイルのWebページを表示し，ページ上のボタンをクリックして動作を確認する」。
このUsageセクションは，ツール・ベンダーにとっても非常に重要な意味を持つ。というのも，Usageセクションには，前述したVariabilityPointとの関係付けによって，ツールで自動化できる作業を記述することもできるからだ。当然，ユーザーにとってはアセットや成果物の再利用がより容易になるというメリットがある。
（４）RelatedAsset
複数のソフトウエア資産を再利用できるようにする際に，1つのアセットとしてパッケージ化した方がよい場合と，別のアセットに分けてパッケージ化した方がよい場合がある。例えば，「コンポーネントxxを再利用する際には，コンポーネントyyの存在が前提になる」というように，物理的な依存関係が強い場合は，1つのアセットとしてパッケージ化すべきである。
これに対して，例えば「フレームワークaaは単独でも再利用できるが，コンポーネントbbを載せて稼働させてもよい」というように，物理的な依存関係が弱い場合は，それぞれを別のアセットとしてパッケージ化し，アセット間の関連付けを行って運用した方がよい。RelatedAssetセクションは，まさにこのようなアセット間の関係を示す場合に使用する。すなわち，対象とするアセットと関係を持つ別のアセットの情報を記述する（図9）。これにより，アセットの再利用の幅を広げることが可能となる。
|
|
|
図9●RelatedAssetセクションの構造を表すクラス図 アセット間の関係を示すためのセクション。対象とするアセットと関係を持つ別のアセットの情報を記述する |
リポジトリにアクセスするAPI
ここまで，コアRASの4つのセクションに記述する，アセットの属性情報の概要を説明してきた。RASについて，もう1つ知っておいていただきたいのが，アセットを効率的に蓄積・再利用するための「リポジトリ」である。
RAS 2.1版では，リポジトリにアクセスするためのAPI（Application Programming Interface）である「RASリポジトリ・サービス」を定めている。正確には，RASで定義したアセットを扱えるツールと，リポジトリ・サービスを実装したプログラム（以下，単にリポジトリと呼ぶ）との間の，リクエストとレスポンスを規定している。Webサービスとして実装することを前提に，JavaのAPIとWSDL（Web Services Description Language）が定義されている（詳細はRAS 2.1版のドキュメントを参照）。
すでに，スウェーデンのボルボや米国特許商標庁（USPTO）は，RASリポジトリ・サービスを利用して効果的にアセットを管理していると言われる。このほか，RASリポジトリ・サービスの実装例としては，米フラッシュラインや米コンポーネントソースのWebサイトがよく知られている。RASリポジトリ・サービスを実際に試せるものとしては，IBMが製品化する前の技術を一般公開する場である「alphaWorks」のサイトがある。ダウンロード可能なプログラムも置かれているのでぜひ試してほしい。
RAS対応ツールも登場
最後に，RASの最大の利点であるツールでの扱いやすさについて，IBMが昨年12月に出荷を開始した「Rational Software Development Platform（RSDP）」を例にとって説明しておきたい。
RSDPのシリーズ製品で，モデリング機能を持つ「Rational Software Modeler（RSM）」と，アーキテクチャの策定からコードの生成までの機能を持つ「Rational Software Ar-chitect（RSA）」では，RASで記述したアセット（RASファイル）を作成して登録したり，再利用したりできる。具体的には，あらかじめ「設定」ダイアログでRASの使用を可能にしておけば，「ファイル」メニューでRASファイルをエクスポートしたりインポートしたりできる（図10）。
|
|
|
図10●開発支援ツールを使ったマニフェスト・ファイルの作成イメージ 登録した属性情報に基づいてマニフェスト・ファイルが自動生成される（IBMのRSDPを例にとった） [画像のクリックで拡大表示] |
RASファイルの作成は，ウィザード形式のダイアログに従うだけだ。エクスポート／インポートの対象となるRASファイルは，ローカルのディレクトリにあるものを使ってもよいし，ネットワークでつながれたリポジトリを利用してアクセスしてもよい。
このように，開発支援ツールがRASの規格をサポートすれば，アセットの再利用は非常に敷居が低くなる。現時点では，RASの規格に対応した開発支援ツールはRSDPだけだが，マイクロソフトやボーランドなど，RASの規格をサポートすると表明したベンダー各社から，RASに対応した製品が投入される可能性も高い。
広範な再利用の実現に向けて
ここまで，再利用可能なアセットを記述するための標準規格であるRASについて解説してきた。アセットの作成方法や再利用方法の概要をご理解いただけたと思う。
RASによってアセット・ベースの開発を支援する環境は整ったわけだが，RASはあくまでもアセットの仕様を記述するための標準規格に過ぎない。つまり，RASに従うだけで，アセットの品質が向上するわけではない。再利用を前提とした体制作りやプロセスの策定，ナレッジマネジメントの整備にも取り組んで初めて，効果的なアセットの再利用が可能になることを忘れないでいただきたい。
|
