ソフトウェアアーキテクチャと設計の概要

システムのアーキテクチャは、その主要なコンポーネント、それらの関係（構造）、およびそれらが互いにどのように相互作用するかを記述します。ソフトウェアのアーキテクチャと設計には、ビジネス戦略、品質属性、ヒューマンダイナミクス、設計、IT環境などのいくつかの要因が含まれます。

ソフトウェアアーキテクチャと設計は、ソフトウェアアーキテクチャとソフトウェア設計の2つの異なるフェーズに分けることができます。にArchitecture、非機能的決定は、機能要件によってキャストおよび分離されます。設計では、機能要件が満たされます。

ソフトウェアアーキテクチャ

アーキテクチャは、 blueprint for a system。これは、システムの複雑さを管理し、コンポーネント間の通信および調整メカニズムを確立するための抽象化を提供します。

それは定義します structured solution パフォーマンスやセキュリティなどの一般的な品質属性を最適化しながら、すべての技術的および運用上の要件を満たすため。
さらに、ソフトウェア開発に関連する組織に関する一連の重要な決定が含まれ、これらの各決定は、品質、保守性、パフォーマンス、および最終製品の全体的な成功に大きな影響を与える可能性があります。これらの決定は、以下で構成されます。
- システムを構成する構造要素とそのインターフェースの選択。
- これらの要素間のコラボレーションで指定された動作。
- これらの構造的および行動的要素の大きなサブシステムへの構成。
- アーキテクチャ上の決定は、ビジネス目標と一致します。
- 建築様式が組織を導きます。

ソフトウェア設計

ソフトウェア設計は、 design planこれは、システムの要素、それらがどのように適合し、システムの要件を満たすために連携するかを説明します。設計計画を立てる目的は次のとおりです。

システム要件を交渉し、顧客、マーケティング、および管理担当者と期待を設定します。
開発プロセス中に青写真として機能します。
詳細な設計、コーディング、統合、テストなどの実装タスクをガイドします。

これは、詳細な設計、コーディング、統合、およびテストの前と、ドメイン分析、要件分析、およびリスク分析の後に行われます。

アーキテクチャの目標

アーキテクチャの主な目標は、アプリケーションの構造に影響を与える要件を特定することです。適切に配置されたアーキテクチャは、技術ソリューションの構築に関連するビジネスリスクを軽減し、ビジネス要件と技術要件の間の架け橋を構築します。

その他の目標のいくつかは次のとおりです-

システムの構造を公開しますが、実装の詳細は非表示にします。
すべてのユースケースとシナリオを実現します。
さまざまな利害関係者の要件に対処するようにしてください。
機能要件と品質要件の両方を処理します。
所有権の目標を減らし、組織の市場での地位を向上させます。
システムが提供する品質と機能を向上させます。
組織またはシステムのいずれかに対する外部の信頼を向上させます。

制限事項

ソフトウェアアーキテクチャは、ソフトウェアエンジニアリング内の新しい分野です。以下の制限があります-

アーキテクチャを表現するためのツールと標準化された方法の欠如。
アーキテクチャが要件を満たす実装になるかどうかを予測するための分析方法の欠如。
ソフトウェア開発に対するアーキテクチャ設計の重要性に対する認識の欠如。
ソフトウェアアーキテクトの役割についての理解の欠如と利害関係者間のコミュニケーション不足。
設計プロセス、設計経験、および設計の評価に関する理解の欠如。

ソフトウェアアーキテクトの役割

ソフトウェアアーキテクトは、技術チームがアプリケーション全体を作成および設計できるソリューションを提供します。ソフトウェアアーキテクトは、次の分野の専門知識を持っている必要があります-

設計の専門知識

オブジェクト指向設計、イベント駆動型設計などのさまざまな方法やアプローチを含む、ソフトウェア設計の専門家。
開発チームを主導し、設計の整合性のために開発作業を調整します。
設計提案とそれらの間のトレードオフを確認できる必要があります。

ドメインの専門知識

開発中のシステムの専門家であり、ソフトウェアの進化を計画しています。
要件調査プロセスを支援し、完全性と一貫性を確保します。
開発中のシステムのドメインモデルの定義を調整します。

技術の専門知識

システムの実装に役立つ利用可能なテクノロジーの専門家。
プログラミング言語、フレームワーク、プラットフォーム、データベースなどの選択を調整します。

方法論の専門知識

SDLC（ソフトウェア開発ライフサイクル）中に採用される可能性のあるソフトウェア開発方法論の専門家。
チーム全体を支援する開発のための適切なアプローチを選択します。

ソフトウェアアーキテクトの隠された役割

チームメンバー間の技術的な作業を促進し、チーム内の信頼関係を強化します。
知識を共有し、豊富な経験を持つ情報スペシャリスト。
チームメンバーの気を散らし、プロジェクトの価値を低下させる外力からチームメンバーを保護します。

アーキテクトの成果物

明確で、完全で、一貫性があり、達成可能な一連の機能目標
少なくとも2層の分解を伴うシステムの機能説明
システムのコンセプト
少なくとも2層の分解を伴うシステム形式の設計
タイミング、オペレーター属性、および実装と運用計画の概念
機能分解が行われ、インターフェースの形式が制御されることを保証するドキュメントまたはプロセス

品質属性

品質とは、卓越性、または欠陥や欠陥がない状態の尺度です。品質属性は、システムの機能とは別のシステムプロパティです。

品質属性を実装すると、良いシステムと悪いシステムを簡単に区別できます。属性は、実行時の動作、システム設計、およびユーザーエクスペリエンスに影響を与える全体的な要因です。

それらは次のように分類できます-

静的品質属性

アーキテクチャ、設計、およびソースコードに直接関連するシステムと組織の構造を反映します。それらはエンドユーザーには見えませんが、開発と保守のコストに影響します。たとえば、モジュール性、テスト容易性、保守性などです。

動的品質属性

実行中のシステムの動作を反映します。これらは、システムのアーキテクチャ、設計、ソースコード、構成、展開パラメータ、環境、およびプラットフォームに直接関係しています。

それらはエンドユーザーに表示され、スループット、堅牢性、スケーラビリティなどの実行時に存在します。

品質シナリオ

品質シナリオは、障害が障害になるのを防ぐ方法を指定します。それらは、属性仕様に基づいて6つの部分に分けることができます-

Source −刺激を生成する人、ハードウェア、ソフトウェア、または物理インフラストラクチャなどの内部または外部エンティティ。
Stimulus −システムに到着したときに考慮する必要のある状態。
Environment −刺激は特定の条件下で発生します。
Artifact −システム全体、またはプロセッサ、通信チャネル、永続ストレージ、プロセスなどの一部。
Response −障害の検出、障害からの回復、イベントソースの無効化など、刺激の到着後に行われるアクティビティ。
Response measure −要件をテストできるように、発生した応答を測定する必要があります。

共通の品質属性

次の表に、ソフトウェアアーキテクチャに必要な一般的な品質属性を示します。

カテゴリー	品質属性	説明
設計品質	概念の完全性	全体的な設計の一貫性と一貫性を定義します。これには、コンポーネントまたはモジュールの設計方法が含まれます。
	保守性	システムがある程度簡単に変更できる能力。
	再利用性	他のアプリケーションでの使用に適したコンポーネントとサブシステムの機能を定義します。
実行時の品質	相互運用性	外部の関係者によって作成および実行されている他の外部システムと情報を通信および交換することにより、1つまたは複数のシステムが正常に動作する能力。
	管理性	システム管理者がアプリケーションを管理するのがどれだけ簡単かを定義します。
	信頼性	長期間にわたって運用を継続するシステムの機能。
	スケーラビリティ	システムのパフォーマンスに影響を与えることなく負荷の増加を処理するシステムの能力、または容易に拡張できる能力。
	セキュリティ	設計された使用法以外の悪意のあるまたは偶発的なアクションを防止するシステムの機能。
	パフォーマンス	指定された時間間隔内に任意のアクションを実行するためのシステムの応答性の表示。
	可用性	システムが機能し、機能している時間の割合を定義します。これは、事前定義された期間におけるシステム全体のダウンタイムのパーセンテージとして測定できます。
システム品質	サポート性	正しく機能しない場合に問題を特定して解決するのに役立つ情報を提供するシステムの機能。
システム品質	テスト容易性	システムとそのコンポーネントのテスト基準を作成するのがどれほど簡単かを測定します。
ユーザーの資質	使いやすさ	直感的に理解することで、アプリケーションがユーザーとコンシューマーの要件をどの程度満たしているかを定義します。
アーキテクチャの品質	正しさ	システムのすべての要件を満たすための説明責任。
実行時以外の品質	移植性	さまざまなコンピューティング環境で実行するシステムの機能。
	完全性	システムの個別に開発されたコンポーネントを正しく連携させる機能。
	変更可能性	各ソフトウェアシステムがソフトウェアの変更に対応しやすいこと。
ビジネス品質属性	費用とスケジュール	市場投入までの時間、予想されるプロジェクトの存続期間、およびレガシーの利用に関するシステムのコスト。
ビジネス品質属性	市場性	市場競争に関するシステムの使用。