ソフトウェア設計(ソフトウェアせっけい、: Software design)は、ソフトウェアのための問題解決と計画の工程である。ソフトウェアの目的と仕様が決定した後で、ソフトウェア開発者設計をしたり、専門の設計者が開発計画を立てる。細かいコンポーネントアルゴリズムの実装だけではなく、アーキテクチャ的観点での検討も行われる。

ソフトウェア開発工程での要求分析によって、ソフトウェア工学における仕様が確定する。そのソフトウェアがユーザーとの対話を必要とするものか、あるいはユーザー中心設計であれば、ソフトウェア設計にはユーザーエクスペリエンス設計も関わり、絵コンテなども仕様に含まれることになる。完全に自動的に動作するソフトウェア(ユーザインタフェースのないソフトウェア)であれば、ソフトウェア設計は単なるフローチャート作成程度の作業となるかもしれない。また、統一モデリング言語 (UML) などの半形式的手法もある。いずれにしても、ソフトウェア設計工程の成果物としては、何らかのソフトウェア設計文書が生成される。

考慮すべき点

編集

ソフトウェア設計にあたっては、様々な観点を考慮する必要がある。ソフトウェアが達成しようとしている目標を反映しているため、それらは重要である。そのような観点の一部を以下に挙げる。

  • 拡張性 - 基盤となるアーキテクチャに大きな変更を加えることなく、新たな機能を追加できること。
  • 頑健性 - 高負荷状態や不正な入力があっても動作すること。例えば、使用可能なメモリ量が少なくても動作するよう設計する。
  • 信頼性 - ある一定期間まで、特定の困難な状態になっても、機能すること。
  • 耐障害性 - コンポーネントの障害が発生しても、それに耐えたり、回復させたりできること。
  • セキュリティ - 悪意ある行為に対して耐性があること。
  • 保守性 - ある一定時間で、特定の状態に復帰できること。例えば、アンチウイルスソフトのように、定期的な更新が可能であるなど。
  • 互換性 - 他の製品と相互にやりとりできること。あるいは、過去の代替すべき製品と互換であること。
  • モジュール性 - モジュール性を考慮した設計。それによって保守性も向上する。開発においてもコンポーネント単位で実装しテスト可能などの利点がある。また、開発作業の分割が容易になる。
  • 再利用 - モジュール性がよければ、個々のコンポーネントを他の場面で再利用できる可能性が生じる。

デザインパターン

編集

ソフトウェア設計者やアーキテクトは、設計上の問題が既存の解決済みの問題と同じであると気づくことがある。よくある問題についての解法のテンプレート(あるいはパターン)をデザインパターンと呼ぶ。過去に評価済みのデザインパターンの利用によって、ソフトウェア開発工程が加速される。

設計方法論

編集

設計方法論は実際のシステム設計におけるテンプレートやフレームワークの役割を果たす。実際の設計工程を単純化し、品質向上のための設計原則の適用を可能とする。

必要性

編集

ソフトウェア設計文書により、プログラミングを開始する前に制約条件、要求仕様などが明らかとなり、検討される。シミュレーションプロトタイプの構築によって設計変更となる場合もある。要求分析や計画立案せずに、プログラミングしながら設計することも可能だが、複雑な大規模プロジェクトではそのような工程の省略は選択肢として考慮されないのが普通である。プログラミングの前に設計工程を置くことで、ソフトウェアの対象領域の専門家と設計者がプログラマと共同で作業し、ソフトウェアの利便性と技術的正当性を高めることができる。

関連項目

編集