1.ウォーターフォールモデル
ウォーターフォールモデルは、ソフトウェアのライフサイクルを、計画、要件分析、ソフトウェア設計、プログラム作成、ソフトウェアテスト、運用と保守の6つの基本アクティビティに分割し、トップダウンと相互接続の固定シーケンスを規定します。 、滝のように、徐々に落ちていきます。
ウォーターフォールモデルは、ソフトウェアのライフサイクルを、定義フェーズ、開発フェーズ、運用および保守フェーズの3つの主要なフェーズに分割します。ウォーターフォールモデルのステージはシーケンシャルで依存しています。次のステージは、前のステージが完了した後にのみ開始できます。前のステージの出力テキストは、後のステージの入力テキストです。
ウォーターフォールモデルの各段階では、以下を順守する
必要があります。（1）各段階では、各段階で指定されたドキュメントを完成させる必要があります。
（2）完成した文書は、各段階が終了する前にレビューする必要があります。これにより、問題をできるだけ早く発見し、エラーを修正できます。
2.ソフトウェアのライフサイクル
ソフトウェアのライフサイクルは、ソフトウェアの定義、ソフトウェアの開発、運用、保守の3つの段階に分かれています。ソフトウェア定義期間中に、ソフトウェア開発プロジェクトの全体的な目標を決定し、プロジェクトの実現可能性を決定します。プロジェクトを完了するための時間コストを見積もり、プロジェクトのスケジュールを作成します。開発段階では、特定の設計と前の期間に定義されたソフトウェアの設計。運用と保守により、ソフトウェアはユーザーのニーズを永続的に満たすことができます。
問題の定義：ユーザーへの調査訪問を通じて、ユーザーの問題の性質、エンジニアリングの目標などを確立します。
実現可能性調査：問題調査の範囲と実現可能性を確立し、どの段階でより多くの人的資源と物的資源を投資する必要があるかを確立します。
要件分析：顧客との綿密なインタビューを実施し、情報を完全に交換して、ユーザーが望むシステムロジックモデル（将来の設計と目標の実現の基礎）を取得します。
全体的な設計：最初に、ターゲットシステムを実現するためのいくつかの可能なソリューションを設計し、プログラムのアーキテクチャを設計する必要があります。つまり、プログラムがどのモジュールで構成され、モジュール間の関係を決定する必要があります。
詳細設計：システムを詳細に実現するタスクを解決し、各モジュールを詳細に設計し、モジュール機能に必要なアルゴリズムとデータ構造を決定します。
コーディングと単体テスト：理解と保守が容易な正しいプログラムモジュールを作成します。
包括的なテスト：さまざまなタイプのテストを通じて、所定の要件を満たします。最も基本的なテストは、統合テストと受け入れテストです。
3.分析モデル
制度分析から導き出された分析モデルには、データモデル、機能モデル、行動モデルが含まれます。モデルは「データディクショナリ」をコアとして、ソフトウェアが使用するすべてのデータオブジェクトを記述します。このコアの周りには、「エンティティ関係図」、「データフロー図」、および「状態遷移図」があります。
実体関連図：データモデリングのためのデータオブジェクトとオブジェクト間の関係を説明します。
データフロー図：システム内のデータフローのプロセスを説明し、機能モデリングの基礎となるデータフローを変換する機能を示します。
状態遷移図：外部イベントへの応答を説明し、システムのさまざまな動作パターン（状態と呼ばれる）と、動作モデリングに使用される状態間の遷移方法を表します。
4.ソフトウェア設計モデル
各分析モデルは、設計モデルの構築に必要な情報を提供します。ソフトウェア設計は、データ、機能、および動作モデルによって表されるソフトウェア要件に従って、データ設計、アーキテクチャ設計、インターフェイス設計、およびプロセス設計に特定の設計方法を採用します。
データ設計は、実体関連図に記述されているオブジェクトとデータディクショナリに記述されている詳細なデータコンテンツとの間の関係をデータ構造の定義に変換します。
アーキテクチャ設計は、ソフトウェアシステムの主要コンポーネント間の関係を定義し、主に、データが1つのモジュールから別のモジュールにどのように流れるか、およびモジュール内の流れの方向を分析する必要があります。
全体的な設計は、データ設計とアーキテクチャ設計に分けられます。
インターフェイス設計は、データフロー図に従って、ソフトウェアのさまざまなコンポーネント間、ソフトウェアと他のコラボレーションシステム間、およびソフトウェアとユーザー間の相互作用メカニズムを定義します。主な分析データは、異なるモジュール間のインターフェイスを設計する方法です。そして、データフロー図が必要です。
プロセス設計は、構造コンポーネントをソフトウェアの手続き型記述に変換します。これには、データ状態の変換と状態変更の方法が含まれます。
5.テストプロセスモデルテストするときは
、最初に単体テストを実行し、次にアセンブリテストを実行し、最後にテストを確認します。
モジュールテスト：ユニットテスト。各モジュールは独立したサブ機能に対応し、各モジュールは独立したエンティティとしてテストされ、各ユニットが正常に動作できることを確認します。この段階でのエラーは通常、コーディングと詳細設計のエラーです。コーダー自身によって完成されます（ホワイトボックス方式）。
システム統合テスト：すなわち、インターフェーステスト、アセンブリテスト。テストしたユニットモジュールを特定の順序でシステムに組み立て、同時にテストを実行します。焦点は、モジュール間の相互通信と調整にあります。システムの規模が大きい場合、統合テストは一般にサブシステムテストとシステムテストに分けられます（ブラックボックス方式）。システムが要件分析の機能とパフォーマンスを実現できるかどうかを検証し、専用のテスト部門が完了する必要があります。
確認試験：認定試験または合格試験。システムがシステムによって指定された要件を満たしていることを確認します。
回帰テスト：統合テストと確認テストの間に回帰テストを追加します。特定のシステムテストで問題が発生した場合、そのシステムに関連するシステムは、完全なテストではなく部分的なテストの対象となり、時間を節約して回帰テストに戻る必要があります。
6.ファウンテンモデルファウンテンモデル
は、ソフトウェアエンジニアリング開発プロセスの反復的でシームレスな特性を具体化します。噴水モデルは反復モデルとも呼ばれ、ソフトウェア開発プロセスのさまざまな段階が重複して複数回繰り返されると考えられています。噴水と同じように、水は中央または下部に上下に噴霧できます。
異なる段階の円は互いに重なり合っており、2つのアクティビティの間に重なりがあることを示しています。
図のフェーズの下向き矢印はそれぞれ、フェーズ内の反復を表しています。メンテナンスサークルが小さく、オブジェクト指向パラダイムを採用したことでメンテナンス時間が短縮されたことを示しています。コーディングフェーズと統合テストフェーズの間に大きな重複があるということは、2つのアクティビティの間に大きな重複があることを示しています。コーディングフェーズの「単体テスト」は、コーダー自身によって行われます。
ウォーターフォールモデルと比較すると、ウォーターフォールモデルは問題指向のソフトウェアモデルであり、ファウンテンモデルはオブジェクト指向分析のモデルです。ファウンテンモデルのさまざまなアクティビティには重複があり、各部分は完成後に精度が必要です。時間を節約する。
7.オブジェクト指向分析モデル
オブジェクト指向分析とは、システム開発時にシステム事業調査を行った後、オブジェクト指向思考に基づいて問題を分析することです。
プロトタイプ開発はオブジェクトの発見を指し、オブジェクトもプロトタイプ開発を指します。プロトタイプ開発は他のアクティビティを統合してすべてのオブジェクトを見つけるためです。初期のプロトタイプは顧客のニーズを確認するために使用され、後期のプロトタイプはユーザーに配信する前に使用状態を変更するために使用されます。確立されたユースケース図は、ユーザーの使用状況/需要状況の図です。オブジェクトの検出は、分析モデルを確立するために必要な操作であり、必要な部分です。オブジェクトの詳細な説明と発見、属性とサービスの定義、構造と接続の確立、双方向矢印によるトピックの分割、集中化または分散可能なモデル内のコンポーネントの定義とテキストによる説明の詳細な分析。相互作用図、状態図、およびアクティビティ図の確立は、オプションの補助モデルです。
8.オブジェクト指向設計モデル
オブジェクト指向設計モデルは、問題領域、人間とコンピューターの相互作用、タスク管理、およびデータ管理の4つの主要なシステムに分けられます。
右側は主にオブジェクト指向分析モデルです。5つのプロセスの間に厳密な階層はありません。最初に、一部のオブジェクトが抽出され、属性とサービスに従って1つのクラスにグループ化されます。クラスが多い場合は、構造があります。分割。より多くの構造がある場合トピックに分割されます。オブジェクトは常に検出されているため、新しいオブジェクトが検出されると、クラスとオブジェクトの分割が再開されます。
9.モデリングプロセスのブロック図
ソフトウェアモデルを構築するときは、事前の知識、演繹分析、帰納的手順、および目標の調整を行い、モデルを構築してから、信頼性分析を実行して最終モデルを取得する必要があります。
ソフトウェアモデルを構築するときは、特定の事前知識が必要です。
演繹分析は、論理的に正しく、数学的に厳密な意味で実行する必要があります。
帰納的モデリングの主な情報源は実験データであり、その信頼性分析は、帰納的手順が数学的および論理的に実行されているかどうかを確認することです。
10.モデリングのプロセス全体
概念モデルがインスタンス化され、コンピューターの実行に必要な設計モデルに変換されます。概念モデルの境界クラスは、操作インターフェースまたはシステムインターフェースに変換できます。制御クラスは、コンピュータプログラムまたは制御プログラムに変換できます。エンティティクラスは、データベース、ドキュメント、またはその他の永続的な特性を持つクラスに変換できます。
9つの凡例を完了する-5つのビューを完了する-3つの変換を完了する
9種類の凡例：ユースケース図、クラス図、オブジェクト図、状態図、シーケンス図、コラボレーション図、アクティビティ図、コンポーネント図、配置図。
5つのビュー：ユースケース、ロジック、コンポーネント、同時実行性、および展開。
3つの変革：現実-ビジネスビジネス-コンセプトコンセプト-デザイン。
概念モデル：元の要件は上向きにマッピングされ、コンピューターにはより高いレベルの抽象化が下向きに提案されます。
境界タイプ：インターフェース。コンピューター上のすべての操作は、インターフェースを介して実行する必要があります。
エンティティクラス：ビジネスエンティティのインスタンス化の結果。実際のビジネスでは使用されないが、コンピュータロジックを変換するときに必要な制御情報を追加します。
制御カテゴリ：元の要件の動的情報、つまり、ビジネスまたはユースケースシナリオのステップとアクティビティ。