ソフトウェア設計

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

ソフトウェア設計は、エージェントが一連のプリミティブコンポーネントを使用し、制約の対象となる、目標を達成することを目的としたソフトウェア成果物の仕様を作成するプロセスです。[1]ソフトウェア設計とは、「複雑なシステムの概念化、フレーミング、実装、試運転、および最終的な変更に関連するすべてのアクティビティ」または「要件仕様に従い、プログラミング前のアクティビティ」のいずれかを指します。エンジニアリングプロセス。」[2]

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

概要

ソフトウェア設計は、1つまたは複数の問題セットに対するソフトウェアソリューションを想定および定義するプロセスです。ソフトウェア設計の主要なコンポーネントの1つは、ソフトウェア要件分析(SRA)です。SRAは、ソフトウェアエンジニアリングで使用される仕様を一覧表示するソフトウェア開発プロセスの一部です。ソフトウェアが「半自動化」またはユーザー中心の場合、ソフトウェア設計には、それらの仕様を決定するのに役立つストーリーボードを生成するユーザーエクスペリエンス設計が含まれる場合があります。ソフトウェアが完全に自動化されている場合(つまり、ユーザーまたはユーザーインターフェイスがない場合))、ソフトウェアの設計は、計画された一連のイベントを説明するフローチャートまたはテキストのように単純な場合があります。統一モデリング言語基本モデリング概念のような半標準的な方法もありますいずれの場合も、計画の一部のドキュメントは通常、設計の成果物です。さらに、ソフトウェア設計は、設計に使用されるテクノロジの可用性に応じて、 プラットフォームに依存しない場合とプラットフォーム固有の場合があります。

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

ソフトウェア設計は、プロセスであると同時にモデルでもあります。設計プロセスは、設計者が構築するソフトウェアのすべての側面を説明できるようにする一連のステップです。創造的なスキル、過去の経験、「優れた」ソフトウェアを作るものの感覚、および品質への全体的な取り組みは、有能な設計の重要な成功要因の例です。ただし、設計プロセスは必ずしも簡単な手順ではないことに注意してください。設計モデルは、建築家の家の計画と比較できます。それは、建てられるものの全体を表すことから始まります(たとえば、家の3次元レンダリング)。ゆっくりと、物事は各詳細を構築するためのガイダンスを提供するために洗練されます(例えば、配管敷設)。同様に、ソフトウェア用に作成された設計モデルは、コンピューターソフトウェアのさまざまなビューを提供します。基本的な設計原則により、ソフトウェアエンジニアは設計プロセスをナビゲートできます。デイビス[3]は、ソフトウェア設計の一連の原則を提案しています。これらの原則は、次のリストに適合および拡張されています。

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

デザインコンセプト

設計コンセプトは、ソフトウェア設計者に、より高度な方法を適用できる基盤を提供します。基本的な設計コンセプトのセットが進化しました。それらは次のとおりです。

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

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

設計上の考慮事項

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

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

モデリング言語

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

デザインパターン

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

テクニック

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

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

使用法

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

も参照してください

参考文献

  1. ^ Ralph、P。およびWand、Y。(2009)。デザインコンセプトの正式な定義の提案。Lyytinen、K.、Loucopoulos、P.、 Mylopoulos、J。、およびRobinson、W。の編集者、設計要件ワークショップ(LNBIP 14)、103〜136ページ。Springer-Verlag、p。109 doi 10.1007 / 978-3-540-92966-6_6
  2. ^ フリーマン、ピーター; デビッドハート(2004)。「ソフトウェア集約型システムの設計科学」。ACMの通信47(8):19–21 [20]。土井10.1145 /1012037.10120547S2CID14331332 _
  3. ^ Davis、A: "201 Principles of Software Development"、McGraw Hill、1995。
  4. ^ ブーチ、グレイディ; etal。(2004)。アプリケーションを使用したオブジェクト指向の分析と設計(第3版)。米国マサチューセッツ州:アディソンウェスリー。ISBN 0-201-89551-X2015年1月30日取得
  5. ^ Suryanarayana、Girish(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. ^ Dijkstra、EW(1988)。「実際にコンピューティングサイエンスを教えることの残酷さについて」2014年1月10日取得
  10. ^ Knuth、Donald E.(1989)。「TeXのエラーに関する注意」(PDF)
  11. ^ Ralph、P。、およびWand、Y。デザインコンセプトの正式な定義の提案。In、Lyytinen、K.、Loucopoulos、P.、Mylopoulos、J.、and Robinson、W。、(eds。)、Design Requirements Engineering:A Ten-Year Perspective:Springer-Verlag、2009、pp.103-136

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