Software-architecture-design-quick-guide
クイックガイド
ソフトウェアアーキテクチャと設計の概要
システムのアーキテクチャは、その主要なコンポーネント、それらの関係（構造）、およびそれらが互いにどのように相互作用するかを記述します。 ソフトウェアのアーキテクチャと設計には、ビジネス戦略、品質属性、人間のダイナミクス、設計、IT環境などのいくつかの要因が含まれます。
ソフトウェアアーキテクチャとソフトウェアデザインは、ソフトウェアアーキテクチャとソフトウェアデザインという2つのフェーズに分けられます。 Architecture では、機能以外の決定がキャストされ、機能要件によって分離されます。 設計では、機能要件が達成されます。
ソフトウェアアーキテクチャ
アーキテクチャは、*システムの青写真*として機能します。 システムの複雑さを管理し、コンポーネント間の通信および調整メカニズムを確立するための抽象化を提供します。
- パフォーマンスやセキュリティなどの一般的な品質属性を最適化しながら、すべての技術的および運用上の要件を満たす*構造化ソリューション*を定義します。
- さらに、ソフトウェア開発に関連する組織に関する一連の重要な決定が含まれ、これらの決定はそれぞれ最終製品の品質、保守性、パフォーマンス、および全体的な成功に大きな影響を与える可能性があります。 これらの決定は-
- システムを構成する構造要素とそのインターフェイスの選択。
- これらの要素間のコラボレーションで指定された動作。
- これらの構造要素と動作要素を大きなサブシステムに構成します。
- 建築上の決定は、ビジネス目標に沿って行われます。
- 建築様式が組織を導きます。
ソフトウェア設計
ソフトウェア設計は、システムの要素、それらがどのように適合するかを説明し、システムの要件を満たすために連携する*設計計画*を提供します。 設計計画を持つ目的は次のとおりです-
- システム要件を交渉し、顧客、マーケティング、および管理担当者と期待を設定するため。
- 開発プロセス中に青写真として機能します。
- 詳細な設計、コーディング、統合、テストなどの実装タスクをガイドします。
詳細な設計、コーディング、統合、テストの前、およびドメイン分析、要件分析、リスク分析の後に行われます。
建築の目標
アーキテクチャの主な目標は、アプリケーションの構造に影響する要件を特定することです。 適切に設計されたアーキテクチャにより、技術ソリューションの構築に関連するビジネスリスクが軽減され、ビジネス要件と技術要件の間に橋が架けられます。
他の目標のいくつかは次のとおりです-
- システムの構造を公開しますが、実装の詳細は隠します。
- すべてのユースケースとシナリオを実現します。
- さまざまな利害関係者の要件に対処するようにしてください。
- 機能要件と品質要件の両方を処理します。
- 所有権の目標を減らし、組織の市場での地位を向上させます。
- システムが提供する品質と機能を改善します。
- 組織またはシステムのいずれかに対する外部の信頼を向上させます。
制限事項
ソフトウェアアーキテクチャは、依然としてソフトウェアエンジニアリングの新しい分野です。 次の制限があります-
- アーキテクチャを表すためのツールと標準化された方法の欠如。
- アーキテクチャが要件を満たす実装になるかどうかを予測するための分析方法の欠如。
- ソフトウェア開発におけるアーキテクチャ設計の重要性に対する認識の欠如。
- ソフトウェアアーキテクトの役割を理解しておらず、関係者間のコミュニケーションが不十分です。
- 設計プロセス、設計経験、および設計の評価に関する理解不足。
ソフトウェアアーキテクトの役割
ソフトウェアアーキテクトは、技術チームがアプリケーション全体を作成および設計できるソリューションを提供します。 ソフトウェアアーキテクトは、次の分野の専門知識を持っている必要があります-
設計の専門知識
- オブジェクト指向設計、イベント駆動設計など、さまざまな方法とアプローチを含むソフトウェア設計の専門家
- 開発チームを率いて、設計の整合性のために開発作業を調整します。
- 設計提案をレビューし、それらの間でトレードオフできる必要があります。
ドメインの専門知識
- 開発中のシステムの専門家であり、ソフトウェアの進化を計画しています。
- 要件調査プロセスを支援し、完全性と一貫性を保証します。
- 開発中のシステムのドメインモデルの定義を調整します。
技術の専門知識
- システムの実装を支援する利用可能な技術の専門家。
- プログラミング言語、フレームワーク、プラットフォーム、データベースなどの選択を調整します。
方法論の専門知識
- SDLC（ソフトウェア開発ライフサイクル）中に採用される可能性のあるソフトウェア開発方法論の専門家。
- チーム全体を支援する適切な開発アプローチを選択してください。
ソフトウェアアーキテクトの隠れた役割
- チームメンバー間の技術作業を促進し、チームの信頼関係を強化します。
- 知識を共有し、豊富な経験を持つ情報スペシャリスト。
- チームメンバーの注意をそらし、プロジェクトの価値を低下させる外力からチームメンバーを保護します。
アーキテクトの成果物
- 機能的目標の明確で完全で一貫した達成可能なセット
- 少なくとも2つのレイヤーの分解があるシステムの機能説明
- システムのコンセプト
- 少なくとも2層の分解を伴うシステム形式の設計
- タイミング、オペレーター属性、および実装と運用計画の概念
- 機能的な分解が行われ、インターフェースの形式が制御されることを保証する文書またはプロセス
品質属性
品質は、優秀さの尺度、または欠陥や欠陥がない状態です。 品質属性は、システムの機能とは別のシステムプロパティです。
品質属性を実装すると、良いシステムと悪いシステムを簡単に区別できます。 属性は、実行時の動作、システム設計、およびユーザーエクスペリエンスに影響する全体的な要因です。
彼らはとして分類することができます-
静的品質属性
アーキテクチャ、設計、およびソースコードに直接関連するシステムおよび組織の構造を反映します。 それらはエンドユーザーには見えませんが、開発とメンテナンスのコストに影響を与えます、例えば：モジュール性、テスト容易性、保守容易性など
動的品質属性
実行中のシステムの動作を反映します。 これらは、システムのアーキテクチャ、設計、ソースコード、構成、展開パラメーター、環境、およびプラットフォームに直接関連しています。
これらはエンドユーザーに表示され、実行時に存在します。 スループット、堅牢性、スケーラビリティなど
品質シナリオ
品質シナリオは、障害が障害にならないようにする方法を指定します。 それらは、属性仕様に基づいて6つの部分に分けることができます-
- ソース-人、ハードウェア、ソフトウェア、または刺激を生成する物理インフラストラクチャなどの内部または外部エンティティ。
- 刺激-システムに到着したときに考慮する必要がある条件。
- 環境-刺激は特定の条件内で発生します。
- アーティファクト-システム全体またはプロセッサ、通信チャネル、永続ストレージ、プロセスなどの一部。
- 応答-障害の検出、障害からの回復、イベントソースの無効化など、刺激の到着後に行われるアクティビティ。
- 応答測定-要件をテストできるように、発生した応答を測定する必要があります。
共通の品質属性
次の表に、ソフトウェアアーキテクチャに必要な共通の品質属性を示します-
カテゴリー
品質属性
説明
設計品質
概念の完全性
設計全体の一貫性と一貫性を定義します。 これには、コンポーネントまたはモジュールの設計方法が含まれます。
保守性
ある程度簡単にシステムを変更できる能力。
再利用性
他のアプリケーションでの使用に適したコンポーネントおよびサブシステムの機能を定義します。
実行時の品質
相互運用性
システムまたは異なるシステムが、外部の当事者によって作成および実行される他の外部システムと情報をやり取りして交換することにより、正常に動作する能力
管理性
システム管理者がアプリケーションを簡単に管理できるかどうかを定義します。
信頼性
システムが長期にわたって稼働し続ける能力。
スケーラビリティ
システムのパフォーマンスに影響を与えずに負荷の増加を処理するシステムの能力、または容易に拡張する能力。
セキュリティ
設計された用途以外の悪意のあるまたは偶発的なアクションを防止するシステムの機能。
パフォーマンス
特定の時間間隔内にアクションを実行するシステムの応答性の指標。
可用性
システムが機能して動作している時間の割合を定義します。 事前に定義された期間におけるシステムの合計ダウンタイムの割合として測定できます。
システム品質
サポート性
システムが正常に機能しない場合に問題を特定して解決するのに役立つ情報を提供する機能。
テスト容易性
システムとそのコンポーネントのテスト基準を作成するのがいかに簡単かを示す尺度。
ユーザー品質
使いやすさ
直感的であることにより、アプリケーションがユーザーと消費者の要件をどれだけ満たすかを定義します。
建築品質
正しさ
システムのすべての要件を満たす責任。
非ランタイム品質
移植性
異なるコンピューティング環境で実行するシステムの能力。
統合性
システムの個別に開発されたコンポーネントを一緒に正しく機能させる機能。
修正可能性
各ソフトウェアシステムがソフトウェアの変更に対応できる容易さ。
ビジネス品質の属性
費用とスケジュール
市場投入までの時間、プロジェクトの予想寿命、およびレガシーの利用に関するシステムのコスト。
市場性
市場競争に関するシステムの使用。
主な原則
ソフトウェアアーキテクチャは、システムの組織として説明されます。システムは、定義された機能を実行するコンポーネントのセットを表します。
建築スタイル
- アーキテクチャスタイル*は、*アーキテクチャパターン*とも呼ばれ、アプリケーションを形成する一連の原則です。 構造的組織のパターンの観点から、システムファミリの抽象的なフレームワークを定義します。
建築様式はに責任があります-
- コンポーネントとコネクタのレキシコンに、それらをどのように組み合わせることができるかに関するルールを提供します。
- 頻繁に発生する問題の解決策を提供することにより、パーティションを改善し、設計の再利用を可能にします。
- コンポーネント（明確に定義されたインターフェイス、再利用可能、交換可能なモジュール）とコネクタ（モジュール間の通信リンク）のコレクションを構成する特定の方法を説明します。
コンピューターベースのシステム用に構築されたソフトウェアは、多くのアーキテクチャスタイルの1つを示しています。 各スタイルは、以下を含むシステムカテゴリを説明します-
- システムが必要な機能を実行するコンポーネントタイプのセット。
- さまざまなコンポーネント間の通信、調整、および協調を可能にするコネクタのセット（サブルーチン呼び出し、リモートプロシージャコール、データストリーム、およびソケット）。
- コンポーネントを統合してシステムを形成する方法を定義するセマンティック制約。
- 実行時の相互関係を示すコンポーネントのトポロジレイアウト。
共通の建築設計
次の表は、主要なフォーカス領域ごとに整理できるアーキテクチャのスタイルを示しています-
カテゴリー
建築デザイン
説明
コミュニケーション
メッセージバス
1つ以上の通信チャネルを使用してメッセージを送受信できるソフトウェアシステムの使用を規定します。
サービス指向アーキテクチャ（SOA）
コントラクトとメッセージを使用して、機能をサービスとして公開および使用するアプリケーションを定義します。
展開
クライアントサーバー
システムを2つのアプリケーションに分離し、クライアントがサーバーにリクエストを送信します。
3層またはN層
機能を個別のセグメントに分割します。各セグメントは、物理的に別個のコンピューターにある層です。
ドメイン
ドメイン駆動設計
ビジネスドメインのモデリングと、ビジネスドメイン内のエンティティに基づいたビジネスオブジェクトの定義に焦点を当てています。
構造
コンポーネントベース
アプリケーション設計を、明確に定義された通信インターフェースを公開する再利用可能な機能または論理コンポーネントに分解します。
レイヤード
アプリケーションの懸念事項を積み重ねられたグループ（レイヤー）に分割します。
オブジェクト指向
アプリケーションまたはシステムの責任のオブジェクトへの分割に基づいており、各オブジェクトにはデータとオブジェクトに関連する動作が含まれています。
アーキテクチャの種類
企業の観点からは4種類のアーキテクチャがあり、これらのアーキテクチャはまとめて*エンタープライズアーキテクチャ*と呼ばれます。
- ビジネスアーキテクチャ-ビジネス、ガバナンス、組織、および企業内の主要なビジネスプロセスの戦略を定義し、ビジネスプロセスの分析と設計に焦点を当てます。
- アプリケーション（ソフトウェア）アーキテクチャ-個々のアプリケーションシステム、その相互作用、および組織のビジネスプロセスとの関係の青写真として機能します。
- 情報アーキテクチャ-論理および物理データ資産とデータ管理リソースを定義します。
- 情報技術（IT）アーキテクチャ-組織の情報システム全体を構成するハードウェアとソフトウェアの構成要素を定義します。
アーキテクチャ設計プロセス
アーキテクチャ設計プロセスは、システムをさまざまなコンポーネントに分解し、それらの相互作用に焦点を当てて、機能要件と非機能要件を満たします。 ソフトウェアアーキテクチャ設計への主要な入力は次のとおりです-
- 分析タスクによって生成された要件。
- ハードウェアアーキテクチャ（ソフトウェアアーキテクトは、ハードウェアアーキテクチャを構成するシステムアーキテクトに要件を提供します）。
アーキテクチャ設計プロセスの結果または出力は、*アーキテクチャの説明*です。 基本的なアーキテクチャ設計プロセスは、次の手順で構成されています-
問題を理解する
- これは、後続の設計の品質に影響するため、最も重要な手順です。
- 問題を明確に理解しないと、問題を作成することはできません 効果的なソリューション。
- 多くのソフトウェアプロジェクトおよび製品は、有効なビジネス上の問題を実際に解決したわけではなく、認識可能な投資収益率（ROI）もなかったため、失敗と見なされます。
設計要素とその関係を特定する
- このフェーズでは、システムの境界とコンテキストを定義するためのベースラインを構築します。
- 機能要件に基づいて、システムをその主要コンポーネントに分解します。 分解は、要素の粒度を指定せずに設計要素間の依存関係を示す設計構造マトリックス（DSM）を使用してモデル化できます。
- このステップでは、アーキテクチャの最初の検証は多くのシステムインスタンスを記述することによって行われ、このステップは機能ベースのアーキテクチャ設計と呼ばれます。
アーキテクチャ設計を評価する
- 各品質属性には推定値が与えられるため、定性的尺度または定量的データを収集するために、設計が評価されます。
- アーキテクチャの品質属性要件への準拠についてアーキテクチャを評価する必要があります。
- 推定されたすべての品質属性が必要な標準に従っている場合、アーキテクチャ設計プロセスは終了します。
- そうでない場合は、ソフトウェアアーキテクチャ設計の第3フェーズである、アーキテクチャ変換が開始されます。 観察された品質属性が要件を満たしていない場合は、新しい設計を作成する必要があります。
アーキテクチャ設計の変革
- このステップは、アーキテクチャ設計の評価後に実行されます。 アーキテクチャ設計は、品質属性の要件を完全に満たすまで変更する必要があります。
- ドメイン機能を維持しながら品質属性を改善するための設計ソリューションの選択に関係しています。
- 設計は、設計演算子、スタイル、またはパターンを適用することにより変換されます。 変換のために、既存の設計を採用し、分解、複製、圧縮、抽象化、リソース共有などの設計演算子を適用します。
- 設計が再度評価され、必要に応じて同じプロセスが複数回繰り返され、再帰的に実行されます。
- 変換（つまり、 品質属性最適化ソリューション）一般に、1つまたはいくつかの品質属性を改善する一方で、他に悪影響を与える
主要なアーキテクチャの原則
以下は、アーキテクチャを設計する際に考慮すべき重要な原則です-
最後まで構築するのではなく、変更して構築する
新しい要件や課題に対処するために、アプリケーションが時間とともにどのように変化する必要があるかを検討し、これをサポートする柔軟性を組み込みます。
分析するリスクとモデルを減らす
設計ツール、視覚化、UMLなどのモデリングシステムを使用して、要件と設計上の決定をキャプチャします。 影響も分析できます。 設計を簡単に反復および適応する機能を抑制する程度にモデルを形式化しないでください。
モデルと視覚化をコミュニケーションおよびコラボレーションツールとして使用する
設計の効率的なコミュニケーション、決定、および設計に対する継続的な変更は、優れたアーキテクチャにとって重要です。 モデル、ビュー、およびアーキテクチャのその他の視覚化を使用して、すべての関係者と設計を効率的に伝達および共有します。 これにより、設計の変更を迅速に伝達できます。
エンジニアリングの重要な決定と、間違いが最も頻繁に発生する領域を特定して理解します。 設計をより柔軟にし、変更によって破損する可能性を低くするために、最初に重要な決定を正しく行うことに投資します。
増分および反復アプローチを使用する
ベースラインアーキテクチャから始めて、アーキテクチャを改善するための反復テストにより候補アーキテクチャを進化させます。 複数のパスにわたって設計に詳細を繰り返し追加して、全体像または正しい画像を取得し、詳細に焦点を合わせます。
主要な設計原則
以下は、コスト、メンテナンス要件を最小限に抑え、アーキテクチャの拡張性、使いやすさを最大限にするために考慮される設計原則です-
関心事の分離
コンポーネントの機能が重複しないように、システムのコンポーネントを特定の機能に分割します。 これにより、高い凝集力と低い結合が得られます。 このアプローチにより、システムのコンポーネント間の相互依存性が回避され、システムの保守が容易になります。
単一責任原則
システムの各モジュールには、ユーザーがシステムを明確に理解するのに役立つ特定の責任が1つ必要です。 また、コンポーネントと他のコンポーネントの統合にも役立つはずです。
最小知識の原理
コンポーネントまたはオブジェクトには、他のコンポーネントの内部詳細に関する知識があってはなりません。 このアプローチにより、相互依存性が回避され、保守性が向上します。
大規模な設計を最小限に抑える
アプリケーションの要件が明確でない場合は、大規模な設計を事前に最小限に抑えます。 要件を変更する可能性がある場合は、システム全体の大規模な設計を避けてください。
機能を繰り返さないでください
機能を繰り返さないことは、コンポーネントの機能を繰り返さないように指定するため、コードの一部は1つのコンポーネントのみに実装する必要があります。 アプリケーション内で機能が重複すると、変更の実装が困難になり、明確さが低下し、不整合が生じる可能性があります。
機能を再利用しながら継承よりも合成を優先する
継承は、子クラスと親クラスの間に依存関係を作成するため、子クラスの自由な使用をブロックします。 対照的に、コンポジションは大きなレベルの自由を提供し、継承階層を減らします。
コンポーネントを特定し、論理層にグループ化します
要件を満たすためにシステムで必要なアイデンティティコンポーネントと関心領域。 次に、これらの関連コンポーネントを論理層にグループ化します。これにより、ユーザーはシステムの構造を高レベルで理解できます。 異なるタイプの懸念のコンポーネントを同じレイヤーに混在させないでください。
レイヤー間の通信プロトコルを定義する
コンポーネントが相互に通信する方法を理解するには、展開シナリオと運用環境の完全な知識が必要です。
レイヤーのデータ形式を定義する
さまざまなコンポーネントがデータ形式を介して相互に作用します。 アプリケーションの実装、拡張、および保守が容易になるように、データ形式を混在させないでください。 さまざまなコンポーネントが相互に通信しながらデータをコード化/デコードする必要がないように、レイヤーのデータ形式を同じにしてください。 処理のオーバーヘッドを削減します。
システムサービスコンポーネントは抽象的である必要があります
セキュリティ、通信、またはロギング、プロファイリング、構成などのシステムサービスに関連するコードは、個別のコンポーネントで抽象化する必要があります。 このコードをビジネスロジックと混在させないでください。設計の拡張と保守が容易です。
設計の例外と例外処理メカニズム
事前に例外を定義すると、コンポーネントがエラーや不要な状況をエレガントに管理するのに役立ちます。 例外管理はシステム全体で同じです。
命名規則
命名規則は事前に定義する必要があります。 これらは、ユーザーがシステムを簡単に理解できるようにする一貫したモデルを提供します。 チームメンバーは、他の人が書いたコードを検証する方が簡単であるため、保守性が向上します。
アーキテクチャモデル
ソフトウェアアーキテクチャには、アーキテクチャスタイルと品質属性を備えた、分解と構成を使用したソフトウェアシステム抽象化の高レベルの構造が含まれます。 ソフトウェアアーキテクチャの設計は、システムの主要な機能とパフォーマンスの要件に準拠するとともに、信頼性、スケーラビリティ、移植性、可用性などの非機能要件を満たす必要があります。
ソフトウェアアーキテクチャは、コンポーネントのグループ、接続、コンポーネント間の相互作用、およびすべてのコンポーネントの展開構成を記述する必要があります。
ソフトウェアアーキテクチャは、多くの方法で定義することができます-
- * UML（Unified Modeling Language）*-UMLは、ソフトウェアモデリングおよび設計で使用されるオブジェクト指向ソリューションの1つです。
- アーキテクチャビューモデル（4 + 1ビューモデル）-アーキテクチャビューモデルは、ソフトウェアアプリケーションの機能要件および非機能要件を表します。
- * ADL（Architecture Description Language）*-ADLは、ソフトウェアアーキテクチャを形式的および意味的に定義します。
UML
UMLはUnified Modeling Languageの略です。 これは、ソフトウェアの設計図を作成するために使用される画像言語です。 UMLはObject Management Group（OMG）によって作成されました。 UML 1.0仕様ドラフトは、1997年1月にOMGに提案されました。 これは、ソフトウェア開発の基礎となるソフトウェア要件分析および設計文書の標準として機能します。
UMLは、ソフトウェアシステムを視覚化、指定、構築、および文書化するための汎用視覚モデリング言語として説明できます。 UMLは一般にソフトウェアシステムのモデル化に使用されますが、この境界内で制限されることはありません。 また、製造ユニットのプロセスフローなどの非ソフトウェアシステムのモデリングにも使用されます。
要素は、 diagram と呼ばれる完全なUML画像を作成するためにさまざまな方法で関連付けることができるコンポーネントのようなものです。 したがって、実際のシステムに知識を実装するには、さまざまな図を理解することが非常に重要です。 ダイアグラムには大きく2つのカテゴリがあり、さらにサブカテゴリに分類されます。 構造図*および*行動図。
構造図
構造図は、システムの静的な側面を表します。 これらの静的な側面は、主要な構造を形成し、したがって安定しているダイアグラムの部分を表します。
これらの静的部分は、クラス、インターフェース、オブジェクト、コンポーネント、およびノードで表されます。 構造図は次のように細分することができます-
- クラス図
- オブジェクト図
- コンポーネント図
- 展開図
- パッケージ図 *複合構造
次の表は、これらの図の簡単な説明を提供します-
| Sr.No. | Diagram & Description |
|---|---|
| 1 |
システムのオブジェクトの向きを表します。 クラスが静的に関連する方法を示します。 |
| 2 |
Object 実行時のオブジェクトのセットとそれらの関係を表し、システムの静的ビューも表します。 |
| 3 |
Component システムのすべてのコンポーネント、それらの相互関係、相互作用、インターフェースについて説明します。 |
| 4 |
Composite structure すべてのクラス、コンポーネントのインターフェースなどを含むコンポーネントの内部構造を説明します。 |
| 5 |
Package パッケージの構造と構成について説明します。 パッケージ内のクラスおよび別のパッケージ内のパッケージをカバーします。 |
| 6 |
Deployment 配置図は、ノードとそれらの関係のセットです。 これらのノードは、コンポーネントが展開される物理エンティティです。 |
行動図
動作図は、基本的にシステムの動的な側面をキャプチャします。 動的な側面とは、基本的にシステムの変化/移動する部分です。 UMLには、次のタイプの行動図があります-
- ユースケース図
- シーケンス図
- コミュニケーション図
- 状態図
- アクティビティ図
- インタラクションの概要 *時系列図
次の表は、これらの図の簡単な説明を提供します-
| Sr.No. | Diagram & Description |
|---|---|
| 1 |
機能とそれらの内部/外部コントローラー間の関係について説明します。 これらのコントローラーはアクターと呼ばれます。 |
| 2 |
Activity システムの制御の流れを説明します。 アクティビティとリンクで構成されています。 フローは、順次、並行、または分岐のいずれかです。 |
| 3 |
State Machine/state chart システムのイベント駆動状態の変化を表します。 基本的に、クラス、インターフェースなどの状態変化について説明します。 内部/外部要因によるシステムの反応を視覚化するために使用されます。 |
| 4 |
Sequence 特定の機能を実行するために、システム内の一連の呼び出しを視覚化します。 |
| 5 |
Interaction Overview アクティビティ図とシーケンス図を組み合わせて、システムとビジネスプロセスの制御フローの概要を提供します。 |
| 6 |
Communication オブジェクトの役割に焦点を合わせていることを除いて、シーケンス図と同じです。 各通信は、シーケンスの順序、番号、および過去のメッセージに関連付けられています。 |
| 7 |
Time Sequenced 状態、条件、およびイベントのメッセージによる変更を説明します。 |
アーキテクチャビューモデル
モデルは、特定の視点または視点からの複数のビューで構成されるソフトウェアアーキテクチャの完全で基本的な簡略化された説明です。
ビューは、関連する一連の懸念の観点からのシステム全体の表現です。 エンドユーザー、開発者、プロジェクトマネージャー、テスターなどのさまざまな利害関係者の観点からシステムを記述するために使用されます。
4 + 1ビューモデル
4 + 1ビューモデルは、Philippe Kruchtenによって設計され、複数の同時ビューの使用に基づくソフトウェア集約型システムのアーキテクチャを記述しています。 これは、システムのさまざまな機能と問題に対処する*複数ビュー*モデルです。 ソフトウェア設計文書を標準化し、すべての関係者が設計を理解しやすくします。
これは、ソフトウェアアーキテクチャの設計を調査および文書化するためのアーキテクチャ検証方法であり、すべての利害関係者のソフトウェアアーキテクチャのあらゆる側面を網羅しています。 それは4つの本質的なビューを提供します-
- 論理ビューまたは概念ビュー-デザインのオブジェクトモデルを説明します。
- プロセスビュー-システムのアクティビティを説明し、設計の同時実行性と同期の側面をキャプチャします。
- 物理ビュー-ソフトウェアのハードウェアへのマッピングを説明し、その分散された側面を反映します。
- 開発ビュー-環境の開発におけるソフトウェアの静的な組織または構造を説明します。
このビューモデルは、エンドユーザーまたはソフトウェアシステムの顧客向けに、*シナリオビュー*または*ユースケースビュー*と呼ばれるもう1つのビューを追加することで拡張できます。 他の4つのビューと整合性があり、「プラスワン」ビュー（4 + 1）ビューモデルとして機能するアーキテクチャを示すために使用されます。 次の図は、5つの同時ビュー（4 + 1）モデルを使用したソフトウェアアーキテクチャを示しています。
なぜ5ではなく4 + 1と呼ばれるのですか？
- ユースケースビュー*は、システムの高レベルの要件を詳述する一方で、他のビューの詳細-それらの要件がどのように実現されるかという点で、特別な意味を持ちます。 他の4つのビューがすべて完了すると、事実上冗長になります。 ただし、それなしでは他のすべてのビューは不可能です。 次の画像と表は、4 + 1ビューを詳細に示しています-
| Logical | Process | Development | Physical | Scenario | |
|---|---|---|---|---|---|
| Description | Shows the component (Object) of system as well as their interaction | Shows the processes/Workflow rules of system and how those processes communicate, focuses on dynamic view of system | Gives building block views of system and describe static organization of the system modules | Shows the installation, configuration and deployment of software application | Shows the design is complete by performing validation and illustration |
| Viewer/Stake holder | End-User, Analysts and Designer | Integrators & developers | Programmer and software project managers | System engineer, operators, system administrators and system installers | All the views of their views and evaluators |
| Consider | Functional requirements | Non Functional Requirements | Software Module organization (Software management reuse, constraint of tools) | Nonfunctional requirement regarding to underlying hardware | System Consistency and validity |
| UML – Diagram | Class, State, Object, sequence, Communication Diagram | Activity Diagram | Component, Package diagram | Deployment diagram | Use case diagram |
アーキテクチャ記述言語（ADL）
ADLは、ソフトウェアアーキテクチャを定義するための構文とセマンティクスを提供する言語です。 システムの実装とは区別される、ソフトウェアシステムの概念アーキテクチャをモデル化する機能を提供する表記仕様です。
ADLは、アーキテクチャ記述の構成要素であるアーキテクチャコンポーネント、その接続、インターフェイス、および構成をサポートする必要があります。 これは、アーキテクチャー記述で使用するための表現形式であり、コンポーネントを分解し、コンポーネントを結合し、コンポーネントのインターフェースを定義する機能を提供します。
アーキテクチャ記述言語は、プロセス、スレッド、データ、サブプログラムなどのソフトウェア機能、およびプロセッサ、デバイス、バス、メモリなどのハードウェアコンポーネントを記述する正式な仕様言語です。
ADLとプログラミング言語またはモデリング言語を分類または区別することは困難です。 ただし、ADLとして分類される言語には次の要件があります-
- すべての関係者にアーキテクチャを伝えるのに適切なはずです。
- アーキテクチャの作成、改良、および検証のタスクに適している必要があります。
- さらに実装するための基盤を提供する必要があるため、ADL仕様に情報を追加して、ADLから最終的なシステム仕様を導出できるようにする必要があります。
- 一般的なアーキテクチャスタイルのほとんどを表現する機能が必要です。
- 分析機能をサポートするか、プロトタイプ生成の迅速な生成を提供する必要があります。
オブジェクト指向のパラダイム
オブジェクト指向（OO）パラダイムは、新しいプログラミングアプローチの最初のコンセプトから形になりましたが、設計と分析の手法への関心はずっと後になりました。 オブジェクト指向の分析と設計のパラダイムは、オブジェクト指向プログラミング言語が広く採用されたことの論理的な結果です。
- 最初のオブジェクト指向言語は Simula （実際のシステムのシミュレーション）で、1960年にノルウェーコンピューティングセンターの研究者によって開発されました。
- 1970年、 Alan Kay とXerox PARCの彼の研究グループは、 Dynabook という名前のパーソナルコンピューターと、Dynabookをプログラミングするための最初の純粋なオブジェクト指向プログラミング言語（OOPL）であるSmalltalkを作成しました。
- 1980年代、 Grady Booch は、主にプログラミング言語Adaの設計を提示したObject Oriented Designというタイトルの論文を発表しました。 その後のエディションでは、彼はアイデアを完全なオブジェクト指向設計方法に拡張しました。
- 1990年代、 Coad はオブジェクト指向メソッドに行動のアイデアを取り入れました。
その他の重要な革新は、 James Rum Baugh によるObject Modeling Techniques（OMT）および Ivar Jacobson によるObject-Oriented Software Engineering（OOSE）です。
OOパラダイムの紹介
オブジェクト指向のパラダイムは、あらゆるソフトウェアの開発にとって重要な方法論です。 パイプとフィルター、データリポジトリ、コンポーネントベースなど、ほとんどのアーキテクチャスタイルまたはパターンは、このパラダイムを使用して実装できます。
オブジェクト指向システムの基本概念と用語-
対象
オブジェクトは、物理的または概念的に存在する可能性のあるオブジェクト指向環境の現実世界の要素です。 各オブジェクトには-
- システム内の他のオブジェクトと区別するID。
- オブジェクトの特性プロパティと、オブジェクトが保持するプロパティの値を決定する状態。
- 状態の変化に関して、オブジェクトによって実行される外部から見えるアクティビティを表す動作。
オブジェクトは、アプリケーションのニーズに応じてモデル化できます。 オブジェクトには、顧客、自動車などの物理的な存在が含まれる場合があります。または、プロジェクト、プロセスなどの無形の概念的存在
クラス
クラスは、共通の動作を示す同じ特性プロパティを持つオブジェクトのコレクションを表します。 ブループリントまたはそれから作成できるオブジェクトの説明を提供します。 クラスのメンバーとしてのオブジェクトの作成は、インスタンス化と呼ばれます。 したがって、オブジェクトはクラスの*インスタンス*です。
クラスの構成要素は-
- クラスからインスタンス化されるオブジェクトの属性のセット。 一般に、クラスの異なるオブジェクトには、属性の値に多少の違いがあります。 多くの場合、属性はクラスデータと呼ばれます。
- クラスのオブジェクトの動作を表す一連の操作。 操作は、関数またはメソッドとも呼ばれます。
例
2次元空間の幾何学的図形の円を表す単純なクラスCircleを考えてみましょう。 このクラスの属性は次のように識別できます-
- x-coord、中心のx座標を示します
- y座標、中心のy座標を示す
- a、円の半径を示す
その操作のいくつかは次のように定義することができます-
- findArea（）、面積を計算するメソッド
- findCircumference（）、円周を計算する方法
- scale（）、半径を増減する方法
カプセル化
カプセル化は、クラス内で属性とメソッドの両方をバインドするプロセスです。 カプセル化により、クラスの内部詳細を外部から隠すことができます。 クラスが提供するインターフェイスを介してのみ、外部からクラスの要素にアクセスできます。
多型
ポリモーフィズムはもともとギリシャ語で、複数の形式を取る能力を意味します。 オブジェクト指向のパラダイムでは、ポリモーフィズムは、操作対象のインスタンスに応じて、さまざまな方法で操作を使用することを意味します。 多態性により、異なる内部構造を持つオブジェクトが共通の外部インターフェイスを持つことができます。 ポリモーフィズムは、継承を実装するときに特に効果的です。
例
それぞれがメソッドfindArea（）を持つ2つのクラス、CircleとSquareを考えてみましょう。 クラス内のメソッドの名前と目的は同じですが、内部実装、つまり面積を計算する手順はクラスごとに異なります。 CircleクラスのオブジェクトがfindArea（）メソッドを呼び出すと、SquareクラスのfindArea（）メソッドと競合することなく、操作によって円の領域が検出されます。
関係
システムを記述するために、システムの動的（動作）仕様と静的（論理）仕様の両方を提供する必要があります。 動的仕様は、オブジェクト間の関係を記述します。 メッセージの受け渡し。 そして、静的仕様は、クラス間の関係を記述します。 集約、関連付け、および継承。
メッセージの受け渡し
どのアプリケーションでも、調和のとれた方法で相互作用する多くのオブジェクトが必要です。 システム内のオブジェクトは、メッセージパッシングを使用して相互に通信できます。 システムにobj1とobj2の2つのオブジェクトがあるとします。 obj1がメソッドの1つをobj2に実行させる場合、オブジェクトobj1はオブジェクトobj2にメッセージを送信します。
構成または集約
集約または合成は、クラスを他のクラスのオブジェクトの任意の組み合わせで構成できるクラス間の関係です。 オブジェクトを他のクラスの本体内に直接配置できます。 集約は、「一部」または「有」関係と呼ばれ、全体からその部分にナビゲートする機能を備えています。 集合オブジェクトは、1つ以上の他のオブジェクトで構成されるオブジェクトです。
協会
関連付けは、共通の構造と共通の動作を持つリンクのグループです。 関連付けは、1つ以上のクラスのオブジェクト間の関係を表します。 リンクは、関連付けのインスタンスとして定義できます。 関連度は、接続に関係するクラスの数を示します。 次数は単項、二項、三項のいずれかです。
- 単項関係は、同じクラスのオブジェクトを接続します。
- バイナリ関係は、2つのクラスのオブジェクトを接続します。
- 三項関係は、3つ以上のクラスのオブジェクトを接続します。
継承
これは、その機能を拡張および改良することにより、既存のクラスから新しいクラスを作成できるようにするメカニズムです。 既存のクラスは基本クラス/親クラス/スーパークラスと呼ばれ、新しいクラスは派生クラス/子クラス/サブクラスと呼ばれます。
サブクラスは、スーパークラスで許可されている場合、スーパークラスの属性とメソッドを継承または派生できます。 また、サブクラスは独自の属性とメソッドを追加し、スーパークラスのメソッドを変更できます。 継承は、「is – a」関係を定義します。
例
クラス哺乳類から、人間、猫、犬、牛などの多くのクラスを派生させることができます。 人間、猫、犬、牛はすべて哺乳類の特徴を持っています。 さらに、それぞれに固有の特性があります。 牛は哺乳類であると言えます。
オブジェクト指向分析
ソフトウェア開発のオブジェクト指向分析フェーズでは、システム要件が決定され、クラスが識別され、クラス間の関係が確認されます。 OO分析の目的は、システムのアプリケーションドメインと特定の要件を理解することです。 このフェーズの結果は、要件の仕様と、論理構造とシステムの実現可能性の初期分析です。
オブジェクト指向分析で相互に使用される3つの分析手法は、オブジェクトモデリング、動的モデリング、および機能モデリングです。
オブジェクトモデリング
オブジェクトモデリングは、オブジェクトに関してソフトウェアシステムの静的構造を開発します。 オブジェクト、オブジェクトをグループ化できるクラス、およびオブジェクト間の関係を識別します。 また、各クラスを特徴付ける主な属性と操作も識別します。
オブジェクトモデリングのプロセスは、次の手順で視覚化することができます-
- オブジェクトを特定し、クラスにグループ化します
- クラス間の関係を特定する
- ユーザーオブジェクトモデル図を作成する
- ユーザーオブジェクト属性を定義する
- クラスで実行する必要のある操作を定義する
動的モデリング
システムの静的な振る舞いを分析した後、時間および外部の変化に関するシステムの振る舞いを調べる必要があります。 これが動的モデリングの目的です。
ダイナミックモデリングは、「個々のオブジェクトがイベント（他のオブジェクトによってトリガーされる内部イベント、または外界によってトリガーされる外部イベント）にどのように応答するかを記述する方法」として定義できます。
動的モデリングのプロセスは、次の手順で視覚化することができます-
- 各オブジェクトの状態を識別する
- イベントを特定し、アクションの適用可能性を分析します
- 状態遷移図で構成される動的モデル図を作成します
- オブジェクトの属性の観点から各状態を表現する
- 描かれた状態遷移図を検証する
機能モデリング
機能モデリングは、オブジェクト指向分析の最終コンポーネントです。 機能モデルは、オブジェクト内で実行されるプロセスと、メソッド間を移動するデータの変化を示します。 オブジェクトモデリングの操作の意味と動的モデリングのアクションを指定します。 機能モデルは、従来の構造化分析のデータフロー図に対応しています。
機能モデリングのプロセスは、次の手順で視覚化することができます-
- すべての入力と出力を特定する
- 機能的な依存関係を示すデータフロー図の作成
- 各機能の目的を述べる
- 制約を特定する
- 最適化基準を指定する
オブジェクト指向設計
分析フェーズの後、概念モデルは、オブジェクト指向設計（OOD）を使用してオブジェクト指向モデルにさらに発展します。 OODでは、分析モデルの技術に依存しない概念が実装クラスにマッピングされ、制約が特定され、インターフェイスが設計され、ソリューションドメインのモデルが作成されます。 オブジェクト指向設計の主な目的は、システムの構造アーキテクチャを開発することです。
オブジェクト指向設計の段階は次のように識別できます-
- システムのコンテキストを定義する
- システムアーキテクチャの設計
- システム内のオブジェクトの識別
- 設計モデルの構築
- オブジェクトインターフェイスの仕様
OOデザインは、概念設計と詳細設計の2つの段階に分けることができます。
- コンセプチュアルデザイン *
この段階では、システムの構築に必要なすべてのクラスが識別されます。 さらに、特定の責任が各クラスに割り当てられます。 クラス図はクラス間の関係を明確にするために使用され、相互作用図はイベントの流れを示すために使用されます。* 高レベル設計*とも呼ばれます。
- きめ細かなデザイン *
この段階では、相互作用図に基づいて属性と操作が各クラスに割り当てられます。 ステートマシン図は、設計の詳細を説明するために作成されます。* 低レベル設計*とも呼ばれます。
デザイン原則
主な設計原則は次のとおりです-
*_デカップリングの原理_*1つのクラスを変更すると、他のクラスのカスケード更新が発生する可能性があるため、高度に相互依存するクラスのセットでシステムを維持することは困難です。 OO設計では、新しいクラスまたは継承を導入することにより、密結合を排除できます。
*_凝集力の確保_*凝集クラスは、密接に関連する一連の機能を実行します。 凝集性の欠如とは、クラスが無関係な機能を実行することを意味しますが、システム全体の動作には影響しません。 これにより、ソフトウェアの構造全体の管理、拡張、保守、および変更が困難になります。
*_オープンクローズド原則_*この原則によれば、システムは新しい要件を満たすために拡張できる必要があります。 システムの拡張の結果として、システムの既存の実装とコードを変更しないでください。 さらに、次のガイドラインは、オープンクローズの原則に従っている必要があります-
- 具体的なクラスごとに、個別のインターフェイスと実装を維持する必要があります。
- マルチスレッド環境では、属性をプライベートにしてください。
- グローバル変数とクラス変数の使用を最小限にします。
データフローアーキテクチャ
データフローアーキテクチャでは、ソフトウェアシステム全体が、データと操作が互いに独立している連続したピースまたは入力データのセットに対する一連の変換と見なされます。 このアプローチでは、データがシステムに入力され、最終的な宛先（出力またはデータストア）に割り当てられるまで、一度に1つずつモジュールを流れます。
コンポーネントまたはモジュール間の接続は、I/Oストリーム、I/Oバッファー、パイプ接続、または他のタイプの接続として実装できます。 データは、サイクルのあるグラフトポロジ、サイクルのない線形構造、またはツリー型構造で飛行できます。
このアプローチの主な目的は、再利用と変更可能性の品質を達成することです。 これは、コンパイラやビジネスデータ処理アプリケーションなど、明確に定義された一連の独立したデータ変換や、秩序だって定義された入力および出力の計算を伴うアプリケーションに適しています。 モジュール間の実行シーケンスには3つのタイプがあります-
- バッチ順次
- パイプアンドフィルターまたは非シーケンシャルパイプラインモード
- プロセス制御
バッチシーケンシャル
バッチシーケンシャルは、従来のデータ処理モデルです。データ変換サブシステムは、前のサブシステムが完全に完了した後にのみプロセスを開始できます-
- データのフローは、1つのサブシステムから別のサブシステムにデータのバッチ全体を運びます。
- モジュール間の通信は、一時的な中間ファイルを介して行われ、連続するサブシステムによって削除できます。
- データがバッチ処理され、各サブシステムが関連する入力ファイルを読み取り、出力ファイルを書き込むアプリケーションに適用できます。
- このアーキテクチャの典型的なアプリケーションには、銀行や公共料金などのビジネスデータ処理が含まれます。
利点
- サブシステムのより単純な区分を提供します。
- 各サブシステムは、入力データを処理し、出力データを生成する独立したプログラムにすることができます。
デメリット
- 高いレイテンシーと低いスループットを提供します。
- 並行性と対話型のインターフェースは提供しません。
- 実装には外部制御が必要です。
パイプとフィルターのアーキテクチャ
このアプローチは、連続するコンポーネントによるデータの増分変換に重点を置いています。 このアプローチでは、データのフローはデータによって駆動され、システム全体がデータソース、フィルター、パイプ、およびデータシンクのコンポーネントに分解されます。
モジュール間の接続は、バイト、文字、またはそのような種類の他のタイプのストリームである先入れ先出しバッファであるデータストリームです。 このアーキテクチャの主な機能は、同時実行と増分実行です。
フィルタ
フィルターは、独立したデータストリームトランスフォーマーまたはストリームトランスデューサーです。 入力データストリームのデータを変換して処理し、変換されたデータストリームをパイプを介して次に処理するフィルターに書き込みます。 接続されたパイプを介してデータが到着するとすぐに動作を開始する増分モードで動作します。 フィルターには、*アクティブフィルター*および*パッシブフィルター*の2種類があります。
アクティブフィルター
アクティブフィルターを使用すると、接続されたパイプでデータを取得し、変換されたデータをプッシュできます。 パッシブパイプで動作し、プルおよびプッシュの読み取り/書き込みメカニズムを提供します。 このモードは、UNIXパイプおよびフィルターメカニズムで使用されます。
パッシブフィルター
パッシブフィルターを使用すると、接続されたパイプでデータをプッシュインおよびプルアウトできます。 アクティブパイプで動作します。アクティブパイプは、フィルターからデータを取得し、データを次のフィルターにプッシュします。 読み取り/書き込みメカニズムを提供する必要があります。
利点
- 過剰なデータ処理に並行性と高いスループットを提供します。
- 再利用性を提供し、システムメンテナンスを簡素化します。
- フィルター間の変更可能性と低結合を提供します。
- パイプで接続された2つのフィルターを明確に分割することにより、シンプルさを提供します。
- 順次実行と並列実行の両方をサポートすることにより、柔軟性を提供します。
デメリット
- 動的な相互作用には適していません。
- ASCII形式でデータを送信するには、低い公分母が必要です。
- フィルター間のデータ変換のオーバーヘッド。
- フィルターが協調して問題を解決するための方法を提供しません。
- このアーキテクチャを動的に構成することは困難です。
Pipe
パイプはステートレスであり、2つのフィルター間に存在するバイナリまたは文字ストリームを伝送します。 データストリームをあるフィルターから別のフィルターに移動できます。 パイプは少しのコンテキスト情報を使用し、インスタンス間で状態情報を保持しません。
プロセス制御アーキテクチャ
これは、データがバッチシーケンシャルでもパイプラインストリームでもないタイプのデータフローアーキテクチャです。 データの流れは、プロセスの実行を制御する一連の変数から発生します。 システム全体をサブシステムまたはモジュールに分解し、それらを接続します。
サブシステムの種類
プロセス制御アーキテクチャには、プロセス制御変数を変更する*処理ユニット*と、変更量を計算する*コントローラーユニット*があります。
コントローラユニットは、次の要素を持っている必要があります-
- 制御変数-制御変数は、基礎となるシステムの値を提供し、センサーで測定する必要があります。 たとえば、クルーズコントロールシステムの速度。
- 入力変数-プロセスへの入力を測定します。 たとえば、温度制御システムの戻り空気の温度
- 操作変数-操作変数値は、コントローラーによって調整または変更されます。
- プロセス定義-いくつかのプロセス変数を操作するメカニズムが含まれています。
- センサー-制御に関連するプロセス変数の値を取得し、操作変数を再計算するためのフィードバック参照として使用できます。
- セットポイント-それは制御変数の望ましい値です。
- 制御アルゴリズム-プロセス変数の操作方法を決定するために使用されます。
応用分野
プロセス制御アーキテクチャは、次のドメインに適しています-
- システムがプロセス制御変数データによって操作される組み込みシステムソフトウェア設計。
- アプリケーション。目的は、プロセスの出力の指定されたプロパティを指定された基準値に維持することです。
- カークルーズ制御および建物の温度制御システムに適用可能。
- 自動車のアンチロックブレーキ、原子力発電所などを制御するリアルタイムシステムソフトウェア
データ中心のアーキテクチャ
データ中心のアーキテクチャでは、データは集中化され、データを変更する他のコンポーネントによって頻繁にアクセスされます。 このスタイルの主な目的は、データの完全性を実現することです。 データ中心のアーキテクチャは、共有データリポジトリを介して通信するさまざまなコンポーネントで構成されています。 コンポーネントは共有データ構造にアクセスし、比較的独立しています。つまり、データストアを介してのみ対話します。
データ中心アーキテクチャの最もよく知られている例は、データベースアーキテクチャです。このアーキテクチャでは、共通のデータベーススキーマがデータ定義プロトコルで作成されます。たとえば、RDBMSのフィールドとデータタイプを持つ関連テーブルのセットです。
データ中心のアーキテクチャのもう1つの例は、共通のデータスキーマ（つまり、 Webのメタ構造）およびハイパーメディアデータモデルに準拠し、プロセスは共有Webベースのデータサービスを使用して通信します。
コンポーネントの種類
コンポーネントの2種類があります-
- *中央データ*構造またはデータストアまたはデータリポジトリ。永続的なデータストレージを提供します。 現在の状態を表します。
- 中央データストアで動作し、計算を実行し、結果を戻す可能性のある*データアクセサー*または独立したコンポーネントのコレクション。
データアクセサー間の相互作用または通信は、データストアを介してのみ行われます。 データは、クライアント間の通信の唯一の手段です。 制御の流れは、アーキテクチャを2つのカテゴリに区別します-
- リポジトリアーキテクチャスタイル
- 黒板のアーキテクチャスタイル
リポジトリアーキテクチャスタイル
リポジトリアーキテクチャスタイルでは、データストアはパッシブであり、データストアのクライアント（ソフトウェアコンポーネントまたはエージェント）はアクティブであり、ロジックフローを制御します。 関与するコンポーネントは、データストアの変更を確認します。
- クライアントはアクションを実行するためにシステムにリクエストを送信します（例： データを挿入）。
- 計算プロセスは独立しており、着信要求によってトリガーされます。
- トランザクションの入力ストリーム内のトランザクションのタイプが実行するプロセスの選択をトリガーする場合、それは従来のデータベースまたはリポジトリアーキテクチャ、またはパッシブリポジトリです。
- このアプローチは、DBMS、ライブラリ情報システム、CORBAのインターフェイスリポジトリ、コンパイラ、およびCASE（コンピューター支援ソフトウェアエンジニアリング）環境で広く使用されています。
利点
- データの整合性、バックアップおよび復元機能を提供します。
- エージェントは相互に直接通信しないため、エージェントのスケーラビリティと再利用性を提供します。
- ソフトウェアコンポーネント間の一時データのオーバーヘッドを削減します。
デメリット
- 障害に対してより脆弱であり、データの複製または複製が可能です。
- データストアのデータ構造とそのエージェント間の高い依存関係。
- データ構造の変更は、クライアントに大きな影響を与えます。
- データの進化は難しく、高価です。
- 分散データのためにネットワーク上でデータを移動するコスト。
黒板のアーキテクチャスタイル
Blackboard Architecture Styleでは、データストアはアクティブであり、クライアントはパッシブです。 したがって、論理フローはデータストアの現在のデータステータスによって決定されます。 中央のデータリポジトリとして機能する黒板コンポーネントがあり、さまざまな計算要素によって内部表現が構築および実行されます。
- 共通のデータ構造で独立して動作する多くのコンポーネントが黒板に保存されます。
- このスタイルでは、コンポーネントは黒板を介してのみ相互作用します。 データストアは、データストアが変更されるたびにクライアントに警告します。
- ソリューションの現在の状態は黒板に保存され、処理は黒板の状態によってトリガーされます。
- データに変更が発生すると、システムは*トリガー*と呼ばれる通知とデータをクライアントに送信します。
- このアプローチは、特定のAIアプリケーションや、音声認識、画像認識、セキュリティシステム、ビジネスリソース管理システムなどの複雑なアプリケーションに見られます。
- 中央データ構造の現在の状態が実行するプロセスを選択する主なトリガーである場合、リポジトリは黒板であり、この共有データソースはアクティブなエージェントです。
- 従来のデータベースシステムとの大きな違いは、黒板アーキテクチャの計算要素の呼び出しは、外部入力ではなく、黒板の現在の状態によってトリガーされることです。
黒板モデルの部品
通常、黒板モデルには3つの主要な部分があります-
ナレッジソース（KS）
ナレッジソースは、*リスナー*または*購読者*とも呼ばれ、別個の独立したユニットです。 問題の一部を解決し、部分的な結果を集計します。 知識ソース間の相互作用は、黒板を通じて一意に行われます。
- Blackboardデータ構造*
問題解決状態データは、アプリケーション依存の階層に編成されます。 知識源は黒板に変更を加え、それが徐々に問題の解決につながります。
コントロール
コントロールはタスクを管理し、作業状態をチェックします。
利点
- 簡単に追加または更新できるナレッジソースを提供するスケーラビリティを提供します。
- すべてのナレッジソースが互いに独立しているため、並行して動作できる並行性を提供します。
- 仮説の実験をサポートします。
- ナレッジソースエージェントの再利用性をサポートします。
デメリット
- 黒板と知識ソースの間に密接な依存関係が存在するため、黒板の構造変更はそのすべてのエージェントに大きな影響を与える可能性があります。
- おおよその解決策のみが予想されるため、推論をいつ終了するかを決定することは困難です。
- 複数のエージェントの同期の問題。
- システムの設計とテストにおける主要な課題。
階層アーキテクチャ
階層アーキテクチャは、システム全体を階層構造と見なします。階層構造では、ソフトウェアシステムは階層のさまざまなレベルで論理モジュールまたはサブシステムに分解されます。 このアプローチは通常、ネットワークプロトコルやオペレーティングシステムなどのシステムソフトウェアの設計に使用されます。
システムソフトウェア階層設計では、低レベルのサブシステムは、隣接する上位レベルのサブシステムにサービスを提供し、下位レベルのメソッドを呼び出します。 下位層は、I/Oサービス、トランザクション、スケジューリング、セキュリティサービスなど、より具体的な機能を提供します。 中間層は、ビジネスロジックやコア処理サービスなど、よりドメインに依存する機能を提供します。 また、上位層は、GUI、シェルプログラミング機能などのユーザーインターフェイスの形式で、より抽象的な機能を提供します。
また、名前空間階層の.NETクラスライブラリなどのクラスライブラリの編成にも使用されます。 すべての設計タイプがこの階層アーキテクチャを実装でき、多くの場合、他のアーキテクチャスタイルと組み合わせます。
階層的な建築スタイルは次のように分かれています-
- メインサブルーチン
- マスタースレーブ
- 仮想マシン
メインサブルーチン
このスタイルの目的は、モジュールを再利用し、個々のモジュールまたはサブルーチンを自由に開発することです。 このスタイルでは、ソフトウェアシステムは、システムの必要な機能に応じてトップダウンの改良を使用してサブルーチンに分割されます。
これらの改良は、分解されたモジュールがその排他的な独立した責任を持つほど単純になるまで、垂直につながります。 機能は再利用され、上位層の複数の呼び出し元によって共有されます。
データがサブルーチンにパラメータとして渡される2つの方法があります、すなわち-
- 値渡し-サブルーチンは過去のデータのみを使用しますが、変更することはできません。
- 参照渡し-サブルーチンは、パラメーターによって参照されるデータの値を使用し、変更します。
利点
- 階層の洗練に基づいてシステムを簡単に分解できます。
- オブジェクト指向設計のサブシステムで使用できます。
デメリット
- グローバルに共有されたデータが含まれているため、脆弱です。
- 密結合により、変更のリップル効果が大きくなる場合があります。
マスタースレーブ
このアプローチは、「分割統治」の原則を適用し、障害計算と計算精度をサポートします。 システムの信頼性とフォールトトレランスを提供するメインサブルーチンアーキテクチャの修正版です。
このアーキテクチャでは、スレーブはマスターに複製サービスを提供し、マスターは特定の選択戦略によってスレーブから特定の結果を選択します。 スレーブは、異なるアルゴリズムと方法またはまったく異なる機能によって同じ機能タスクを実行できます。 これには、すべてのスレーブを並行して実行できる並列コンピューティングが含まれます。
マスター-スレーブパターンの実装は、5つのステップに従います-
- タスクの計算を同等のサブタスクのセットに分割する方法を指定し、サブタスクの処理に必要なサブサービスを特定します。
- 個々のサブタスクの処理から取得した結果を使用して、サービス全体の最終結果を計算する方法を指定します。
- 手順1で特定したサブサービスのインターフェイスを定義します。 スレーブによって実装され、個々のサブタスクの処理を委任するためにマスターによって使用されます。
- 前の手順で開発した仕様に従って、スレーブコンポーネントを実装します。
- 手順1〜3で開発した仕様に従ってマスターを実装します。
アプリケーション
- ソフトウェアの信頼性が重要な問題であるアプリケーションに適しています。
- 並列および分散コンピューティングの分野で広く適用されています。
利点
- より高速な計算と簡単なスケーラビリティ。
- スレーブを複製できるため、堅牢性を提供します。
- スレーブを異なる方法で実装して、セマンティックエラーを最小限に抑えることができます。
デメリット
- 通信のオーバーヘッド。
- すべての問題を分割できるわけではありません。
- 実装が難しく、移植性の問題。
仮想マシンのアーキテクチャ
仮想マシンアーキテクチャは、機能が実装されているハードウェアやソフトウェアに固有ではない機能を装います。 仮想マシンは既存のシステム上に構築され、仮想抽象化、一連の属性、および操作を提供します。
仮想マシンアーキテクチャでは、マスターはスレーブの「同じ」サブサービスを使用し、作業の分割、スレーブの呼び出し、結果の結合などの機能を実行します。 開発者は、まだ構築されていないプラットフォームをシミュレートおよびテストでき、実際のシステムでテストするには複雑すぎる、コストがかかる、または危険な「災害」モードをシミュレートできます。
ほとんどの場合、仮想マシンは実行プラットフォームからプログラミング言語またはアプリケーション環境を分離します。 主な目的は、*移植性*を提供することです。 仮想マシンを介した特定のモジュールの解釈は、次のように認識されます-
- 解釈エンジンは、解釈されるモジュールから命令を選択します。
- 指示に基づいて、エンジンは仮想マシンの内部状態を更新し、上記のプロセスが繰り返されます。
次の図は、単一の物理マシン上の標準VMインフラストラクチャのアーキテクチャを示しています。
- ハイパーバイザー*は*仮想マシンモニター*とも呼ばれ、ホストOS上で実行され、一致したリソースを各ゲストOSに割り当てます。 ゲストがシステムコールを行うと、ハイパーバイザーはそれをインターセプトし、ホストOSがサポートする対応するシステムコールに変換します。 ハイパーバイザーは、各仮想マシンのCPU、メモリ、永続ストレージ、I/Oデバイス、およびネットワークへのアクセスを制御します。
アプリケーション
仮想マシンのアーキテクチャは、次のドメインに適しています-
- 直接的な解決策がない場合、シミュレーションまたは翻訳によって問題を解決するのに適しています。
- サンプルアプリケーションには、マイクロプログラミング、XML処理、スクリプトコマンド言語の実行、ルールベースのシステム実行、SmalltalkおよびJavaインタープリター型プログラミング言語のインタープリターが含まれます。
- 仮想マシンの一般的な例は、インタープリター、ルールベースのシステム、構文シェル、コマンド言語プロセッサーです。
利点
- 移植性とマシンプラットフォームの独立性。
- ソフトウェア開発のシンプルさ。
- プログラムを中断および照会する機能により柔軟性を提供します。
- 災害作業モデルのシミュレーション。
- 実行時に変更を導入します。
デメリット
- インタープリターの性質により、インタープリターの実行が遅い。
- 実行に追加の計算が含まれるため、パフォーマンスコストが発生します。
レイヤードスタイル
このアプローチでは、システムは階層内の多数の上位層と下位層に分解され、各層はシステム内で独自の責任を負います。
- 各層は、パッケージ、デプロイされたコンポーネント、またはメソッドライブラリまたはヘッダーファイルの形式のサブルーチンのグループとしてカプセル化された関連クラスのグループで構成されます。
- 各レイヤーは、その上のレイヤーにサービスを提供し、下のレイヤーのクライアントとして機能します。 レイヤーi +1への要求は、レイヤーiのインターフェースを介してレイヤーiによって提供されるサービスを呼び出します。 タスクが完了すると、応答はレイヤーi +1に戻る場合があります。それ以外の場合、レイヤーiは、下のレイヤーi -1から継続的にサービスを呼び出します。
アプリケーション
レイヤードスタイルは、次の分野に適しています-
- 階層的に編成できるサービスの異なるクラスを含むアプリケーション。
- アプリケーション固有の部分とプラットフォーム固有の部分に分解できるアプリケーション。
- コアサービス、重要なサービス、ユーザーインターフェイスサービスなどの間に明確な区分があるアプリケーション。
利点
- 段階的な抽象化レベルに基づいた設計。
- 1つのレイヤーの機能の変更が最大で他の2つのレイヤーに影響するため、拡張の独立性を提供します。
- 標準インターフェースとその実装の分離。
- システムが新しいコンポーネントのプラグアンドプレイをはるかに容易にするコンポーネントベースのテクノロジを使用して実装されます。
- 各層は、移植性をサポートする独立して配置された抽象マシンにすることができます。
- トップダウンの洗練された方法でタスクの定義に基づいてシステムを簡単に分解する
- 同じレイヤーの異なる実装（同一のインターフェース）を交換可能に使用できます
デメリット
- 多くのアプリケーションまたはシステムは、階層構造で簡単に構成できません。
- クライアントの要求またはクライアントへの応答が潜在的にいくつかの層を通過する必要があるため、実行時のパフォーマンスが低下します。
- また、各レイヤーによるデータのマーシャリングとバッファリングのオーバーヘッドに関するパフォーマンス上の懸念もあります。
- 層間通信を開くとデッドロックが発生し、「ブリッジング」により密結合が発生する場合があります。
- 階層化アーキテクチャでは、例外とエラー処理が問題になります。これは、1つの層の障害がすべての呼び出し層に広がる必要があるためです。
インタラクション指向のアーキテクチャ
対話指向アーキテクチャの主な目的は、ユーザーの対話をデータ抽象化およびビジネスデータ処理から分離することです。 対話指向のソフトウェアアーキテクチャは、システムを3つの主要なパーティションに分解します-
- データモジュール-データモジュールは、データの抽象化とすべてのビジネスロジックを提供します。
- 制御モジュール-制御モジュールは、制御およびシステム構成アクションのフローを識別します。
- * Viewプレゼンテーションモジュール*-Viewプレゼンテーションモジュールは、データ出力の視覚的または音声的プレゼンテーションを担当し、ユーザー入力用のインターフェイスも提供します。
対話指向アーキテクチャには、 Model-View-Controller （MVC）および Presentation-Abstraction-Control （PAC）の2つの主要なスタイルがあります。 MVCとPACはどちらも3つのコンポーネントの分解を提案し、複数のトークとユーザーの対話を伴うWebアプリケーションなどの対話型アプリケーションに使用されます。 制御と組織の流れが異なります。 PACはエージェントベースの階層アーキテクチャですが、MVCには明確な階層構造がありません。
モデルビューコントローラ（MVC）
MVCは、特定のソフトウェアアプリケーションを3つの相互接続された部分に分解します。これは、ユーザーに提示または受け入れられた情報から情報の内部表現を分離するのに役立ちます。
| Module | Function |
|---|---|
| Model | Encapsulation the underlying data and business logic |
| Controller | Respond to user action and direct the application flow |
| View | Formats and present the data from model to user. |
モデル
モデルは、アプリケーションのデータ、ロジック、および制約を直接管理するMVCの中心的なコンポーネントです。 これは、生のアプリケーションデータとインターフェイスのアプリケーションロジックを保持するデータコンポーネントで構成されます。
- 独立したユーザーインターフェイスであり、アプリケーションの問題ドメインの動作をキャプチャします。
- ドメイン固有のソフトウェアシミュレーションまたはアプリケーションの中心構造の実装です。
- 状態が変更されると、関連するビューに通知を送信して更新された出力を生成し、コントローラーが使用可能なコマンドのセットを変更します。
View
ビューを使用すると、ダイアグラムやチャートなどのグラフィック形式で情報の出力を表すことができます。 データの視覚的表現を提供するプレゼンテーションコンポーネントで構成されます
- ビューはモデルから情報を要求し、ユーザーへの出力表現を生成します。
- 管理用の棒グラフや会計士用の表形式ビューなど、同じ情報の複数のビューが可能です。
コントローラ
コントローラーは入力を受け入れ、それをモデルまたはビューのコマンドに変換します。 これは、モデルを変更してユーザーからの入力を処理する入力処理コンポーネントで構成されています。
- これは、関連するモデルとビュー、および入力デバイス間のインターフェースとして機能します。
- モデルにコマンドを送信してモデルの状態を更新し、モデルに関連付けられたビューにコマンドを送信して、モデルのビューの表示を変更できます。
MVC-I
これは、システムが2つのサブシステムに分割されているMVCアーキテクチャのシンプルなバージョンです-
- コントローラービュー-コントローラービューは、入力/出力インターフェイスとして機能し、処理が行われます。
- モデル-モデルはすべてのデータおよびドメインサービスを提供します。
- MVC-Iアーキテクチャ*
モデルモジュールは、データの変更をコントローラービューモジュールに通知し、それに応じてグラフィックデータの表示が変更されるようにします。 コントローラーは、変更時に適切なアクションも実行します。
コントローラービューとモデル間の接続は、subscribe-notifyのパターンで設計することができます（上の図を参照）。これにより、コントローラービューがモデルにサブスクライブし、モデルがコントローラービューに変更を通知します。
MVC-II
MVC–IIは、ビューモジュールとコントローラーモジュールが分離されているMVC-Iアーキテクチャの拡張機能です。 モデルモジュールは、データベースでサポートされるすべてのコア機能とデータを提供することにより、MVC-Iと同様に積極的な役割を果たします。
ビューモジュールはデータを提示し、コントローラーモジュールは入力要求を受け入れ、入力データを検証し、モデル、ビュー、それらの接続を開始し、タスクをディスパッチします。
- MVC-IIアーキテクチャ*
MVCアプリケーション
MVCアプリケーションは、単一のデータモデルに複数のビューが必要で、新しいインターフェイスビューまたは変更インターフェイスビューを簡単にプラグインできるインタラクティブなアプリケーションに効果的です。
MVCアプリケーションは、モジュール間に明確な区分があるアプリケーションに適しているため、さまざまな専門家をそのようなアプリケーションのさまざまな側面で同時に作業するように割り当てることができます。
メリット
- 多くのMVCベンダーフレームワークツールキットが利用可能です。
- 複数のビューが同じデータモデルと同期しました。
- 新しいプラグインまたはインターフェースビューを簡単にプラグインできます。
- グラフィックの専門家、プログラミングの専門家、データベース開発の専門家が設計されたプロジェクトチームで作業しているアプリケーション開発に使用されます。
デメリット
- インタラクティブなモバイルアプリケーションやロボットアプリケーションなど、エージェント指向のアプリケーションには適していません。
- 同じデータモデルに基づいたコントローラーとビューの複数のペアは、データモデルの変更に費用がかかります。
- ビューとコントローラーの区分が明確でない場合があります。
プレゼンテーション抽象化制御（PAC）
PACでは、システムは多くの協力エージェント（トライアド）の階層に配置されます。 インタラクティブな要件に加えて、複数のエージェントのアプリケーション要件をサポートするためにMVCから開発されました。
各エージェントには3つのコンポーネントがあります-
- プレゼンテーションコンポーネント-データの視覚および音声プレゼンテーションをフォーマットします。
- 抽象化コンポーネント-データを取得して処理します。
- 制御コンポーネント-他の2つのコンポーネント間の制御および通信のフローなどのタスクを処理します。
PACアーキテクチャは、プレゼンテーションモジュールがMVCのビューモジュールに似ているという意味で、MVCに似ています。 抽象化モジュールはMVCのモデルモジュールに似ており、制御モジュールはMVCのコントローラーモジュールに似ていますが、制御と編成のフローが異なります。
各エージェントの抽象化コンポーネントとプレゼンテーションコンポーネントの間には直接的な接続はありません。 各エージェントの制御コンポーネントは、他のエージェントとの通信を担当します。
次の図は、PAC設計の単一エージェントのブロック図を示しています。
複数のエージェントを使用したPAC
複数のエージェントで構成されるPACでは、トップレベルのエージェントがコアデータとビジネスロジックを提供します。 最下層のエージェントは、詳細な特定のデータとプレゼンテーションを定義します。 中レベルまたは中レベルのエージェントは、低レベルのエージェントのコーディネーターとして機能します。
- 各エージェントには、固有の割り当てられたジョブがあります。
- 一部の中間レベルのエージェントでは、インタラクティブなプレゼンテーションが必要ないため、プレゼンテーションコンポーネントがありません。
- 制御コンポーネントは、すべてのエージェントが互いに通信するためのすべてのエージェントに必要です。
次の図は、PACに参加する複数のエージェントを示しています。
アプリケーション
- システムを階層的な方法で多くの協調エージェントに分解できるインタラクティブシステムに効果的です。
- エージェントの変更が他に影響を与えないように、エージェント間の結合が緩いと予想される場合に効果的です。
- すべてのエージェントが遠くに分散しており、各エージェントがデータと対話型インターフェースを備えた独自の機能を持つ分散システムに効果的です。
- それぞれが独自の現在のデータと対話型インターフェースを保持し、他のコンポーネントと通信する必要があるリッチGUIコンポーネントを備えたアプリケーションに適しています。
利点
- マルチタスクとマルチビューのサポート
- エージェントの再利用性と拡張性のサポート
- 新しいエージェントのプラグインや既存のエージェントの変更が簡単
- 異なるスレッドまたは異なるデバイスまたはコンピューターで複数のエージェントが並行して実行されている並行性のサポート
デメリット
- プレゼンテーションと抽象化の間のコントロールブリッジ、およびエージェント間のコントロールの通信によるオーバーヘッド。
- 疎結合とエージェント間の高い独立性のため、エージェントの適切な数を決定するのが困難です。
- エージェント間の通信はエージェントのコントロール間でのみ行われるため、各エージェントのコントロールによるプレゼンテーションと抽象化の完全な分離により、開発の複雑さが生じます。
分散アーキテクチャ
分散アーキテクチャでは、コンポーネントは異なるプラットフォーム上に提示され、特定の目的または目標を達成するために、いくつかのコンポーネントが通信ネットワークを介して相互に連携できます。
- このアーキテクチャでは、情報処理は単一のマシンに限定されず、複数の独立したコンピューターに分散されます。
- 分散システムは、多層アーキテクチャのベースとなるクライアント/サーバーアーキテクチャによって実証できます。代替手段は、CORBAなどのブローカーアーキテクチャ、およびサービス指向アーキテクチャ（SOA）です。
- .NET、J2EE、CORBA、.NET Webサービス、AXIS Java Webサービス、Globus Gridサービスなど、分散アーキテクチャをサポートするいくつかのテクノロジーフレームワークがあります。
- ミドルウェアは、分散アプリケーションの開発と実行を適切にサポートするインフラストラクチャです。 アプリケーションとネットワークの間にバッファを提供します。 *システムの中央に位置し、分散システムのさまざまなコンポーネントを管理またはサポートします。 例としては、トランザクション処理モニター、データコンバーター、通信コントローラーなどがあります。
分散システムのインフラストラクチャとしてのミドルウェア
Concepts Distributed Architecture
分散アーキテクチャの基本は、その透明性、信頼性、および可用性です。
次の表は、分散システムにおける透過性のさまざまな形式を示しています-
| Sr.No. | Transparency & Description |
|---|---|
| 1 |
リソースへのアクセス方法とデータプラットフォームの違いを隠します。 |
| 2 |
Location リソースが配置されている場所を非表示にします。 |
| 3 |
Technology プログラミング言語やOSなどのさまざまなテクノロジーをユーザーから隠します。 |
| 4 |
Migration/Relocation 使用中の別の場所に移動される可能性のあるリソースを非表示にします。 |
| 5 |
Replication 複数の場所でコピーされる可能性のあるリソースを非表示にします。 |
| 6 |
Concurrency 他のユーザーと共有される可能性のあるリソースを非表示にします。 |
| 7 |
Failure ユーザーのリソースの障害と回復を隠します。 |
| 8 |
Persistence リソース（ソフトウェア）がメモリまたはディスクにあるかどうかを非表示にします。 |
利点
- リソース共有-ハードウェアおよびソフトウェアリソースの共有。
- オープン性-さまざまなベンダーのハードウェアとソフトウェアを使用する柔軟性。
- 並行性-パフォーマンスを向上させるための並行処理。
- スケーラビリティ-新しいリソースを追加することでスループットが向上しました。
- フォールトトレランス-フォールトが発生した後も動作を継続する機能。
デメリット
- 複雑さ-集中システムよりも複雑です。
- セキュリティ-外部からの攻撃を受けやすくなります。
- 管理性-システム管理により多くの労力が必要です。
- 予測不能-システム構成とネットワーク負荷に応じた予測不能な応答。
集中システムvs. 分散システム
| Criteria | Centralized system | Distributed System |
|---|---|---|
| Economics | Low | High |
| Availability | Low | High |
| Complexity | Low | High |
| Consistency | Simple | High |
| Scalability | Poor | Good |
| Technology | Homogeneous | Heterogeneous |
| Security | High | Low |
クライアントサーバーアーキテクチャ
クライアントサーバーアーキテクチャは、システムを2つの主要なサブシステムまたは論理プロセスに分解する最も一般的な分散システムアーキテクチャです-
- クライアント-これは、2番目のプロセスにリクエストを発行する最初のプロセスです。 サーバー。
- サーバー-これは、要求を受信して実行し、クライアントに応答を送信する2番目のプロセスです。
このアーキテクチャでは、アプリケーションは、サーバーによって提供される一連のサービスと、これらのサービスを使用する一連のクライアントとしてモデル化されます。 サーバーはクライアントについて知る必要はありませんが、クライアントはサーバーのIDを知っている必要があり、プロセッサーとプロセスのマッピングは必ずしも1対1ではありません。
クライアントサーバーアーキテクチャは、クライアントの機能に基づいて2つのモデルに分類することができます-
シンクライアントモデル
シンクライアントモデルでは、すべてのアプリケーションの処理とデータ管理はサーバーによって行われます。 クライアントは、プレゼンテーションソフトウェアを実行するだけです。
- レガシーシステムがクライアントサーバーアーキテクチャに移行されるときに使用されます。レガシーシステムは、クライアントに実装されたグラフィカルインターフェイスを備えた独自のサーバーとして機能します。
- 主な欠点は、サーバーとネットワークの両方に高い処理負荷がかかることです。
シック/ファットクライアントモデル
シッククライアントモデルでは、サーバーはデータ管理のみを担当します。 クライアント上のソフトウェアは、アプリケーションロジックとシステムユーザーとの対話を実装します。
- クライアントシステムの機能が事前にわかっている新しいC/Sシステムに最適
- 特に管理用のシンクライアントモデルよりも複雑です。 アプリケーションの新しいバージョンをすべてのクライアントにインストールする必要があります。
利点
- ユーザーインターフェイスの表示やビジネスロジックの処理などの責任の分離。
- サーバーコンポーネントの再利用性と同時実行の可能性
- 分散アプリケーションの設計と開発を簡素化します
- 既存のアプリケーションを分散環境に簡単に移行または統合できます。
- また、多数のクライアントが高性能サーバーにアクセスしているときにリソースを効果的に使用します。
デメリット
- 要件の変更に対処するための異種インフラストラクチャの欠如。
- セキュリティの複雑さ。
- サーバーの可用性と信頼性の制限。
- 限られたテスト容易性とスケーラビリティ。
- プレゼンテーションとビジネスロジックを併せ持つ太ったクライアント。
多層アーキテクチャ（n層アーキテクチャ）
多層アーキテクチャは、プレゼンテーション、アプリケーション処理、データ管理などの機能が物理的に分離されているクライアント/サーバーアーキテクチャです。 アプリケーションを層に分けることにより、開発者はアプリケーション全体を作り直す代わりに、特定のレイヤーを変更または追加するオプションを取得します。 開発者が柔軟で再利用可能なアプリケーションを作成できるモデルを提供します。
多層アーキテクチャの最も一般的な使用法は、3層アーキテクチャです。 3層アーキテクチャは通常、プレゼンテーション層、アプリケーション層、およびデータストレージ層で構成され、個別のプロセッサで実行できます。
プレゼンテーション層
プレゼンテーションレイヤーは、WebページやオペレーティングシステムGUI（グラフィカルユーザーインターフェイス）など、ユーザーが直接アクセスできるアプリケーションの最上位レベルです。 このレイヤーの主な機能は、タスクと結果をユーザーが理解できるものに変換することです。 他の層と通信して、結果をブラウザ/クライアント層およびネットワーク内の他のすべての層に配置します。
アプリケーション層（ビジネスロジック、ロジック層、または中間層）
アプリケーション層は、アプリケーションを調整し、コマンドを処理し、論理的な決定を下し、評価し、計算を実行します。 詳細な処理を実行することにより、アプリケーションの機能を制御します。 また、周囲の2つのレイヤー間でデータを移動および処理します。
データ層
このレイヤーでは、データベースまたはファイルシステムから情報が保存および取得されます。 次に、情報は処理のために戻され、ユーザーに戻されます。 データ永続化メカニズム（データベースサーバー、ファイル共有など）が含まれ、保存されたデータを管理する方法を提供するAPI（アプリケーションプログラミングインターフェイス）をアプリケーション層に提供します。
メリット
- シンクライアントアプローチよりもパフォーマンスが高く、シッククライアントアプローチよりも管理が簡単です。
- 再利用性とスケーラビリティを強化します。要求が増加するにつれて、サーバーを追加できます。
- マルチスレッドサポートを提供し、ネットワークトラフィックも削減します。
- 保守性と柔軟性を提供します
デメリット
- テストツールの不足による不十分なテスト可能性。
- より重要なサーバーの信頼性と可用性。
ブローカーの建築スタイル
ブローカーアーキテクチャスタイルは、分散コンピューティングで使用されるミドルウェアアーキテクチャであり、登録されたサーバーとクライアント間の通信を調整および可能にします。 ここでは、オブジェクト通信は、オブジェクトリクエストブローカー（ソフトウェアバス）と呼ばれるミドルウェアシステムを介して行われます。
- クライアントとサーバーは互いに直接対話しません。 クライアントとサーバーは、仲介業者と通信するプロキシに直接接続しています。
- サーバーは、インターフェースをブローカーに登録および公開することによりサービスを提供し、クライアントはルックアップにより静的または動的にブローカーにサービスを要求できます。
- CORBA（Common Object Request Broker Architecture）は、ブローカーアーキテクチャの優れた実装例です。
ブローカーのアーキテクチャスタイルのコンポーネント
ブローカーのアーキテクチャスタイルのコンポーネントについては、次のヘッドを通して説明します-
ブローカ
ブローカーは、結果や例外の転送やディスパッチなど、通信の調整を担当します。 呼び出し指向のサービス、ドキュメント、またはクライアントがメッセージを送信するメッセージ指向のブローカーのいずれかです。
- サービスリクエストの仲介、適切なサーバーの特定、リクエストの送信、クライアントへのレスポンスの返信を行います。
- サーバーは、機能やサービス、位置情報などのサーバーの登録情報を保持します。
- クライアントが要求するAPI、応答するサーバー、サーバーコンポーネントを登録または登録解除する、メッセージを転送する、サーバーを見つけるAPIを提供します。
スタブ
スタブは静的コンパイル時に生成され、クライアントのプロキシとして使用されるクライアント側に展開されます。 クライアント側プロキシは、クライアントとブローカーの間のメディエーターとして機能し、それらとクライアントの間の透過性をさらに高めます。リモートオブジェクトはローカルオブジェクトのように見えます。
プロキシは、プロトコルレベルでIPC（プロセス間通信）を非表示にし、パラメーター値のマーシャリングとサーバーからの結果のマーシャリング解除を実行します。
スケルトン
スケルトンは、サービスインターフェイスのコンパイルによって生成され、サーバー側に展開されます。サーバー側は、サーバーのプロキシとして使用されます。 サーバー側プロキシは、低レベルのシステム固有のネットワーク機能をカプセル化し、サーバーとブローカーの間を仲介する高レベルAPIを提供します。
リクエストを受け取り、リクエストをアンパックし、メソッド引数を非整列化し、適切なサービスを呼び出し、さらに結果を整列化してからクライアントに送り返します。
ブリッジ
ブリッジは、異なる通信プロトコルに基づいて2つの異なるネットワークを接続できます。 DCOM、.NETリモート、Java CORBAブローカーなどのさまざまなブローカーを仲介します。
ブリッジはオプションのコンポーネントであり、2つのブローカーが相互運用し、リクエストとパラメーターをある形式で受け取り、それらを別の形式に変換するときに実装の詳細を隠します。
- CORBAでのブローカー実装*
CORBAは、Object Request Brokerの国際標準です。OMG（オブジェクト管理グループ）によって定義された分散オブジェクト間の通信を管理するミドルウェアです。
サービス指向アーキテクチャ（SOA）
サービスは、明確に定義された自己完結型の独立した公開されたビジネス機能のコンポーネントであり、標準のプログラミングインターフェイスを介して使用できます。 サービス間の接続は、SOAP Webサービスプロトコルなどの一般的な汎用のメッセージ指向プロトコルによって行われます。このプロトコルは、サービス間で要求と応答を緩やかに配信できます。
サービス指向アーキテクチャは、アプリケーションがソフトウェアサービスとソフトウェアサービスコンシューマ（クライアントまたはサービスリクエスタとも呼ばれる）で構成されるビジネス駆動型ITアプローチをサポートするクライアント/サーバー設計です。
SOAの機能
サービス指向アーキテクチャは、次の機能を提供します-
- 分散展開-エンタープライズデータとビジネスロジックを、疎結合、結合、発見、構造化、標準ベース、粗粒度、サービスと呼ばれる機能のステートレスユニットとして公開します。
- コンポーザビリティ-明確に定義され、公開され、標準的な苦情インターフェイスを通じて、希望の粒度で公開されている既存のサービスから新しいプロセスを組み立てます。
- 相互運用性-基盤となるプロトコルや実装技術に関係なく、ネットワーク全体で機能を共有し、共有サービスを再利用します。
- 再利用性-サービスプロバイダーを選択し、サービスとして公開されている既存のリソースにアクセスします。
SOAオペレーション
次の図は、SOAの動作方法を示しています-
メリット
- サービス指向の疎結合により、企業はプラットフォームやテクノロジーの制限に関係なく、利用可能なすべてのサービスを利用できるようになります。
- ステートレスサービス機能により、各サービスコンポーネントは他のサービスから独立しています。
- 公開されたインターフェイスが変更されない限り、サービスの実装はサービスのアプリケーションに影響を与えません。
- クライアントまたはサービスは、プラットフォーム、テクノロジー、ベンダー、または言語の実装に関係なく、他のサービスにアクセスできます。
- サービスのクライアントは、そのパブリックインターフェイス、サービス構成を知るだけでよいため、資産とサービスの再利用性。
- SOAベースのビジネスアプリケーション開発は、時間とコストの面ではるかに効率的です。
- スケーラビリティを強化し、システム間の標準接続を提供します。
- 「ビジネスサービス」の効率的かつ効果的な使用。
- 統合がはるかに簡単になり、本質的な相互運用性が向上します。
- 開発者の複雑さを抽象化し、エンドユーザーにより近いビジネスプロセスを活性化します。
コンポーネントベースのアーキテクチャ
コンポーネントベースのアーキテクチャは、メソッド、イベント、プロパティを含む明確に定義された通信インターフェイスを表す個々の機能コンポーネントまたは論理コンポーネントへの設計の分解に焦点を当てています。 それは、より高いレベルの抽象化を提供し、問題をサブ問題に分割します。それぞれがコンポーネントパーティションに関連付けられています。
コンポーネントベースのアーキテクチャの主な目的は、*コンポーネントの再利用性*を確保することです。 コンポーネントは、ソフトウェア要素の機能と動作を再利用可能で自己展開可能なバイナリユニットにカプセル化します。 COM/DCOM、JavaBean、EJB、CORBA、.NET、Webサービス、グリッドサービスなど、多くの標準コンポーネントフレームワークがあります。 これらのテクノロジーは、グラフィックJavaBeanコンポーネント、MS ActiveXコンポーネント、COMコンポーネントなど、ローカルデスクトップGUIアプリケーション設計で広く使用されており、ドラッグアンドドロップ操作で簡単に再利用できます。
コンポーネント指向のソフトウェア設計には、次のような従来のオブジェクト指向のアプローチよりも多くの利点があります-
- 既存のコンポーネントを再利用することにより、市場での時間と開発コストを削減しました。
- 既存のコンポーネントの再利用による信頼性の向上。
コンポーネントとは何ですか？
コンポーネントは、その実装をカプセル化し、より高いレベルのインターフェースとしてエクスポートする、明確に定義されたモジュール式のポータブルで交換可能な再利用可能なセットです。
コンポーネントとは、特定の機能または一連の機能をカプセル化し、他のコンポーネントと対話することを目的としたソフトウェアオブジェクトです。 明確に定義されたインターフェイスを持ち、アーキテクチャ内のすべてのコンポーネントに共通の推奨動作に準拠しています。
ソフトウェアコンポーネントは、契約で指定されたインターフェイスと明示的なコンテキスト依存関係のみを持つ構成単位として定義できます。 つまり、ソフトウェアコンポーネントは独立して展開でき、サードパーティによる構成の対象となります。
コンポーネントのビュー
コンポーネントには、オブジェクト指向ビュー、従来のビュー、プロセス関連のビューという3つの異なるビューがあります。
オブジェクト指向ビュー
コンポーネントは、1つ以上の連携するクラスのセットと見なされます。 各問題ドメインクラス（分析）とインフラストラクチャクラス（設計）を説明して、その実装に適用されるすべての属性と操作を識別します。 また、クラスが通信して連携できるようにするインターフェースを定義することも含まれます。
従来のビュー
これは、処理ロジック、処理ロジックの実装に必要な内部データ構造、コンポーネントを呼び出してデータを渡すことができるインターフェースを統合するプログラムの機能要素またはモジュールと見なされます。
プロセス関連ビュー
このビューでは、システムは各コンポーネントを一から作成する代わりに、ライブラリに保持されている既存のコンポーネントから構築しています。 ソフトウェアアーキテクチャが定式化されると、ライブラリからコンポーネントが選択され、アーキテクチャの設定に使用されます。
- ユーザーインターフェイス（UI）コンポーネントには、グリッド、コントロールと呼ばれるボタン、およびユーティリティコンポーネントが含まれ、他のコンポーネントで使用される機能の特定のサブセットを公開します。
- 他の一般的なタイプのコンポーネントは、リソースを集中的に使用するものであり、頻繁にアクセスされないため、ジャストインタイム（JIT）アプローチを使用してアクティブ化する必要があります。
- エンタープライズJavaBean（EJB）、. NETコンポーネント、CORBAコンポーネントなどのエンタープライズビジネスアプリケーションやインターネットWebアプリケーションで配布される多くのコンポーネントは非表示です。
コンポーネントの特性
- 再利用性-コンポーネントは通常、さまざまなアプリケーションのさまざまな状況で再利用されるように設計されています。 ただし、一部のコンポーネントは特定のタスク用に設計されている場合があります。
- 交換可能-コンポーネントは、他の同様のコンポーネントと自由に置き換えることができます。
- コンテキスト固有ではありません-コンポーネントは、さまざまな環境およびコンテキストで動作するように設計されています。
- 拡張可能-コンポーネントを既存のコンポーネントから拡張して、新しい動作を提供できます。
- カプセル化された-コンポーネントは、呼び出し元がその機能を使用できるようにするインターフェイスを表し、内部プロセスまたは内部変数または状態の詳細を公開しません。
- 独立-コンポーネントは、他のコンポーネントに最小限の依存関係を持つように設計されています。
コンポーネントベースの設計の原則
コンポーネントレベルの設計は、何らかの中間表現を使用して表現できます（例： グラフィカル、表形式、またはテキストベース）。ソースコードに変換できます。 データ構造、インターフェイス、およびアルゴリズムの設計は、エラーの発生を回避するために確立されたガイドラインに準拠する必要があります。
- ソフトウェアシステムは、再利用可能な、まとまりのある、カプセル化されたコンポーネントユニットに分解されます。
- 各コンポーネントには、必要なポートと提供されたポートを指定する独自のインターフェイスがあります。各コンポーネントは、詳細な実装を隠します。
- コンポーネントは、コンポーネントの既存の部分に内部コードを作成したり、設計を変更したりせずに拡張する必要があります。
- 抽象化コンポーネントに依存することは、他の具体的なコンポーネントに依存しないため、消耗性が難しくなります。
- コネクタはコンポーネントを接続し、コンポーネント間の相互作用を指定および決定します。 対話タイプは、コンポーネントのインターフェースによって指定されます。
- コンポーネントの対話は、メソッド呼び出し、非同期呼び出し、ブロードキャスト、メッセージ駆動型対話、データストリーム通信、およびその他のプロトコル固有の対話の形式をとることができます。
- サーバークラスの場合、クライアントの主要なカテゴリにサービスを提供するための特別なインターフェイスを作成する必要があります。 クライアントの特定のカテゴリに関連する操作のみをインターフェイスで指定する必要があります。
- コンポーネントは他のコンポーネントに拡張でき、独自の拡張ポイントを提供できます。 これは、プラグインベースのアーキテクチャの概念です。 これにより、プラグインは別のプラグインAPIを提供できます。
コンポーネントレベルの設計ガイドライン
アーキテクチャモデルの一部として指定されたコンポーネントの命名規則を作成し、コンポーネントレベルモデルの一部として洗練または詳細化します。
- 問題ドメインからアーキテクチャコンポーネント名を取得し、それらがアーキテクチャモデルを表示するすべての利害関係者に意味を持つようにします。
- 他のエンティティに関連する依存関係なしに独立して存在できるビジネスプロセスエンティティを抽出します。
- これらの独立したエンティティを新しいコンポーネントとして認識し、発見します。
- 実装固有の意味を反映するインフラストラクチャコンポーネント名を使用します。
- 依存関係を左から右へ、継承を上（基本クラス）から下（派生クラス）へとモデル化します。
- コンポーネントの依存関係は、コンポーネント間の直接の依存関係として表すのではなく、インターフェイスとしてモデル化します。
コンポーネントレベルの設計の実施
分析モデルおよびアーキテクチャモデルで定義された問題ドメインに対応するすべての設計クラスを認識します。
- インフラストラクチャドメインに対応するすべての設計クラスを認識します。
- 再利用可能なコンポーネントとして取得されないすべての設計クラスを説明し、メッセージの詳細を指定します。
- 各コンポーネントの適切なインターフェイスを識別し、属性を詳述し、それらを実装するために必要なデータ型とデータ構造を定義します。
- 擬似コードまたはUMLアクティビティ図を使用して、各操作内の処理フローを詳細に説明します。
- 永続データソース（データベースとファイル）について説明し、それらを管理するために必要なクラスを特定します。
- クラスまたはコンポーネントの動作表現を開発および詳述します。 これは、分析モデル用に作成されたUML状態図を作成し、設計クラスに関連するすべてのユースケースを調べることで実行できます。
- 展開図を作成して、追加の実装の詳細を提供します。
- クラスインスタンスを使用し、特定のハードウェアおよびオペレーティングシステム環境を指定することにより、システム内の主要なパッケージまたはコンポーネントのクラスの場所を示します。
- 最終的な決定は、確立された設計原則とガイドラインを使用して行うことができます。 経験豊富な設計者は、最終設計モデルに落ち着く前に、すべての（またはほとんどの）代替設計ソリューションを検討します。
利点
- 展開の容易さ-新しい互換バージョンが利用可能になると、他のコンポーネントやシステム全体に影響を与えることなく、既存のバージョンを簡単に置き換えることができます。
- コストの削減-サードパーティのコンポーネントを使用すると、開発とメンテナンスのコストを分散できます。
- 開発の容易さ-コンポーネントは、定義された機能を提供する既知のインターフェイスを実装し、システムの他の部分に影響を与えることなく開発を可能にします。
- 再利用可能-再利用可能なコンポーネントの使用は、複数のアプリケーションまたはシステムに開発および保守コストを分散するために使用できることを意味します。
- 技術的な複雑さの修正-コンポーネントは、コンポーネントコンテナとそのサービスを使用して複雑さを修正します。
- 信頼性-各コンポーネントの信頼性が再利用によりシステム全体の信頼性を高めるため、システム全体の信頼性が向上します。
- システムのメンテナンスと進化-残りのシステムに影響を与えることなく、簡単に実装を変更および更新できます。
- 独立-コンポーネントの独立性と柔軟な接続性。 異なるグループによるコンポーネントの独立した開発。 ソフトウェア開発と将来のソフトウェア開発の生産性。
ユーザーインターフェース
ユーザーインターフェイスは、ユーザーの観点から見たソフトウェアシステムの第一印象です。 したがって、どのソフトウェアシステムもユーザーの要件を満たす必要があります。 UIは主に2つの機能を実行します-
- ユーザーの入力を受け入れる
- 出力を表示する
ユーザーインターフェイスは、あらゆるソフトウェアシステムで重要な役割を果たします。 それはおそらくソフトウェアシステムの唯一の目に見える側面です-
- ユーザーは、内部システムを考慮せずに、ソフトウェアシステムの外部ユーザーインターフェイスのアーキテクチャを最初に表示します。
- 優れたユーザーインターフェイスは、ユーザーを間違いなくソフトウェアシステムを使用するように引き付ける必要があります。 ユーザーが誤解を招く情報なしにソフトウェアシステムを簡単に理解できるようにする必要があります。 悪いUIは、ソフトウェアシステムの競合に対する市場の失敗を引き起こす可能性があります。
- UIには構文とセマンティクスがあります。 構文は、テキスト、アイコン、ボタンなどのコンポーネントタイプで構成されます。 また、ユーザビリティはUIのセマンティクスを要約しています。 UIの品質は、ルックアンドフィール（構文）と使いやすさ（セマンティクス）によって特徴付けられます。
- 基本的に2つの主要な種類のユーザーインターフェイスがあります-a）テキストb）グラフィカル。
- 異なるドメインのソフトウェアでは、たとえば、 電卓は、数値を表示するための小さな領域のみを必要としますが、コマンド、Webページにはフォーム、リンク、タブなどが必要です。
グラフィカル・ユーザー・インターフェース
グラフィカルユーザーインターフェイスは、現在利用できる最も一般的なタイプのユーザーインターフェイスです。 それは写真、グラフィックス、アイコンを使用するため、非常にユーザーフレンドリーです-それが「グラフィック」と呼ばれる理由です。
また、 [。underline]＃WIMP＃interface としても使用されます。
- [。underline] W indows -一般的に使用されるアプリケーションが実行される画面上の長方形の領域。
- [。underline] I cons -ソフトウェアアプリケーションまたはハードウェアデバイスを表すために使用される画像または記号。
- [。underline] M enus -ユーザーが必要なものを選択できるオプションのリスト。
- [。underline] P ointers -ユーザーがマウスを動かすと画面内を移動する矢印などの記号。 ユーザーがオブジェクトを選択するのに役立ちます。
ユーザーインターフェイスの設計
まず、ユーザーの主要なタスクと問題の領域を理解するタスク分析から始めます。 プログラマーではなく、ユーザーの用語とユーザーの仕事の観点から設計する必要があります。
- ユーザーインターフェイス分析を実行するには、開業医は4つの要素を研究し、理解する必要があります-
- インターフェイスを介してシステムと対話する*ユーザー*
- エンドユーザーが作業を行うために実行する必要がある*タスク*
- インターフェースの一部として表示される*コンテンツ*
- これらのタスクが実行される*作業環境*
- 適切または優れたUIデザインは、マシンではなくユーザーの機能と制限から機能します。 UIを設計する際、ユーザーの作業と環境の性質に関する知識も重要です。
- 次に、実行するタスクを分割して、それぞれの機能と制限に関する知識に基づいて、ユーザーまたはマシンに割り当てます。 ユーザーインターフェイスの設計は、多くの場合、4つの異なるレベルに分かれています-
- 概念レベル-システムのユーザーの視点とそれらに対して可能なアクションを考慮した基本的なエンティティを説明します。
- セマンティックレベル-システムによって実行される機能、つまり システムの機能要件の説明。ただし、ユーザーが機能を呼び出す方法については説明しません。
- 構文レベル-説明された機能を呼び出すために必要な入力と出力のシーケンスを説明します。
- 語彙レベル-入力および出力がプリミティブハードウェア操作から実際にどのように形成されるかを決定します。
ユーザーインターフェイスの設計は反復プロセスであり、すべての反復で、前の手順で開発された情報を説明し、改良します。 ユーザーインターフェイス設計の一般的な手順
- ユーザーインターフェイスオブジェクトとアクション（操作）を定義します。
- ユーザーインターフェイスの状態を変更するイベント（ユーザーアクション）を定義します。
- ユーザーがインターフェースを介して提供される情報からシステムの状態をどのように解釈するかを示します。
- 実際にエンドユーザーに見えるように、各インターフェイスの状態を説明します。
ユーザーインターフェイス開発プロセス
次の図に示すように、スパイラルプロセスに従います-
インターフェース分析
システムと対話するユーザー、タスク、コンテンツ、および作業環境に集中または焦点を合わせます。 システム機能を実現するために必要な人間およびコンピューター指向のタスクを定義します。
インターフェース設計
インターフェースオブジェクト、アクション、およびそれらの画面表現のセットを定義します。これにより、ユーザーは、システムに定義されたすべてのユーザビリティ目標を満たす方法で、定義されたすべてのタスクを実行できます。
インターフェース構築
使用シナリオの評価を可能にするプロトタイプから始まり、構築を完了するための開発ツールを継続します。
インターフェースの検証
これは、すべてのユーザータスクを正しく実装し、すべてのタスクバリエーションに対応し、すべての一般的なユーザー要件を達成し、インターフェイスが使いやすく、習得しやすい程度のインターフェイスの機能に焦点を当てています。
ユーザーインターフェイスモデル
ユーザーインターフェイスが分析され、設計されている場合、次の4つのモデルが使用されます-
ユーザープロファイルモデル
- ユーザーまたはソフトウェアエンジニアによって作成され、年齢、性別、身体能力、教育、動機、目標、および性格に基づいてシステムのエンドユーザーのプロファイルを確立します。
- ユーザーの構文および意味の知識を考慮し、ユーザーを初心者、知識豊富な断続的、知識豊富な頻繁なユーザーとして分類します。
設計モデル
- ソフトウェアのデータ、アーキテクチャ、インターフェース、および手続き表現を組み込むソフトウェアエンジニアによって作成されます。
- 要件の分析モデルから派生し、システムのユーザーの定義に役立つ要件仕様の情報によって制御されます。
実装モデル
- システムの構文とセマンティクスを説明するすべてのサポート情報（書籍、ビデオ、ヘルプファイル）と組み合わせて、インターフェイスのルックアンドフィールに取り組むソフトウェア実装者によって作成されます。
- ユーザーがソフトウェアに満足し、効果的に使用できるように、設計モデルの翻訳として機能し、ユーザーのメンタルモデルに同意しようとします。
ユーザーのメンタルモデル
- アプリケーションと対話するときにユーザーによって作成されます。 これには、ユーザーが頭の中で運ぶシステムのイメージが含まれています。
- 多くの場合、ユーザーのシステムの認識と説明の正確さは、ユーザーのプロファイルとアプリケーションドメイン内のソフトウェアの全体的な知識に依存します。
ユーザーインターフェイスの設計上の考慮事項
ユーザー中心
ユーザーインターフェースは、製品の開発ライフサイクル全体を通してユーザーを巻き込むユーザー中心の製品でなければなりません。 ユーザーインターフェイスのプロトタイプは、ユーザーが利用できるようにし、ユーザーからのフィードバックを最終製品に組み込む必要があります。
シンプルで直感的
UIはシンプルで直感的なため、指示なしですばやく効果的に使用できます。 GUIはテキストUIよりも優れています。GUIはメニュー、ウィンドウ、ボタンで構成され、マウスを使用するだけで操作できるためです。
ユーザーを管理下に置く
事前定義されたシーケンスをユーザーに強制しないでください。 キャンセルするか、保存して、中断した場所に戻るかを選択します。 システムまたは開発者の用語ではなく、ユーザーが理解できるインターフェイス全体で用語を使用します。
ユーザーにアクションの結果を表示するか、アクションが正常に行われたことを確認することにより、アクションが実行されたことを示す情報を提供します。
透明度
UIは透明である必要があります。これにより、ユーザーはコンピューターを介して直接到達し、作業中のオブジェクトを直接操作しているように感じられます。 ユーザーにシステムオブジェクトではなく作業オブジェクトを提供することにより、インターフェイスを透過的にすることができます。 たとえば、ユーザーはシステムパスワードが少なくとも6文字である必要があることを理解する必要があります。パスワードが必要なストレージのバイト数ではありません。
段階的な開示を使用する
共通の機能と頻繁に使用されるアクションに常に簡単にアクセスできるようにします。 あまり一般的でない機能とアクションを非表示にし、ユーザーがそれらをナビゲートできるようにします。 1つのメインウィンドウにすべての情報を入れようとしないでください。 重要な情報ではない情報にはセカンダリウィンドウを使用します。
一貫性
UIは、製品内および製品間で一貫性を維持し、相互作用の結果を同じに保ち、UIコマンドとメニューは同じ形式を持ち、コマンドの句読点は類似し、パラメーターはすべてのコマンドに同じ方法で渡される必要があります。 UIには、ユーザーを驚かせるような振る舞いがあってはならず、ユーザーが間違いから回復できるメカニズムを含める必要があります。
統合
ソフトウェアシステムは、MSメモ帳やMS-Officeなどの他のアプリケーションとスムーズに統合する必要があります。 クリップボードコマンドを直接使用して、データ交換を実行できます。
コンポーネント指向
UIの設計がソフトウェアシステムの本体の設計と同じ要件を持つように、UI設計はモジュール式で、コンポーネント指向のアーキテクチャを組み込む必要があります。 モジュールは、システムの他の部分に影響を与えることなく、簡単に変更および交換できます。
カスタマイズ可能
ソフトウェアシステム全体のアーキテクチャにはプラグインモジュールが組み込まれているため、多くの異なる人々がソフトウェアを個別に拡張できます。 個人の好みやニーズに合わせて、個々のユーザーがさまざまな利用可能なフォームから選択できるようにします。
ユーザーのメモリ負荷を減らす
ユーザーにコンピューターが何をすべきかを思い出させて繰り返すように強制しないでください。 たとえば、オンラインフォームに入力する場合、ユーザーが入力した後、または顧客レコードを開いた後、顧客名、住所、および電話番号をシステムが記憶する必要があります。
ユーザーインターフェイスは、情報を呼び出す必要がなく、ユーザーが認識できるアイテムをユーザーに提供することにより、長期のメモリ取得をサポートします。
分離
再利用性と保守性を高めるために、その実装を通じてUIをシステムのロジックから分離する必要があります。
建築技術
反復および増分アプローチ
これは、候補ソリューションの生成に役立つ5つの主要なステップで構成される反復的で漸進的なアプローチです。 この候補ソリューションは、これらの手順を繰り返すことでさらに洗練され、最終的にはアプリケーションに最適なアーキテクチャ設計を作成できます。 プロセスの最後に、すべての関係者にアーキテクチャを確認して伝えることができます。
これは可能なアプローチの1つにすぎません。 アーキテクチャを定義、レビュー、および伝達する他の多くの正式なアプローチがあります。
アーキテクチャの目標を特定する
アーキテクチャと設計プロセスを形成するアーキテクチャの目標を特定します。 完璧で明確な目標は、アーキテクチャを強調し、設計の適切な問題を解決し、現在のフェーズが完了し、次のフェーズに移行する準備ができているかどうかを判断するのに役立ちます。
このステップには、次のアクティビティが含まれます-
- 最初にアーキテクチャの目標を特定します。
- アーキテクチャの消費者を特定します。
- 制約を特定します。
アーキテクチャアクティビティの例には、Webアプリケーションの注文処理UIに関するフィードバックを得るためのプロトタイプの構築、顧客の注文追跡アプリケーションの構築、セキュリティレビューを実行するためのアプリケーションの認証および承認アーキテクチャの設計が含まれます。
主なシナリオ
このステップでは、最も重要な設計に重点を置きます。 シナリオとは、ユーザーとシステムとの相互作用に関する広範囲にわたる包括的な説明です。
主要なシナリオは、アプリケーションを成功させるための最も重要なシナリオと見なされるシナリオです。 アーキテクチャに関する決定を下すのに役立ちます。 目標は、ユーザー、ビジネス、およびシステムの目標のバランスをとることです。 たとえば、ユーザー認証は、重要な機能（ユーザーがシステムにログインする方法）と品質属性（セキュリティ）の共通点であるため、重要なシナリオです。
アプリケーションの概要
アプリケーションの概要を作成します。これにより、アーキテクチャがよりタッチしやすくなり、実際の制約と決定に結び付けられます。 それは次の活動で構成されています-
アプリケーションの種類を特定する
モバイルアプリケーション、リッチクライアント、リッチインターネットアプリケーション、サービス、Webアプリケーション、またはこれらのタイプの組み合わせであるかどうかにかかわらず、アプリケーションタイプを識別します。
展開の制約を特定する
適切な展開トポロジを選択し、アプリケーションとターゲットインフラストラクチャ間の競合を解決します。
重要なアーキテクチャ設計スタイルを特定する
クライアント/サーバー、階層化、メッセージバス、ドメイン駆動設計など、重要なアーキテクチャ設計スタイルを特定します。 頻繁に発生する問題の解決策を提供することにより、パーティションを改善し、設計の再利用を促進します。 多くの場合、アプリケーションはスタイルの組み合わせを使用します。
関連する技術を特定する
開発中のアプリケーションの種類、アプリケーション展開トポロジおよびアーキテクチャスタイルの推奨オプションを考慮して、関連するテクノロジを特定します。 テクノロジーの選択は、組織のポリシー、インフラストラクチャの制限、リソーススキルなどによっても指示されます。
主要な問題または主要なホットスポット
アプリケーションの設計中、ホットスポットは、ミスが最も頻繁に発生するゾーンです。 品質属性と横断的な懸念に基づいて重要な問題を特定します。 潜在的な問題には、新しいテクノロジーの出現や重要なビジネス要件が含まれます。
品質属性は、実行時の動作、システム設計、ユーザーエクスペリエンスに影響を与える、アーキテクチャの全体的な機能です。 横断的な関心事は、すべてのレイヤー、コンポーネント、および層に適用される可能性のあるデザインの機能です。
これらは、影響の大きい設計ミスが最も頻繁に行われる領域でもあります。 横断的関心事の例は、認証と承認、通信、構成管理、例外管理と検証などです。
候補ソリューション
主要なホットスポットを定義した後、初期ベースラインアーキテクチャまたは最初の高レベルの設計を構築し、詳細の入力を開始して候補アーキテクチャを生成します。
候補アーキテクチャには、アプリケーションの種類、展開アーキテクチャ、アーキテクチャスタイル、技術の選択、品質属性、横断的関心事が含まれます。 候補のアーキテクチャが改善された場合、新しい候補のアーキテクチャを作成およびテストできるベースラインになる可能性があります。
サイクルを繰り返して設計を改善する前に、すでに定義されている主要なシナリオと要件に対してソリューション候補の設計を検証します。
設計の特定の領域を発見したり、新しい概念を検証したりするために、アーキテクチャスパイクを使用する場合があります。 アーキテクチャスパイクは設計プロトタイプであり、特定の設計パスの実現可能性を判断し、リスクを軽減し、さまざまなアプローチの実行可能性を迅速に判断します。 主要なシナリオとホットスポットに対してアーキテクチャのスパイクをテストします。
アーキテクチャレビュー
アーキテクチャのレビューは、ミスのコストを削減し、できるだけ早くアーキテクチャの問題を見つけて修正するための最も重要なタスクです。 これは、プロジェクトのコストとプロジェクトの失敗の可能性を削減する、十分に確立された費用対効果の高い方法です。
- 主要なプロジェクトのマイルストーンで、およびその他の重要なアーキテクチャの変更に対応して、アーキテクチャを頻繁に確認します。
- アーキテクチャレビューの主な目的は、アーキテクチャを正しく検証するベースラインおよび候補アーキテクチャの実行可能性を判断することです。
- 機能要件と品質属性を提案された技術ソリューションとリンクします。 また、問題を特定し、改善すべき領域を認識するのにも役立ちます
シナリオベースの評価は、ビジネスの観点から最も重要なシナリオに焦点を当て、アーキテクチャに最も大きな影響を与えるアーキテクチャ設計をレビューするための主要な方法です。以下は一般的なレビュー方法です-
ソフトウェアアーキテクチャ分析方法（SAAM）
もともとは変更可能性を評価するために設計されていましたが、後に品質属性に関してアーキテクチャをレビューするために拡張されました。
アーキテクチャトレードオフ分析方法（ATAM）
これは、SAAMの洗練され改善されたバージョンであり、品質属性要件に関するアーキテクチャ上の決定と、特定の品質目標をどの程度満たすかをレビューします。
アクティブデザインレビュー（ADR）
一般的なレビューを実行するのではなく、一度にアーキテクチャの一連の問題または個々のセクションに重点を置く、不完全または進行中のアーキテクチャに最適です。
中間デザインのアクティブなレビュー（ARID）
進行中のアーキテクチャをレビューするADRの側面と一連の問題に焦点を合わせ、シナリオベースのレビューのATAMおよびSAAMアプローチを品質属性に焦点を合わせて組み合わせます。
費用便益分析方法（CBAM）
アーキテクチャの決定のコスト、利点、およびスケジュールへの影響を分析することに焦点を当てています。
アーキテクチャレベル変更可能性分析（ALMA）
ビジネス情報システム（BIS）のアーキテクチャの変更可能性を推定します。
ファミリーアーキテクチャ評価方法（FAAM）
相互運用性と拡張性に関する情報システムファミリのアーキテクチャを推定します。
アーキテクチャ設計の伝達
アーキテクチャ設計を完了した後、開発チーム、システム管理者、オペレーター、事業主、およびその他の利害関係者を含む他の利害関係者に設計を伝える必要があります。
他の人にアーキテクチャを説明するためのいくつかの次の有名な方法があります：-
4 + 1モデル
このアプローチでは、アーキテクチャ全体の5つのビューを使用します。 その中で、4つのビュー（論理ビュー、*プロセスビュー、*物理ビュー、*および*開発ビュー）は、さまざまなアプローチのアーキテクチャを説明しています。 5番目のビューは、ソフトウェアのシナリオとユースケースを示しています。 利害関係者は、特に関心のあるアーキテクチャの機能を見ることができます。
アーキテクチャ記述言語（ADL）
このアプローチは、システム実装の前にソフトウェアアーキテクチャを記述するために使用されます。 動作、プロトコル、およびコネクタの次の懸念に対処します。
ADLの主な利点は、設計の使用を正式に開始する前に、完全性、一貫性、あいまいさ、およびパフォーマンスについてアーキテクチャを分析できることです。
アジャイルモデリング
このアプローチは、「コンテンツは表現よりも重要」という概念に従います。これにより、作成されるモデルがシンプルでわかりやすく、十分に正確で、詳細で、一貫性が保たれます。
アジャイルモデルドキュメントは、特定の顧客を対象とし、その顧客の作業努力を実現します。 文書の単純さにより、成果物のモデリングに利害関係者が積極的に参加することが保証されます。
IEEE 1471
IEEE 1471は、ANSI/IEEE 1471-2000、「ソフトウェア集中システムのアーキテクチャ記述の推奨プラクティス」として正式に知られている標準の短縮名です。IEEE1471は、アーキテクチャ記述の内容を強化し、特にコンテキストに特定の意味を与えます、ビュー、およびビューポイント。
統一モデリング言語（UML）
このアプローチは、システムモデルの3つのビューを表します。 機能要件ビュー（ユースケースを含む、ユーザーの観点からのシステムの機能要件）; 静的構造ビュー（オブジェクト、属性、関係、およびクラス図を含む操作）; 動的な動作ビュー（オブジェクト間のコラボレーションと、シーケンス、アクティビティ、状態図を含むオブジェクトの内部状態の変更）。
