トピック

概論 先頭へ

以下の点を根拠として、全体的にみてシステムは堅固なアーキテクチャーの基盤の上に載っている。

  • アーキテクチャーは安定していると思われる。

    作成フェーズの特性上、安定の必要性があるのは当然のことです。作成においては、プロジェクトは通常は拡大します。それは、共同で作業する開発者 (製品の作成にあたって他の開発者との多少のつながりをもつ) の数が増えるからです。 アーキテクチャーが安定していないと、作成において必要とされる程度の独立性と並列性を達成することはできません。

    安定したアーキテクチャーの重要性は、過大評価されすぎることはありません。 「ほとんど最高に近ければ十分である」という考えに陥らないでください。不安定は不安定でしかなく、先を急ぐよりは、現在の作成フェーズが遅れてもアーキテクチャーを是正するほうがましです。 開発者がアーキテクチャーの基盤上での構築に取り組んでいる間に、アーキテクチャーの修理作業にからんで調整上の問題が発生すれば、スケジュールが早まれば確実に得られたはずの利益が簡単に消え去ってしまいます。 作成フェーズでのアーキテクチャーの変更は、多大な影響を及ぼします。多くの場合、コストがかかり、混乱を生じ、しかも意欲の喪失をまねきます。

    アーキテクチャーの安定度の評価における本当の難題は、「分からないものは分からない」という点にあります。安定度は、見込まれる変更に対して相対的に評定されるからです。 すなわち、安定度は、本質的に主観的に評定されるということです。 しかし、そのような主観性を、単なる推測以上の土台の上に置くことができます。 アーキテクチャーそのものは、アーキテクチャーの面から見て重要なシナリオを考慮に入れたうえで開発されます。そのようなシナリオとは、システムが対応すべき技術的に最もやりがいのある作業を代表するユース・ケースの 1 つです。 アーキテクチャーの安定度の評価では、将来そのアーキテクチャーにおいて「想定外の事態」が起きないようにするため、アーキテクチャーの対象を広範囲に設定することも懸案事項の 1 つになります。

    アーキテクチャーに関するこれまでの経緯も重要な指針になることがあります。アーキテクチャーの変更率が低い場合に、新しいシナリオを取り上げたときにも低いままであれば、そのアーキテクチャーは安定していると考えてもよい十分な根拠となります。 それとは逆に、新しいシナリオが原因でアーキテクチャーに変更が加えられた場合は、そのアーキテクチャーはまだ発展途中であって、基本的な点で未確定であるということです。

  • システムの複雑さは、そのシステムに備えられた機能性に一致する。
  • 以下のスキルと経験をふまえたうえで、概念上の複雑さはそれに見合っている。
    • ユーザー
    • オペレーター
    • 開発者
  • システムには、整合性があってしかも首尾一貫した単一のアーキテクチャーがある。
  • コンポーネントの数とタイプは妥当である。
  • システム全体を通して一貫したセキュリティー機能が備えられている。 すべてのセキュリティー・コンポーネントは連携して機能し、システムを安全保護している。
  • システムは、その可用性目標を達成することになる。
  • 障害の発生時には所定の時間内にシステムがリカバリーできるアーキテクチャーである。
  • システムの基盤となる製品と技法は、推定寿命に符合しているか。
    • 寿命の短い暫定 (戦術的) システムは、旧テクノロジーを使って安全に作成することができます。これは、まもなく廃棄されるからです。
    • 推定寿命の長いシステム (大半のシステム) は、保守と拡張に対応できるようにして、将来の要件への対処を可能にするために、最新のテクノロジーと方式に基づいて構築する必要があります。
  • アーキテクチャーには、チームの並行開発を目的としたパーティション化を可能にするために明確に定義されたインターフェースが備わっている。
  • モデル・エレメントの設計者は、設計を完遂するために十分アーキテクチャーを理解し、モデル・エレメントを開発することができる。
  • パッケージ化のアプローチをとれば、複雑さが軽減され、理解が深まる。
  • パッケージ内での結合力を極限まで高めるようにパッケージが定義されている一方で、パッケージそのものは互いに疎結合されている。
  • 共通アプリケーション・ドメイン内の似通ったソリューションを考慮の対象とした。
  • ソリューション案は、問題領域で一般に認知されている人物にとって簡単に理解できるものである。
  • チーム内の全員が、ソフトウェア設計者から提示されたものと同じアーキテクチャーの観点を共有している。
  • ソフトウェア・アーキテクチャー説明書は現行版である。
  • 設計ガイドラインを守っている。
  • 技術上のリスクはすべて削減されたか、または偶発時対処計画によって対応されている。 新たに見つかったリスクは文書化されて、生じうる影響を分析した。
  • パフォーマンスの主要要件 (確定済み予算) は満たされた。
  • テスト・ケース、テスト用具、およびテスト構成は調べて確認済みである。
  • アーキテクチャーが「過剰設計」であるとは考えられない。
    • 該当するメカニズムは、使用法が十分に簡潔である。
    • メカニズムの種類は妥当な数であり、システムの有効範囲および問題域の用途と整合している。
  • 現在の反復で定義されたすべてのユース・ケースの実現は、下図に示されているとおり、アーキテクチャーによって実行することができる。
    • オブジェクトどうしの相互作用
    • タスクとプロセス間の相互作用
    • 物理ノードどうしの相互作用

モデル 先頭へ

アーキテクチャーの分析に関する考慮事項 Top

概要
    • サブシステムとパッケージのパーティション化とレイヤリングには、論理的に一貫性がある。
    • すべての分析メカニズムは、特定済みおよび説明済みである。
サブシステム
    • 上位レベルのレイヤー内のサブシステムのサービス (インターフェース) は、定義済みである。
    • サブシステムとパッケージの相互依存関係は、それぞれの中のクラスどうしの関係に対応している。
    • サブシステム内のクラスは、そのサブシステムで識別済みのサービスをサポートする。
クラス
    • 主要なエンティティー・クラスとその相互関係は特定済みである。
    • 主要なエンティティー・クラスどうしの関係は定義済みである。
    • 各クラスの名前と説明は、そのクラスが果たす役割を明確に反映している。
    • 各クラスの説明は、そのクラスの責務を正確に表明している。
    • 該当する場合、分析メカニズムに対してエンティティー・クラスをマップ済みである。
    • 集約と関連付けの役割名は、互いに関連しあったクラスの関係を正確に言い表している。
    • 関係の多様性は正しい。
    • 主要なエンティティー・クラスとその相互関係は、ビジネス・モデル (存在する場合)、ドメイン・モデル (存在する場合)、要件、および用語集のエントリーと整合している。

モデルに関する一般考慮事項 先頭へ

    • モデルは、その目的が確定されたうえで、それに適した詳細レベルになっている。
    • 推敲フェーズにおけるビジネス・モデル、要件モデル、または設計モデルの場合、実装に関する問題に重点を置きすぎていない。
    • 作成フェーズにおける設計モデルの場合、比較的単純なエレメントを組み合わせて使って、構築する設計を複雑化することで、モデル・エレメントどうしの機能性の釣り合いがよくとれている。
    • モデルは、問題領域に当てはまるモデル概念への全面的な通暁と適性を示している。身近な問題に合わせてモデリング技法が適切に使用されている。
    • 概念は、可能なかぎり簡潔な方法でモデル化されている。
    • モデルは簡単に発展させられる。見込まれる変更には簡単に対処できる。
    • それと同時に、簡略性や理解しやすさを犠牲にして、わざわざありそうにない変更を処理するようにモデルを過剰に構造化していない。
    • モデルの背後にある主要な前提事項は、文書化されていて、しかもモデルの検閲者に対して表示できる。 その前提事項が特定の反復に対して当てはまる場合、そのような前提事項のもとに (必ずしもその前提事項外ではないとはかぎらない) モデルを発展しなければならない。 前提事項を文書化すれば、考えうる「すべて」の要件を設計者が確認する手間を省く手段になります。 反復プロセスでは、考えうるすべての要件を分析したり、将来のすべての要件を取りあげたモデルを定義したりすることは不可能です。

ダイアグラム 先頭へ

    • ダイアグラムの目的は、明確に述べられていて分かりやすいことにある。
    • グラフィカル・レイアウトは簡明で、所定の情報をはっきりと伝えている。
    • ダイアグラムは、その目的を達成するだけで十分であり、それ以上は必要ない。
    • 詳細にわたりすぎないよう、そして明快さを向上するように、カプセル化が効果的に使用されている。
    • 詳細にわたりすぎないよう、そして明快さを向上するように、抽象化が効果的に使用されている。
    • モデル・エレメントは、相互関係を効率よく伝えるように配置されている。互いに似通っていたりほとんど結合状態のエレメントはまとめてグループ化されている。
    • モデル・エレメントどうしの関係は、分かりやすい。
    • モデル・エレメントには、分かりやすさを高めるのに役立つラベルが付けられている。

説明書 先頭へ

    • 各モデル・エレメントにはそれぞれ特定の目的がある。
    • 不必要なモデル・エレメントはない。いずれもが、システムにおいて不可欠な役割を果たす。

エラー・リカバリー 先頭へ

    • 各エラーまたは例外ごとに、システムを「正常」な状態にリストアするためのポリシーが定義されている。
    • 起こりうるユーザーの入力エラーまたは外部システムから得る誤ったデータのタイプごとに、システムを「正常」な状態にリストアするためのポリシーが定義されている。
    • 例外状態を処理するために一貫して適用されるポリシーがある。
    • データベース内のデータの破壊を処理するために一貫して適用されるポリシーがある。
    • これまでどおりデータをシステムに入力して後で保管できる場合も含め、データベースが使用不能になった場合の処理のために一貫して適用されるポリシーがある。
    • システムとシステムがデータを交換する場合に、システムがデータ・ビューを同期する方法に関するポリシーがある。
    • フォールト・トレランスまたは高い可用性を実現するためにシステムが冗長プロセッサーまたはノードを利用する場合、複数のプロセッサーまたはノードが、自身をプライマリーであると「考え」たり、どのプロセッサーまたはノードもプライマリーではないと「考え」たりしないような戦略がある。
    • 分散システムの障害モードが識別されていて、障害に対処する戦略が定義されている。

遷移とインストール 先頭へ

    • データや操作機能を喪失しないで既存のシステムをアップグレードするためのプロセスが定義済みであって、テスト済みである。
    • 前のリリースで使われていたデータを変換するプロセスが定義済みであって、テスト済みである。
    • 製品のアップグレードやインストールに必要なリソースの量と時間がよく理解されていて、文書化されている。
    • システムの機能を一度に 1 ユース・ケースずつ活動化することができる。

管理 先頭へ

    • システムの稼働中にディスク・スペースの再編成またはリカバリーを行うことができる。
    • システムの構成のための責務と手順が確認済みであって、文書化されている。
    • オペレーティング・システムまたは管理機能へのアクセスが制限されている。
    • ライセンス交付要件が満たされている。
    • システムの稼働中に診断ルーチンを実行できる。
    • システムは、自身で操作パフォーマンス (たとえば、容量しきい値、パフォーマンスの限界しきい値、リソースの枯渇など) をモニターする。
      • しきい値に達した場合にとるアクションが定義済みである。
      • アラーム処理ポリシーが定義済みである。
      • アラームの処理メカニズムが定義済みであって、プロトタイプ化およびテスト済みである。
      • アラームの処理メカニズムを「調整」して、偽または冗長のアラームを防止することができる。
    • ネットワーク (LAN、WAN) のモニターと管理のためのポリシーと手順が定義済みである。
    • ネットワーク上の障害を特定することができる。
    • トラブルシューティングに役立てるために使用可能なイベント・トレース機能がある。
      • 設備のオーバーヘッドが了解されている。
      • 管理スタッフには、設備を効率よく使用するための知識がある。
    • 不純な意図をもったユーザーが以下を行うことはできない。
      • 入力に進入する。
      • 重大なデータを破壊する。
      • すべてのリソースを使い果たす。

パフォーマンス 先頭へ

  • パフォーマンス要件は妥当であって、問題領域内の実際の制約事項を反映している。その指定は任意ではありません。
  • システム・パフォーマンスの見積もり (必要に応じて作業負荷分析モデルを使ってモデル化されたもの) が存在し、それは、パフォーマンス要件は重大なリスクではないことを示している。
  • アーキテクチャーのプロトタイプを使ってすでにシステム・パフォーマンスの見積もりを検証済みである。パフォーマンスが重視される要件の場合はこれが特に当てはまる。

メモリー使用 先頭へ

    • アプリケーション用のメモリー予算が定義済みである。
    • メモリー・リークの検出と防止のための処置がとられている。
    • 仮想メモリー・システムの使用、モニター、および調整の方法を定義して一貫して適用されるポリシーがある。

コストとスケジュール 先頭へ

    • これまでに開発したコードの実際の行数は、現在のマイルストーンで見積もったコードの行数と合っている。
    • 見積もりの前提事項は見直されて、有効のままである。
    • 実際の最新の実績と生産性パフォーマンスに沿って、コストとスケジュールの見積もりは再計算済みである。

ポータビリティー 先頭へ

    • ポータビリティー要件が満たされている。
    • プログラミング・ガイドラインに、ポータブル・コードの作成に関するガイダンスが述べられている。
    • プログラミング・ガイドラインに、ポータブル・アプリケーションの設計に関するガイダンスが述べられている。
    • ポータビリティーの要件を検証するために、「ポートのテスト」が行われた。

信頼性 先頭へ

    • 品質の測定値 (MTBF、未解決の不良箇所数、など) を満足している。
    • アーキテクチャーには、災害時またはシステム障害時のリカバリーに対する備えがある。

セキュリティー先頭へ

    • セキュリティー要件が満たされている。

社内の課題 先頭へ

    • チームはしっかりした構造であるか。 各責務は、チームどうしによってうまく分担されているか。
    • チームの有能性を阻害する政治的、組織的、管理的な問題はあるか。
    • 対人関係で対立はあるか。

ユース・ケース・ビュー 先頭へ

ソフトウェア・アーキテクチャー説明書のユース・ケース・ビューのセクションは次のとおりです。

    • 各ユース・ケースはアーキテクチャーという観点から見て重要であり、以下の理由でそのように認識されています。
      • 顧客にとってきわめて大切である。
      • 他のビューの主要エレメントの動機付けになる。
      • 機能性以外の要件へのすべての取り組みを含め、1 つ以上の主なリスクを軽減するための軸である。
    • 別のユース・ケースによって取り上げられているアーキテクチャー上の懸案事項をもつユース・ケースはない。
    • ユース・ケースのアーキテクチャー上の重大な側面は明白であって、詳細が失われていない。
    • ユース・ケースは明快であって、アーキテクチャーに影響を与えるような変更が加えられるとは考えにくいか、またはその代わりとして、そのような明快さと安定性を達成する方法に関する計画がある。
    • アーキテクチャー上重要でないユース・ケースは省かれている (このビューで選択されていないユース・ケースの何らかの分析が必要な場合もある)。

論理ビュー 先頭へ

ソフトウェア・アーキテクチャー説明書の論理ビューのセクションは次のとおりです。

    • 設計のアーキテクチャー上重要なエレメントの概要を正確かつ完全に提示している。
    • 設計中で使用されている一連のすべてのアーキテクチャー・メカニズムを、その選択において使用された論理的根拠と一緒に示している。
    • レイヤーのパーティション化に使用された論理的根拠を付記して、設計のレイヤリングを示している。
    • パターンまたはフレームワークの選択に使用された論理的根拠を付記して、設計中で使用されたすべてのフレームワークまたはパターンを示している。
    • アーキテクチャー上重要なモデル・エレメントの数は、システムのサイズと有効範囲に比例している一方で、システム内で作業中の主な概念を分かりやすくするのに適したサイズである。

    プロセス・ビュー 先頭へ

    トピック

    リソース使用 先頭へ

      • 起こりうる競合状態 (クリティカル・リソースを求めるプロセスの競合) が特定されていて、その回避と解決の戦略が定義済みである。
      • 「I/O キューがフル」または「バッファーがフル」の条件を処理するために定義された戦略がある。
      • 容量システムが自身をモニターし (容量のしきい値、重要な性能のしきい値、リソースの消費)、障害を検知した場合に訂正措置をとることができる。

    パフォーマンス 先頭へ

      • 各メッセージごとの応答時間要件を特定済みである。
      • メッセージの応答時間を計測するための診断モードがシステムにある。
      • 重要な操作に関して、公称およびパフォーマンス上の要件が指定済みである。
      • パフォーマンス要件が満たされているかどうかを測定するための一連のパフォーマンス・テストがある。
      • パフォーマンス・テストは、システムの「通常以外」の動作 (始動と終了、ユース・ケースのイベントの代替と例外的な流れ、システム障害モード) も対象とする。
      • 起きる可能性のあるパフォーマンス上のボトルネックの原因となるアーキテクチャー上の弱点を特定済みである。 特に以下の点に重点が置かれている。
        • セマフォー、ファイル処理、ロック、ラッチ、共有メモリーなど (ただしこれらのみに限らない) の有限共有リソースの使用
        • プロセス間通信。 境界をまたいだ通信は、プロセス内通信よりも常に多くのリソースを消費する。
        • プロセッサー間通信。 境界をまたいだ通信は、プロセス間通信よりも常に多くのリソースを消費する。
        • 物理メモリーと仮想メモリーの使用。物理メモリーを使い尽くして仮想メモリーを利用し始める地点が、通常は急激にパフォーマンスが低下する地点である。

    フォールト・トレランス 先頭へ

      • プライマリーとバックアップのプロセスがある場合、複数のプロセスが自身をプライマリーであると考える (または、プライマリーであると考えているプロセスはない) 可能性に対して配慮が払われており、その競合を解決するために特別に設計された措置がとられる。
      • プロセス障害などのイベントが原因で、システムが一貫性のない状態になった場合にシステムを一貫性のある状態に復元するための外部プロセスが存在する。
      • エラーや例外が発生した場合にシステムが一貫した状態に復帰できるように、システムにはエラーおよび例外に対するトレランスがある。
      • システムの稼動中に診断テストを実行できる。
      • 必要があれば、システムの稼動中にシステム (ハードウェア、ソフトウェア) をアップグレードできる。
      • システム内のアラームを処理する一貫したポリシーがあって、そのポリシーが一貫して適用されている。 アラーム・ポリシーでは以下の点を取り上げる。
        • アラーム報知メカニズムの「感度」
        • 誤アラームまたは重複アラームの防止
        • アラーム報知メカニズムを使用するスタッフのトレーニングおよびユーザー・インターフェースに関する要件
      • パフォーマンスに対するアラーム報知メカニズムの影響 (プロセス・サイクル、メモリーなど) は査定済みであって、パフォーマンス要件で規定されたパフォーマンスしきい値の許容範囲内に収まっている。
      • 作業負荷/パフォーマンスの要件は、調査済みで、満足されている。 パフォーマンス要件が現実にそぐわない場合、調整し直されている。
      • 存在する範囲内のメモリー予算は確認済みであって、ソフトウェアがその要求を満たすことは検証済みである。 メモリー・リークの検出と防止のための処置がとられている。
      • 仮想メモリー・システムの使用のモニターと調整を含め、仮想メモリー・システムの使用に関するポリシーがある。

    モジュール性 先頭へ

      • 必要があれば複数のプロセッサーあるいはノードに振り分けて分散できるように、プロセスがそれぞれ 1 つずつ完全に独立している。
      • 共存したままである必要があるプロセス (パフォーマンスやスループット上の要件のためか、またはセマフォーや共有メモリーなどのプロセス間通信メカニズムのため) が識別済みであって、この作業負荷が分担されないことによる影響が考慮に入れられている。
      • リソースの可用性が高まったときに処理できるように、非同期化しても差し支えないメッセージが特定済みである。

    配置ビュー 先頭へ

      • ノードをまたいで処理を分散することでスループット要件が満たされていて、生じうるパフォーマンスのボトルネックに対する対策が講じられている。
      • 情報が分散されて複数のノードにまたがって複製される可能性がある場合に、情報の整合性が確保されている。
      • 現在ある範囲で、信頼性の高いメッセージ転送に関する要件が満たされている。
      • 現在ある範囲で、セキュアなメッセージ転送に関する要件が満たされている。
      • 一貫性とリソースに関する制約に従ってネットワーク・トラフィックと応答時間が最小化されるように、処理がノードをまたがって分散されている。
      • 現在ある範囲で、システム使用可能性に関する要件が満たされている。
        • サーバーまたはネットワークに障害が生じた際の最大のダウン時間が特定されていて、要件に定義されたとおりの許容限界内にある。
        • 複数のサーバーを「プライマリ」サーバーと指定できないようにしたうえで、冗長サーバーおよびスタンバイ・サーバーが定義されている。
      • 起こりうるすべての障害モードが文書化されている。
      • ネットワーク上の障害を特定、診断、および解決することができる。
      • CPU 利用での「余力」の容量が特定されていて、しかも測定方法が定義されている。
      • 最大 CPU 利用率を超えた場合にとるべき措置を明確に規定したポリシーがある。

     

    Rational Unified Process   2003.06.15