![]() |
連載:アプリケーション・アーキテクチャ・ガイド2.0解説第3回 設計判断が必要なホットスポットを抽出するには? ―― 設計プロセスから見るアプリケーション・アーキテクチャ(後編) ―― 日本ユニシス 猪股 健太郎2009/06/23 |
前回は、AAGが推奨するアーキテクチャ設計の5つのステップのうち、「2. アプリケーション概要の定義」について詳解した。今回は「3. ホットスポットの抽出」について詳しく説明する。
■ホットスポットを抽出するには
主要なホットスポット(=横断的な関心事にかかわる設計判断が必要な個所)の抽出について説明する。主要なホットスポットを抽出する手掛かりとして、AAGでは「アーキテクチャ・フレーム」と「品質属性」を挙げている。
●アーキテクチャ・フレーム
アーキテクチャ・フレームとは、複数の論理階層や物理階層にまたがった設計に影響を与える横断的関心事を分類し、まとめた枠組みである。以下のように、関心事と、それに対応する複数の検討項目をまとめた形になっている。
ホットスポットを抽出する際には、以下のアーキテクチャ・フレームをベースとし、主要シナリオと関連性の強い検討項目から優先的に選び出すとよい。
| 関心事 | 検討項目 |
| 認証と承認 | 認証の設計方針 |
| 承認の設計方針 | |
| 認証情報の引き渡し方 | |
| ディレクトリ・サービスを使わない場合の、機密情報の保管場所 | |
| キャッシュと状態 | キャッシュ技術の選択 |
| キャッシュするデータの選択 | |
| キャッシュする場所 | |
| 有効期限に関する方針 | |
| 通信 | 階層をまたがった通信のプロトコル |
| 論理階層の疎結合化 | |
| 非同期通信の実現方法 | |
| 機密性の高い情報の通信方法 | |
| UIの組み立て | UIデザイン・パターンの選択 |
| UIの構成要素の依存性を減らす方法 | |
| UIの構成要素を連携させる方法 | |
| 同時実行と トランザクション |
スレッドの同時実行制御 |
| 楽観的/悲観的同時実行制御の選択 | |
| 分散トランザクションの扱い | |
| ロング・トランザクションの扱い | |
| 構成管理 | 設定変更可能とする情報の選択 |
| 設定情報の保持場所と方法 | |
| 機密性の高い設定情報を保護する方法 | |
| サーバ・ファームやクラスタでの設定情報の扱い | |
| 結合度と凝集度 | 関心事を分離するために論理階層に分ける際の方針 |
| 凝集度の高いコンポーネントの設計方法 | |
| 同じ論理階層の中で疎結合にすべき場合 | |
| データ・アクセス | データベース・コネクションの管理方法 |
| 例外の扱い | |
| 性能向上の方法 | |
| 大きなバイナリ・データの扱い | |
| 例外管理 | 例外の扱い |
| 例外のログ出力 | |
| 監視と通知の実装 | |
| ログ出力と監視 | ログに出力する情報の選択 |
| ログ出力を設定変更可能にする方法 | |
| ログ出力レベルと対応する情報の決定 | |
| ユーザー体験 | 効率性と有効性を上げる方法 |
| 応答性を上げる方法 | |
| 利用者に統制力を与える方法 | |
| ルック&フィールを向上する方法 | |
| 入力値検証 | 入力値検証の実施場所と方法 |
| 長さ・範囲・フォーマット・型の検証方法 | |
| 入力値の抑制と拒否 | |
| 出力値の無害化 | |
| ワークフロー | ワークフロー実装技術の選択 |
| ワークフロー内の同時実行制御 | |
| 失敗したプロセスの扱い | |
| プロセスを統合管理する方法 | |
| アーキテクチャ・フレーム(ホットスポットを抽出するための、横断的関心事に関する検討項目) | |
●品質属性
品質属性は、アプリケーションの非機能要件のうち、アプリケーションの品質を規定するものとしてとらえられるものを指す。ISO標準(国内ではJIS規格)では「ソフトウェア品質特性」として定義されている。品質属性それ自体、アプリケーションのさまざまな個所で考慮しなければならない横断的な関心事なのである。
ここでは、まず品質属性の一覧を紹介し、その後、各属性にかかわる検討項目を説明する。そこから主要なホットスポットを抽出するには、アーキテクチャ・フレームと同様に、主要シナリオと関連性の強い検討項目から優先的に選び出すとよい。
| 種別 | 品質属性 | 説明 |
| システム品質 | サポータビリティ | 見通しのよさ |
| テスト容易性 | テスト・ケースの作成しやすさと実行しやすさ | |
| 実行時品質 | 可用性 | 稼働率で測定される |
| 相互運用性 | 異なるコンポーネントやシステムとの連携可能性 | |
| 運用性 | システムの監視やデバッグなどに十分な情報が提供されているか | |
| 性能 | 応答時間やスループットで測定される | |
| 信頼性 | 期待した期間システムが稼働し続ける確率 | |
| スケーラビリティ | 負荷が増大したときにも十分な機能を提供できる能力 | |
| セキュリティ | さまざまな脅威からシステムを守る手段 | |
| 設計品質 | 概念の整合性 | 設計上の一貫性。設計方針や各種規約など |
| 柔軟性 | ビジネスやシステムの環境の変化に対応した構成をとる能力 | |
| 保守性 | 機能の追加変更などに対応できるかどうか | |
| 再利用性 | コンポーネントやサブシステムが別のアプリケーションでも利用できるかどうか | |
| 利用者品質 | ユーザビリティ | 利用者にとっての使いやすさ |
| 品質属性の一覧 | ||
各属性についての検討項目は以下のようになる。
○サポータビリティ
サポータビリティ(=サポートのしやすさ)とは、運用者・開発者・ユーザーにとってのシステムの理解しやすさであり、トラブルが発生したときの問題解決のしやすさである。
サポータビリティを高めるためには以下のようなことを検討する。
- システムの動作状況を監視する方法
- システムの動作効率を監視する方法
- トレースの実装方法
- トラブルシュートのための情報を提供する方法
- 監査とロギングの実装方法
○テスト容易性
テスト容易性とは、システムやコンポーネントを検査する基準の設定しやすさと、その基準が満たされているかどうかのテストの実行しやすさである。テスト容易性が高ければ、システムの欠陥を効率よく特定できる。
テスト容易性を高めるためには以下のようなことを検討する。
- 開発ライフサイクルの早期からテストを実施できるようにする方法
- ユーザー操作を伴うテストを自動化する方法
- 非常に複雑な機能やルールに対するテストと結果報告を自動化する方法
- 論理階層や物理階層を個別にテストする方法
- テスト・ケースの作成のためにシステムの入出力を特定する方法
- コンポーネントと通信のインターフェイスを明確に定義する方法
○可用性
可用性とは、システムが正しく稼働している時間の割合、すなわち稼働率で測定される。稼働率は、システム・エラー、インフラの問題、悪意のある攻撃、システム負荷の増大などで悪化する。
可用性を高めるためには以下のようなことを検討する。
- 物理階層を分け、フェイルオーバーをサポートするよう設計する方法
- 自然災害でもフェイルオーバーできるように、離れた拠点での冗長化が必要か決定する方法
- 実行時にシステムを更新できるようにする設計方法
- アプリケーションの失敗を減らすために例外処理を適切に設計する方法
- 信頼できないネットワーク接続を取り扱う方法
○相互運用性
相互運用性とは、さまざまなコンポーネント同士がサービスなどを通して情報を交換することで正しく動作する能力である。相互運用性のあるシステムでは情報の交換や再利用を内部的にも外部的にも行うことができる。
相互運用性を高めるためには以下のようなことを検討する。
- 外部システムやレガシー・システムから来る異なったデータ・フォーマットを取り扱う方法。
- システムが別々に進化したり置き換えられたりしていても相互運用を可能にする方法。
- サービス・インターフェイスを用いることによりシステムを分離する方法。
- マッピング層を用いることによりシステムを分離する方法。
○運用性
運用性とは、システム監視やデバッグやパフォーマンス・チューニングに必要十分な情報を公開することによる運用のしやすさである。
運用性を高めるためには以下のようなことを検討する。
- 運用環境の要件の変更に伴ってシステムの振る舞いを変えられるようにする方法
- システム負荷の変化に伴ってシステムの振る舞いを変えられるようにする方法
- トラブルシューティングのためにシステムの状態のスナップショットを作成する方法
- システムの動作とヘルスを監視する方法
- 詳細な動作レポートをログ出力する方法
- システムに送信された要求の詳細を確認する方法
○性能
性能とは、単位時間の間に特定の処理を実行したときのシステムの応答性であり、レスポンス・タイムやスループットで測定される。
性能を高めるためには以下のようなことを検討する。
- キャッシュ戦略を決定する方法
- 論理階層の間で高性能な通信を設計する方法
- 効率的なトランザクション、ロック、スレッディング、待ち行列を選ぶ方法
- アプリケーションの構造を決定する方法
- リソースを効果的に管理する方法
○信頼性
信頼性とは、想定どおりの動作を続けることができる能力である。信頼性は、一定の期間中にシステムが失敗せずに意図された機能を実行する確率で測定される。
信頼性を高めるためには以下のようなことを検討する。
- 信頼できない外部システムを取り扱う方法
- 失敗を検出し、自動的にフェイルオーバーを始める方法
- 極限状況の下で負荷を割り振る方法
- システムをオフラインにしながら、要求を待ち行列に入れておく方法
- 通信の失敗を取り扱う方法
- トランザクションの失敗を取り扱う方法
○スケーラビリティ
スケーラビリティとは、需要が変化し、システムの負荷が増加したときでも、システムの可用性、信頼性、パフォーマンスを維持することができる能力である。
スケーラビリティを高めるためには以下のようなことを検討する。
- スケーラビリティを持った論理階層や物理階層を設計する方法
- アプリケーションをスケールアップまたはスケールアウトする方法
- データベースをスケールアップする方法
- UIをスケールアップする方法
- トラフィックと負荷についてスパイクを作成する方法
○セキュリティ
セキュリティとは、情報の漏えいや損失から保護されている度合いである。守秘性、完全性、可用性などで表される。
セキュリティを高めるためには以下のようなことを検討する。
- 認証と承認について記述する方法
- 悪意のある入力から保護する方法
- 機密データを保護する方法
- SQLインジェクションから保護する方法
- クロス・サイト・スクリプティングから保護する方法
○概念の整合性
概念の整合性とは、設計の全体的な一貫性のことである。これには、コンポーネントやモジュールの設計方針だけでなく、コーディング・スタイルや変数の命名規約なども含む。
概念の整合性を高めるためには以下のようなことを検討する。
- 関心事の範囲を特定して、論理階層に分割する方法
- 開発プロセスを管理する方法
- アプリケーション・ライフサイクルを通じてコミュニケーションやコラボレーションを容易にする方法
- 設計やコーディングの標準を確立して実施する方法
- レガシー技術からの移行パスを検討する方法
- 外部への依存関係からアプリケーションを分離する方法
○柔軟性
柔軟性とは、環境や状況の変化に適応し、ビジネスの方針とルールの変更に対応する能力である。
柔軟性を高めるためには以下のようなことを検討する。
- 動的なビジネス・ルール(例えば承認やデータ、プロセスに関連した変化)を取り扱う方法
- 動的なユーザー・インターフェイス(UI)(例えば承認やデータやプロセスに関連した変化)を取り扱う方法
- データやロジック処理における変更に反応する方法
- コンポーネントやサービスの責任や関係性が明確に定義されていることを保証する方法
○保守性
保守性とは、機能を追加変更したり、バグを修正したり、新しいビジネス要件を満たすようにしたとき、必要に応じてコンポーネントやサービスや機能やインターフェイスを変更できる能力である。
保守性を高めるためには以下のようなことを検討する。
- コンポーネント間や論理階層間の依存関係を減らす方法
- 拡張可能なアーキテクチャを実装し、更新や保守やテストを容易にする方法
- アプリケーションに固有な機能を実装するコードから横断的関心事の機能を切り離す方法
- 適切な通信モデルやフォーマットやプロトコルを選ぶ方法
- 高凝集度のコンポーネントを作成する方法
○再利用性
再利用性とは、あるコンポーネントに機能を追加することなく、ほかのコンポーネントやシナリオで利用できるという可能性のことである。
再利用性を高めるためには以下のようなことを検討する。
- 複数のコンポーネントで類似したロジックの重複を減らす方法
- 複数の論理階層またはサブシステムで類似したロジックの重複を減らす方法
- 別のシステムで機能を再利用する方法
- 複数のシステムにまたがって機能を共有する方法
- アプリケーション内の異なるサブシステムにまたがって機能を共有する方法
○ユーザビリティ
ユーザビリティとは、アプリケーション・インターフェイスがユーザーにとって直感的であったり、障害を持ったユーザーでもアクセスできたり、素晴らしいユーザー体験(UX)を提供できたりする能力のことである。
ユーザビリティを高めるためには以下のようなことを検討する。
- 効率的なインタラクション・パターンを支援する方法
- ユーザー体験の受け入れ基準を決定する方法
- ユーザーへの応答を改善する方法
- 効果的なUI技術を決定する方法
- 視覚効果を強化する方法
以上の検討項目から、アプリケーションのホットスポットとなり得る部分を抽出する。見てのとおり広範な検討項目が挙げられているが、最初からすべてを検討することは困難である。よって、前回でも述べたとおり、アーキテクチャ設計のステップは何回か繰り返し実行することで、検討の幅や深さを大きくしていくことが重要である。
■
次回は、プレゼンテーション層、ビジネス層、データ・アクセス層、サービス層という論理4階層におけるアプリケーション・アーキテクチャについて解説する。![]()
| 「アプリケーション・アーキテクチャ・ガイド2.0解説」 |
- 第2回 簡潔なコーディングのために (2017/7/26)
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために (2017/7/19)
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator (2017/7/18)
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
|
|





