ソフトウェア設計

ソフトウェア設計とは、ソフトウェアシステムを実装または変更する前に、そのシステムがどのように機能するかを概念化するプロセスです。 ^[1] ソフトウェア設計は、設計プロセスの直接的な結果、つまり設計ドキュメントとドキュメント化されていない概念の両方で構成されるソフトウェアの動作方法の概念を指すこともあります。

ソフトウェア設計は通常、結果として得られるシステムの目標によって決定され、高レベルのソフトウェア アーキテクチャと低レベルのコンポーネントおよびアルゴリズムの設計の両方を含む問題解決と計画を伴います。

ウォーターフォール開発プロセスの観点から見ると、ソフトウェア設計は要件仕様に従い、コーディングの前に行う活動です。^[2]

設計プロセスにより、設計者はソフトウェア システムが存在する前にそのさまざまな側面をモデル化できます。

創造性、過去の経験、「優れた」ソフトウェアを生み出すための感覚、品質へのこだわりは、優れた設計の成功要因です。ただし、設計プロセスは必ずしも簡単な手順ではありません。

ソフトウェア設計モデルは、住宅の設計図に例えることができます。高レベルの計画は、住宅の全体を表します (例: 住宅の 3 次元レンダリング)。低レベルの計画は、各詳細を構築するためのガイダンスを提供します (例: 配管レイアウト)。同様に、ソフトウェア設計モデルは、提案されたソフトウェア ソリューションのさまざまなビューを提供します。

ソフトウェア設計ドキュメントは、コーディング前に制約、仕様、さらには要件を調整できるようにレビューまたは提示される場合があります。プログラムされたシミュレーションまたはプロトタイプのレビュー後に再設計が行われる場合があります。計画や要件分析なしでコーディングの過程でソフトウェアを設計することは可能ですが、^[3]より複雑なプロジェクトではこれはあまり現実的ではありません。コーディングの前に別の設計を行うことで、多分野にわたる設計者と専門家（SME）がプログラマーと協力し、有用で技術的に健全なソフトウェアを作成することができます。

ソフトウェア設計のコンポーネントの 1 つは、ソフトウェア要件分析(SRA) です。SRA は、ソフトウェア エンジニアリングで使用される仕様をリストするソフトウェア開発プロセスの一部です。

分析の出力は、解決すべきより小さな問題です。対照的に、設計は機能に重点を置くため、同じ問題に対して複数の設計が存在する可能性があります。環境に応じて、信頼できるフレームワークから作成されるか、適切な設計パターンで実装されるかによって、設計は異なることがよくあります。

設計プロセスには、フローチャート、ユースケース、疑似コード、統一モデリング言語モデル、その他の基本的なモデリング概念などの成果物の作成が含まれる場合があります。ユーザー中心のソフトウェアの場合、設計には、仕様を決定するのに役立つ ストーリーボードを生み出すユーザーエクスペリエンス設計が含まれる場合があります。

設計プロセスの出力は、設計ドキュメントになることがあります。

基本的な設計原則は、ソフトウェアエンジニアが設計プロセスを進めることを可能にします。デイビス^[4]はソフトウェア設計のための一連の原則を提案しており、それらは次のリストのように適応および拡張されています。

• 設計プロセスは「トンネルビジョン」に陥ってはなりません。優れた設計者は、問題の要件と、作業を実行するために利用できるリソースに基づいてそれぞれを判断し、代替アプローチを検討する必要があります。
• 設計は分析モデルまで追跡可能である必要があります。設計モデルの 1 つの要素が複数の要件まで遡ることができる場合が多いため、設計モデルによって要件がどのように満たされたかを追跡する手段が必要です。
• 設計では車輪の再発明をしてはいけません。システムは一連の設計パターンを使用して構築されますが、その多くは以前に遭遇したことがある可能性があります。これらのパターンは常に再発明の代替として選択する必要があります。時間は短く、リソースは限られています。設計時間は、既存のパターンを統合して (該当する場合)、(真に新しい) アイデアを表現することに投資する必要があります。
• 設計では、ソフトウェアと現実世界に存在する問題との間の「知的距離を最小限に抑える」必要があります。つまり、ソフトウェア設計の構造は、可能な限り、問題領域の構造を模倣する必要があります。
• デザインは統一性と統合性を備えている必要があります。デザインが完全に首尾一貫しているように見える場合、そのデザインは統一されています。この結果を達成するには、デザイン作業を開始する前に、デザイン チームに対してスタイルと形式のルールを定義する必要があります。デザイン コンポーネント間のインターフェイスの定義に注意を払えば、そのデザインは統合されています。
• デザインは、変更に対応できるように構築する必要があります。次のセクションで説明するデザイン コンセプトにより、デザインでこの原則を実現できます。
• 異常なデータ、イベント、または動作条件に遭遇した場合でも、緩やかに劣化するように設計する必要があります。適切に設計されたソフトウェアは「爆発」することはありません。異常な状況に対応できるように設計されている必要があり、処理を終了する必要がある場合は、適切に終了する必要があります。
• 設計はコーディングではなく、コーディングは設計ではありません。プログラム コンポーネントの詳細な手順設計が作成された場合でも、設計モデルの抽象化レベルはソース コードよりも高くなります。コーディング レベルで行われる設計上の決定は、手順設計をコーディングできるようにする小さな実装の詳細のみに対応する必要があります。
• 設計の品質は、事後ではなく、作成時に評価する必要があります。開発プロセス全体を通じて設計者が品質を評価するのに役立つさまざまな設計コンセプトと設計基準が用意されています。
• 設計は、概念的 (意味的) エラーを最小限に抑えるためにレビューする必要があります。設計のレビュー時に、細部に重点を置き、全体像を見失う傾向が時々あります。設計チームは、設計モデルの構文を心配する前に、設計の主要な概念的要素 (省略、曖昧さ、矛盾) が対処されていることを確認する必要があります。

デザイン コンセプトは、より洗練された方法を適用するための基盤をデザイナーに提供します。次のようなデザイン コンセプトのセットが進化してきました。

• 抽象化- 抽象化とは、概念または観察可能な現象の情報量を削減して一般化するプロセスまたは結果であり、通常は特定の目的に関連する情報のみを保持します。これは、背景の詳細​​や説明を含めずに、重要な特徴を表現する行為です。
• 洗練- 精緻化のプロセスです。マクロ的な機能ステートメントを段階的に分解して、プログラミング言語ステートメントに到達すると、階層が構築されます。各ステップでは、特定のプログラムの 1 つまたは複数の命令がより詳細な命令に分解されます。抽象化と洗練は補完的な概念です。
• モジュール性- ソフトウェア アーキテクチャは、モジュールと呼ばれるコンポーネントに分割されます。
• ソフトウェア アーキテクチャ- ソフトウェアの全体的な構造と、その構造がシステムの概念的整合性を提供する方法を指します。優れたソフトウェア アーキテクチャは、パフォーマンス、品質、スケジュール、コストなど、プロジェクトの望ましい結果に関して優れた投資収益率をもたらします。
• 制御階層 - プログラム コンポーネントの構成を表し、制御の階層を意味するプログラム構造。
• 構造的パーティショニング - プログラム構造は水平方向と垂直方向に分割できます。水平パーティションは、主要なプログラム機能ごとにモジュール階層の個別のブランチを定義します。垂直パーティションは、制御と作業をプログラム構造内でトップダウンに分散する必要があることを示しています。
• データ構造- データの個々の要素間の論理的な関係を表現します。
• ソフトウェア手順 - 各モジュールの個別の処理に重点を置いています。
• 情報の隠蔽- モジュールは、モジュール内に含まれる情報が、そのような情報を必要としない他のモジュールからアクセスできないように指定および設計する必要があります。

Grady Boochはオブジェクトモデルの中で、抽象化、カプセル化、モジュール化、階層化を基本的なソフトウェア設計原則として挙げています。 ^[5]これらの4つの基本原則を指すために、PHAME（階層、抽象化、モジュール化、カプセル化の原則）という頭字語が使用されることもあります。^[6]

ソフトウェアの設計には、考慮すべき点が数多くあります。各考慮事項の重要性は、ソフトウェアが満たすために作成されている目標と期待を反映する必要があります。これらの側面の一部を以下に示します。

• 互換性 - ソフトウェアは、他の製品との相互運用性を考慮して設計された他の製品と連携して動作できます。たとえば、ソフトウェアは、それ自体の古いバージョンと下位互換性がある場合があります。
• 拡張性- 基盤となるアーキテクチャに大きな変更を加えずに、ソフトウェアに新しい機能を追加できます。
• モジュール性- 結果として得られるソフトウェアは、明確に定義された独立したコンポーネントで構成され、保守性が向上します。コンポーネントは、統合されて目的のソフトウェア システムを形成する前に、個別に実装およびテストできます。これにより、ソフトウェア開発プロジェクトでの作業を分割できます。
• フォールト トレランス- ソフトウェアはコンポーネント障害に対して耐性があり、回復することができます。
• 保守性- バグ修正や機能変更をどれだけ簡単に実行できるかの尺度。高い保守性は、モジュール性と拡張性の産物です。
• 信頼性 (ソフトウェアの耐久性) - ソフトウェアは、指定された期間、指定された条件下で必要な機能を実行できます。
• 再利用性- 既存のソフトウェアの一部またはすべての側面を、ほとんどまたはまったく変更せずに他のプロジェクトで使用できる機能。
• 堅牢性- ソフトウェアは、ストレス下でも動作でき、予測できない入力や無効な入力にも耐えることができます。たとえば、メモリ不足の状態でも耐性を持つように設計できます。
• セキュリティ- ソフトウェアは敵対的な行為や影響に耐えることができます。
• ユーザビリティ- ソフトウェアのユーザーインターフェースは、対象ユーザー/視聴者にとって使いやすいものでなければなりません。パラメータのデフォルト値は、大多数のユーザーにとって適切な選択となるように選択する必要があります。^[7]
• パフォーマンス- ソフトウェアは、ユーザーが許容できる時間枠内でタスクを実行し、大量のメモリを必要としません。
• 移植性- ソフトウェアはさまざまな条件や環境で使用できる必要があります。
• スケーラビリティ- ソフトウェアは、データの増加や機能の追加、ユーザー数の増加にうまく適応します。Marc Brooker によると、「システムは、追加ワークロードの限界コストがほぼ一定である範囲でスケーラブルです。」サーバーレステクノロジーはこの定義に適合しますが、インフラコストだけでなく総所有コストを考慮する必要があります。^[8]

モデリング言語は、一貫した一連のルールによって定義された構造で情報、知識、またはシステムを表現するために使用できます。これらのルールは、構造内のコンポーネントの解釈に使用されます。モデリング言語は、グラフィカルまたはテキスト形式です。ソフトウェア設計用のグラフィカル モデリング言語の例には、次のものがあります。

• アーキテクチャ記述言語(ADL) は、ソフトウェア システムのソフトウェア アーキテクチャを記述および表現するために使用される言語です。
• ビジネス プロセス モデリング表記法(BPMN) は、プロセス モデリング言語の例です。
• EXPRESSおよび EXPRESS-G (ISO 10303-11) は、国際標準の汎用データ モデリング言語です。
• 拡張エンタープライズ モデリング言語(EEML) は、複数のレイヤーにわたるビジネス プロセス モデリングによく使用されます。
• フローチャートは、アルゴリズムやその他の段階的なプロセスを図式的に表現したものです。
• Fundamental Modeling Concepts (FMC) は、ソフトウェア集約型システム向けのモデリング言語です。
• IDEF はモデリング言語のファミリーであり、その中で最も有名なものには、機能モデリング用のIDEF0 、情報モデリング用のIDEF1X、オントロジーモデリング用のIDEF5などがあります。
• Jackson 構造化プログラミング(JSP) は、データ ストリーム構造とプログラム構造の対応に基づいた構造化プログラミングの手法です。
• LePUS3 は、オブジェクト指向のビジュアル設計記述言語であり、主に大規模なオブジェクト指向 ( Java、C++、C# ) プログラムと設計パターンのモデリングに適した形式仕様言語です。
• 統一モデリング言語(UML) は、ソフトウェアを構造的および動作的に記述するための汎用モデリング言語です。グラフィカル表記法を備え、プロファイル (UML)による拡張が可能です。
• Alloy (仕様言語) は、ソフトウェア システム内の複雑な構造上の制約と動作を表現するための汎用仕様言語です。一階関係論理に基づいた簡潔な言語ベースを提供します。
• システム モデリング言語(SysML) は、システム エンジニアリング用の新しい汎用モデリング言語です。
• サービス指向モデリングフレームワーク（SOMF）^[9]

ソフトウェア設計者は、過去に他の人が検討し、おそらく解決した設計の側面を特定することがあります。共通の問題に対する解決策を記述したテンプレートまたはパターンは、デザインパターンとして知られています。このようなパターンを再利用すると、ソフトウェア開発の速度が向上します。^[10]

ソフトウェアに関して「設計」という用語を使用する際の難しさは、ある意味では、プログラムのソース コードが、それが生成するプログラムの設計であるということです。これが真実である限り、「ソフトウェア設計」は設計の設計を指します。 エドガー W. ダイクストラは、このセマンティック レベルの階層化をコンピュータ プログラミングの「根本的な新しさ」と呼びました。^[11]また、ドナルド クヌースは、TeX を書いた経験から、プログラムを実装する前に設計しようとすることの無益さを説明しています。

もし私が単に仕様を定めただけで、初期の実装に完全に参加していなかったら、 T _E X は完全な失敗作になっていたでしょう。実装の過程で、私は常に予期せぬ疑問に遭遇し、元の仕様をどのように改善できるかについて新たな洞察を得ることができました。^[12]

ウィキメディア・コモンズには、ソフトウェア設計に関連するメディアがあります。

• アスペクト指向ソフトウェア開発
• デザイン
• 設計の根拠
• グラフィックデザイン
• インタラクションデザイン
• アイコンデザイン
• ソフトウェアの概要
• ソフトウェア開発の概要
• ソフトウェア工学の概要
• 検索ベースのソフトウェアエンジニアリング
• ソフトウェア設計記述(IEEE 1016)
• ソフトウェア開発
• ユーザーエクスペリエンス
• ユーザーインターフェース設計
• ウェブデザイン
• ゼロワンインフィニティ

^ Roger S. Pressman (2001).ソフトウェアエンジニアリング: 実践者のアプローチ. McGraw-Hill. ISBN 0-07-365578-3。