** ソフトウェアの設計 **

ソフトウェア要件が確定した後、ソフトウェア設計段階に入る。ソフトウェア設計はソフトウェア工学の重要な段階です。ソフトウェア設計の基本的な目的は、システムをどのように実装するかという問いに答えることです。ソフトウェア設計の任務は、ソフトウェア要求仕様書に規定された機能要素を、実際の条件を考慮して、ソフトウェアシステム要求を満たす技術案に変換し、次の段階のソフトウェア実施作業の基礎を築くことである。

** ソフトウェア設計の概要 ***

ソフトウェア設計は、ソフトウェア開発プロセスにおけるソフトウェア製品の品質を決定する重要な段階です。ソフトウェア設計段階で行われる決定は、最終的にソフトウェア開発の成功を決定し、さらに重要なことに、これらの設計決定は、ソフトウェア保守の容易さを決定する。

ソフトウェア設計活動は、高品質、低コスト、保守が容易なソフトウェアを取得するための最も重要なステップの1つです。その主な目的は、ソフトウェアの青写真を描き、各種技術と実施方法の長所と短所を比較し、各種資源を合理的に配分し、ソフトウェアシステムの詳細な方案と関連モデルを構築し、ソフトウェアの実施作業の順調な展開を指導することである。

ソフトウェア設計は、開発期間の開始段階であり、ソフトウェア開発期間全体の品質に関わる。ソフトウェア開発期間情報フローは、図5-1に示すように、ソフトウェア要件からソフトウェアコーディングまでのソフトウェア設計を記述し、その役割を果たす。

図5-1ソフトウェア開発期間の情報フロー

** ソフトウェア設計のタスク **

ソフトウェア設計の任務はソフトウェア要求仕様書から出発し、要求分析段階で確定した機能によってソフトウェアシステムの全体構造を設計し、機能モジュールを分割し、モジュールごとの実現アルゴリズムを確定し、ソフトウェアの具体的な設計案を形成することである。ソフトウェア設計とは、ソフトウェアが顧客のニーズをどのように満たすか、どのように実装しやすく、どのように機能を拡張して新しいニーズに対応できるかなど、設計者の計画においてさまざまな視点から考えられる創造的な活動です。

ソフトウェア工学の観点から、一般にソフトウェア設計は、図5-2に示すように、概要設計と詳細設計の2段階に分けられる。ソフトウェアプロジェクトの規模及び複雑さに応じて、概要設計及び詳細設計は、ソフトウェア設計段階に統合されてもよいし、またはソフトウェア要件内容が完全に実現されるまで反復されてもよい。

図5-2ソフトウェア設計段階の区分とタスク

**概要設計 **

概要設計は全体設計とも呼ばれ、需要分析段階の作業結果から、選択可能な技術方案を明確にし、ソフトウェア構造を分ける前作業をしっかり行い、その後、システムを構成する物理要素を分け、ソフトウェアアーキテクチャ設計、データ設計とユーザーインターフェース設計を行う。

プロファイル設計の主なプレーヤーは、ソフトウェアアナリスト、ユーザー、ソフトウェアプロジェクトマネージャー、および関連する技術専門家です。ソフトウェア分析者は目標システムに対する物理方案と最終的なソフトウェア構造設計を完成する;ユーザーはシステムの物理方案と最終的なソフトウェア構造を評価して最終的に承認する;ソフトウェアプロジェクト管理者はソフトウェア分析者が設計したシステム物理方案とソフトウェア構造を評価し、ソフトウェア分析者の設計作業に対して指導を行う;関連する技術専門家は主にソフトウェア分析者が設計したシステム物理方案及びソフトウェア構造を評価する。

概要設計の主なタスクは、アーキテクチャ設計、データ設計、およびユーザーインターフェイス設計を完了することです。

1)アーキテクチャ設計。サブシステムモジュール間のデータ転送と呼び出しの関係を決定する。構造化設計テーマ区分では、主にクラスとクラス間の関係を決定する。 2)データデザイン。データ設計には、データベース、データファイル、グローバルデータ構造の定義が含まれる。構造化設計では、要求段階のエンティティ-リンク図、データ辞書によってデータモデルが構築される。オブジェクト指向設計では、データ設計プロセスは、クラスの抽象化とインスタンス化、およびクラスの永続記憶の設計によって完了される。 3)ユーザーインターフェースの設計システムと相互作用するヒューマン·マシン·インターフェース設計、及びモジュール間、システムと外部システムとのインターフェース関係を含む。構造化設計では、データストリームエントリに応じて、モジュールインタフェース、大域的なデータ構造を定義する。オブジェクト指向設計では、関連クラス、インターフェースクラス、境界クラスなどを定義し、ヒューマンマシンインターフェースデータの統一を満たし、クラス間データの転送を完了する。

** 詳細なデザイン **

詳細設計のタスクは、概要設計に基づいて、システムのすべての内容が十分に詳細なプロセス記述を有するまで、各部分の詳細を具体的に実現することであり、符号化のタスクは、詳細設計の内容をプログラム設計言語に“翻訳”することである。正確には、詳細設計のタスクは、プロセス設計を完了することです。

プロセス設計には、ソフトウェアモジュール内の具体的な実装プロセスとローカルデータ構造の決定が含まれます。構造化設計において、モジュール独立性はデータ構造とアルゴリズムを分離する状況を制約し、両者が設計時に必ず局所性を持たせ、外部からの影響を減少させる。オブジェクト指向設計では、クラスのカプセル化はアルゴリズムとデータ構造の内部性をよりよく反映している。クラスの継承は、複数のクラスクラスファミリーが共同でプロセス設計を実装するためのメカニズムを提供する。

** ソフトウェア設計原則 **

ソフトウェア開発技術が進歩するにつれて、いくつかの良い設計原則が絶えず提案され、ソフトウェア設計プロセスを指導し、ソフトウェア品質を確保する。

（1） 分割統治：分割統治は、大規模で複雑な問題を解決するために使用される戦略です。大問題を若干の小問題に分け、一つの大問題に対する解解を若干の小問題に対する解に変換し、このようにして問題の複雑度を大幅に低下させる。モジュール化は、ソフトウェア設計が分割統治のアイデアを実現する技術的手段である。構造化設計では、モジュールは関数、プロシージャ、さらにはコードスニペットであってもよい。オブジェクト指向設計では、クラスはモジュールの主要な形式である。

（2） 再利用デザインパターン：再利用とは、同じものを変更せずに何度も使用できる仕組みです。概要設計が完成するのはシステムソフトウェア構造であるため、再利用される内容はソフトウェア設計パターンです。ソフトウェア設計パターンは、特定のソフトウェア設計に直面するのではなく、ソフトウェア設計のプロセスとモデルのクラスを対象とする。設計パターンを再利用することにより、ソフトウェア設計品質を保証するだけでなく、設計中の新しいプロセス、新しい方法にリソースを集中させ、設計時に新しいプロセス、新しい方法の将来の再利用をさらに考慮する。

（3） トレーサビリティ：ソフトウェア設計のタスクの1つは、ソフトウェアのさまざまな部分間の関係を決定することです。システム構造を設計することは、システムの各部分、各モジュール間の相互呼び出しまたは制御関係を決定することであり、モジュールを修正する必要がある時、修正モジュールに関連する他の部分を把握し、問題の根源を正確にたどることができる。

（4） 柔軟性：設計の柔軟性は、主に設計の変更が容易であることを指します。修正には、既存のデザインの追加、削除、変更が含まれます。修正の原因は主に、ユーザーの要求が変更され、設計に欠陥があり、設計に最適化が必要であり、設計に再利用される。

ソフトウェア設計の柔軟性は、主にシステム記述問題の抽象化によって具現化される。抽象化は、物事の同じ属性または操作の統一的な記述であり、広範性を有する。したがって、システム設計およびデザインパターンの抽象化度が高いほど、カバー範囲が大きくなります。例えば、“鳥”が“スズメ”を抽象化すると、スズメが飛ぶことができる特性を具現化することができ、他の鳥の説明もカバーする。しかし、抽象化は“両刃の剣”であり、過度の抽象化はむしろ理解と設計に困難をもたらします。“スズメ”の実体を“生き物”で抽象化すると、馬としての特徴の多くは“生き物”で定義することが困難になる。

5 一貫性：一貫性はソフトウェア設計方法とプロセスの両方に反映されます。ソフトウェア設計において、インターフェイスビューの一貫性はユーザー体験とシステムに対する忠誠度を保証し、例えばWindowsオペレーティングシステムのインターフェイスは、複数のバージョンの変更を経ても、ユーザー操作方式は基本的に変更されていない。統一的な規則と制約規範モジュールインターフェースを用いて定義し、符号化段階のインターフェースとデータ構造の統一的な操作を確保し、データ理解上の曖昧さを減少させ、ソフトウェア品質を保証させる。

(6)信頼性：設計は機能設計のすべての側面を横断し、基本機能を満たしながら、信頼性に影響を与える要因を十分に考慮する必要があります。設計と実現においては、ソフトウェアアーキテクチャ設計は合理的でなければならず、各モジュール間の結合を最小限に抑え、システムのフォールトトレランスを向上させ、単一モジュールの故障が他のモジュールやシステム全体に影響を及ぼさないようにする。ソフトウェア開発プロセスでは、開発テストの同期、リアルタイムテストと問題の発見の原則に従う必要があり、繰り返し検証し、リスクを低減し、ソフトウェアの信頼性を向上させる必要があります。

（7） スケーラビリティ：ソフトウェアの設計と実装は、モジュールの役割の境界を明確にし、統一された標準入出力インタフェースを使用して、ソフトウェア関連業務の水平展開を容易にし、モジュールにはデータ型、サブ機能、操作インタフェースが含まれており、ソフトウェア関連業務の垂直展開を容易にする。

8 保守性：設計と実装において、ソフトウェアの各構成項目は完全なログ記録（プロセスログと例外ログを含む）を提供し、ソフトウェアエラーが発生した場合には明確な例外情報を提示する必要があります。すべての障害状態と情報は自動的に記録して保存し、事後的な障害対策分析を容易にする必要があります。

ソフトウェア設計の改善、ソフトウェア品質の向上は、次の原則に従う必要がある。

1)モジュール独立性の高い

ソフトウェアの初期構造を設計した後、モジュールをさらに分解または統合して、結合を低減し、凝集を向上させることを試みるべきである。例えば、複数のモジュールに共通する1つのサブ機能は、独立してモジュールを定義し、これらのモジュールによって呼び出されることができ、制御情報の伝達および全データへの参照を減らし、インターフェースの複雑さを減らすために、モジュールを分割またはマージすることができる場合がある。

2)モジュールのサイズは適度

大きなモジュールはよく分解が不十分であるためであるが、さらなる分解は問題構造に適合しなければならず、一般に分解後にモジュール独立性を低下させるべきではない。モジュールが小さすぎると、効率的な動作よりもオーバーヘッドが大きくなり、モジュール数が多すぎると、システムインタフェースが複雑になります。したがって、小さすぎるモジュールは単独で存在する価値がない場合があり、特に1つのモジュールのみがそれを呼び出す場合、通常は単独で存在することなく上位モジュールにマージすることができます。

3)深さ、幅、ファンアウト、およびファンイン適切な深さは、ソフトウェア構造における制御の層の数を表し、システムのサイズおよび複雑さを大まかに示すことができる。

図5-3に示します。それとプログラムの长さとの间には粗い対応があるべきであるが、当然この対応は一定范囲内で変化する。階層数が多すぎる場合は、管理モジュールの多くが単純すぎて適切に統合する必要がないかどうかを考慮する必要があります。幅は、ソフトウェア構造内の同じ階層にあるモジュールの総数の最大値です。一般的に幅が大きいほどシステムは複雑になる。幅に最も影響を与える要因は、モジュールのファンアウトです。

図5-3ソフトウェア構造の用語