トピック

はじめにページの先頭へ

RUP の複数の作業において、形成される設計モデルを検討し、品質のさまざまな局面について判断をくだし、場合によっては設計モデルをリファクタリングする必要性について吟味します。アーキテクチャーおよび設計要求に関する違反がなく、実装時においてもシステムをアーキテクチャーの開発構想にかなったものにするには、実装後にシステムの統一性を維持できることも重要です。RUP では作業において次の主なチェックポイントが発生します。アーキテクチャーのレビュー設計レビューおよびコード・レビュー

それとは異なりますが類似する問題が、アーキテクチャーと設計の合成時に生じます。アーキテクチャー分析 (『アーキテクチャー概要の作成』および『利用可能な資産の調査』を参照) および既存の設計要素の取り込みの作業において、ソフトウェア・アーキテクトは既存の設計およびコード資産を、必要があればリバース・エンジニアリングの後で設計モデルに取り込んで、再利用する可能性を検討することをお勧めします。再利用する資産に対して何らかの品質証明が存在しない場合には、ソフトウェア・アーキテクトはそれらの資産を、新たに作成された設計およびコードと同様に詳しく調査します。

いずれの場合も、ソフトウェア・アーキテクトがこの静的分析を行う必要性は同じです。

  • コード化されたアプリケーション (またはそのフラグメント) を取り込むには、そのアプリケーションのシンボリック構造を発見し、理想的には、それを UML 形式で設計モデルにリカバリーします。このブラウズ可能な文書成果物は、文書が存在しないか、古くて使用できない場合にソフトウェア・アーキテクトが実際にコードがどのように構造化されるかを参照できるという点からも重要な価値があります。
  • 設計モデルを分析可能にするには、../artifact/ar_metr.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません成果物: 測定計画書で呼び出され、成果物: ソフトウェア・アーキテクチャー説明書および../artifact/ar_projspecgls.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません設計ガイドラインへの準拠をチェックする品質メトリック (結合 など) を収集します。
  • 必要な場合に修正処置を実行できるように、重大なアーキテクチャーまたは設計の変更について認識します。重要度はソフトウェア・アーキテクトにより設定された基準に照らして決定されます。

理論的には、これらのニーズは検査によって満たすことができますが、実際には、より大規模で複雑なシステムの場合は何らかの自動化支援が必要となります。 次のセクションでは、これらのトピックを推敲し、ツール・サポートの例を示します。

アーキテクチャーのディスカバリーとリカバリーページの先頭

背景

Greenfield 開発においては、要求、ドメイン・コンテキストおよび規則 (パターンと機構を含む) に基づいてソフトウェア・アーキテクチャーが形成されます。成果物である補足仕様書はアーキテクチャーを決定する上で重要な役割を果たします。このソフトウェア・アーキテクチャーを成形するプロセスは、ほとんどの場合、要求からアーキテクチャーへの直接的な機械的マッピングではないため、ディスカバリーと呼ばれることがあります。ただし、本書ではディスカバリー を異なる意味で使用し、ソフトウェア・アーキテクトがコード形式の従来のアプリケーションまたはアプリケーション・フラグメントを理解するための支援プロセスを表します。アーキテクチャーのリカバリー はそれよりも大掛かりなものです。リカバリーを使用して、ソフトウェア・アーキテクトはアプリケーションを理解するだけでなく、アプリケーションのモデルを、理想的には設計モデルと互換性のある抽象化レベルで抽出します。そうすることにより、これらのモデルをマージできる可能性が生まれ、変換によって 新規アプリケーションを、異なるプラットフォーム などに対して生成することができます。

ディスカバリー

アーキテクチャー分析 (『アーキテクチャー概要の作成』および『利用可能な資産の調査』を参照) および既存の設計要素の取り込みの作業において、ソフトウェア・アーキテクトは既存の設計およびコード資産を再利用する可能性を検討します。例えば、組織は複数の 参照アーキテクチャーを資産ベースに保有している可能性があります。それらが最新の文書およびモデルによって完成できることが理想的です。ただし、アーキテクチャー文書が存在していても、それが現行のものでない場合は、ソース・コード以上の要素が必要となる場合がよくあります。

多くの場合、ソフトウェア・アーキテクトはそのようなコードを (インターフェースが明確に定義されていても) ブラック・ボックスとして処理することはできませんが、その構造を理解する必要があります。このプロセスにおいて、ブラウズ可能なコードの説明を自動的に生成する機能は大きな支援となります。この機能を使用すれば、ソフトウェア・アーキテクトはコード形式のパターンとアンチパターンを視覚的に「発見」することができます。この種の支援の例は、Rational ソフトウェア・アーキテクト・ツールで参照できます。その例では、アーキテクチャー・ディスカバリー機能によって、Java アプリケーション用のパッケージ構造、クラス内部、継承ツリー、コラボレーションなどのトピック・ダイアグラムのデータが自動的に取り込まれます。詳しくは、Rational ソフトウェア・アーキテクトの 文書を参照してください。

リカバリーと変換

再使用可能な資産をモデルによって完成させると、これらのモデルをプロジェクト固有のモデルと結合し、変換手法を使用してプラットフォーム固有の実装へ進むことが可能になります。すべてのコードが既存のコードである場合は、変換により作成されたコードと既存のコードを統合することにより、変換ベースのアプローチを使用して資産を再使用することも可能です。

ソフトウェア・アーキテクトはアーキテクチャー・リカバリーを使用することにより、最大限の能力と柔軟性を得ることができます。リカバリー機能は豊富な意味体系を持つアプリケーションのモデルを生成し、このモデルはブラウズだけでなくコード生成にも使用できます。 実際に、明白なビジュアル表示へのリバース・エンジニアリング・コードは、多くの場合トレース可能です。 一般的に、このようなモデルをプラットフォームから独立した 設計モデルと同一レベルまで抽象化する作業を自動完了することは困難です。

これは基本的に、PIM 変換に対する PSM です (『概念: モデル駆動型開発 (MDD) 』および『モデル駆動型アーキテクチャー ® (MDA®)』を参照)。 リカバリーされた PIM (フラグメント) は、モデル・マージ (「OMG03」を参照) タイプの変換を使用して、設計モデル (PIM) と結合されます。

アーキテクチャーの分析 ページの先頭

ブラウズ可能なモデルがあれば、ソフトウェア・アーキテクトは検査によってアーキテクチャーの品質を検証できます。ただし、これは手間と時間のかかる作業であり、この方法で標準および規則への準拠を検査し、メトリックを収集するとエラーが生じやすくなります。ソフトウェア・アーキテクトはできる限りこのプロセスの可能性を追求することで、改善策を見つけ、適用することにより多くの時間をかけるべきです。自動化によってソフトウェア・アーキテクトは試験を行い、「起りうるケース」を想定し、結果をすばやくチェックすることができます。

自動化可能な作業

自動アーキテクチャー分析では、次のことが可能です。

  • アーキテクチャーのパターンとアンチパターン (異常構造) の検索
  • さまざまな構造およびレポート・ md_metri.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんメトリック に関する測定の実施
  • ソフトウェア・アーキテクトによって設定された制約への準拠の確認 (『アーキテクチャーに関する制御』を参照)

パターン の使用はプロジェクトおよび組織の標準に規定されており、パターンを使用する根拠はソフトウェア・アーキテクチャー説明書 (アーキテクチャーに関して重要である場合) または設計ガイドラインに記述されています。自動分析を使用すれば、ソフトウェア・アーキテクトはパターンの使用をすばやくチェックして、ソフトウェア・アーキテクチャー説明書および設計ガイドラインの意図に適合しているかどうか検証できます。アンチパターンとは、アーキテクチャーの堅固さを低下させたり、より複雑にしたり、保守しにくいものにすることで、アーキテクチャーを弱体化させる異常なアーキテクチャー構造および設計構造です。

実行する測定は、成果物: 測定計画書で呼び出されます (推奨されるメトリックをmd_metri.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません『ガイドライン: メトリック』で参照してください)。測定計画書には、メトリックの使用方法も記述されています。例えば、高い値または低い値のどちらが望ましいか、それが重要な傾向かどうかなどです。したがって、メトリック分析においてホット・スポット (変更によって、収集されたメトリックが大幅に改善される場所) を識別すると役立ちます。当然、これらは構造上の異常に関連することがよくあります。そこでソフトウェア・アーキテクトは基本的な改善目標を持ち、変更を行ったり、完了後にテストできるフォローアップ・アクションを委任することができます。

分析ターゲット

分析ターゲットは、実施する開発アプローチに応じて、ライフ・サイクルを通じて変化します。プロジェクトが変換 (世代別) アプローチを使用する場合は、生成されるアプリケーションが常に設計と同期化されるという前提事項のもとにターゲットは通常、設計モデルになります。成果物: 実装モデルが作成され、個別に保守される場合やコードを再利用する場合、フォーカスはコードおよび、ソフトウェア・アーキテクチャー説明書および設計ガイドラインに照らした測定においてコードがアーキテクチャーの統一性を保つことに移ります。

このタイプの (実装モデルに関する) 分析は、実際には分析目的のために明示的な設計モデルをリカバリーしない場合があります。ただし、その場合でも分析はコーディング標準ではなく、アーキテクチャーと設計の問題 (コード内で明白であるため) に関係しています。

これらの概念および機能の例

Rational ソフトウェア・アーキテクト・ツールは、アーキテクチャーのディスカバリーにより Java アプリケーションの文書をリカバリーする機能を持つほか、アーキテクチャーの潜在的な障害スポットを示す事前定義パターンのセットに対するレポートを識別できます。これらのパターンには次のものが含まれます。

  • Butterfly
  • Breakable
  • Hub
  • Tangle
Butterfly

butterfly は、butterfly が変更されると影響を受けるクラスなどの他の従属エレメントとさまざまな関係を持つエレメントです。直接的な関係を持つこのようなエレメントをローカル butterfly と呼びます。Rational ソフトウェア・アーキテクトは、アプリケーションのカスケードを実行するときに関係をトレースして、エレメントの変更が直接的な依存だけでなく、エレメントの依存、さらにはアプリケーション全体の変化にも影響を及ぼすかどうかを判別できます。このような、さまざまな間接的な依存関係を持つエレメントをグローバル butterfly と呼びます。ローカル butterfly の図を以下に示します。この図には、UML 依存関係以外の関係も持ちうることが示されています。例えば、エレメントが別のエレメントを実現するとそのエレメントに依存します。エレメントの指定を変更すると、それを実現するエレメントに影響を及ぼします。

この図は、4 つの依存を持つクラスを示します。そのうち 2 つは使用の依存関係、1 つは一般化の関係、1 つは実現関係です。

ローカル Butterfly

Breakable

breakable は、多くの依存関係を持つエレメントです。つまり、breakable エレメントは別のエレメントに依存する場合に、多くの関係を持ちます。それらの別のエレメントが変更された場合、breakable に影響を及ぼします。butterfly と同様に、直接的な関係を持つ場合、そのエレメントをローカル breakable と呼び、エレメントに影響を与える多くの間接的な関係を持つ場合はグローバル breakable と呼びます。グローバル breakable はアプリケーションの様々な箇所の変更に対してぜい弱であり、モジュール性に欠けることを示します。ローカル breakable の図を以下に示します。

この図は、4 つの別のクラスに依存するクラスを示します。そのうち 2 つは使用の依存関係、1 つは一般化の関係、1 つは実現関係です。

ローカル Breakable

Hub

hub は、butterfly と breakable の特性を結合させたエレメントです。このエレメントにはローカル 形式とグローバル 形式があります。グローバル hub が存在するということは、区分化が不十分であることを示し、その結果ソフトウェアは変更の影響をきわめて受けやすくなり、変更がアプリケーション全体に波及する傾向があります。

Tangle

tangle は大規模なエレメントのグループであり、それらの関係はきわめて複雑に絡み合っているため、1 つのエレメントの変更が他のすべてのエレメントに影響を及ぼす可能性があります。このような構造は、非常に不安定な状態を招く原因となります。

Rational ソフトウェア・アーキテクト・ツールを使用すれば、ソフトウェア・アーキテクトは、これらのホット・スポットをすばやく発見し、設計者と協力してそれらを修正することができます。 詳しくは、Rational ソフトウェア・アーキテクトの文書を参照してください。

タイミング

これらの分析の結果は、あらゆるレビュー・マイルストーンにおいて、アーキテクチャーおよび設計品質の目標および定量化が可能な裏づけとして重要であり、『設計モデルの編成の更新』 (アクティビティー: 既存の設計要素の取り込み) の場合と同様に重要なアーキテクチャーの変更がある場合にも重要です。

アーキテクチャーに関する制御 ページの先頭

ソフトウェア・アーキテクトの開発構想はソフトウェア・アーキテクチャー説明書に取り込まれ、設計者のための実践的なガイドラインは設計ガイドラインで参照できます。その開発構想をすべてのスタッフが共有したとしても、日常のプロジェクト作業において緊急事態が発生する中で、開発構想はその明瞭さを失う可能性があります。守るべき期限がある場合、主要部分以外はカットされ、すべての決定にソフトウェア・アーキテクトが参加できるとは限らない場合があります。そして制御に関する問題が生じます。プロジェクト管理者がしきい値および制限を設定し、それを監視する必要があるように (../activity/ac_monpr.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません『作業: プロジェクト・ステータスの監視』を参照)、ソフトウェア・アーキテクトはソフトウェアの設計および実装に対して同様の役割を担います。

アーキテクチャーの制御を使用することによって、ソフトウェア・アーキテクトはアーキテクチャーの制約実施の規則を作成する機能が得られます。例えば、特定のインターフェースを実現するたびに注意を喚起する規則を定義します。ツール・サポートを使用しないこの規則の単純式では、違反を見つけるためのレビューをほぼ一定に行う必要があります。これを自動化することにより、規則がエンコードされるため、一連の規則に関する違反をアーキテクチャー分析時に発見することができます。これはその後も継続して実行され、拡張制御環境によって規則が設計およびコード生成プロセスにエンコードされるため、まずは規則の違反を未然に防ぎます。その場合も、手動のレビュー・プロセスが大幅に向上します。

Rational ソフトウェア・アーキテクト・ツールには、Java アプリケーションのための同様の機能が含まれ、ソフトウェア・アーキテクトは規則を設定し、その準拠を検証するための分析を実行できます。詳しくは、 Rational ソフトウェア・アーキテクトの文書を参照してください。

Rational Unified Process   2003.06.15