ソフトウェアアーキテクチャビューとは
では、ソフトウェアアーキテクチャビューとは何でしょうか。Philippe Kruchtenは彼の著書「Introduction to the Rational Unified Process」に次のように書いています。
アーキテクチャビューは、特定の視点または特定のポイントから見たシステムの簡略化された説明であり、システムの特定の側面をカバーし、この側面に関連しないエンティティは省略されています。
つまり、人間の脳の「一度に克服する」能力を超えて、アーキテクチャーでカバーするには内容と決定が多すぎるため、「分割統治」手法を使用して、異なる視点から設計します。アーカイブは便利です。
ほとんどの書籍で、マルチビュー方式がソフトウェアアーキテクチャのアーカイブ方式であることを強調していますが、そうではありません。マルチビュー方式は、建築のためのアーカイブ技術であるだけでなく、建築設計において私たちを導く考え方でもあります。
Philippe Kruchtenによって提案された4 + 1ビュー方法
1995年、Philippe Kruchtenは、「IEEEソフトウェア」の「The 4 + 1 View Model of Architecture」というタイトルの論文を発表しました。これは、業界で大きな懸念を引き起こし、RUPによって最終的に採用されました。図2に示すように。
図2 Philippe Kruchtenによって提案された4 + 1ビュー方法
メソッドのさまざまなアーキテクチャビューは、さまざまなアーキテクチャ設計の決定を伝達し、さまざまな目標と用途をサポートします。
論理ビュー：オブジェクト指向の設計手法が採用されている場合、論理ビューはオブジェクトモデルです。
開発ビュー：開発環境でのソフトウェアの静的編成について説明します。
処理ビュー：システムの同時実行性と同期化の側面の設計について説明します。
物理的ビュー：ソフトウェアがハードウェアにどのようにマッピングされるかを説明し、システムの設計を配布の観点から反映します。
4 + 1ビューの方法を使用する：さまざまなニーズに合わせてアーキテクチャを設計する
前述のように、ユーザーを満足させるソフトウェアを開発することは容易ではなく、ソフトウェアアーキテクトはさまざまなニーズのさまざまな矛盾を十分に理解し、要件を比較検討し、さまざまなニーズを1つずつ分類する必要があります。満足です。
図3に示すように、Philippe Kruchtenによって提案された4 + 1ビュー方式は、ソフトウェアアーキテクトが「要件を1つずつ克服する」ための優れた基盤を提供します。
図3 4 + 1ビューの方法を使用して、さまざまなニーズに合わせてアーキテクチャを設計する
論理ビュー。論理ビューは、ユーザーに表示される機能だけでなく、ユーザー機能を実装するために提供する必要がある「補助機能モジュール」を含む機能に焦点を当てています。これらは、論理レイヤー、機能モジュールなどの場合があります。
開発ビュー。開発ビューでは、作成するソースプログラムだけでなく、直接使用できるサードパーティのSDKや既製のフレームワークとクラスライブラリ、開発したシステムが実行されるシステムソフトウェアやミドルウェアなど、パッケージに焦点を当てています。開発ビューと論理ビューの間には、特定のマッピング関係がある場合があります。たとえば、論理レイヤーは通常、複数のパッケージにマッピングされます。
ビューを処理します。処理ビューは、プロセス、スレッド、オブジェクトなどの実行時の概念、および関連する同時実行性、同期、通信の問題に焦点を当てています。処理ビューと開発ビューの関係：開発ビューは通常、コンパイル時のパッケージの静的依存関係に焦点を当てており、これらのプログラムは実行後にオブジェクト、スレッド、およびプロセスとして表示されます。処理ビューは、これらのランタイムユニットの相互作用により深く関係しています。問題です。
物理的なビュー。物理ビューは、「ターゲットプログラムとそれに依存するランタイムおよびシステムソフトウェア」が最終的に物理マシンにインストールまたはデプロイされる方法、およびソフトウェアシステムの信頼性とスケーラビリティの要件に合わせてマシンとネットワークをデプロイする方法に焦点を当てています。物理ビューと処理ビューの関係：処理ビューはターゲットプログラムの動的実行に特に注意を払いますが、物理ビューはターゲットプログラムの静的な位置を重視します。物理ビューは、ソフトウェアシステムとITシステム全体の間の相互作用を包括的に考慮するアーキテクチャビューです。
機器デバッグシステムのケースの概要
この記事の次の部分では、特定のタイプの機器デバッグシステムというケースについて検討します。
装置デバッガは、このシステムを利用することで、装置の状態（装置の状態情報を専用のデータ収集装置でリアルタイムに収集する）を確認し、デバッグコマンドを送信することができます。システムのユースケース図を図4に示します。
図4機器デバッグシステムのユースケース図
開発者とクライアントの間の緊密な協力の後、最終的な要件は表2にまとめられます。
表2機器デバッグシステムの要件
以下は、RUPが推奨する4 + 1ビュー方式を使用して、さまざまなビューからアーキテクチャを設計し、さまざまなニーズに1つずつ対応します。
論理ビュー：機能要件を満たすアーキテクチャの設計
まず、予備設計の機能要件に従って、細分性のある責任の分割。図5に示すように。
アプリケーション層は、デバイスステータスの表示を担当し、ユーザーがデバッグコマンドを送信するためのシミュレーションコンソールを提供します。
アプリケーション層は通信層と埋め込み層を使用して対話しますが、アプリケーション層は通信の詳細を知りません。
通信層は、RS232プロトコルの上に一連の専用「アプリケーションプロトコル」を実装する責任があります。
アプリケーション層がデバッグ命令を含むプロトコルパケットを送信すると、通信層はRS232プロトコルに従ってそれを埋め込み層に渡します。
埋め込み層が元のデータを送信すると、通信層はそれをアプリケーションプロトコルパケットとして解釈し、アプリケーション層に送信します。
埋め込み層は、デバッグ装置の特定の制御を担当し、データコレクターからデバイスステータスデータを頻繁に読み取ります。
デバイス制御命令の物理仕様は埋め込み層の内部にカプセル化されており、データコレクターの読み取りの詳細も埋め込み層の内部にカプセル化されています。
図5デバイスデバッグシステムアーキテクチャの論理図
開発ビュー：開発中に品質属性を満たすアーキテクチャを設計する
ソフトウェアアーキテクチャの開発ビューは、開発者に実用的なガイダンスを提供する必要があります。全体的な状況に影響を与える設計上の決定は、アーキテクチャの設計によって完了する必要があります。これらの決定が「漏れる」場合、それらは大規模な並列開発の段階でのみ発見され、多数の「プログラマが一時的な決定をする」可能性があります。それは必然的に衰退し、プロジェクトを失敗させることさえあります。
その中で、どの既製のフレームワーク、どのサードパーティのSDK、さらにはどのミドルウェアプラットフォームを検討する必要があるかは、ソフトウェアアーキテクチャの開発ビューによって決定する必要があります。図6は、デバイスデバッグシステムのソフトウェアアーキテクチャ開発ビュー（の一部）を示しています。アプリケーション層はMFCに基づいて設計および実装され、通信層はシリアル通信にサードパーティのSDKを使用します。
図6デバイスデバッグシステムアーキテクチャの開発ビュー
拘束力のある要件について話します。制約は、各アーキテクチャビューが焦点を当てて観察する必要があるいくつかの設計制約である必要があります。たとえば、「一部の開発者は組み込み開発の経験がない」という制約を考慮すると、アーキテクトはシステムのターゲットプログラムのコンパイル方法を明確に示す必要があります。図7は、ターゲットプログラムpcをシステム全体のデスクトップ部分に示しています。 moduel.exeと埋め込みモジュールrom-module.hexのコンパイル方法。このグローバルな説明は間違いなく、経験の浅い開発者に本当の意味を提供します。これは、システムのソフトウェアアーキテクチャのより包括的な理解に役立ちます。
図7デバイスデバッグシステムアーキテクチャの開発ビュー
処理ビュー：ランタイム品質属性を満たすアーキテクチャを設計する
パフォーマンスは、ソフトウェアシステムの動作中に示される品質のレベルであり、通常、システムの応答時間とシステムのスループットによって測定されます。高いパフォーマンス要件を達成するために、ソフトウェアアーキテクトはソフトウェアのランタイム条件を分析および設計する必要があります。これをソフトウェアアーキテクチャの処理ビューと呼びます。処理ビューは、プロセス、スレッド、オブジェクトなどの実行時の概念、および関連する同時実行性、同期、通信の問題に焦点を当てています。図8に、デバイスデバッグシステムアーキテクチャの処理ビューを示します。
建築家が高性能要件を満たすためにマルチスレッド設計を採用したことがわかります。
アプリケーション層のスレッドはメインプログラムの実行を表し、MFCのメインウィンドウスレッドを直接利用します。ユーザーとの対話であれ、シリアルポートデータの到着であれ、非同期イベントを使用して処理されるため、時間のかかる「ビジー待機」がなくなり、システムの応答時間が短縮されます。
通信層には、「アップおよびダウン」データを制御する独立したスレッドがあり、データ受信とデータ処理を比較的独立させるためにデータバッファーが設定されているため、一時的なビジー処理によってデータ受信が停止することがなく、システムが増加します。スループット。
組み込み層の設計では、対応する処理ロジックがそれぞれクロック割り込みとRS232ポート割り込みによって刺激され、データのポーリングと送受信の目的を達成します。
図8デバイスデバッグシステムアーキテクチャの処理ビュー
物理的ビュー：展開に関連するアーキテクチャ上の決定
ソフトウェアは、最終的には実行するハードウェアに常駐、インストール、または展開する必要があり、ソフトウェアアーキテクチャの物理ビューは、「ターゲットプログラムとその依存ランタイムおよびシステムソフトウェア」が物理マシンに最終的にインストールまたは展開される方法、およびマシンとネットワークを展開する方法に焦点を当てていますソフトウェアシステムの信頼性とスケーラビリティの要件に協力します。図９に示す物理的アーキテクチャ図は、デバイスデバッグシステムソフトウェアとハードウェアとの間のマッピング関係を表現している。組み込み部品はデバッグマシンにあり（デバッグマシンは専用のシングルボードコンピューターです）、PCはデスクトップ実行可能プログラムの一般的な形式であることがわかります。
図9デバイスデバッグシステムアーキテクチャの物理図
図10に示すように、特定の状況のニーズに応じて、特定のターゲットモジュールとその通信構造を物理アーキテクチャビューでより明確に表現することもできます。
図10デバイスデバッグシステムアーキテクチャの物理図
概要と説明
いわゆるDaosheng。ソフトウェア要件の分類の複雑さを深く理解し、機能要件、制約、ランタイム品質属性、開発品質属性などのさまざまなタイプの要件を明確に区別することは、「本」です。これは、アーキテクチャ設計に対するさまざまな要件の影響が大きく異なるためです。この記事では、特定のケースの分析を通じて、RUPの4 + 1表示方法を使用して、さまざまなニーズに合わせてアーキテクチャを設計し、重要なニーズを1つずつ確実に満たす方法を示します。
この記事では方法の説明に焦点を当てているため、アーキテクチャ設計における多くの特定の問題の説明は省略されていると同時に、この記事で提供されているアーキテクチャ設計スキームを説明するモデルも簡略化されています。読者の注意。
転載：http://www.uml.org.cn/zjjs/201412262.asp
