Software-architecture-design-architecture-models
アーキテクチャモデル
ソフトウェアアーキテクチャには、アーキテクチャスタイルと品質属性を備えた、分解と構成を使用したソフトウェアシステム抽象化の高レベルの構造が含まれます。 ソフトウェアアーキテクチャの設計は、システムの主要な機能とパフォーマンスの要件に準拠するとともに、信頼性、スケーラビリティ、移植性、可用性などの非機能要件を満たす必要があります。
ソフトウェアアーキテクチャは、コンポーネントのグループ、接続、コンポーネント間の相互作用、およびすべてのコンポーネントの展開構成を記述する必要があります。
ソフトウェアアーキテクチャは、多くの方法で定義することができます-
- * 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から最終的なシステム仕様を導出できるようにする必要があります。
- 一般的なアーキテクチャスタイルのほとんどを表現する機能が必要です。
- 分析機能をサポートするか、プロトタイプ生成の迅速な生成を提供する必要があります。
