Software-architecture-design-introduction
ソフトウェアアーキテクチャと設計の概要
システムのアーキテクチャは、その主要なコンポーネント、それらの関係（構造）、およびそれらが互いにどのように相互作用するかを記述します。 ソフトウェアのアーキテクチャと設計には、ビジネス戦略、品質属性、人間のダイナミクス、設計、IT環境などのいくつかの要因が含まれます。
ソフトウェアアーキテクチャとソフトウェアデザインは、ソフトウェアアーキテクチャとソフトウェアデザインという2つのフェーズに分けられます。 Architecture では、機能以外の決定がキャストされ、機能要件によって分離されます。 設計では、機能要件が達成されます。
ソフトウェアアーキテクチャ
アーキテクチャは、*システムの青写真*として機能します。 システムの複雑さを管理し、コンポーネント間の通信および調整メカニズムを確立するための抽象化を提供します。
- パフォーマンスやセキュリティなどの一般的な品質属性を最適化しながら、すべての技術的および運用上の要件を満たす*構造化ソリューション*を定義します。
- さらに、ソフトウェア開発に関連する組織に関する一連の重要な決定が含まれ、これらの決定はそれぞれ最終製品の品質、保守性、パフォーマンス、および全体的な成功に大きな影響を与える可能性があります。 これらの決定は-
- システムを構成する構造要素とそのインターフェイスの選択。
- これらの要素間のコラボレーションで指定された動作。
- これらの構造要素と動作要素を大きなサブシステムに構成します。
- 建築上の決定は、ビジネス目標に沿って行われます。
- 建築様式が組織を導きます。
ソフトウェア設計
ソフトウェア設計は、システムの要素、それらがどのように適合するかを説明し、システムの要件を満たすために連携する*設計計画*を提供します。 設計計画を持つ目的は次のとおりです-
- システム要件を交渉し、顧客、マーケティング、および管理担当者と期待を設定するため。
- 開発プロセス中に青写真として機能します。
- 詳細な設計、コーディング、統合、テストなどの実装タスクをガイドします。
詳細な設計、コーディング、統合、テストの前、およびドメイン分析、要件分析、リスク分析の後に行われます。
建築の目標
アーキテクチャの主な目標は、アプリケーションの構造に影響する要件を特定することです。 適切に設計されたアーキテクチャにより、技術ソリューションの構築に関連するビジネスリスクが軽減され、ビジネス要件と技術要件の間に橋が架けられます。
他の目標のいくつかは次のとおりです-
- システムの構造を公開しますが、実装の詳細は隠します。
- すべてのユースケースとシナリオを実現します。
- さまざまな利害関係者の要件に対処するようにしてください。
- 機能要件と品質要件の両方を処理します。
- 所有権の目標を減らし、組織の市場での地位を向上させます。
- システムが提供する品質と機能を改善します。
- 組織またはシステムのいずれかに対する外部の信頼を向上させます。
制限事項
ソフトウェアアーキテクチャは、依然としてソフトウェアエンジニアリングの新しい分野です。 次の制限があります-
- アーキテクチャを表すためのツールと標準化された方法の欠如。
- アーキテクチャが要件を満たす実装になるかどうかを予測するための分析方法の欠如。
- ソフトウェア開発におけるアーキテクチャ設計の重要性に対する認識の欠如。
- ソフトウェアアーキテクトの役割を理解しておらず、関係者間のコミュニケーションが不十分です。
- 設計プロセス、設計経験、および設計の評価に関する理解不足。
ソフトウェアアーキテクトの役割
ソフトウェアアーキテクトは、技術チームがアプリケーション全体を作成および設計できるソリューションを提供します。 ソフトウェアアーキテクトは、次の分野の専門知識を持っている必要があります-
設計の専門知識
- オブジェクト指向設計、イベント駆動設計など、さまざまな方法とアプローチを含むソフトウェア設計の専門家
- 開発チームを率いて、設計の整合性のために開発作業を調整します。
- 設計提案をレビューし、それらの間でトレードオフできる必要があります。
ドメインの専門知識
- 開発中のシステムの専門家であり、ソフトウェアの進化を計画しています。
- 要件調査プロセスを支援し、完全性と一貫性を保証します。
- 開発中のシステムのドメインモデルの定義を調整します。
技術の専門知識
- システムの実装を支援する利用可能な技術の専門家。
- プログラミング言語、フレームワーク、プラットフォーム、データベースなどの選択を調整します。
方法論の専門知識
- SDLC（ソフトウェア開発ライフサイクル）中に採用される可能性のあるソフトウェア開発方法論の専門家。
- チーム全体を支援する適切な開発アプローチを選択してください。
ソフトウェアアーキテクトの隠れた役割
- チームメンバー間の技術作業を促進し、チームの信頼関係を強化します。
- 知識を共有し、豊富な経験を持つ情報スペシャリスト。
- チームメンバーの注意をそらし、プロジェクトの価値を低下させる外力からチームメンバーを保護します。
アーキテクトの成果物
- 機能的目標の明確で完全で一貫した達成可能なセット
- 少なくとも2つのレイヤーの分解があるシステムの機能説明
- システムのコンセプト
- 少なくとも2層の分解を伴うシステム形式の設計
- タイミング、オペレーター属性、および実装と運用計画の概念
- 機能的な分解が行われ、インターフェースの形式が制御されることを保証する文書またはプロセス
品質属性
品質は、優秀さの尺度、または欠陥や欠陥がない状態です。 品質属性は、システムの機能とは別のシステムプロパティです。
品質属性を実装すると、良いシステムと悪いシステムを簡単に区別できます。 属性は、実行時の動作、システム設計、およびユーザーエクスペリエンスに影響する全体的な要因です。
彼らはとして分類することができます-
静的品質属性
アーキテクチャ、設計、およびソースコードに直接関連するシステムおよび組織の構造を反映します。 それらはエンドユーザーには見えませんが、開発とメンテナンスのコストに影響を与えます、例えば：モジュール性、テスト容易性、保守容易性など
動的品質属性
実行中のシステムの動作を反映します。 これらは、システムのアーキテクチャ、設計、ソースコード、構成、展開パラメーター、環境、およびプラットフォームに直接関連しています。
これらはエンドユーザーに表示され、実行時に存在します。 スループット、堅牢性、スケーラビリティなど
品質シナリオ
品質シナリオは、障害が障害にならないようにする方法を指定します。 それらは、属性仕様に基づいて6つの部分に分けることができます-
- ソース-人、ハードウェア、ソフトウェア、または刺激を生成する物理インフラストラクチャなどの内部または外部エンティティ。
- 刺激-システムに到着したときに考慮する必要がある条件。
- 環境-刺激は特定の条件内で発生します。
- アーティファクト-システム全体またはプロセッサ、通信チャネル、永続ストレージ、プロセスなどの一部。
- 応答-障害の検出、障害からの回復、イベントソースの無効化など、刺激の到着後に行われるアクティビティ。
- 応答測定-要件をテストできるように、発生した応答を測定する必要があります。
共通の品質属性
次の表に、ソフトウェアアーキテクチャに必要な共通の品質属性を示します-
カテゴリー
品質属性
説明
設計品質
概念の完全性
設計全体の一貫性と一貫性を定義します。 これには、コンポーネントまたはモジュールの設計方法が含まれます。
保守性
ある程度簡単にシステムを変更できる能力。
再利用性
他のアプリケーションでの使用に適したコンポーネントおよびサブシステムの機能を定義します。
実行時の品質
相互運用性
システムまたは異なるシステムが、外部の当事者によって作成および実行される他の外部システムと情報をやり取りして交換することにより、正常に動作する能力
管理性
システム管理者がアプリケーションを簡単に管理できるかどうかを定義します。
信頼性
システムが長期にわたって稼働し続ける能力。
スケーラビリティ
システムのパフォーマンスに影響を与えずに負荷の増加を処理するシステムの能力、または容易に拡張する能力。
セキュリティ
設計された用途以外の悪意のあるまたは偶発的なアクションを防止するシステムの機能。
パフォーマンス
特定の時間間隔内にアクションを実行するシステムの応答性の指標。
可用性
システムが機能して動作している時間の割合を定義します。 事前に定義された期間におけるシステムの合計ダウンタイムの割合として測定できます。
システム品質
サポート性
システムが正常に機能しない場合に問題を特定して解決するのに役立つ情報を提供する機能。
テスト容易性
システムとそのコンポーネントのテスト基準を作成するのがいかに簡単かを示す尺度。
ユーザー品質
使いやすさ
直感的であることにより、アプリケーションがユーザーと消費者の要件をどれだけ満たすかを定義します。
建築品質
正しさ
システムのすべての要件を満たす責任。
非ランタイム品質
移植性
異なるコンピューティング環境で実行するシステムの能力。
統合性
システムの個別に開発されたコンポーネントを一緒に正しく機能させる機能。
修正可能性
各ソフトウェアシステムがソフトウェアの変更に対応できる容易さ。
ビジネス品質の属性
費用とスケジュール
市場投入までの時間、プロジェクトの予想寿命、およびレガシーの利用に関するシステムのコスト。
市場性
市場競争に関するシステムの使用。
