ソフトウェア設計

ソフトウェア設計は、エージェントが一連の基本的なコンポーネントを使用し、制約に従って、目標を達成することを目的としたソフトウェア成果物の仕様を作成するプロセスです[1]この用語は、ソフトウェアの「概念化、枠組み化、実装、コミッショニング、そして最終的な変更に関わるすべての活動」、より具体的には「要件仕様に続き、プログラミング前の活動」を指すために広く使用されることがあります。定型化されたソフトウェア エンジニアリング プロセスです。」[2]

ソフトウェア設計には通常、問題解決とソフトウェアソリューションの計画が含まれます。これには、低レベルのコンポーネントとアルゴリズムの設計と、高レベルのアーキテクチャ設計の両方が含まれます。

概要

ソフトウェア設計は、1 つ以上の問題セットに対するソフトウェア ソリューションを構想し、定義するプロセスです。ソフトウェア設計の主要コンポーネントの 1 つはソフトウェア要件分析(SRA) です。SRA は、ソフトウェア エンジニアリングで使用される仕様をリストするソフトウェア開発プロセスの一部です

ソフトウェアが「半自動」またはユーザー中心の場合、ソフトウェア設計には、仕様の決定に役立つストーリーボードを生成するユーザー エクスペリエンス設計が含まれる場合があります。ソフトウェアが完全に自動化されている(つまり、ユーザーユーザー インターフェイスがない) 場合、ソフトウェアの設計は、計画された一連のイベントを説明するフローチャートやテキストと同じくらい単純になる可能性があります。統一モデリング言語基本モデリング概念などの準標準的な手法もありますどちらの場合でも、計画の文書の一部は通常、設計の成果物です。さらに、ソフトウェア設計は、設計に使用されるテクノロジの可用性に応じて、 プラットフォームに依存しない場合もあれば、プラットフォームに固有になる場合もあります。

ソフトウェア分析と設計の主な違いは、ソフトウェア分析の出力が、解決すべき小さな問題で構成されることです。さらに、分析は、チームのメンバーやグループごとに大きく異なるように設計すべきではありません。対照的に、この設計は機能に焦点を当てているため、同じ問題に対して複数の設計が存在する可能性があり、今後も存在することになります。環境に応じて、信頼性の高いフレームワークから作成されるか、適切な設計パターンで実装されるかなど、設計は異なることがよくあります設計例には、オペレーティング システム、Web ページ、モバイル デバイス、さらには新しいクラウド コンピューティング パラダイムが含まれます。

ソフトウェア設計はプロセスであり、モデルでもあります。設計プロセスは、設計者が構築するソフトウェアのあらゆる側面を記述することを可能にする一連のステップです。創造的なスキル、過去の経験、何が「良い」ソフトウェアを作るのかという感覚、そして全体的な品質への取り組みは、有能な設計にとって重要な成功要因の例です。ただし、設計プロセスは必ずしも単純な手順ではありません。設計モデルは、建築家の住宅計画にたとえることができます。それは、建設されるものの全体を表現することから始まります (たとえば、家の 3 次元レンダリング)。ゆっくりと、細部 (配管など) を構築するためのガイダンスを提供するように改良されます。同様に、ソフトウェア用に作成された設計モデルは、コンピューター ソフトウェアのさまざまなビューを提供します。基本的な設計原則により、ソフトウェア エンジニアは設計プロセスを進めることができます。Davis [3]は、ソフトウェア設計の一連の原則を提案しています。これらの原則は、次のリストに適応および拡張されています。

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

デザインコンセプト

設計概念は、ソフトウェア設計者に、より洗練された手法を適用できる基盤を提供します。一連の基本的な設計コンセプトが進化しました。それらは次のとおりです。

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

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

設計上の考慮事項

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

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

モデリング言語

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

デザインパターン

ソフトウェア設計者またはアーキテクトは、過去に他の人が訪れ、おそらくは解決した設計上の問題を特定する場合があります。一般的な問題の解決策を記述したテンプレートまたはパターンは、デザイン パターンとして知られています。このようなパターンを再利用すると、ソフトウェア開発プロセスのスピードアップに役立ちます。[8]

技術

ソフトウェアに関して「設計」という用語を使用するのが難しいのは、ある意味、プログラムのソース コードが、それが生成するプログラムの設計であるということです。これが真実である限り、「ソフトウェア設計」は設計の設計を指します。 Edsger W. Dijkstra は、この意味レベルの階層化をコンピューター プログラミングの「根本的な新規性」と呼び[9]Donald KnuthはTeXを書いた経験を利用して、実装前にプログラムを設計しようとすることの無益さを説明しました。

もし私がそれを指定しただけで、最初の実装に全面的に参加していなかったとしたら、 T E X は完全に失敗していたでしょう。実装のプロセスでは、常に予期せぬ質問が発生し、元の仕様をどのように改善できるかについて新たな洞察が得られました。[10]

使用法

ソフトウェア設計文書は、コンピュータプログラミングの前に制約、仕様、さらには要件さえも調整できるようにレビューまたは提示される場合がありますプログラムされたシミュレーションまたはプロトタイプのレビュー後に再設計が行われる場合があります計画や要件の分析を行わずに、プログラミングの過程でソフトウェアを設計することは可能ですが[11]、より複雑なプロジェクトの場合、これは実現可能とは考えられません。プログラミングの前に個別の設計を行うことで、多分野の設計者や専門家(SME) が高度なスキルを持つプログラマーと協力して、有用かつ技術的に健全なソフトウェアを作成することができます。

こちらも参照

参考文献

  1. ^ ラルフ、P. およびワンド、Y. (2009)。デザインコンセプトの正式な定義の提案。Lyytinen, K.、Loucopoulos, P.、Mylopoulos, J.、および Robinson, W. 編集者、Design Requirements Workshop (LNBIP 14)、103 ~ 136 ページ。Springer-Verlag、p. 109土井:10.1007/978-3-540-92966-6_6。
  2. ^ フリーマン、ピーター; デビッド・ハート (2004)。「ソフトウェア集約型システムの設計の科学」。ACM の通信47 (8): 19–21 [20]。土井:10.1145/1012037.1012054。S2CID  14331332。
  3. ^ Davis、A:「ソフトウェア開発の 201 原則」、McGraw Hill、1995 年。
  4. ^ ブーチ、グレイディ; 他。(2004)。オブジェクト指向分析とアプリケーションによる設計 (第 3 版)。マサチューセッツ州、米国: アディソン・ウェスリー。ISBN 0-201-89551-X2015 年1 月 30 日に取得
  5. ^ スリヤナラヤナ、ギリッシュ (2014 年 11 月)。ソフトウェア設計のリファクタリングの匂いモーガン・カウフマン。p. 258.ISBN _ 978-0128013977
  6. ^ ジョン・キャロル編。(1995年)。シナリオベースのデザイン: システム開発における作業とテクノロジーを構想するニューヨーク:ジョン・ワイリー&サンズ。ISBN 0471076597
  7. ^ マイケル、ベル (2008). 「サービス指向モデリングの概要」。サービス指向モデリング: サービス分析、設計、およびアーキテクチャワイリー&サンズ。ISBN 978-0-470-14111-3
  8. ^ ジュディス・ビショップ。「C# 3.0 デザイン パターン: C# 3.0 の力を利用して現実世界の問題を解決する」。O'Reilly Media の C# 書籍2012 年 5 月 15 日に取得.NET アプリケーションの開発をスピードアップしたい場合は、C# 設計パターンを使用する準備ができています。これは、一般的なプログラミングの問題に対処するエレガントで受け入れられ、実証済みの方法です。
  9. ^ ダイクストラ、EW (1988)。「コンピューティング科学を実際に教えることの残酷さについて」2014 年 1 月 10 日に取得
  10. ^ クヌース、ドナルド E. (1989)。「TeX のエラーに関する注意事項」(PDF)
  11. ^ Ralph, P. および Wand, Y. デザイン コンセプトの正式な定義に関する提案。In、Lyytinen、K.、Loucopoulos、P.、Mylopoulos、J.、および Robinson, W. (編)、「設計要件エンジニアリング: 10 年間の展望」: Springer-Verlag、2009 年、103-136 ページ

^ロジャー・S・プレスマン (2001)。ソフトウェア エンジニアリング: 実践者のアプローチマグロウヒル。ISBN 0-07-365578-3