2.6.1. ソフトウェア設計

1. 概要

　ソフトウェア設計は、ソフトウェア開発プロセスにおいて極めて重要な段階です。この段階では、ソフトウェア要件定義書を基に、開発者の視点からソフトウェアの構造と要素の設計を行います。具体的には、ソフトウェア要素をソフトウェアユニット（プログラム）まで分割し、各ユニットの機能、ユニット間の処理手順や関係を明確にします。

　このプロセスは、効率的で保守性の高いソフトウェアを開発するための基盤となります。適切な設計により、開発チームは共通の理解を持って作業を進めることができ、結果として高品質なソフトウェアの実現につながります。

2. 詳細説明

2.1. ソフトウェア設計の主要概念

2.1.1. 構造化設計

　構造化設計は、ソフトウェアを機能的に分割し、階層的な構造を持たせる手法です。この手法により、ソフトウェアの複雑さを管理し、開発と保守を容易にします。

2.1.2. ソフトウェア要素とソフトウェアユニット

　ソフトウェア要素は、ソフトウェア全体を構成する大きな機能単位を指します。これらの要素はさらに小さな単位であるソフトウェアユニットに分割されます。ソフトウェアユニットは、通常、1つの特定の機能を持つプログラムやモジュールです。

2.1.3. ソフトウェアユニット分割

　ソフトウェアユニット分割は、大きな機能をより小さく、管理しやすい単位に分解するプロセスです。これにより、開発の並行性が高まり、テストや保守が容易になります。

2.2. ソフトウェア設計のプロセス

2.2.1. ソフトウェアユニット機能仕様決定

　各ソフトウェアユニットが担う具体的な機能を明確に定義します。これには、入力、処理、出力の詳細な仕様が含まれます。

2.2.2. ソフトウェアユニット間インタフェース設計

　ユニット間のデータの受け渡しや、制御の流れを定義します。これにより、ユニット間の依存関係や相互作用が明確になります。非同期通信やエラーハンドリングも考慮し、必要な場合はシーケンス図などを用いて、通信のタイミングとデータフローを明確化します。

sequenceDiagram
    participant A as ユニットA
    participant B as ユニットB
    participant C as ユニットC
    participant D as ユニットD
    A->>B: データ要求
    B->>A: データ応答
    A->>C: 処理要求
    C->>D: 外部API呼び出し
    D->>C: API応答
    C->>A: 処理結果
    A-->>B: 非同期通知

2.2.3. ソフトウェア統合のためのテスト要件

　個々のユニットを統合する際のテスト要件を定義します。統合テスト、回帰テスト、ユニットテストなど、テストの種類ごとに事前に問題を予測し、対策を立てます。これにより、統合段階でのトラブルが減少し、全体の品質を向上させることができます。

テストタイプ	目的	対象	主な内容	期待される結果
ユニットテスト	個々のソフトウェアユニットが正しく動作することを確認する	個別のクラス、メソッド、関数	– 入力値の境界値テスト – 異常系テスト – コードカバレッジの確認	– 全てのテストケースが通過する – コードカバレッジが80%以上
統合テスト	複数のユニットが正しく連携して動作することを確認する	モジュール間の相互作用、サブシステム	– ユニット間のデータ受け渡しの確認 – エラー処理の検証 – パフォーマンステスト	– データの整合性が保たれる – エラーが適切に処理される – 応答時間が規定値以内
回帰テスト	新機能の追加や修正が既存の機能に悪影響を与えていないことを確認する	システム全体	– 既存機能の動作確認 – 過去に発生したバグの再発チェック – パフォーマンスの変化確認	– 既存機能が正常に動作する – 過去のバグが再発していない – システムの性能が維持されている

テスト要件の例（ユニットテスト、統合テスト、回帰テスト）

補足説明

ユニットテスト

自動化テストツールを活用し、継続的に実行することが推奨される
テスト駆動開発（TDD）を採用する場合、コード実装前にテストを書く

統合テスト

モックオブジェクトやスタブを使用して、外部依存を管理する
エッジケースや異常系のシナリオも含めてテストする

回帰テスト

自動化されたテストスイートを使用して効率的に実行する
重要度の高い機能に対しては、手動でのテストも併用する

　これらのテストを適切に組み合わせることで、ソフトウェアの品質を高め、バグの早期発見と修正が可能になります。

2.3. ソフトウェア設計の要素

2.3.1. 基本機能設計

　ソフトウェアの核となる機能を設計します。これはソフトウェアの主要な目的を達成するための中心的な部分です。

2.3.2. 部品設計

　再利用可能な部品（コンポーネント）を設計します。これにより、開発効率の向上と品質の安定化が図れます。

2.3.3. 入出力設計

　ユーザーインターフェースや外部システムとのデータのやり取りを設計します。

2.3.4. 物理データ設計

　データベースやファイル構造などの物理的なデータ保存形式を設計します。

3. 応用例

3.1. Webアプリケーション開発

　Webアプリケーション開発では、フロントエンド、バックエンド、データベースなどの主要コンポーネントを明確に分離し、それぞれのインターフェースを設計します。たとえば、ユーザー認証、データ処理、表示ロジックなどを個別のソフトウェアユニットとして設計し、それらの相互作用を定義します。

3.2. モバイルアプリケーション開発

　モバイルアプリケーションでは、UI/UXデザイン、ネットワーク通信、ローカルデータ管理などの機能を別々のモジュールとして設計します。これにより、異なるプラットフォーム（iOS、Android）間でのコード再利用性を高めることができます。

3.3. 組み込みシステム開発

　組み込みシステムでは、ハードウェア制御、リアルタイム処理、省電力管理などの機能を独立したソフトウェアユニットとして設計します。リアルタイム処理では、タスクスケジューリングやデッドラインを守るための設計が必要です。これにより、ハードウェアの変更に対する柔軟性が向上し、テストや検証が容易になります。

flowchart TD
    A[システム起動] --> B{初期化成功?}
    B -->|Yes| C[タスクスケジューラ起動]
    B -->|No| Z[エラー処理]
    C --> D{割り込み発生?}
    D -->|Yes| E[割り込み処理]
    E --> F{高優先度タスク?}
    F -->|Yes| G[高優先度タスク実行]
    F -->|No| H[割り込み処理完了]
    H --> D
    G --> D
    D -->|No| I{定期タスク時間到達?}
    I -->|Yes| J[定期タスク実行]
    J --> K{デッドライン内?}
    K -->|Yes| D
    K -->|No| L[デッドラインミス処理]
    L --> D
    I -->|No| M{アイドル状態?}
    M -->|Yes| N[省電力モード移行]
    N --> D
    M -->|No| O[バックグラウンドタスク実行]
    O --> D
    Z --> P[システムリセット]
    P --> A

　このフローチャートは、組み込みシステムにおけるリアルタイム処理の基本的な流れを示しています。主な特徴と処理の流れは以下の通りです：

システム起動と初期化
- システムが起動し、初期化プロセスを実行します。
- 初期化に失敗した場合は、エラー処理を行い、システムをリセットします。
タスクスケジューラの起動
- 初期化成功後、タスクスケジューラを起動します。
割り込み処理
- 常に割り込みの発生をチェックします。
- 割り込みが発生した場合、その処理を行います。
- 高優先度のタスクである場合は、即座に実行します。
定期タスクの実行
- 定期的に実行すべきタスクの時間が来たかチェックします。
- タスクを実行し、デッドライン内に完了したかを確認します。
- デッドラインを超過した場合、適切な処理を行います。
アイドル状態の処理
- システムがアイドル状態の場合、省電力モードに移行します。
- アイドル状態でない場合、バックグラウンドタスクを実行します。
継続的なループ
- 処理が完了するたびに、再び割り込みのチェックに戻ります。

　このフローチャートは、リアルタイムオペレーティングシステム（RTOS）の基本的な動作原理を示しており、優先度ベースのスケジューリング、割り込み処理、デッドライン管理、省電力制御などの重要な概念を含んでいます。

　実際の組み込みシステムでは、このフローチャートをベースに、具体的なアプリケーションの要件に応じてさらに詳細化や拡張が行われます。

4. 例題

例題1:

　ある企業の在庫管理システムのソフトウェア設計を行うとします。このシステムは、商品の入出庫管理、在庫レベルの監視、発注処理を行う必要があります。主要なソフトウェアユニットを3つ挙げ、それぞれの機能を簡潔に説明してください。

回答例:

入出庫管理ユニット：商品の入庫と出庫を記録し、在庫数を更新する。
在庫監視ユニット：現在の在庫レベルを監視し、設定された閾値を下回った場合にアラートを発する。
発注処理ユニット：在庫が不足している商品を特定し、自動的に発注書を作成する。

例題2:

　上記の在庫管理システムにおいて、「在庫監視ユニット」と「発注処理ユニット」間のインターフェース設計を考えます。これらのユニット間でどのようなデータをどのようなタイミングで受け渡すべきか、簡潔に説明してください。

回答例:
　在庫監視ユニットは、定期的に（例：1時間ごと）全商品の在庫レベルをチェックし、閾値を下回った商品のリストを作成します。このリストは、商品ID、現在の在庫数、設定閾値を含み、発注処理ユニットに渡されます。発注処理ユニットは、このリストを受け取ると、各商品の発注量を計算し、発注処理を開始します。

graph LR
    subgraph 在庫監視ユニット
    A[在庫レベル監視] --> B[閾値チェック]
    B --> C{閾値以下?}
    C -->|Yes| D[低在庫リスト作成]
    C -->|No| A
    end
    
    subgraph 発注処理ユニット
    E[低在庫リスト受信] --> F[発注量計算]
    F --> G[発注書作成]
    G --> H[発注実行]
    end
    
    D -->|低在庫リスト転送| E
    
    I[(在庫DB)] --> A
    H -->|更新| I
    
    style 在庫監視ユニット fill:#f9f,stroke:#333,stroke-width:2px
    style 発注処理ユニット fill:#bbf,stroke:#333,stroke-width:2px

　この図は、在庫監視ユニットと発注処理ユニットのインターフェースと主要な処理フローを示しています。以下が主な要素と処理の流れです：

在庫監視ユニット:
- 在庫レベル監視: 定期的に在庫DBから情報を取得し、在庫レベルをチェックします。
- 閾値チェック: 各商品の在庫レベルが設定された閾値以下かどうかを確認します。
- 低在庫リスト作成: 閾値以下の商品があれば、それらをリストアップします。
発注処理ユニット:
- 低在庫リスト受信: 在庫監視ユニットから低在庫リストを受け取ります。
- 発注量計算: 各商品の適切な発注量を計算します。
- 発注書作成: 計算された発注量に基づいて発注書を作成します。
- 発注実行: 作成された発注書に基づいて実際の発注処理を行います。
インターフェース:
- 低在庫リスト転送: 在庫監視ユニットから発注処理ユニットへのデータ転送を示します。
- 在庫DB: 両方のユニットが参照・更新する共通のデータストアです。
データフロー:
- 在庫DBから在庫監視ユニットへの在庫情報の提供
- 在庫監視ユニットから発注処理ユニットへの低在庫リストの転送
- 発注処理ユニットから在庫DBへの更新（発注後の予定在庫数の反映など）

　この図は、二つのユニット間の相互作用と、それぞれのユニット内部の主要な処理ステップを明確に示しています。これにより、システムの動作の流れや、各ユニットの責任範囲が視覚的に理解しやすくなっています。

　実際の実装では、この基本的な設計をベースに、より詳細な機能や例外処理などが追加されることになります。

5. まとめ

　ソフトウェア設計は、ソフトウェア開発プロセスにおいて重要な役割を果たします。ソフトウェア要件定義書を基に、ソフトウェアの構造を決定し、ソフトウェア要素をソフトウェアユニットに分割します。各ユニットの機能仕様を決定し、ユニット間のインターフェースを設計することで、ソフトウェアの全体像を明確にします。

　構造化、部品化、再利用性を考慮しながら、基本機能、入出力、物理データなどの設計を行います。これにより、開発効率の向上、品質の安定化、保守性の向上が図れます。ソフトウェア設計書の作成においては、各要素を明確に記述し、開発チーム全体で共有できるようにすることが重要です。