ソフトウェアエンジニアリングの一般的なレビューノート

特記事項:
この記事は参考用であり、この記事の内容の一部は AI の概要、インターネットでの収集、個人的な実践に基づいています。情報に誤りが含まれている場合は、読者の皆様は批判や修正を歓迎します。この記事は学習とコミュニケーションのみを目的としており、商業目的ではありません。

ソフトウェアエンジニアリングコースのレビュー概要

1. 基礎知識のポイント

1. ソフトウェアエンジニアリングの概念と目標

ソフトウェアエンジニアリングの定義

ソフトウェアエンジニアリングは、工学、科学、数学の原理と方法を使用してコンピュータソフトウェアを開発および保守するための関連技術と管理方法です。1993年のIEEEの定義によれば、ソフトウェアエンジニアリングとは、ソフトウェアの開発、運用、保守の全プロセスに、体系的かつ標準化された測定可能なエンジニアリング手法を適用することであり、それらの手法を研究する学問分野でもあります。

ソフトウェア エンジニアリングは、メソッド、ツール、プロセスという 3 つの主要なコンポーネントで構成されます。

• メソッド:ソフトウェア開発の「ハウツー」テクニックを提供します。プロジェクトの計画と見積もり、システムとソフトウェアの要件分析、ソフトウェア設計、コーディング、テスト、メンテナンスをサポートします。

• ツール:ソフトウェア エンジニアリング手法のための自動または半自動のソフトウェア サポート環境を提供します。統合されたコンピュータ支援ソフトウェアエンジニアリング（CASE）環境が確立されています。

• プロセス:メソッドが使用される順序、提供が必要なドキュメント、品質を確保し変更を調整するために必要な管理、およびソフトウェア開発の各段階のマイルストーンを定義します。

ソフトウェア エンジニアリングの手法、ツール、プロセスはソフトウェア エンジニアリングの 3 つの要素を構成しており、これらの要素が連携してソフトウェア プロジェクトの開発と保守を成功させます。

ソフトウェアエンジニアリングの目標

ソフトウェア エンジニアリングの目標は、指定されたコストとスケジュール内で次の特性を持つソフトウェア製品を開発することです。

1. 変更可能性:ソフトウェアは、新しいニーズや環境に適応するために簡単に変更およびアップグレードできます。

2. 信頼性:ソフトウェアはさまざまな条件下でも安定して実行でき、障害やエラーが発生しにくいです。

3. 有効性:ソフトウェアは、リソースを無駄にすることなく、効率的な方法で意図した機能を完了できます。

4. 理解性:ソフトウェアの構造とコードは理解しやすいため、開発者は保守や改善が容易になります。

5. 保守性:ソフトウェアは、バグの修正、機能の更新、新しいハードウェアまたはソフトウェア環境への適応など、簡単に保守できます。

6. 再利用性:ソフトウェア モジュールまたはコンポーネントを他のシステムまたはモジュールに効果的に適用して、開発効率を向上させ、コストを削減できます。

7. 適応性:ソフトウェアは変化する環境やニーズに適応でき、将来の課題にも対応できる柔軟性と拡張性を備えています。

8. 移植性:ソフトウェアを簡単に移植し、大幅な変更を加えることなく、さまざまなハードウェア プラットフォーム、オペレーティング システム、または環境上で実行できること。

9. トレーサビリティ:ソフトウェア開発およびメンテナンスのプロセスを追跡して、プロジェクトが計画どおりに進行することを確認し、いつでもプロジェクトのステータスと進行状況を把握できる機能。

10. 相互運用性:ソフトウェアは他のソフトウェアまたはシステムと効果的に対話および統合して、データと機能を共有できます。

これらの目標を総合すると、ソフトウェア エンジニアリングの結果がユーザーのニーズを満たし、品質と保守性が高く、開発プロセス中の経済性を維持できることが保証されます。

標準的な定義:ソフトウェア エンジニアリングは、体系的で標準化された測定可能な方法を通じてソフトウェアを開発、保守、管理するエンジニアリング分野です。目標は、ソフトウェアの品質を向上させ、開発コストを削減し、ソフトウェア プロジェクトを予定通りに納品することです。

一般的な説明:ソフトウェア エンジニアリングは家を建てるプロセスに似ており、順序立てた手順と仕様を通じて、ソフトウェアをより効果的に作成、保守、管理できます。目標は、ソフトウェアをより良く、より安価に、そして期限通りに作成することです。住宅を建築するのと同じように、ソフトウェア エンジニアは最終製品の品質と信頼性を確保するために作業を計画する必要があります。

2. ソフトウェア危機の概念と典型的な現象

ソフトウェア危機の概念

ソフトウェアクライシスとは、コンピュータソフトウェアの開発や保守において遭遇する一連の重大な問題を指します。これには、課題の 2 つの主な側面が含まれます。

1. 増大するソフトウェア需要を満たすソフトウェアを開発する方法。
2. 増え続ける既存のソフトウェアをどのように維持するか。

一般的に言えば、ソフトウェア危機の中心的な問題は、需要と供給の不均衡と開発コストの制御不能にあり、その結果、進捗の遅れ、信頼性の低下、メンテナンスの困難が生じます。ソフトウェア危機の典型的な症状は次のとおりです。

ソフトウェア危機の典型的な兆候

1. 見積もりの​​精度の問題:ソフトウェア開発コストとスケジュールの見積もりは不正確であることが多く、プロジェクトが予算を超過して遅延する可能性があります。

2. ユーザー満足度の問題:ユーザーは「完成した」ソフトウェア システムに不満を抱くことが多く、ソフトウェアによって提供される製品とユーザーの期待との間にギャップがあることを示しています。

3. ソフトウェアの品質の問題:ソフトウェア製品の品質は信頼性が低いことが多く、エラーや欠陥が存在する可能性があり、システムの安定性と信頼性に影響を与えます。

4. メンテナンスの困難さ:ソフトウェアはメンテナンス不可能であることが多く、更新、修復、拡張が難しいため、その後のメンテナンスがさらに困難になります。

5. 不十分なドキュメントの問題:ソフトウェアには適切なドキュメントがなく、詳細な説明書やガイドが不足していることが多く、保守担当者にトラブルを引き起こしています。

6. コスト割合の上昇の問題:コンピュータ システムの総コストに占めるソフトウェア コストの割合は年々増加しており、ソフトウェア開発は経済的に持続不可能になっています。

7. 生産性向上が不十分な問題：ソフトウェア開発の生産性向上率がハードウェアの開発速度に追いつかず、コンピュータアプリケーションの普及・深化の流れに大きく遅れをとり、開発の遅れが生じている。

これらの症状は総合的にソフトウェア危機の臨床症状を構成し、急速に増大する需要と複雑さに対処する従来のソフトウェア開発モデルの難しさを浮き彫りにしています。したがって、ソフトウェア工学の開発は、これらの問題を解決し、ソフトウェア開発の品質と効率を向上させることを目的としています。

概念の標準定義:ソフトウェア クライシスとは、ソフトウェア開発プロセス中に遭遇する一連の深刻な問題や課題を指し、その結果、計画どおりにプロジェクトを完了できなくなり、品質が不安定になり、リソースが過剰に消費されます。ソフトウェア危機は通常、不明確な要件、スケジュールの遅延、コストの超過などとして現れ、ソフトウェア エンジニアリングの実現可能性と信頼性を脅かします。

概念の一般的な説明:ソフトウェア クライシスは、住宅の建設中に元の設計図に多くの問題があることが判明するようなものです。プロジェクトは期限内に完了できず、コストは予算を超えます。これは、ソフトウェア開発において、不明確な要件、遅延、開発コストの超過などによりプロジェクトが行き詰まる可能性があることを意味します。

典型的な症状の標準的な定義:ソフトウェア危機の典型的な症状には、需要の膨張、プロジェクト スケジュールの遅れ、品質の不安定、予算を超える開発コスト、ユーザーの期待に応えられないことが含まれますが、これらに限定されません。これらの問題は、ソフトウェア プロジェクトの失敗、または要件を満たすソフトウェア製品を効果的に提供できなくなる可能性があります。

典型的な症状の一般的な説明:ソフトウェア危機は、ソフトウェア プロジェクトに一連の問題をもたらす嵐のようなものです。家を建てるときと同じように、当初の設計図に多くの間違いが発覚し、工事の進捗が遅れたり、コストが増大したりすることがあります。ソフトウェア開発では、これはプロジェクトの要件がますます複雑になることを意味し、スケジュールの遅延、品質の不安定化、開発コストの増大につながり、最終的には予定通りに納品できない可能性があります。

3. ウォーターフォールモデルの概念と特徴

ウォーターフォール モデルは古典的な伝統的なソフトウェア エンジニアリング プロセス モデルであり、ウォーターフォール フロー プロセスと同様に、6 つのソフトウェア エンジニアリング活動の接続順序を規定します。

1. 入力を受け入れる:前のアクティビティからこのアクティビティの作業オブジェクトを入力として受け入れます。
2. 実装アクティビティのコンテンツ:この入力を使用して、アクティビティで完了する必要があるコンテンツを実装します。
3. 作業結果の生成:このアクティビティの作業結果を提供し、出力として次のアクティビティに渡します。
4. 作業のレビュー:このアクティビティのために実施された作業をレビューします。作業が確認された場合は、次のアクティビティに進みます。そうでない場合は、フィードバックと修正のために前のアクティビティまたは前のアクティビティに戻ります。

ウォーターフォール モデルの利点:

1. 効果的な管理図:ソフトウェア開発計画の策定、コスト予算の実行、開発部隊の組織化に役立つ明確な開発フローチャートを提供します。

2. 段階的なレビューと文書管理:レビューと文書管理は各段階で実行され、開発プロセス全体を効果的に監視および指導するのに役立ち、ソフトウェア製品が予定通りに納品され、期待される品質要件を満たしていることを保証します。

3. プロジェクトの制御と管理:ウォーターフォール モデルはプロジェクトに明確な段階を提供し、プロジェクトの制御と管理をより直感的で操作しやすくします。

ウォーターフォール モデルの欠点:

1. 柔軟性の欠如:ウォーターフォール モデルは厳密な段階順序を必要とし、変更に対する柔軟な対応に欠けており、プロジェクト要件の変化に適応することが困難です。

2. 要件の問題を解決できない:ソフトウェア要件が不明瞭、不正確、または継続的な改善が必要な場合、ウォーターフォール モデルでは要件の変更を後の段階で実装することが難しいため、開発が困難になる可能性があります。

3. 再利用と統合のサポートが不十分:ウォーターフォール モデルでは、コンポーネントの再利用と複数の開発アクティビティの統合をサポートすることが困難であり、これは現代のソフトウェア開発における重要な課題です。

ウォーターフォール モデルのこうした欠点を解決するために、近年、柔軟性、反復開発、変化への機敏な対応に重点を置いた、スパイラル モデルやプロトタイプ モデルなど、他のさまざまなソフトウェア開発モデルが登場しています。要件にあります。これらのモデルは、複雑で急速に変化するソフトウェア開発環境により適応します。

ウォーターフォールモデルの概念:

標準の定義:
ウォーターフォール モデルは、ソフトウェア エンジニアリングの分野における古典的な開発手法です。プロセスは線形かつ順次であり、段階に分割され、各段階の出力が次の段階の入力として使用されます。ウォーターフォール モデルの主な段階には、要件分析、システム設計、実装、テスト、展開、メンテナンスが含まれます。

一般的な説明:
ウォーターフォール モデルは滝のようなもので、開発プロセスは一定のプロセスに沿って段階的に進み、各段階には特定のタスクと目標があります。水の流れが元に戻らないのと同じで、一度次の段階に入ると前の段階に戻ることは困難です。このアプローチにより、プロジェクトの明確な計画と実行が容易になりますが、開始する前に要件を比較的完全に理解する必要もあります。

4. ラピッドプロトタイピングモデルの特徴

• 標準の定義:プロトタイプは、ターゲット ソフトウェア システムのいくつかの重要な側面を実装する運用モデルです。ラピッドプロトタイピングモデルは、システムのプロトタイプを迅速に作成してユーザーのニーズを理解し、フィードバックを収集し、これに基づいてシステムを段階的に改善することです。
• 一般的な説明:ラピッド プロトタイピング モデルは予備モデルを作成するようなもので、ユーザーがソフトウェアのプロトタイプを事前に確認できるため、要件をより適切に調整および改善できます。
  
  プロトタイプの利点

1. ユーザーとソフトウェア アナリストの学習を促進する

• 利点:プロトタイプ モデルは、ユーザーとソフトウェア アナリストの両方が互いの分野の知識を学ぶのに役立ちます。
• 詳細な説明:視覚的なプロトタイプを迅速に生成することで、ユーザーはソフトウェア システムの潜在的な機能とインターフェイスをより直観的に理解できます。同時に、ソフトウェア アナリストはユーザーのニーズを深く理解し、ユーザーと開発チーム間のコミュニケーションと協力を促進できます。

2. 統一された要件の理解と定義

• 利点:プロトタイプ モデルは、ユーザーと開発者がソフトウェア要件の知識と理解を統一するのに役立ち、要件の定義レビューを容易にします。
• 詳細な説明:プロトタイプを示すことで、ユーザーと開発者はシステムがどのように見え、動作するかをより明確に理解できます。これにより、理解のあいまいさがなくなり、要件の正確性が保証されます。レビュープロセスでは、プロトタイプを通じてチームメンバーが要件をより詳細に議論および検証できるため、要件定義の品質が向上します。

プロトタイプ モデルのこれらの利点により、プロトタイプ モデルは、要件の不確実性に対処し、チームワークを促進するための強力なツールになります。ただし、プロトタイプ モデルを使用する場合は、タイムリーなユーザー フィードバックと効果的なコミュニケーションが成功を確実にするための重要な要素であることに注意することが重要です。

ラピッドプロトタイピングモデルの特徴:

標準定義:

1. 迅速な設計:ラピッド プロトタイピング モデルは、システムのプロトタイプを迅速に作成して早期にユーザー フィードバックを取得することに重点を置いた、迅速な設計および反復的なソフトウェア開発方法です。
2. ユーザーの関与:ユーザーの関与は、プロトタイプに基づいてフィードバックを提供し、システム要件の改善に役立てることができるため、重要な機能です。
3. 反復開発:プロトタイプはシステム設計の検証と改善に使用され、複数回の反復を通じて徐々に最終製品に進化します。
4. 柔軟性:ラピッド プロトタイピング モデルは柔軟性が高く、開発プロセス中に要件と設計を柔軟に調整できます。

一般的な説明:

1. 青写真を描く:家を建てる前に描く簡単なモデルと同様、ラピッド プロトタイピングでは、設計アイデアを迅速に提示します。
2. ユーザーと握手する:ユーザーはもはや傍観者ではなく、プロトタイプと対話し、最終製品が期待に応えているかどうかを確認するためにフィードバックを提供します。
3. 繰り返しの構築:ブロックを積み上げるように、プロトタイプを継続的に調整および改善することで、最終的なソフトウェア製品が徐々に形成されます。
4. 柔軟性:柔軟性が重要であり、ユーザーのフィードバックやニーズに基づいてプロトタイプを調整し、変化するプロジェクト要件に適応できます。

5.スパイラルモデルの基本的な考え方

• 標準の定義:スパイラル モデルは、ラピッド プロトタイピングの反復特性とウォーターフォール モデルの体系的かつ厳密なモニタリングを考慮した進化的なソフトウェア開発プロセス モデルです。スパイラルモデルの最大の特徴は、他のモデルにはないリスク分析を導入し、重大なリスクを除去できない場合にソフトウェアを停止する機会を与え、損失を軽減できることです。同時に、各反復段階でプロトタイプを構築することは、スパイラル モデルがリスクを軽減する方法です。スパイラル モデルは、大規模で高価なシステム レベルのソフトウェア アプリケーションに適しています。【1】鄭仁潔・『ソフトウェアエンジニアリング入門』：機械工業新聞社、2010年
• 一般的な説明:スパイラル モデルは上昇し続ける螺旋梯子のようなもので、反復ごとに考えられるリスクを考慮して解決しながら 1 レベルずつ上がっていきます。
  

スパイラル モデルは、ウォーターフォール モデルとプロトタイプ モデルの利点を組み合わせ、新しいコンポーネントであるリスク分析を導入したソフトウェア開発モデルです。スパイラルモデルの構成要素と特徴は以下のとおりです。

モデル構成

1. 要件定義:

   • 需要分析テクノロジーを使用してアプリケーション分野を理解し、事前のユーザーニーズを取得し、プロジェクト開発計画を策定します。

2. リスク分析:

   • 初期要件や改善提案に基づいてオプションを検討し、リスクを排除または軽減する方法を提供します。

3. プロジェクトの実施:

   • 前に紹介したプロトタイプ構築方法を使用して、既知のユーザーのニーズに基づいて迅速なプロトタイプを生成します。

4. レビュー：

   • プロトタイプをユーザーに提出して使用してもらい、改善のためのフィードバックを求めます。ユーザーがプロトタイプがニーズを満たせると判断した場合は実行段階に入りますが、そうでない場合は開発者がユーザーの緊密な協力を得ながら新たなユーザーニーズを整理し、次のプロトタイプ進化計画を策定します。

モデルの特徴

1. 総合的な利点:

   • スパイラル モデルは、ウォーターフォール モデルとプロトタイプ モデルの利点を体現しており、線形逐次開発プロセスと高速反復プロトタイプ構築方法を統合しています。

2. 新しい成分の追加 - リスク分析:

   • スパイラル モデルでは、重要な要素としてリスク分析が導入されています。各反復のリスクを分析することで、潜在的な問題を早期に特定して解決できるため、プロジェクトの成功率が向上します。

3. ループの反復:

   • スパイラル モデルはスパイラルの形で反復され、各スパイラル円はリスク分析、プロトタイプの構築、ユーザー レビューなどの開発段階を表します。この反復的なアプローチは、変化する要件に適応し、タイムリーにリスクに対処するのに役立ちます。

スパイラル モデルは、リスク分析と反復開発を導入することにより、プロジェクトの適応性と柔軟性を向上させます。大規模で複雑でリスクの高いプロジェクトに適しており、プロジェクトの成功をより確実に保証します。
スパイラルモデルの利点と問題点

アドバンテージ

1. ウォーターフォール モデルとプロトタイプの利点を統合します。

   • スパイラル モデルは、ウォーターフォール モデルの構造化プロセスとプロトタイプ モデルの反復的かつ迅速な開発を組み合わせたもので、両方の利点を組み合わせています。

2. 要件分析とソフトウェア実装は相互依存しており、密接に関連しています。

   • スパイラル モデルは、開発プロセス中の要件の正確な理解とタイムリーな調整を確実にするために、要件分析とソフトウェア実装の相互依存性を強調します。

3. 意思決定へのユーザーの参加:

   • プロトタイピング段階でのユーザー参加により、ユーザーはソフトウェア開発のすべての重要な決定に参加できるようになり、最終的なソフトウェア製品がユーザーの期待に応えることができるようになります。

4. 形式的要件の仕様:

   • プロトタイプは、実行可能な要件仕様の形式として、ユーザーと開発者が共同で理解しやすく、その後の開発の基礎として機能し、明確な開発の方向性を提供することもできます。

5. 便利なプロジェクト管理:

   • これにより、プロジェクト マネージャーは管理上の決定をタイムリーに調整することが容易になり、ソフトウェア開発のリスクが軽減されます。

質問

1. 比較的長い開発サイクル:

   • スパイラルモデルは他のモデルに比べて開発サイクルが長いため、繰り返しが多すぎると開発コストが増加し、提出時期が遅れる可能性があります。

2. 開発コストが高い:

   • プロトタイプの進化プロセス中に、重要なユーザーのニーズと主要な改善点を特定できないと、人的資源、資金、時間の不必要な損失につながる可能性があります。

スパイラルモデルの利点は、異なるモデルの利点を組み合わせることですが、実際の適用では、プロジェクトの特性に応じて開発サイクルとコストの関係を比較検討する必要があります。

6. ソフトウェアライフサイクルの概念とその段階分け

ソフトウェアのライフサイクル

ソフトウェアのライフ サイクルには、通常のものと同様にライフ サイクル、つまり妊娠、誕生、成長、成熟、死亡の各段階があります。ソフトウェア製品のプロセス全体は、構想から始まり、開発、使用、メンテナンスを経て、最終的に廃止されるまで続きます。ソフトウェアのライフサイクルには、ソフトウェア定義、ソフトウェア開発、ソフトウェアの使用、および保守の 3 つの部分が含まれます。
ソフトウェアのライフサイクルは、実現可能性調査、要件分析、概要設計、詳細設計、実装（コーディング）、テスト、使用、保守、廃止といういくつかの段階に分かれています。

1. 実現可能性調査:

   • 目的: プロジェクトの実現可能性を評価し、追求する価値があるかどうかを判断します。
   • 活動内容：市場調査、技術評価、経済分析等を実施し、プロジェクト実現可能性レポートを作成します。

2. 要件分析：

   • 目標: システムの機能要件とパフォーマンス要件を明確にします。
   • アクティビティ: ユーザーとコミュニケーションし、ユーザー要件を収集および分析し、要件仕様を作成します。

3. システムデザイン：

   • 目標: システムの全体構造とモジュール分割を定義します。
   • 活動: システムの基本フレームワークを設計し、モジュール間のインターフェイスを決定し、概要設計ドキュメントを作成します。

4. きめ細かなデザイン：

   • 目的: システム内の各モジュールの設計を詳しく説明します。
   • アクティビティ: アルゴリズムやデータ構造などの詳細を含む、各モジュールの詳細な設計文書を作成します。

5. 実装 (コーディング) (実装/コーディング):

   • 目標: 設計を実際の実行可能コードに変換します。
   • アクティビティ: コードを作成、テスト、デバッグして、ソフトウェアの実行可能バージョンを作成します。

6. テスト:

   • 目標: ソフトウェアが要件を満たしていることを確認し、バグを見つけて修正します。
   • アクティビティ: 単体テスト、統合テスト、システム テストなどのさまざまなテストを実行します。

7. 使用 (展開):

   • 目標: ソフトウェアをターゲット環境にデプロイして、ユーザーが使用できるようにします。
   • アクティビティ: ソフトウェアのインストール、構成、起動、ユーザー トレーニングとサポートの提供。

8. メンテナンス：

   • 目標: ソフトウェアの適切な機能を維持し、必要な改善を加えます。
   • アクティビティ: バグの修正、新機能の追加、環境の変化への適応など。

9. 退職：

   • 目的: ソフトウェアの廃止戦略を決定し、実装します。
   • アクティビティ: データのアーカイブ、ユーザーへの通知、システムのシャットダウンなど。

各フェーズには独自のタスクとアクティビティがあり、ソフトウェア ライフサイクル管理は、ソフトウェア プロジェクトがスケジュール、品質、コストに従って確実に進行するように支援します。

7. ソフトウェア要件の定義

• 標準の定義:ソフトウェア要件は、システムまたはシステム コンポーネントの機能とパフォーマンス、およびユーザーがシステムに達成してほしい望ましい結果を記述したものです。
• 一般的な説明:ソフトウェア要件は、ソフトウェアが実装すべき機能や達成すべきパフォーマンス レベルなど、ソフトウェアに対するユーザー要件のリストのようなものです。

正確に言うと、ソフトウェア要件は、ビジネス要件、ユーザー要件、システム要件 (機能要件と非機能要件を含む) の 3 つの主要なレベルに分類されます。

1. ビジネス要件：

   • 特性:システムまたは製品に対する組織または顧客の高レベルの期待と目標を反映します。
   • 内容:ビジネスプロセス、戦略的目標、組織のニーズの理解を重視します。

2. ユーザー要件:

   • 特徴:ユーザーの操作と期待に焦点を当て、製品を使用する際にユーザーが完了する必要があるタスクについて説明します。
   • 内容:ユーザー エクスペリエンス、インタラクション、システム動作の期待に焦点を当てます。

3. 機能要件:

   • 機能:ユーザーがタスクを確実に完了できるように開発者が実装する必要があるソフトウェア機能を定義します。
   • 内容:ユーザー インターフェイス、データ処理、セキュリティなど、システムの特定の機能に焦点を当てます。

4. 非機能要件:

   • 特徴:機能面だけでなく、パフォーマンス、信頼性、セキュリティなどにも焦点を当てて、システムの品質特性と制約について説明します。
   • 内容:システムの全体的な品質とパフォーマンスに影響を与える、パフォーマンス要件、セキュリティ標準、ユーザビリティ要件などが含まれます。

これら 3 つのレベルの要件は相互に関連しており、ビジネス要件はユーザー要件をガイドし、ユーザー要件はさらに機能要件と非機能要件に細分化されるため、開発者は達成すべき目標を明確に理解できます。ソフトウェア プロジェクトが期待どおりに進行するためには、要件管理の有効性が非常に重要です。

8. 一般的なソフトウェア要件の取得手法

予備的な要件の抽出はソフトウェア開発プロセスにおける重要なステップであり、一般的に使用されるいくつかの予備的な要件の抽出手法を次に示します。

1. インタビューとミーティング:主要な関係者 (顧客、エンドユーザー、ビジネス アナリストなど) との対面インタビューやミーティングを通じて、洞察、期待、ニーズを獲得します。これにより、ビジネス プロセスとシステムの期待についての洞察が得られます。

2. ユーザーのワークフローを観察する:実際の作業環境でユーザーの操作とプロセスを観察および分析し、潜在的な問題、ボトルネック、改善点を特定します。このアプローチは、実際の要件とユーザー エクスペリエンスの詳細を把握するのに役立ちます。

3. 共同ワーキング グループを設立する:開発チームのメンバー、エンド ユーザー、その他の関係者を共同ワーキング グループに集めます。コラボレーションとディスカッションを通じて、チームは要件を共同で理解し、情報共有を促進し、すべての関係者の期待を確実に考慮することができます。

これらの手法は、多くの場合、複数の観点から正確かつ包括的な要件を収集するために組み合わせて使用​​されます。効果的な事前要件の取得により、その後のシステム設計および開発作業の指針を提供するための強固な要件基盤を確立できます。

9. 機能要件と非機能要件にはどのような側面が含まれますか?

• 機能要件:ユーザーのログイン、データのエクスポートなど、システムに必要な特定の機能を説明します。
• 非機能要件:システムのパフォーマンスと制約 (パフォーマンス、セキュリティ、信頼性など) を説明します。

機能要件:

標準の定義:
機能要件は、システムが特定のタスクを実行する方法、または特定の機能を満たす方法を記述する仕様です。これらは通常、システムの入力、処理、出力に関係し、さまざまな状況でシステムが示すべき動作を記述します。

以下の側面を含みます:

1. 入力要件:システムが受け入れる必要があるさまざまな入力タイプと形式を定義します。
2. 処理要件:システムが入力データを処理し、特定の機能を実行する方法を説明します。
3. 出力要件:システムが入力処理結果を表示または出力する方法を指定します。
4. データ管理:データの保存、取得、更新、削除などの操作を含みます。
5. ユーザー インターフェイス:インターフェイスのデザインやユーザー エクスペリエンスなど、システムがユーザーと対話する方法を定義します。

非機能要件:

標準の定義:
非機能要件は、システムの品質属性と制約を記述します。通常、これらは特定の機能には直接関係しませんが、システムのパフォーマンス、セキュリティ、保守性などの側面に焦点を当てています。

以下の側面を含みます:

1. パフォーマンス要件:応答時間、スループットなどを含む。
2. セキュリティ要件:データ保護とユーザー ID 認証に関するシステムのセキュリティ要件について説明します。
3. 信頼性/可用性:通常動作時および障害発生時におけるシステムの信頼性と可用性を説明します。
4. 保守性:コードの可読性や拡張性など、システムの保守と変更がどの程度簡単であるかを指定します。
5. 移植性:さまざまな環境に導入お​​よび実行できるシステムの機能を説明します。
6. 規制と標準:システムが準拠する必要がある規制と業界標準が含まれます。

機能要件はシステムが何ができるかに焦点を当てているのに対し、非機能要件はシステムがどのように実行すべきか、どのような条件で動作すべきかに焦点を当てています。これら 2 つを合わせて、包括的なシステム要件仕様を形成します。

10. 実現可能性分析の定義

• 標準定義：実現可能性分析は、市場需要、資源供給、建設規模、プロセスルート、設備選定、環境影響、資金調達、収益性などのプロジェクトの主な内容と裏付け条件に基づいて、技術の観点から分析されます。プロジェクトが投資に値するかどうかについての諮問意見を提供するために、プロジェクト完了後に達成される可能性のある財務的、経済的便益および社会環境への影響を予測するため、その他の側面での調査、分析および比較を実施します。建設の進め方やプロジェクトの意思決定の基礎となる、総合的なシステム分析手法。実現可能性分析は、予測可能で、公平で、信頼性があり、科学的である必要があります。
• 一般的な説明:実現可能性分析は、プロジェクトが実現可能かどうか、リソースを投資する価値があるかどうかを確認するための計画の包括的な調査と見積もりに似ています。

11. ソフトウェアの保守性を向上させるためにはどのようなコーディング標準がありますか?

• コーディング標準の重要性:ソフトウェアを保守するための最初のステップは、読みやすく保守しやすいコードです。
• 保守性を向上させるためのコーディング標準:適切なコメント、命名規則、コードの冗長性の回避など。

ソフトウェアの保守性を向上させるには、コーディング標準を策定し、それに従うことが重要です。コードの可読性、保守性、チームワークの効率を向上させるのに役立つ一般的なコーディング手法をいくつか紹介します。

1. 命名規則:変数、関数、クラスなどに名前を付けるときは、意味があり、明確で一貫性のある命名規則を使用し、単純すぎる名前や曖昧な名前の使用を避けてください。

2. インデントと書式設定:コードのインデント スタイルを統一し、書式設定方法を選択し、チーム全体が同じスタイルに従うようにして、コードの一貫性を向上させます。

3. コメント:他の開発者がコードの意図を理解できるように、コードの重要な部分、アルゴリズムのアイデア、特別な処理などを説明する明確かつ簡潔なコメントを追加します。

4. 関数とメソッドの長さ:関数とメソッドの長さを制御して関数が大きすぎるのを避けると、コードの可読性と保守性が向上します。

5. 例外処理:適切な例外処理メカニズムを追加して、コードが例外を適切に処理し、意味のあるエラー情報を提供できるようにします。

6. モジュール性と単一責任の原則:コードを小さな独立したモジュールに分割し、各モジュールが明確なタスクを担当し、単一責任の原則に従います。

7. コードの再利用:既存のコードを再利用して車輪の再発明を回避し、関数、クラス、モジュールを使用してコードの保守性を向上させます。

8. バージョン管理:バージョン管理システム (Git など) を使用して、コードの変更を追跡し、コード履歴を追跡できるようにし、チームのコラボレーションとコードのロールバックを促進します。

9. 単体テスト:単体テストを作成して実行して、コードの安定性と正確性を確認し、潜在的な問題の検出に役立てます。

10. ドキュメント:他の開発者がコードをすぐに理解して使用できるように、コード ドキュメント、API ドキュメントなどを含む適切なドキュメントを作成します。

これらのコーディング標準は、一貫したコーディング スタイルを形成し、コードのメンテナンスの難しさを軽減し、チームのコラボレーション効率を向上させ、ソフトウェア システムのメンテナンス性を確保するのに役立ちます。

12. ソフトウェア設計の原則

• 設計原則の概要:設計原則は、適切に構造化され保守しやすいソフトウェアを設計するのに役立つ一般的なガイドラインです。
  • 単一責任の原則:クラスには、変更する理由が 1 つだけある必要があります。
  • オープンクローズの原則:ソフトウェア エンティティは、拡張に対してオープンであり、変更に対してクローズである必要があります。
    ソフトウェア設計の原則とは、高品質で保守可能、スケーラブルでわかりやすいソフトウェアの設計を保証するために、ソフトウェア システムを設計する際に従うべきいくつかの基本原則とガイドラインを指します。一般的なソフトウェア設計原則をいくつか示します。

1. 単一責任原則 (SRP):クラスの変更理由は 1 つだけである必要があります。つまり、クラスの責任は 1 つだけである必要があります。

2. オープン/クローズ原則 (OCP):ソフトウェア エンティティ (クラス、モジュール、関数など) は拡張に対してオープンであり、変更に対してクローズである必要があります。つまり、既存のコードを変更せずに拡張機能を通じて新しい関数を追加できます。

3. リスコフ置換原則 (LSP):サブクラスはその基底クラスを置き換えることができ、またプログラムはそれが基底クラスであるかサブクラスであるかを知らなくても実行できる必要があります。

4. 依存性反転原則 (DIP):高レベルのモジュールは低レベルのモジュールに依存すべきではなく、両方とも抽象化に依存する必要があります。抽象化は詳細に依存すべきではなく、詳細は抽象化に依存する必要があります。

5. インターフェイス分離原則 (ISP):クライアントは、使用しないインターフェイスに依存することを強制されるべきではありません。つまり、あるクラスの別のクラスに対する依存関係は、最小のインターフェイスに基づく必要があります。

6. 合成/集約再利用原則 (CARP):コードの再利用を実現するには、継承ではなく合成/集約を使用することが推奨されます。

7. デメテルの法則 (LoD):オブジェクトは、他のオブジェクトについての知識を最小限に抑える必要があります。つまり、オブジェクトは、他のオブジェクトの構造と実装についてできるだけ知識を持たなくてはなりません。

8. 最小驚きの原則 (POLA):システムのユーザーまたはプログラマーがシステムを使用するときに驚かないように設計する必要があります。

9. モジュール性の原則:システムをよりよく理解し、維持し、拡張するために、システムを小さな独立したモジュールに分割します。

10. 高凝集性と低結合性の原理:モジュール内の要素は相互に密接に統合されており、モジュール間の結合度は可能な限り低くする必要があります。

ソフトウェア設計におけるこれらの原則は、保守性、柔軟性、拡張性があり、理解しやすいコードを作成するのに役立ちます。特定のアプリケーション シナリオとプロジェクトのニーズに応じて、一部の原則が強調され、他の原則の適用が弱められる場合があります。

13. 凝集と結合の概念、およびいくつかの一般的な凝集と結合

• 凝集度:モジュール内のパーツが互いにどの程度緊密に関連しているかを指します。
  • 逐次結合:各部分が順番に実行されます。
  • 機能的な結合:すべての部分が連携して機能を完了します。
• 結合:モジュール間の相互依存の度合い。
  • データカップリング:共有データを介した相互作用。
  • 制御結合: 1 つのモジュールが別のモジュールを制御します。

凝集度は、モジュール内のコンポーネントがどの程度密接に接続されているかを示す尺度です。分割統治ではタスクをいくつかの小さなタスクに分解しますが、結合では分解中に関連するコンテンツをまとめることが重視されます。凝集度は、システム内の各モジュールが妥当なプログラム単位であるかどうか、つまり妥当なモジュールであるかどうかを判断するために使用されます。モジュール内のさまざまなコンポーネントが密接に接続されているほど良好であり、これらのコンポーネントが一緒にこのモジュールを形成する必要があることを示します。

結合はモジュール間の相互接続の強度の尺度であり、設計者が設計されたシステムが一連の疎結合モジュールで構成されていることを確認するのに役立ちます。モジュール間の結合の強さは、モジュール間でデータが転送される方法、インターフェイスの複雑さ、転送されるデータの種類によって異なります。

いくつかの一般的な結合と結合:

1. 逐次結合:各モジュール要素は実行順序に従って密接に接続されており、ある要素の出力は別の要素の入力として機能します。この結合は通常、一連のプロセスを完了するために行われます。

2. 機能的結合:モジュール内の要素は同様の機能を実行し、特定のタスクを完了するために相互に関連しています。これは高度な凝集度であり、モジュール内の各要素は同じ機能を中心に展開します。

3. 通信の凝集性:モジュール内の要素は同じデータを共有し、メッセージを渡すことによって相互に通信します。この凝集度は、モジュール内の要素間で情報が共有される程度を測定します。

4. 手続き的結合:モジュール内の要素は特定の論理順序で実行されますが、相互の関連性は弱くなります。この凝集度は低く、モジュール内の要素は特定の順序でのみタスクを実行します。

5. 偶然の結合:モジュール内の要素は互いに直接関連していませんが、歴史的またはその他の理由でのみ同じモジュールに配置されます。これは最小限の凝集レベルです。

6. 密結合:異なるモジュール間の依存関係が強く、1 つのモジュールへの変更が他のモジュールに影響を与える可能性があります。密結合システムは変更や保守が困難です。

7. 疎結合:異なるモジュール間の依存関係は弱く、1 つのモジュールへの変更が他のモジュールに影響を与える可能性はほとんどありません。疎結合システムは、より柔軟で保守しやすくなります。

ソフトウェア設計では、理解、変更、保守が容易なシステムを作成するために、高い凝集性と低い結合性を追求します。合理的な結合と結合関係は、システムの品質と拡張性の向上に役立ちます。

14. ソフトウェア詳細設計およびソフトウェア概要設計の考え方と主な作業

• ソフトウェア詳細設計:各モジュールの実装方法を具体的に説明する設計フェーズ。
  • 主なタスク:データ構造、アルゴリズム、インターフェイスなどの詳細を定義します。
• ソフトウェア概要設計:システム全体の構造とモジュール間の関係を記述する設計フェーズ。
  • 主なタスク:システム モジュールを分割し、モジュール間のインターフェイスを定義します。

ソフトウェア詳細設計とソフトウェア概要設計の概念と主なタスク:

1. ソフトウェアのハイレベル設計:

   • 概念:ソフトウェア アウトライン設計は、要件分析の後、全体的なソフトウェア設計の前の段階です。主な目標は、システムの全体構造とモジュール間の関係を定義し、概要を示し、システム設計が要件と一致していることを確認することです。要件。

   • メインミッション:

     • アーキテクチャの策定:モジュール分割、インターフェイス、モジュール間のデータ フローなど、システム全体の構造を決定します。
     • モジュール機能の定義:各モジュールの基本的な機能と責任を説明し、モジュール間の連携の概要を説明します。
     • データ構造の決定:システムで使用される主なデータ構造と、モジュール間でデータがどのように転送および処理されるかを決定します。
     • インターフェイス仕様の作成:入力パラメータ、出力パラメータ、呼び出しメソッドなど、モジュール間のインターフェイス仕様を定義します。
     • システムパフォーマンスの決定:応答時間、スループットなど、システムのパフォーマンス要件の大まかな評価。
     • 予備テスト計画を作成する:概略設計を検証およびテストする方法を計画します。

2. ソフトウェアの詳細設計:

   • 概念:詳細なソフトウェア設計は、概要設計の後、コーディングの前の段階であり、主なタスクは、概要設計モジュールをさらに改良し、各モジュールの内部実装の詳細を明確にし、プログラマに具体的な開発ガイダンスを提供することです。

   • メインミッション:

     • モジュールの内部設計:データ構造、アルゴリズム、データ フローなどを含む、各モジュールの内部構造の詳細な説明。
     • インターフェイスの改良:モジュール間のインターフェイスをさらに改良し、関数、プロシージャ、クラスなどの詳細な仕様を定義します。
     • データ構造設計:データの編成、保存、アクセス方法など、モジュール内で使用される特定のデータ構造を定義します。
     • アルゴリズム設計:モジュールに含まれる特定のアルゴリズムを定式化して、パフォーマンスと機能の要件が確実に満たされるようにします。
     • エラー処理と例外の設計:システムの安定性を確保するために、エラーや例外に直面したときのシステムの処理メカニズムを定義します。
     • リソース管理設計:システムがコンピューティング リソース、ストレージ リソース、ネットワーク リソースなどをどのように管理および利用するかを決定します。
     • プログラミング言語とツールの選択:適切なプログラミング言語と開発ツールを選択し、プロジェクトのニーズと制約に適合していることを確認します。

ソフトウェア概要設計とソフトウェア詳細設計は、どちらもソフトウェア エンジニアリングの設計フェーズの重要な要素であり、ソフトウェア プロジェクトが計画どおりにスムーズに進行し、シ​​ステムの品質と保守性を向上させるのに役立ちます。

15. ソフトウェアテストの定義

• 標準の定義:ソフトウェア テストとは、ソフトウェア システムまたはアプリケーションを実行して、ソフトウェア開発プロセス中に指定された要件、機能、およびパフォーマンスの標準を満たしているかどうかを検証するプロセスを指します。ソフトウェア テストの目的は、ユーザーに提供する前に、潜在的なエラーや欠陥を見つけて、ソフトウェアが高品質、安定性、信頼性を備えていることを確認することです。
• 百度百科: ソフトウェアテスト（英語: Software Testing ）とは、ソフトウェアがユーザーのニーズを満たしているかどうかを、手動で操作する（手動テスト）、またはソフトウェアを自動的に実行する（自動テスト）ことによって確認するプロセスのことです。

16. ホワイトボックステストとブラックボックステストの主な考え方

• ホワイト ボックス テスト:コードの内部構造に基づいて、プログラム ロジックと内部パスに焦点を当てたテスト。
• ブラックボックステスト:内部実装の詳細を無視して、ソフトウェアの機能とユーザーのニーズに基づいたテスト。
• 主なアイデア:ホワイト ボックスは内部ロジックに焦点を当て、ブラック ボックスは外部の動作に焦点を当てます。

ホワイト ボックス テストとブラック ボックス テストの主な考え方は次のとおりです。

1. ホワイトボックステストの主なアイデア:

   • 概念:ホワイトボックス テストは、構造テストまたはロジック駆動テストとも呼ばれ、ソフトウェア内の論理構造、コード、アルゴリズムのテストに焦点を当てています。テスト担当者は、プログラムの各論理パスをカバーするテスト ケースを設計するために、テスト対象のソフトウェアの内部実装を理解する必要があります。

   • 本旨：

     • 透明性:ホワイトボックス テストではソフトウェアの内部構造が検査され、テスターはテスト対象のソフトウェアのソース コード、アルゴリズム、データ構造をより詳細に理解できます。
     • 包括的なテスト カバレッジ:ホワイトボックス テストの目標は、すべての論理パスを確実にテストして、最大のテスト カバレッジを達成することです。
     • パスのテスト:ループ、条件ステートメント、分岐ステートメントなど、プログラムの各論理パスをテストして、考えられるエラーを見つけます。
     • コード カバレッジ:ホワイトボックス テストは通常​​、ステートメント カバレッジ、ブランチ カバレッジ、パス カバレッジなどのコード カバレッジを対象とします。

2. ブラックボックステストの主なアイデア:

   • 概念:ブラック ボックス テストは、内部実装の詳細を考慮せずに、ソフトウェアの機能と動作をテストすることに重点を置いています。この場合、テスターはソフトウェアを「ブラック ボックス」として扱い、入力と出力の関係のみを考慮します。

   • 本旨：

     • 機能の独立性:ブラック ボックス テストでは、ソフトウェアの内部実装の詳細が無視され、ソフトウェアが独立した機能モジュールとして扱われるため、テスターはソフトウェアの内部ロジックを知る必要がありません。
     • ユーザーのニーズに基づく:ブラック ボックス テストの設計はユーザーのニーズとシステム仕様に基づいており、ソフトウェアが指定された機能と性能の基準を満たしているかどうかを検証するテスト ケースが設計されています。
     • 入出力関係：テスターは適切なデータを入力し、ソフトウェアの出力を観察して、ソフトウェアが仕様通りに正常に動作するかどうかを確認します。
     • ユーザーの観点:ブラック ボックス テストは主にユーザーの観点から開始され、ソフトウェアの外部動作、インターフェイス、および相互作用に焦点を当てます。

全体的な比較:

• ホワイト ボックス テストとブラック ボックス テストの選択:ホワイト ボックス テストとブラック ボックス テストのどちらを選択するかは、通常、テストの目的、テスト段階、テスターの役割によって異なります。一般に、ホワイトボックス テストは主に単体テストと結合テストのフェーズで使用され、ブラック ボックス テストは主にシステム テストと受け入れテストのフェーズで使用されます。

• 補完性:これら 2 つのテスト方法は通常、ソフトウェア テストにおいて補完的であり、これらを組み合わせて使用​​することで、内部ロジックとユーザー ニーズの両方を考慮してソフトウェアを包括的にカバーすることができます。

17. ユースケース図とその使用法を理解する

• ユースケース図の定義:システムと外部エンティティ (通常はユーザー) の間の機能的な関係を説明するために使用されます。
• 使用法:システムの機能要件、およびシステムとユーザー間の対話を視覚化して理解するために使用されます。

ユースケース図の理解と使用:

概念:
ユースケース図とは、システムの機能要件を記述するために使用されるUML(統一モデリング言語)図であり、主にシステム内の各ユースケース(Use Case)と、そのユースケースに参加する外部エンティティ(Actor)を表示します。 . . ユースケース図は、システムの機能の概要を示し、システムが外部エンティティとどのように対話するかを理解するために使用されます。

主な要素:

1. ユースケース:ユースケースはシステム内の機能単位を表し、通常はシステムの特定の機能またはユーザータスクに対応します。
2. アクター:アクターは、システムの外部のエンティティ (人、他のシステム、または外部コンポーネントなど) を表し、システムの 1 つ以上のユースケースと対話します。
3. 関係:ユースケースと参加者の間の関係を説明するために使用されます。これには、関係、拡張関係、一般化関係などが含まれます。

使用：

1. 要件分析:ユースケース図は、チームがシステムの機能要件を理解し、ユーザーとシステム間の対話を把握するのに役立つように、システム要件分析段階でよく使用されます。

2. システム設計:ユースケース図はシステム設計フェーズをサポートするために使用でき、設計者がシステムの機能境界を決定し、主要なユースケースとアクターを特定するのに役立ちます。

3. コミュニケーション ツール:ユース ケース図は、プロジェクト チーム、顧客、その他の関係者にシステム機能の概要を提供する、シンプルで直感的なコミュニケーション ツールです。

4. テスト ケースの設計:ユース ケース図はテスト ケース設計の基礎を提供し、テスト担当者がシステムの主な機能を理解して効果的なテスト ケースを作成するのに役立ちます。

5. システムの進化:システムが進化するにつれて、ユースケース図は、チームが新機能の導入と既存の機能の変更をよりよく理解し、管理するのに役立ちます。

6. ドキュメントの作成:ユース ケース図は、ユーザーと開発者にシステムの全体的な理解を提供するために、ユーザー マニュアル、システム仕様、その他のドキュメントを作成するためによく使用されます。

例：

ユースケース図例1：オンライン書籍ショッピングシステム

@startuml
left to right direction
actor Customer
actor Admin
rectangle "Online Bookstore" {
  Customer --> (Browse Books)
  Customer --> (Add to Cart)
  Customer --> (Checkout)
  Admin --> (Manage Inventory)
}
@enduml

この例は、顧客と管理者の 2 人の参加者がいるオンライン書籍ショッピング システムを表しています。使用例には、「書籍を閲覧する」、「書籍をカートに追加する」、「注文をチェックアウトする」などがあります。

ユースケース図の例 2: シンプルな銀行システム

@startuml
left to right direction
actor Customer
actor BankTeller
rectangle "Simple Banking System" {
  Customer --> (View Balance)
  Customer --> (Withdraw Money)
  Customer --> (Transfer Money)
  BankTeller --> (Manage Accounts)
}
@enduml

この例は、顧客と銀行窓口係という 2 人の参加者がいる単純な銀行システムを表しています。ユースケースとしては「残高確認」「出金」「送金」などがあり、銀行窓口では「口座管理」が可能です。

上記のコードをオンライン UML エディター ( PlantTextやPlantUML Editorなど) に貼り付けて実行し、ユースケース図を生成できます。ネイティブ UML ツールを使用する場合は、コードを .plantuml ファイルとして保存し、ツールで開くこともできます。

18. データフロー図を理解して使用する

• データ フロー ダイアグラムの定義:システム内でデータがどのように流れるかを表すグラフィカル ツール。
• 用途:システム内のデータ処理プロセスを理解し、設計と分析を支援するために使用されます。

データ フロー図は、データ フローと処理に重点を置いた情報システム モデリング手法です。IPO モデル (入力-処理-出力モデル) に基づいて、ソフトウェアの機能は、入力データを出力データに変換する、データの形式変換のプロセスとして見ることができます。データ フロー ダイアグラム モデリングの本質は次のとおりです。

1. データの転送と変換:

   • 特徴:データ フロー図は、主にシステム内のデータの転送とそれに対応する変換プロセスに焦点を当てています。
   • 目的:データがある状態から別の状態にどのように流れ、一連の遷移を通じて変化するかを明らかにします。

2. 上から下に向かって、徐々に精製および分解します。

   • 特徴:データフロー図は、システムの各部分を全体から詳細に徐々に分解するトップダウン分解方法を採用しています。
   • 目的:段階的な分解を通じて、複雑なシステムの問題をより管理しやすく理解しやすいモジュールに分解することで、システムの機能とプロセスを詳細に把握するのに役立ちます。

3. 情報処理システムの構成：

   • 概念:情報処理システムは、データの流れと一連の変換で構成されます。
   • 機能:変換は、システムによって実行されるさまざまな機能、つまり入力データ ストリームを出力データ ストリームに変換するプロセスを定義します。

データ フロー図を通じて、アナリストはシステムのデータ フローを洞察し、重要な変換プロセスを特定し、システムがユーザーのニーズを満たしていることを確認できます。この方法により、ソフトウェアの機能要件を明確に提示でき、システムの設計と開発に強力なガイダンスを提供できます。

19. クラス図とその使用法を理解する

• クラス図の定義:システム内のクラスとクラス間の関係を表すために使用されます。
• 使用法:オブジェクト指向設計で、クラスのプロパティ、メソッド、および関係を表すために使用されます。

UML クラス図 (組み合わせ、集約、関連付け、依存関係)

UML クラスはドメインの概念モデルを表します

UML では、概念はクラスを通じて表現され、クラス図はドメインの概念モデルを表示します。要件分析の初期段階では、すべてのクラスの属性とメソッドを一度に列挙する必要はありません。最初はクラス名のみが必要ですが、分析と設計が進むにつれて、属性リストとメソッドリストが徐々に改善されます。

UML クラスの 3 つの部分:

1. クラス名
2. 物件一覧
3. メソッドリスト

要素の形状を図で表現します。

UML クラス間の関係には、主に継承、集約、関連付け、依存関係が含まれます。継承とは、サブクラスが親クラスの属性と操作を再利用することを意味します。サブクラスのオブジェクトは親クラスのオブジェクトでもあります。これは一般化と呼ばれることもあります。

20. クラス間の関係を理解する

• クラス間の関係の概要:関連、集約、結合、継承、その他の関係を含みます。
• 使用法:システムのモジュール性と保守性を促進するためにクラス間の関係を定義するために使用されます。
  クラス間の集約関係は、現実世界の部分と全体の関係をシミュレートします。
  # UML の集計関係

UML では、集計関係を次の 2 つのタイプに分類します。

1. 通常の集約関係:コンポーネント オブジェクトは、複数の全体オブジェクトに同時に参加できます。

2. 構成関係:構成要素オブジェクトは常にクラス全体の 1 つのオブジェクトにのみ参加するように制限し、構成要素クラスのオブジェクトとクラス全体のオブジェクトが共存します。
   

# 接続関係

関連関係は、2 つのクラスのオブジェクト間にメッセージ送信用の安定したチャネルがあることを示します。例えば、履修登録管理システムでは、「学生」クラス、「教員」クラス、「科目設定」クラスが関連付けられています。「科目設定」は、学生や教員の科目選択に関わるものであるため、学生と教師はコース設定関連情報を照会する必要があります。

通常、2 つのクラスのオブジェクト間には定量的な対応関係があり、これはビジネス ルールの具体的な表現です。分析や設計がある程度進んだ段階では、「コース設定」の各オブジェクトに10以上、以下の要素を持たせるという意味で、集約・構成・関連性の表現の横に明示する必要があります。コース選択学生は50名。

# 依存関係

依存関係とは、依存クラス B のオブジェクトが依存クラス A のオブジェクトにメッセージを送信する必要があり、依存クラス A を依存クラス B の演算の仮パラメータ型として使用できることを意味します。依存関係は、操作が完了すると消える一時的なメッセージング チャネルです。

たとえば、「Order」パッケージ内のクラスは、「Database Interface」パッケージ内のクラス（インターフェース）にのみ依存するため、関連付け関係を確立する必要はありません。依存関係は関連付けを弱めることであり、依存クラスの変更が依存クラスに影響を与えることを意味します。

依存関係の強化が結合、結合の強化が集合、集合の強化が合成である。

21. ソフトウェア設計はどの 2 つの段階に分けられますか?

• ステージ区分：
  • 設計フェーズの概要:システム全体の構造とモジュールの関係を説明します。
  • 詳細設計フェーズ:各モジュールの実装内容を詳細に説明します。

ソフトウェア設計は通常、次の 2 つの主要なフェーズに分けることができます。

1. 概要設計 (上位設計):

   • 概念:概要設計段階は、需要分析を経たシステム全体の高度な計画と設計です。主に、システムの全体構造、モジュール分割、モジュール間のインターフェイス定義、データ フローと制御フローの設計などの高レベルの構造問題に焦点を当てます。
   • タスク:概要設計段階で、設計チームはシステムの主要モジュール、それらの間の関係、およびシステムの全体的なフレームワークを決定する必要があります。この段階での設計上の決定は、システム全体のアーキテクチャに影響を与え、詳細な設計の基礎となります。

2. 詳細設計 (低レベル設計):

   • コンセプト：詳細設計フェーズでは、概要設計を基に、システム内の各モジュールをより具体的に設計します。アルゴリズムの選択、データ構造の具体的な実装、関数の定義など、モジュール内の実装の詳細に焦点を当てています。
   • タスク:詳細設計段階では、設計チームは各モジュールの機能と実装方法をさらに明確にし、具体的なアルゴリズムとデータ構造を決定し、プログラマーが詳細設計に基づいて具体的な実装を実装できるように関数とインターフェイスを定義する必要があります。コーディング段階。

これら 2 つの段階は、ソフトウェア開発ライフ サイクルで重要な役割を果たします。概要設計では、システムの全体的なフレームワークと構造が提供され、詳細設計のガイダンスが提供されます。一方、詳細設計では、各モジュールの品質を確保するためのコーディングに関する具体的なガイダンスが提供されます。 . 機能と実装は詳細に計画されます。これら 2 つの段階での設計上の決定は、ソフトウェアの品質、保守性、パフォーマンスに直接影響します。

22. ユーザーインターフェイス設計の重要な原則

• 主な原則:
  • 一貫性:一貫したユーザー エクスペリエンスを提供するには、インターフェイス要素に一貫性がある必要があります。
  • 可視性:ユーザーが必要とする機能と情報が見える必要があります。
  • フィードバック:ユーザーにタイムリーかつ明確な運用フィードバックを提供します。

ユーザー インターフェイスのデザインはソフトウェア開発の重要な部分であり、ユーザー エクスペリエンスとソフトウェアの使いやすさに直接影響します。ユーザー インターフェイス設計の重要な原則をいくつか示します。

1. 可視性:

   • 定義:システム内の操作と機能は視覚的に見える必要があり、ユーザーは現在実行できる操作を明確に理解できる必要があります。
   • 実装:明確なラベル、アイコン、メニューを使用して、ユーザーがインターフェイス要素の機能を直感的に識別して理解できるようにします。

2. 一貫性：

   • 定義:インターフェイスの設計要素はシステム全体で一貫しており、同様の外観と動作を提供し、ユーザーが信頼できる使用パターンを確立できるようにする必要があります。
   • 実装:色、フォント、ボタンのスタイル、その他の要素を統一して、同様の機能を持つ操作がインターフェイスのさまざまな部分で同様の方法で表示されるようにします。

3. フィードバック：

   • 定義:タイムリーなフィードバックを提供して、操作がシステムに受け入れられたことをユーザーに通知し、操作のステータスと結果に関する情報を提供します。
   • 実装:プロンプト、アニメーション、ステータス バーなどを使用して、操作の結果と現在のシステム ステータスをユーザーに明確に表示します。

4. エラー防止:

   • 定義:設計時に起こり得るユーザーエラーを考慮し、これらのエラーの影響を防止または軽減するための措置を講じます。
   • 実装:ユーザーが入力エラーを回避し、起こり得るエラーを修正できるように、明確な識別情報とヘルプ情報、および適切な検証メカニズムを提供します。

5. シンプルさ:

   • 定義:ユーザーがシステムを簡単に理解して使用できるように、インターフェイスは簡潔かつ明確である必要があり、複雑な要素や機能が多すぎるのを避けます。
   • 実装:不要な機能を合理化し、よく使用される操作を目立つ場所に配置し、乱雑で過度に複雑なレイアウトを避けます。

6. 柔軟性と効率性:

   • 定義:さまざまなユーザーのニーズや作業スタイルを満たすショートカット キーやカスタム オプションなどを提供し、ユーザーが複数の方法でタスクを実行できるようにします。
   • 実装:ユーザーがシステムをより効率的に使用できるように、ショートカット キー、検索機能、カスタム設定などを提供します。

7. 予測可能性:

   • 定義:ユーザーは、システムの動作を予測し、操作の結果を理解し、システムの使用に自信を持てる必要があります。
   • 実装:一般的なインターフェイス設計規則に従って、ユーザーが操作を実行するときにシステムの応答を正確に予測できるようにします。

8. 制御性:

   • 定義:ユーザーはシステムを制御でき、操作を自由に実行でき、必要に応じて元に戻したりロールバックしたりできる必要があります。
   • 実装:元に戻す、やり直し、オプションの設定などの機能を提供し、ユーザーがシステムの動作を個別に制御できるようにします。

これらの原則は、ユーザー エクスペリエンスを向上させ、ユーザーの学習コストを削減し、システムの使いやすさを向上させる、ユーザーフレンドリーなインターフェイス設計を形成します。

23. RUPモデル

• RUP モデルの概要: RUP (Rational Unified Process) は、反復的なソフトウェア開発プロセスです。
  • 特徴:反復、ユースケース主導、アーキテクチャ指向を重視します。

24. 構造化ソフトウェア開発の基本的な考え方

• 基本的な考え方:構造化されたソフトウェア開発では、ソフトウェアの設計と開発にモジュール式、トップダウン、段階的な改良アプローチが採用されています。
  • モジュール化:システムを独立したモジュールに分割して、複雑さを軽減します。

データフロー指向設計手法（SD手法）

データフロー指向の設計手法、すなわち構造化設計手法（SD法）は、要求フェーズでデータフローを解析してデータフロー図やデータ辞書を生成し、これに基づいてソフトウェア構造を設計します。

データ フロー図は、システム内の情報の処理とフローを記述します。このメソッドは、データ フロー グラフの特性に基づいて、変換フローとトランザクション フローという 2 つのマッピングを定義します。これら 2 つのマッピングは、データ フロー図をプログラム構造に機械的に変換します。

この方法の目的は、ソフトウェア構造設計への体系的なアプローチを提供し、設計者がソフトウェアを全体的に理解し、データ フローの特性を分析することでプログラム構造を定義できるようにすることです。

• 構造化アプローチのデメリット

1. 安定性が悪い:

   • 問題:構造分析および設計手法は機能分解に基づいていますが、ユーザーの要件が変化すると、システム構造に壊滅的な影響を与える可能性があります。
   • 理由：システム構造は機能を実現するプロセスを中心に展開されており、機能の変更は構造の不安定化につながる可能性があります。
   • 影響:変更がシステムの複数の部分に伝播される可能性があり、システムの保守と拡張が困難になります。

2. 修正可能性が低い:

   • 問題:構造解析および設計手法はシステムの境界を明確に定義しますが、これはシステムを新しい境界を越えて拡張することが難しいことも意味します。
   • 理由:システム構造はシステム境界の定義に依存しており、システムを拡張するには境界の再検討と調整が必要です。
   • 影響:新しい機能要件の変更または追加に応じて、システムに大幅な変更が必要になる場合があります。

3. 再利用性が低い:

   • 問題:機能分解の恣意性により、分解されたモジュールの機能が不確実になり、モジュールの再利用性が低下する可能性があります。
   • 理由:モジュールの機能が明確に定義されていないと、同様の機能を持つモジュール間に大きな違いが生じる可能性があります。
   • 影響:同様の機能を持つモジュールが存在する可能性が低いため、モジュールレベルの再利用は困難です。

これらの問題を総合すると、構造化分析および設計手法が変更、修正、再利用に対処する際に直面する可能性のある課題のいくつかが浮き彫りになります。現代のソフトウェア開発手法とアーキテクチャ設計は、変化するニーズをより適切に満たし、システムの保守性、変更性、再利用性を向上させるために、より柔軟なモジュール式およびオブジェクト指向の手法を採用する傾向にあります。

25. オブジェクト指向ソフトウェア開発の基本的な考え方

• 基本的な考え方:オブジェクト指向ソフトウェア開発では、オブジェクトを定義して編成することによってシステムのモデリングと設計を実行します。
  • オブジェクト:データとメソッドをカプセル化するエンティティ。
    この方法の核心は、オブジェクト指向の概念と方法を使用して、ソフトウェア要件のモデルを構築することです。これには、要件分析をガイドするためのオブジェクト指向スタイルのグラフィカル言語メカニズムとオブジェクト指向の方法論が含まれています。

オブジェクト指向の要件分析手法

オブジェクト指向 (OO) 要件分析手法では、オブジェクトやオブジェクト間のメッセージ受け渡しなどの言語メカニズムを提供することで、アナリストが解決空間の問題空間におけるオブジェクトとその動作を直接シミュレートできるため、セマンティック ギャップが削減されます。要件モデリング活動のサポートと方法論的ガイダンス。

現実の問題を解決空間でシミュレートし、人間の思考習慣と一致させるために、OO 方法論には次の中心的な概念が含まれています。

1. 物体

   • オブジェクトは、現実世界の個人または物体を抽象的に表現したものです。
   • 属性はオブジェクトのプロパティを表し、属性値はオブジェクトのすべての可能な状態を指定します。
   • オブジェクトの操作は、オブジェクトが公開できる外部サービスを参照します。

   例: 大型旅客機は、位置、速度、色、定員などの属性を持つオブジェクトと見なすことができ、離陸、着陸、加速、整備などの操作を実行できます。

2. 親切

   • クラスは、プロパティと操作に関して特定のオブジェクトの共通の特性を表します。
   • 共通の属性と操作がクラスの特性を形成します。

   例: ヘリコプター、大型旅客機、爆撃機は航空機として分類できます。共通の属性には位置、速度、色が含まれます。一般的な操作には離陸、着陸、加速、メンテナンスが含まれます。

3. 継承する

   • クラス間の継承関係は、現実世界の遺伝関係をシミュレートします。
   • クラス間の固有の関係と、属性と操作の共有を表します。

   例: 航空機、自動車、船舶は車両クラスに分類でき、航空機クラスは車両クラスの一部のプロパティと操作を継承できます。

4. 集める

   • 現実世界における部分と全体の関係を説明します。
   • OO 手法では、クラス間の集約関係として表現されます。

   例: 航空機はエンジン、胴体、機械制御システム、電子制御システムなどで構成されています。

5. 情報

   • メッセージングは​​、オブジェクトが外の世界とどのように関係するかです。
   • オブジェクトはメッセージを送受信することによってサービスを提供します。

   例: ヘリコプターが船舶の緊急信号に応答して救助活動を行います。

オブジェクト指向 = オブジェクト + クラス + 継承 + 集約 + メッセージ。

26. 構造化ソフトウェア開発において、ソフトウェア構造を取得する方法

• ソフトウェア構造の取得:モジュール式のトップダウン設計手法により、システムがモジュールに分解され、モジュール間の関係が定義されます。

構造化ソフトウェア開発では、次の手順に従ってソフトウェア構造を取得します。

1. 要件分析: まず、詳細な要件分析を実行して、ソフトウェア システムの機能とユーザーのニーズを理解します。これは、ソフトウェアが解決しようとしている問題を明確にし、必要な機能モジュールを特定するのに役立ちます。

2. モジュール分割: ソフトウェア システムをより小さなモジュールまたはコンポーネントに分割し、各モジュールが特定の機能を処理します。高い凝集性と低い結合性を実現するには、モジュール間に明確な境界と責任が存在する必要があります。

3. インターフェイスを定義する: 各モジュールには、入力と出力、および他のモジュールとの通信方法を指定する、明確に定義されたインターフェイスが必要です。これは、モジュール間の対話の信頼性と一貫性を確保するのに役立ちます。

4. 構造図の描画: UML (Unified Modeling Language) などの適切なグラフィカル表現手法を使用して、ソフトウェアの構造図を描画します。構造図では、モジュール間の関係と依存関係を明確に示す必要があります。

5. 階層設計: ソフトウェア構造を階層的に設計し、機能をさまざまなレベルに分割し、各レベルが特定のタスクを担当します。たとえば、3 層アーキテクチャ (プレゼンテーション層、ビジネス ロジック層、データ アクセス層) を使用すると、懸念事項の分離を実現し、スケーラビリティを向上させることができます。

6. デザイン パターンの適用: 適切なデザイン パターンを適用して、一般的なソフトウェア設計の問題を解決します。デザイン パターンは、柔軟で保守可能、スケーラブルなソフトウェア構造の構築に役立つ実証済みのソリューションを提供します。

7. ドキュメントの作成: システムの概要、モジュールの機能、インターフェイス定義、構造図などを含む、ソフトウェア構造の詳細なドキュメントを作成します。ドキュメントは明確で理解しやすく、他の人がソフトウェアを理解して保守できるようにする必要があります。

8. 継続的改善: ソフトウェアの構造は静的なものではなく、要件の変化やシステムの進化に応じて、構造の調整や改善が必要になる場合があります。ソフトウェア構造を継続的に評価および改善し、システムの堅牢性と保守性を確保します。

上記の手順により、適切なソフトウェア構造が得られ、ソフトウェア開発プロセスの制御性と信頼性が向上し、同時にソフトウェアの品質と保守性が向上します。

27. ソフトウェアメンテナンスの種類

1. 事後メンテナンス

   • 定義:ソフトウェアの既知のエラー、欠陥、不具合を修正して、システムが適切に動作することを確認します。
   • 目的:現在のシステムで見つかった問題を診断して修正し、通常は既存の欠陥を修正します。

2. 適応型メンテナンス

   • 定義:ソフトウェア システムが環境の変化や新しい要件に適応し、新しい環境でも効果的に動作し続けるようにソフトウェア システムを調整すること。
   • 目的:オペレーティング システムの更新、ハードウェアの変更、規制の更新などの外部の変更に対応するため。

3. 完璧なメンテナンス

   • 定義:バグを修正するだけではなく、ソフトウェア システムのパフォーマンス、保守性、ユーザー エクスペリエンスを最適化すること。
   • 目的:ソフトウェアの品質の向上、パフォーマンスの向上、新機能の追加、またはユーザー エクスペリエンスの向上。

4. 予防保守

   • 定義:潜在的な障害やエラーを減らすために、将来の問題を防ぐための措置を講じること。
   • 目的:コード構造の最適化、コードレビューの実施、ドキュメントの更新などにより、潜在的な欠陥や問題を防止します。

このような種類のメンテナンスは通常、ソフトウェア開発サイクル全体を通じて継続的に実行されます。修正保守および適応保守は主に既知の問題または今後発生する問題に焦点を当てますが、完全保守および予防保守は将来の課題に対処するためにシステムの品質とパフォーマンスを向上させることに重点を置きます。メンテナンス作業はソフトウェアのライフサイクル全体を通じて重要であり、システムの堅牢性と継続性を確保するのに役立ちます。

28. ソフトウェアのデバッグとテストの違い

• 違い：
  • ソフトウェアのデバッグ:コード内のバグを見つけて修正します。
  • ソフトウェアテスト:ソフトウェアが要件を満たしているかどうかを検証し、潜在的なエラーを発見します。

ソフトウェア テストとソフトウェア デバッグには、目的、テクノロジ、および方法の点で、主に次の点で大きな違いがあります。

① テストはプログラムの失敗を一方的に証明するのに対し、デバッグはプログラムが正しいことを証明することです。

② テストは既知の条件から開始され、あらかじめ定義されたプログラムを使用し、結果は予測可能ですが、プログラムがテストに合格するかどうかは予測できません。一般に、デバッグは未知の内部状態から始まり、統計的デバッグを除いて、結果は予測できません。

③ テストは計画され、テスト設計が必要ですが、デバッグは時間の制約を受けません。

④ テストはエラーの発見、修正、再テストのプロセスですが、デバッグは推論のプロセスです。

⑤ テストの実行は規制されていますが、デバッグの実行ではプログラマが必要な推論や認識の飛躍を必要とすることがよくあります。

⑥ テストはソフトウェア設計を理解せずに独立したテストグループによって完了することがよくありますが、デバッグは詳細な設計を理解しているプログラマによって完了する必要があります。

⑦ほとんどのテストの実行と設計はツールでサポートでき、デバッグの際、プログラマが使用できる主なツールはデバッガです。

29. ソフトウェア開発労力を測定する方法

• 測定方法：
  • ファンクションポイント分析:システムの機能要件に基づいてワークロードを測定します。
  • 行動ポイント分析:ユーザーのインタラクション行動に基づいてワークロードを測定します。
    ソフトウェア開発労力の測定は、プロジェクトの管理、進捗状況の評価、リソースの割り当てにおいて重要な部分です。一般的に使用されるいくつかの方法と指標を次に示します。

1. ファンクションポイント分析

   • 測定単位としてファンクション ポイントを使用し、ソフトウェアの機能と複雑さに基づく評価方法。
   • ソフトウェア機能の種類と数を特定してカウントすることで、労力を評価します。

2. コード行数 (LOC)

   • 労力はソース コードの行数で測定されます。ただし、コード行が複雑さと労力を正確に反映していない可能性があるため、LOC は常に最も正確な測定値であるとは限りません。

3. 人件費の見積もり

   • 作業量は、開発者が特定のタスクを完了するのにかかると見積もった時間に基づいて見積もられます。
   • 見積もりは、専門的な経験、履歴データ、タスクの内訳などの方法を使用して行うことができます。

4. タスクと機能ポイントに基づく見積もり

   • タスクと機能ポイントをより小さな単位に分解し、各単位を見積もります。
   • このアプローチでは、各タスクの作業量を詳細に評価し、それを集計して合計作業量を算出する必要があります。

5. 専門的なツールとソフトウェアを使用する

   • JIRA、Trello、MS Project など、ワークロードの測定と見積もりの​​自動化と簡素化に役立つプロジェクト管理ツールやソフトウェアが多数あります。

6. リスク推定

   • 潜在的なリスク要因を考慮して、ワークロードに特定の調整と修正を加えます。

7. 経験則と過去のデータ

   • 類似プロジェクトの完了時間やリソース割り当てを参考にするなど、過去の類似プロジェクトのデータと経験則に基づいて工数を見積もります。

実際のプロジェクトでは、作業量をより正確に見積もるために、複数の手法と指標が組み合わされることがよくあります。必要に応じて見積もりを調整し、見積もりの​​精度を向上させるために、作業の進捗状況と実際の完了を継続的に追跡することが重要です。

30. データフロー図におけるバランスの問題を理解する

• バランスの問題の説明:データ フロー図内の各処理モジュールの入力と出力は、どこかでのバックログやデータ不足を避けるためにバランスをとる必要があります。

データ フロー図とバランスの原則

31. Java テクノロジー スタックには何が含まれていますか?

Java テクノロジー スタックとは、Java アプリケーションを開発するために Java エコシステムで使用されるテクノロジー、フレームワーク、およびツールのコレクションを指します。このテクノロジー スタックは、次のようなさまざまな側面をカバーしていますが、これらに限定されません。

1. コアJava

   • Java SE (Standard Edition): Java の基本コア。基本的な言語機能、クラス ライブラリ、ツールが含まれます。
   • Java EE/Jakarta EE (Enterprise Edition):サーブレット、JSP、JPA、EJB などのエンタープライズ レベルの API およびツールを提供する、エンタープライズ レベルのアプリケーション開発用の Java 拡張機能。

2. 開発ツール

   • 統合開発環境 (IDE): Java コードの作成、デバッグ、テストに使用される Eclipse、IntelliJ IDEA、NetBeans など。
   • ビルド ツール: Apache Maven や Gradle など、自動ビルド、依存関係管理、プロジェクト管理に使用されます。

3. ウェブ開発

   • Spring Framework:依存関係注入、AOP、MVC などを含む、包括的なエンタープライズ レベルの Java 開発サポートを提供します。
   • Spring Boot: Spring ベースのアプリケーションの開発を簡素化し、自動構成と迅速な開発を実現します。
   • サーブレットと JSP: Web ベースの Java アプリケーションの構築に使用されます。
   • Jakarta EE:以前は Java EE で、一連のエンタープライズレベルの Java 仕様と API を提供します。

4. データベース

   • JDBC (Java Database Connectivity): Java とデータベース間の接続と対話に使用されます。
   • Hibernate、JPA (Java Persistence API): Java オブジェクトとデータベース間のマッピングを簡素化するオブジェクト リレーショナル マッピング (ORM) に使用されます。

5. フロントエンド開発

   • JavaServer Faces (JSF):ユーザー インターフェイスを構築するための Java Web フレームワーク。
   • Spring Web Flow: Web アプリケーションのページ フローとナビゲーションを管理するために使用されます。

6. マイクロサービスとクラウドネイティブ

   • Spring Cloud:マイクロサービス アーキテクチャに基づいたアプリケーションを構築します。
   • Quarkus、Micronaut:クラウドネイティブ アプリケーションを構築するための軽量 Java フレームワーク。

7. テストと展開

   • JUnit、TestNG:単体テストを作成および実行するための Java テスト フレームワーク。
   • Docker、Kubernetes: Java アプリケーションのコンテナ化とデプロイ用。

Java テクノロジー スタックは非常に豊富かつ多様で、基本的な言語機能から、エンタープライズ レベルのアプリケーションやクラウド ネイティブ開発に必要なさまざまなツール、フレームワーク、ライブラリに至るまで、あらゆるものをカバーしています。適切なテクノロジー スタックの選択は、プロジェクトのニーズ、規模、チームの好みや経験によって異なります。

32. フローチャート

• フローチャートの概念:プロセスのグラフィック表現。処理ステップとプロセス制御を示します。
• 用途：システム、アルゴリズム、ビジネスプロセスを視覚化して理解するため。
  

例 1: 簡単なフローチャート

import graphviz

# 创建流程图对象
dot = graphviz.Digraph()

# 添加流程图元素
dot.node('A', '开始', shape='ellipse', fontname='SimSun')
dot.node('B', '步骤1', shape='box', fontname='SimSun')
dot.node('C', '步骤2', shape='box', fontname='SimSun')
dot.node('D', '结束', shape='ellipse', fontname='SimSun')

# 添加连接线
dot.edge('A', 'B')
dot.edge('B', 'C')
dot.edge('C', 'D')

# 保存并显示流程图
dot.format = 'png'
dot.render('flowchart_example1', view=True)

例 2: 判定条件を含むフローチャート

import graphviz

# 创建流程图对象
dot = graphviz.Digraph()

# 添加流程图元素
dot.node('A', '开始', shape='ellipse', fontname='SimSun')
dot.node('B', '步骤1', shape='box', fontname='SimSun')
dot.node('C', '决策', shape='diamond', fontname='SimSun')
dot.node('D', '步骤2', shape='box', fontname='SimSun')
dot.node('E', '结束', shape='ellipse', fontname='SimSun')

# 添加连接线和决策条件
dot.edge('A', 'B')
dot.edge('B', 'C')
dot.edge('C', 'D', label='条件1', fontname='SimSun')
dot.edge('C', 'E', label='条件2', fontname='SimSun')
dot.edge('D', 'E')

# 保存并显示流程图
dot.format = 'png'
dot.render('flowchart_example2', view=True)

グラフィカルに考える: Graphviz の芸術と実践、および DOT 言語
Graphviz をインストールし、そのパスをシステムの PATH 環境変数に追加します。次の手順に従ってください。

1. Graphviz インストーラーをダウンロードする: Graphviz 公式 Web サイトから、オペレーティング システムに適切なインストーラーをダウンロードできます。

2. Graphviz をインストールする: ダウンロードした Graphviz インストーラーを実行し、指示に従ってインストール プロセスを完了します。

3. Graphviz パスをシステムの PATH 環境変数に追加します。

   • Windowsの場合は、「コントロールパネル」を開き、「システムとセキュリティ」→「システム」に進み、左側の「システムの詳細設定」をクリックします。
   • [システムのプロパティ]ダイアログ ボックスで、[詳細設定]タブをクリックし、[環境変数]ボタンをクリックします。
   • 「システム環境変数」セクションで「Path」という名前の変数を見つけて、「編集」ボタンをクリックします。
   • [環境変数の編集] ダイアログ ボックスで、[新規] ボタンをクリックし、Graphviz のインストール パス (例: C:\Program Files\Graphviz\bin) を追加します。
   • 「OK」をクリックして変更を保存し、すべてのダイアログボックスを閉じます。

4. ターミナルまたはエディタを再起動してコードを再度実行すると、フローチャートを正常に描画できるはずです。

上記の手順に従っても問題が解決しない場合は、Graphviz が正しくインストールされていることを確認し、パスが正しく設定されていることを確認してください。graphvizまた、Anaconda 環境を使用している場合は、Graphviz とライブラリが正しい環境にインストールされていることを確認してください。

33. ソフトウェアテストにおけるドライバーとスタブ

• ドライバーとスタブの定義:
  • ドライバー:テスト対象のモジュールを呼び出し、テスト データを提供するプログラム。
  • スタブ プログラム:シミュレーション データを提供するためにテスト対象のモジュールによって呼び出されるシミュレーション プログラム。

ソフトウェア テスト、特に統合テスト段階では、ドライバーとスタブは、システムのさまざまな部分をシミュレートするために使用される 2 つの重要なテスト ツールです。

1. 運転者：

   • 定義:ドライバーは、開発または統合されている下位レベルのモジュールをテストするために、上位レベルのモジュールの動作をシミュレートするために使用されるテスト ツールです。テスト対象のモジュールのインターフェイスを呼び出し、テスト データを渡して上位モジュールの動作をシミュレートします。
   • 機能:ドライバーの主な機能は、テスト対象のモジュールを呼び出し、テスト データをモジュールに渡すことです。このようにして、ドライバーは、テスト対象のモジュールの機能が正しく、設計要件を満たしているかどうかをテスターが検証するのに役立ちます。

2. スタブ：

   • 定義:スタブは、開発または統合されている上位レベルのモジュールをテストするために、下位レベルのモジュールの動作をシミュレートするために使用されるテスト ツールです。これは、上位モジュールによって呼び出されるインターフェイスを提供し、下位モジュールの動作をシミュレートするためにシミュレートされたデータまたは結果を返します。
   • 機能:スタブの主な機能は、上位モジュールの正確性をテストするために下位モジュールを置き換えることです。スタブは通常、統合テストに使用されます。下位レベルのモジュールが完全に開発されていない場合、スタブを使用して下位レベルのモジュールの動作をシミュレートし、上位レベルのモジュールをテストできます。

統合テストでは、ドライバーとスタブを一緒に使用して、システムのさまざまな部分を段階的に組み立ててテストすることがよくあります。テスターはドライバーを使用して上位レベルのモジュールを呼び出し、スタブを使用して下位レベルのモジュールをシミュレートすることで、システム全体の統合と機能を段階的に検証できます。

このようにドライバーとスタブを使用すると、システムの一部を分離できるため、他のモジュールの影響を受けることなく 1 つのモジュールの機能に集中してテストできます。これにより、1 つのモジュールの開発が完了する前にスタブを使用して他のモジュールの動作をシミュレートできるため、開発とテストを並行して行うこともできます。

34. ホワイトボックステストケースとブラックボックステストケースの生成

• ホワイトボックス テスト ケースの生成:コード構造に従ってテスト ケースを設計し、さまざまなパスをカバーします。
• ブラックボックス テスト ケースの生成:機能要件に基づいてテスト ケースを設計し、システムがユーザーの期待を確実に満たすようにします。

ホワイトボックステスト:

ホワイト ボックス テスト (構造化テストまたはガラス ボックス テストとも呼ばれます) には、ソフトウェアの内部構造のテストが含まれます。テスト ケースは、コード、ロジック、コード実行パスの理解に基づいて作成されます。

1. ステートメントの対象範囲:

   • コード内のすべてのステートメントを少なくとも 1 回テストします。
   • テスト中にすべての実行可能ステートメントが実行されることを確認してください。

2. 支店の対応範囲:

   • コード内のすべての分岐 (決定) をテストします。
   • 意思決定ポイントの true と false の両方の結果が確実に実装されるようにします。

3. パスの適用範囲:

   • コード内のさまざまなパスを特定してテストします。
   • 可能な条件のすべての組み合わせを実行します。

4. 境界値分析:

   • 入力変数の境界または極値をテストします。
   • 上限と下限でのシステムの動作を確認します。

5. エラー処理：

   • エラー パスをテストし、適切なエラー メッセージが生成されることを確認します。
   • システムが予期しない入力をどのように処理するかを確認してください。

6. 統合テスト:

   • 異なるコンポーネント間の相互作用が正しいことを確認します。
   • モジュールの統合をテストして、インターフェイスの問題を特定します。

ブラックボックステスト:

ブラック ボックス テストは、内部コード構造を知らずにソフトウェアの機能をテストすることに重点を置いています。テスト ケースは仕様と要件に基づいて設計されます。

1. 等価クラス分割:

   • 入力範囲を等価クラスに分割します。
   • 各カテゴリ内の代表値をテストします。

2. 境界値分析:

   • 同値クラスの境界で入力値をテストします。
   • システムが上限値と下限値をどのように処理するかを確認してください。

3. デシジョンテーブルのテスト:

   • さまざまな入力条件とそれに対応するアクションを特定します。
   • 考えられるすべてのシナリオをカバーするために、入力のさまざまな組み合わせをテストします。

4. 状態遷移テスト:

   • 異なる状態を持つシステムの場合、状態間の遷移がテストされます。
   • システムがさまざまな状態で正しく動作することを確認します。

5. ユースケーステスト:

   • ユースケースに基づいてテストケースを作成します。
   • 現実世界のシナリオでシステムの動作をテストします。

6. ランダムテスト:

   • 入力をランダムに選択し、システムへの影響をテストします。
   • これにより、予期せぬ問題が見つかる可能性があります。

7. ユーザーインターフェイスのテスト:

   • ソフトウェアのユーザー インターフェイスをテストして、使いやすさの要件を満たしていることを確認します。
   • すべてのユーザー入力が正しく処理されていることを確認します。

効果的なテスト戦略は通常、ソフトウェアの機能と内部構造を完全にカバーするために、ホワイトボックス テスト手法とブラックボックス テスト手法を組み合わせていることに留意してください。

1. 次の説明を読んで、設問 1 ～ 4 に答え、解答用紙の該当する欄に記入してください。

【解説】
四則演算自動生成ソフトが完成し、ユーザに提出したとします。しかし、ユーザーはこのソフトウェアに非常に不満を抱いており、オリジナルのソフトウェアを拡張してほしいという新たな要求を次々と出してきました。たとえば、整数に加えて、1/6+1/8=7/24 などの真の分数の四則演算もサポートする必要があり、プログラムはユーザー入力を処理し、正しいか間違っているかを判断でき、スコアを蓄積し、加算、減算、乗算、除算などの演算を選択するプログラム サポートをユーザーが提供できます。
[質問 1] ソフトウェア クライシスとは何ですか?また、ソフトウェア クライシスの原因は何ですか?
【質問2】 ソフトウェアの開発プロセスでは、ユーザーのニーズを汲み取ることが重要です。一般的な事前要件の抽出テクニックについて話しましょう?
【質問3】 あなたがこのソフトウェアの開発を担当している場合、どのようなソフトウェア開発モデル（ウォーターフォールモデル、スパイラルモデル、プロトタイプモデルなど）を採用する予定であるか、その理由を説明してください。
【質問4】 ソフトウェア保守の種類と作業内容を述べ、本件がどのようなソフトウェア保守に属するかを説明してください。

質問 1: ソフトウェア クライシスとは何ですか? ソフトウェア クライシスの原因は何ですか?

ソフトウェア クライシスとは、ソフトウェア開発で発生する一連の問題や課題を指します。これにより、ソフトウェア プロジェクトが計画された計画や予算に従って完了することが困難になり、プロジェクトが失敗したり、提供されたソフトウェアがユーザーのニーズを満たせなくなったりすることがあります。ソフトウェア クライシスの主な原因は次のとおりです。

1. 複雑さの増加:ソフトウェア システムは機能が追加されるにつれて複雑になり、理解と保守が困難になります。

2. 要件の変更:ソフトウェアに対するユーザー要件が頻繁に変更されると、元の開発計画が無効になり、開発の難易度が高まります。

3. 技術レベル:ソフトウェア開発の初期段階では技術レベルが比較的低いため、開発プロセス中に多くのエラーが発生し、修理コストが増加します。

4. プロジェクト管理:効果的なプロジェクト管理と制御の欠如は、プロジェクトのスケジュールの遅延やコストの超過につながります。

5. 標準の欠如:統一されたソフトウェア開発標準と仕様の欠如は、開発プロセスの混乱につながります。

質問 2: ソフトウェア開発プロセスでは、ユーザーのニーズを把握することが重要です。一般的な事前要件の抽出テクニックについて話しましょう?

ユーザーのニーズを捉えるための手法には次のようなものがあります。

1. インタビュー：ユーザーと直接コミュニケーションをとり、質疑応答を通じてユーザーのニーズを聞き出します。

2. アンケート調査：システムに対するユーザーの期待やニーズに関する情報を収集するためにアンケートを配布します。

3. ブレーンストーミング:チーム メンバーがブレーンストーミングを行い、考えられるさまざまな要件を要約します。

4. プロトタイプの設計:ユーザーがシステムをより直観的に理解し、フィードバックを提供できるように、単純なプロトタイプを作成します。

5. ユーザー観察:実際の運用におけるユーザーの行動を観察し、ユーザーのニーズや問題を発見します。

質問 3: あなたがこのソフトウェアの開発責任者である場合、どのソフトウェア開発モデルを採用する予定であるかについて話し、その理由を説明してください。

この場合、スパイラル モデルが選択される可能性があります。その理由は次のとおりです。

スパイラル モデルを選択する主な理由は次のとおりです。

1. リスク管理:このプロジェクトは、ユーザーニーズの変化に直面していますが、スパイラルモデルは、リスク分析段階を通じて需要の変化、技術的リスクなどをより包括的に検討および分析することができ、これらのリスクをより適切に管理するのに役立ちます。

2. 柔軟性と反復開発:スパイラル モデルでは繰り返しの反復が可能で、各スパイラルには複数のフェーズが含まれており、それぞれのフェーズで要件分析、設計、開発、テストを実行できます。この種の柔軟性は需要の変化に適応し、反復中に改善と調整を続けることができます。

3. ユーザーの関与とフィードバック:スパイラル モデルでは、ユーザーがあらゆる段階で参加してフィードバックを提供することが奨励されます。これは、要件の頻繁な変更に直面するプロジェクトにとって非常に重要です。ユーザーからのフィードバックをタイムリーに取得し、フィードバックに基づいてソフトウェアの設計と機能を調整および最適化することができます。

4. リスク管理:スパイラルの各段階でのリスク分析と評価を通じて、プロジェクト内のリスクを特定してタイムリーに対処し、プロジェクト失敗の可能性を低減します。

5. 適応性:スパイラル モデルは、変更に対する柔軟性と敏感さを必要とするプロジェクトに適しており、開発プロセス中に反復と調整を行って、ソフトウェア システムが実際のニーズを確実に満たすことができます。

全体として、スパイラル モデルを選択すると、リスクをより適切に管理し、需要の変化に適応し、ソフトウェアの品質を継続的に最適化し、ユーザーが参加してフィードバックを提供できるようになり、変化するプロジェクト環境に直面するプロジェクトにとってより適切な選択となります。

質問4：ソフトウェア保守の種類と作業内容を述べ、本件がどのようなソフトウェア保守に属するかを説明してください。

ソフトウェア メンテナンスには次の種類があります。

1. 修正メンテナンス:発見されたエラーや欠陥を修正して、ソフトウェアが正常に動作するようにします。

2. 適応型メンテナンス:環境の変化 (オペレーティング システムのアップグレード、ハードウェアの交換など) を調整して、新しい環境に適応します。

3. 完璧なメンテナンス:ソフトウェアを最適化および改善して、パフォーマンス、保守性、ユーザー エクスペリエンスを向上させます。

4. 予防メンテナンス:潜在的な問題を特定して修正することで、将来のエラーを防止します。

この場合、ユーザーからの新たな要求により、元の四則演算自動生成ソフトウェアを、真の分数の四則演算やその他の関数に対応するように拡張する必要があります。新しいニーズや変更に合わせてソフトウェアを調整する必要があるため、これは適応型メンテナンスです。同時に、ユーザーの入力を判定し、スコアを蓄積するなどの操作には、ソフトウェアの正確性とパフォーマンスを保証するための修正保守と完全性保守が含まれる場合があります。

---

2. 次の注意事項を読んで、解答用紙の該当する欄に解答を記入してください。

レストランの注文システムには、顧客と管理者の 2 種類のユーザーがいます。ログイン後、顧客はメニューの閲覧、料理の注文、注文メニューの表示、注文メニューの変更、チェックアウトが可能です。ログイン後、管理者はメニューの管理と注文メニューの表示が可能です。対応する操作が完了した後、顧客と管理者は終了できます。システム。
[質問 1] オブジェクト指向ソフトウェア開発プロセスの RUP モデルについて簡単に説明してください。
【質問2】ユースケース図とは何ですか? 飲食店のオーダーシステムのユースケース図を描いてください。（5 点）
【質問 3】 オブジェクト指向設計において、ユースケースの実装プロセスを記述するためにどのような図を使用できますか?
[質問 4] オブジェクト指向ソフトウェア開発手法と構造化ソフトウェア開発手法の違いと関連性について話し合ってください。

質問 1: オブジェクト指向ソフトウェア開発プロセスの RUP モデルについて簡単に説明してください。

RUP (Rational Unified Process) モデルは、反復的かつ段階的な開発手法を重視したオブジェクト指向のソフトウェア開発プロセスです。RUP には次の主要な機能が含まれています。

• 反復:ソフトウェア開発プロセス全体を複数の反復に分割し、各反復にはシステムの機能の一部が含まれます。各反復により、ソフトウェアの実行可能バージョンが生成されます。

• 増分:反復ごとに新しい機能がシステムに追加され、ソフトウェアが徐々に改善されます。この段階的なアプローチにより、ソフトウェアは開発されるにつれて徐々に完成度が高まります。

• ユースケース主導: RUP はユースケース主導のアプローチ、つまりユーザーの観点からシステムの機能と動作を明確に定義することを重視しています。

• アーキテクチャ主導:システムのアーキテクチャ設計を重視し、システムが合理的に構造化され、スケーラブルで、保守が容易であることを保証します。

質問 2: ユースケース図とは何ですか? レストランの注文システムのユースケース図を描いてください。

ユースケース図は、システムの機能を説明する図であり、システムのさまざまなユースケース (機能) とそれらの間の関係を示します。ここでは、単純なレストラン注文システムのユースケース図を説明します。

この使用例図には、顧客と管理者の 2 つの主な役割のほか、顧客の注文、メニューの表示、チェックアウトなどの使用例、および管理者によるメニューの管理や注文の表示などの使用例が含まれている場合があります。ユースケース間の関係は関連線で表すことができます。

@startuml
left to right direction
package  餐厅点餐系统 {
    
    

actor 顾客 as C
actor 管理员 as A

rectangle  {
    
    
  C --> (浏览菜单)
  C --> (点菜)
  C --> (查看已点菜单)
  C --> (修改已点菜单)
  C --> (结账)
  A --> (管理菜单)
  A --> (查看已点菜单)
}
}
@enduml

質問 3: オブジェクト指向設計では、ユースケースの実装プロセスを説明するためにどのような図を使用できますか? 少なくとも 2 つの図を説明してください。

オブジェクト指向設計では、次の 2 つの図を使用してユースケースの実装プロセスを説明できます。

1. クラス図:クラス図は、システム内のクラスとそれらの間の関係を表します。各ユース ケースは通常、ユース ケースの構造と動作を記述するプロパティとメソッドを含むクラスに対応します。

2. インタラクション図:インタラクション図には、システム内のオブジェクト間の対話プロセスを記述するために使用されるシーケンス図とコラボレーション図が含まれます。シーケンス図はオブジェクト間のメッセージのシーケンスを示し、コラボレーション図はオブジェクト間のコラボレーション関係を示します。

質問 4: オブジェクト指向ソフトウェア開発手法と構造化ソフトウェア開発手法の違いと関連性について話し合ってください。

• 違い：

  • 方法論:オブジェクト指向方法では、オブジェクト、クラス、継承などの概念が強調され、システムの抽象化とモデル化に重点が置かれますが、構造化方法では、プロセス、モジュール、データ フローなどの設計により注意が払われます。

  • 再利用性:オブジェクト指向メソッドは、クラスとオブジェクトの再利用を通じてシステムの保守性と柔軟性を向上させることに重点を置いていますが、構造化メソッドは再利用には比較的弱いです。

  • モジュール化：オブジェクト指向方式はクラスのカプセル化によりシステムの保守性を向上させるモジュール設計を実現し、構造化方式はモジュールを分割することでモジュール設計を実現します。

• 接続する：

  • 目標:どちらも、優れた設計および開発手法を通じて、信頼性が高く、保守可能で、スケーラブルなソフトウェア システムを構築することを目指しています。

  • 開発プロセス:すべては反復的で段階的に改善された開発手法を採用しており、段階的かつモジュール式の設計を重視しています。

  • 要件分析:どちらも、最終的なシステムがユーザーの期待に応えることを保証するために、ユーザーのニーズを理解して把握することに重点を置いています。

実際のアプリケーションでは、この 2 つの方法を組み合わせて使用​​することがよくあります。つまり、システム設計にはオブジェクト指向の考え方を使用し、特定のコーディングとモジュール分割を実現するには構造化手法を使用します。このように組み合わせることで、それぞれの利点を最大限に発揮し、ソフトウェア開発の効率と品質を向上させることができます。

3. 次の説明と図を読んで、解答用紙の該当する欄に答えを記入してください。

ある病院は患者監視システムの開発を計画しています。このシステムは、さまざまな機器を通じて患者のバイタルサインを監視し、バイタルサインに異常がある場合に医師や看護スタッフに警告します。システムの主な機能は次のとおりです。
(1) ローカルモニタリング: 体温、血圧、心拍数、その他のデータなどの患者のバイタル特性を定期的に取得します。
(2) バイタル特性のフォーマット: 患者の重要なバイタル特性データをフォーマットし、ログ ファイルに保存し、バイタル特性を確認します。
(3) 生体特徴の確認：フォーマットされた生体特徴を、生体特徴範囲ファイルにあらかじめ設定された正常範囲と比較します。事前に設定された範囲を超えると、システムは医師と介護者に警告メッセージを送信します。
(4) バイタル特性値の範囲を維持する：医師は、必要に応じて（例えば、新しい研究結果が出た場合など）、バイタル特性値の正常範囲を追加または更新します。
(5) レポートの抽出: 医師または看護スタッフが患者のバイタル特性レポートを要求すると、ログ ファイルから患者のバイタル特性を取得して特性レポートを生成し、要求者に返します。
(6) 医療記録の作成: ログ ファイル内の重要な特徴に基づいて、医師は患者の状態を説明し、医療記録を作成し、医療記録ファイルに保存します。
(7) 医療記録照会：医師の医療記録照会要求に従って、医療記録ファイルが検索され、医療記録レポートが医師に返されます。
(8) 治療意見の作成：ログファイルの生体特性や診療記録をもとに、医師が処方箋などの治療意見を出し、治療意見ファイルに保存します。
(9) 治療意見の聴取：医師や看護スタッフが治療意見を聴取し、患者さんに応じた治療を行います。
ここで、構造化手法を使用して患者監視システムを分析および設計し、図 3-1 に示すトップレベルのデータ フロー図と図 3-2 に示すレイヤー 1 データ フロー図を取得します。

[問題 1] 記述中の単語を使用して、図 1 のエンティティ E1 ～ E3 の名前を答えてください。
[問題 2] 説明中の単語を使用して、図 2 のデータ ストア D1 ～ D4 の名前を答えてください。
[質問 3]
(1) 図 2 では 4 つのデータ フローが欠落しています。図 3-1 と図 2 の指示と用語を使用して、データ フローの名前とその開始点と終了点を答えてください。
(2) エンティティ E1 とエンティティ E3 の間にデータの流れがあるかどうかと、その理由を説明してください。
[質問 5] 変換データ フロー図をソフトウェア構造にマッピングする手順を説明してください。

図 1 最上位のデータ フロー図

図 2 レイヤ 1 データ フロー図

質問 1: 説明内の単語を使用して、図 1 のエンティティ E1 から E3 の名前を答えてください。

• E1: 患者
• E2: 看護職員
• E3: ドクター

質問 2: 説明内の単語を使用して、図 2 のデータ ストア D1 から D4 の名前を教えてください。

• D1: バイタルサイン範囲ファイル
• D2: ログファイル
• D3: 医療記録文書
• D4：治療意見書

質問 3:

データフロー名	出発点	終わり
重要なバイタルサイン	ローカルモニタリング	バイタルサインのフォーマット
フォーマットされたバイタルサイン	バイタルサインのフォーマット	バイタルサインをチェックする
医療記録	医療記録を生成する	D3 または医療記録ファイル
バイタルサイン	D2 またはログ ファイル	医療記録を生成する

データ フローの開始点と終了点のどちらかが処理中である必要があるため、E1 と E3 の間にデータ フローは存在できません。

質問 5: 変換データ フロー図をソフトウェア構造にマッピングする手順について説明してください。

1. 処理 (プロセス) の特定:データ フロー図からすべてのプロセスを特定します。これらのプロセスはソフトウェア内のモジュールまたは機能にマッピングされます。

2. データ ストアの特定:データベースまたはファイル システムにマップされるデータ フロー図でデータ ストアを特定します。

3. データ フローの特定:システム内の情報の流れを表すデータ フローを特定します。これらは、モジュール間で受け渡される関数呼び出しまたはデータにマップされます。

4. 外部エンティティの識別:ユーザーや他のシステムなど、システムの外部のエンティティを表す外部エンティティを識別します。これらは、外部環境とのシステムのインターフェイスにマッピングされます。

5. 構造図の作成:特定された処理、データ ストレージ、データ フロー、外部エンティティに基づいて、ソフトウェア システムの構造とモジュール間の関係を表す構造図を作成します。

6. インターフェイスとデータ送信の明確化:システムのさまざまな部分間の連携作業を確実にするために、構造図内の各モジュールのインターフェイスとデータ送信方法を明確にします。

7. 検証と調整:構造図の合理性を検証し、必要に応じて調整を行い、システム構造が設計要件と性能要件を満たしていることを確認します。

---

4. 次の指示を読んで質問に答え、解答用紙の対応する欄に答えを記入してください。

【说説明】
業界のプログラマは何年もの間、協力して作業することで、より短い時間で高品質のソフトウェア製品を作成できると主張してきました。しかし、彼らの証拠は、「効果がある」とか「正しいと感じる」といった、逸話的で主観的なものでした。これらの主張を検証するために、私たちは、ペア プログラミング (2 人のプログラマーが同じ設計、アルゴリズム、コード、またはテストで 1 台のコンピューターで並んで作業する) が実際にソフトウェアの品質を向上させ、市場投入までの時間を短縮することを示す定量的証拠を収集しました。さらに、学生やプロのプログラマーは、一人で作業するよりもペア プログラミングの方が楽しいと常に感じています。
しかし、ペア プログラミングを実際に試したことのない人のほとんどは、このアイデアをプログラミング リソースの冗長で無駄な使用として拒否します。そんなことする余裕はないよ！」しかし、ラリー・コンスタンティンが書いたように、2 人のプログラマーが連携することは冗長ではないことがわかりました。それは効率の向上と品質の向上への直接的なルートです。」
【問題 1】何がペアワイズプログラミングですか?
团队开発行
流程?

質問 1: ペアワイズ プログラミングとは何ですか?

**ペア プログラミング** は、2 人のプログラマーが同じコンピューター上で協力して設計、アルゴリズム、コーディング、テストなどのタスクを完了するソフトウェア開発手法です。ペアプログラミングでは、一方のプログラマーが「ドライバー」として実際のコーディング作業を担当し、もう一方のプログラマーが「オブザーバー」または「ナビゲーター」としてコードのレビューを担当し、より高いレベルの提案や思考を行います。デザインの問題。2 人のプログラマーは、コラボレーションのバランスを維持するために役割を交換することがよくあります。

質問 2: ペア プログラミングの長所と短所は何ですか?

アドバンテージ：

1. ソフトウェア品質の向上:ペア プログラミングは、エラーを見つけて修正し、欠陥の数を減らし、コードの品質を向上させるのに役立ちます。
2. 起動後の問題の削減:コードは二重レビューされるため、運用開始後に修正が必要な問題が少なくなります。
3. 知識の共有:ペア プログラミングにより、チーム メンバー間の知識の共有が促進され、情報のサイロ化が軽減されます。
4. 学習の加速:初心者は、経験豊富な開発者とペアプログラミングすることで、より早くスキルを学び、向上させることができます。

欠点:

1. リソースの消費: 2 人のプログラマーの時間とエネルギーが必要となり、非効率に見える可能性があります。
2. コミュニケーションコスト：パートナーシップが良好でなかったり、コミュニケーションが不十分な場合、ペアプログラミングは効果的ではない可能性があります。
3. 適応性が低い:すべてのタスクや誰もがペア プログラミングに適しているわけではなく、開発者によっては独立して作業することを好む場合があります。

質問 3: 記事内のペア プログラミングの説明と組み合わせて、個人のソフトウェア開発プロセスとチーム開発プロセスについて話しますか?

個人的なソフトウェア開発プロセス:

• 独立して作業する:通常、個々のソフトウェア開発者は、要件分析、設計、コーディング、テスト、メンテナンスを含むソフトウェア開発プロセス全体を単独で完了します。
• 独立した意思決定:開発者は技術的および設計上の決定を独立して行い、高い柔軟性を備えていますが、独立した思考では盲点になりがちです。

チーム開発プロセス:

• ペア プログラミング:チームでペア プログラミングを使用すると、コードの品質が向上し、エラーが減り、学習が加速され、チームのコラボレーションが促進されます。
• コラボレーションとコミュニケーション:チーム メンバーは、コード レビューや反復開発などを通じてプロジェクトの進行を共同で促進するために、良好なコミュニケーションとコラボレーションを必要とします。
• 知識の共有:情報のサイロ化を回避し、すべてのメンバーがプロジェクトの全体的なアーキテクチャと設計を確実に理解できるように、チーム内で知識の共有を実現する必要があります。

実際には、個々のソフトウェア開発者は独立性と自律的な意思決定に重点を置く場合がありますが、チーム開発プロセスではコラボレーション、コミュニケーション、共有に重点が置かれます。チームでは、プロジェクトの性質やチームメンバーの特性に応じて適切な開発手法を選択し、場合によっては個人の自主作業とチームの連携を組み合わせることで、最良の開発結果を達成することができます。

5. 次の Java コード スニペットに基づいて、対応する UML クラス図モデルを描画します。

パブリッククラスAnimal { public void move(){} }パブリックインターフェイスICanEat { public void Eat(); public class Dog extends Animalimplements ICanEat { public void Eat() {} public void bark(){} }

提供された Java コード スニペットに基づいて、次の UML クラス図モデルを描画できます。

+-------------------+          +-----------------+          +----------------+
|      Animal       |          |    ICanEat      |          |      Dog       |
+-------------------+          +-----------------+          +----------------+
|                   |          |                 |          |                |
|                   |          |                 |          |                |
| + move()          |          | + eat()         |          | + eat()        |
|                   |          |                 |          | + bark()       |
+-------------------+          +-----------------+          +----------------+

この UML クラス図では次のようになります。

• Animalクラスには 1 つのメソッドがありますmove()。
• ICanEatインターフェースには 1 つのメソッドがありますeat()。
• DogクラスはAnimalクラスを継承してICanEatインターフェイスを実装します。これにはmove()、(継承からの) メソッドとeat()(インターフェイス実装からの) メソッド、および独自の固有のbark()メソッドがあります。

関係の説明:

• 継承関係は実線の矢印で表されます。
• インターフェイスの実装関係は破線の矢印で表されます。
  以下は、提供された Java コード スニペットから生成された単純な UML クラス図モデルです。

@startuml
class Animal {
  +move()
}

interface ICanEat {
  +eat()
}

class Dog {
  +eat()
  +bark()
}

Animal <|-- Dog
ICanEat <|.. Dog
@enduml

この UML クラス図は、Animal クラス、ICanEat インターフェイス、Dog クラスの関係を表しています。クラス間の矢印は、継承または実装の関係を示します。Animal クラスは基本クラスであり、Dog クラスは Animal クラスを継承して ICanEat インターフェイスを実装します。

このコードは PlantUML 言語で書かれており、観光名所ガイド システムの参加者とユースケースの関係を表す UML ユースケース図を生成するために使用されます。次の手順に従って、これを使用して UML 図を生成できます。

1. オンライン エディター: PlantTextやPlantUML Editorなどのオンライン PlantUML エディターを使用します。コードをエディターに貼り付けると、UML 図が生成されます。

2. ローカル環境:図をローカルで生成する場合は、PlantUML をインストールし、テキスト エディターを使用してこのコードを含むファイルを作成する必要があります。次に、コマンド ラインで PlantUML を実行して図を生成します。

   • インストール:公式 Web サイトからPlantUML をダウンロードし、指示に従ってインストールします。

   • コマンド ライン:インストールが完了したら、次のようにコマンド ラインで PlantUML を実行します。

     plantuml yourfile.uml
     

     yourfile.umlは実際のファイル名に置き換えられます。

   • 画像の表示:コマンドを実行すると、画像ファイル (PNG など) が生成されます。画像ビューアを使用して画像ファイルを開き、UML 図を表示します。

6. 以下の資料の説明に基づいて質問に答えてください。

観光名所ガイドシステムは、Spring Boot フレームワークと Vue.js フレームワークに基づいて、景勝地ガイド情報の閲覧と公開を実装します。このシステムを使用する役割には、未承認ユーザー、承認済みユーザー、バックエンド管理者が含まれます。権限のないユーザーは、アカウントの登録、アトラクションの紹介の閲覧、アトラクションのレビューの閲覧、景勝地の検索にシステムを使用できますが、許可されたユーザーは、アトラクションの紹介の閲覧、アトラクションのレビューの閲覧、景勝地の検索の機能権限に加えて、また、システムにログインしたり、アトラクションのレビューを投稿したり、チケットを注文したりすることもできます。許可されたユーザーがチケットを注文する場合、WeChat システムを使用して注文の支払いを行います。バックエンド管理者は、ユーザー情報、景勝地情報、景勝地情報などを管理できる権限のあるユーザーです。
1) 観光名所ガイドシステムのシステム参加者は誰なのか分析してください。
2) さまざまな参加者に関連付けられたユースケースを分析し、分析結果に基づいて観光スポットガイドシステムの UML ユースケース図を作成します。

1) システム参加者:

• 不正なユーザー
• 許可されたユーザー
• バックステージ管理者

2) 関連するユースケース分析と UML ユースケース図:

• 権限のないユーザー:

  • アカウント登録
  • アトラクションの紹介を見る
  • アトラクションのレビューを閲覧する
  • 景勝地を探す

• 許可されたユーザー:

  • ログインシステム
  • アトラクションのレビューを投稿する
  • チケットを注文する
  • アトラクションの紹介を見る
  • アトラクションのレビューを閲覧する
  • 景勝地を探す

• バックエンド管理者:

  • ユーザー情報の管理
  • 景勝地情報の管理
  • アトラクション情報の管理

UML ユースケース図:

+------------------------+        +------------------------+       +------------------------+
|   Unauthorized User   |         |     Authorized User    |       |  Back-End Administrator|
|------------------------|        |------------------------|       |------------------------|
| + RegisterAccount()    |        | + Login()              |       | + ManageUserInfo()     |
| + BrowseSpotIntro()    |        | + PostComment()        |       | + ManageScenicInfo()   |
| + BrowseSpotComments() |--------| + OrderTicket()        |       | + ManageSpotInfo()     |
| + SearchScenic()       |        | + BrowseSpotIntro()    |       +------------------------+
+------------------------+        | + BrowseSpotComments() |
                                  | + SearchScenic()       |
                                  +------------------------+

これは、特定の関係線を描画しない、簡略化された UML ユースケース図です。関係線には通常、関連付け、継承、インクルードなどが含まれます。システムの実際のニーズに基づいて、適切な関係をユース ケース図に追加して、アクターとユース ケースの関係をより正確に表現できます。

ユースケース図の関連付けは次のとおりです。

• 権限のないユーザー: アカウントを登録し、観光スポットの紹介を閲覧し、観光スポットのレビューを閲覧し、景勝地を検索します。
• 承認されたユーザー: システムへのログイン、アトラクションへのコメントの投稿、チケットの注文 (WeChat 支払いを含む)、アトラクションの紹介の閲覧、アトラクションのレビューの閲覧、景勝地の検索。
• バックエンド管理者: ユーザー情報を管理し、景勝地情報を管理し、景勝地情報を管理します。

UML ユースケース図の例:

@startuml
left to right direction
package "旅游景区指南系统" {

actor 未授权用户 as UU
actor 已授权用户 as AU
actor 后台管理员 as Admin

  rectangle  {
    UU --> (注册账户)
    UU --> (浏览景点介绍)
    UU --> (浏览景点评论)
    UU --> (搜索景区)

    AU --> (登录系统)
    AU --> (发表景点评论)
    AU --> (订购门票)

    Admin --> (管理用户信息)
    Admin --> (管理景区信息)
    Admin --> (管理景点信息)
  }
}
@enduml

このユースケース図は、システムのアクターとそれに関連するユースケースを簡単に示しています。

このコードは PlantUML 言語で書かれており、観光名所ガイド システムの参加者とユースケースの関係を表す UML ユースケース図を生成するために使用されます。次の手順に従って、これを使用して UML 図を生成できます。

1. オンライン エディター: PlantTextやPlantUML Editorなどのオンライン PlantUML エディターを使用します。コードをエディターに貼り付けると、UML 図が生成されます。

2. ローカル環境:図をローカルで生成する場合は、PlantUML をインストールし、テキスト エディターを使用してこのコードを含むファイルを作成する必要があります。次に、コマンド ラインで PlantUML を実行して図を生成します。

   • インストール:公式 Web サイトからPlantUML をダウンロードし、指示に従ってインストールします。

   • コマンド ライン:インストールが完了したら、次のようにコマンド ラインで PlantUML を実行します。

     plantuml yourfile.uml
     

     yourfile.umlは実際のファイル名に置き換えられます。

   • 画像の表示:コマンドを実行すると、画像ファイル (PNG など) が生成されます。画像ビューアを使用して画像ファイルを開き、UML 図を表示します。

テストの質問と回答:

1. ある図書管理システムの機能としては、
   ①読者はシステムにログインすると情報照会、図書の予約、更新ができる、
   ②図書館員はシステムにログインすると情報照会、読者情報、図書情報の管理ができる、そして、 ③
   読者が本を返却する際、予定時間を超過した場合、図書館員は図書館規定に従って罰金を科す;
   ④ 背景管理者はシステムにログインした後、システムを保守することができる
   . 分析してください。 (1)要件の
   分析にシステムに参加するのは誰ですか?
   (2) 質問(1)の分析結果に基づいて、各参加者に関連するシステムのユースケースをさらに分析します。
   (3) UML ユースケース図を使用して、質問 (1) と (2) の分析結果を視覚化します。
   参考回答：
   （1）閲覧者、図書館員、管理者、
   （2）閲覧者：ログイン、図書予約、図書更新、情報照会、
   図書館員：ログイン、情報照会、読者情報管理、図書情報管理、
   管理会員：ログイン、システムメンテナンス
   (3) ユースケース図の参考図は以下のとおりです。
   

2. ある病院は、分散型患者監視システム (PMS: Patients Monitoring System) の開発を計画しています。PMS は、病棟内の各患者の重要な生理学的信号 (体温、血圧、脈拍信号など) を監視するために使用され、患者の医療記録を定期的に更新および管理できます。さらに、患者の生理学的信号が医師が指定した安全範囲を超えた場合、システムは直ちに看護スタッフに通知することができ、看護スタッフは必要に応じていつでもシステムを通じて患者関連のレポートを作成できます。
   PMS の主な機能は次のとおりです。
   ① ベッドモニターによる局所モニタリングを実現し、患者の生理信号を取得します。
   ② 保健室での集中モニタリングの導入
   ③ 患者の医療記録の更新と管理
   ④ 患者の状態レポートとアラーム情報の生成
   質問:
   (1) PMS のデータ ソース ポイントとデータ エンド ポイントを分析してください。
   (2) 要求の説明によると、PMS はどのようなデータ処理に分類できますか?
   (3) 質問(1)と(2)の分析結果を基に、レイヤー1のデータフロー図を作成します。
   参考回答:
   (1) PMS のデータソースは患者と看護師、データのエンドポイントは看護師、
   (2) PMS は 4 つのデータ処理に分けられます: ローカルモニタリング、集中モニタリング、レポートの生成、患者の生理学的データの記録
   (3) ) 1 層データ フロー図の参考図は次のとおりです。