2023年システムアナリスト --- 要件エンジニアリング

1. 要件エンジニアリング

1. 要件エンジニアリングの概要:

1. 要件開発活動: 要件取得、要件分析、要件定義、要件検証
2. 要件管理活動: 変更管理、バージョン管理、要件追跡、要件ステータス追跡

2. 需要分類:

1. ニーズの階層:

1. 1. ビジネス要件：これは、システムに対する企業または顧客の高レベルのターゲット要件を指します。通常、プロジェクトの投資家、製品を購入する顧客、顧客ユニットの管理担当者、マーケティング部門または製品計画部門などからのものです。プロジェクトのビューと範囲は、ビジネス要件によって決定でき、将来の開発作業の基礎を築くことができます。
   2. ユーザー要件: ユーザーの特定の目標、またはユーザーがシステムに完了を要求するタスクを記述します。つまり、ユーザー要件は、ユーザーがシステムでできることを記述します。
   3. システム要件：機能要件、非機能要件、設計上の制約など、システムの観点からソフトウェアの要件を記述することです。機能要件は動作要件とも呼ばれ、開発者がシステムに実装する必要があるソフトウェア機能を指定し、ユーザーはこれらの機能を使用してタスクを完了し、ビジネス要件を満たします。非機能要件とは、システムが備えなければならない属性または品質を指し、ソフトウェアの品質属性とその他の非機能要件に細分することができます。制約または補足仕様とも呼ばれる設計制約は、通常、システムに対する何らかの制約です。

1. QFD

1. 1. 品質機能展開 QFD は、ユーザー要件をソフトウェア要件に変換するテクノロジです。その目的は、ソフトウェア エンジニアリング プロセスにおいてユーザーの満足度を最大化することです。QFD は、ソフトウェア要件を次の 3 つのカテゴリに分類します。

1. 1. 1. 一般要件（基本要件）：システムが実現すべきとユーザーが考える機能や性能は、実現すればするほどユーザーの満足度が高くなります。
      2. 期待される要件：ユーザーは、システムが機能または性能を備えていることを当然のことと考えていますが、それらの機能または性能に対する要件を正しく記述できていません。期待が満たされない場合、ユーザーは不満を抱く
      3. Exciting needs (予期せぬニーズ): ユーザーの要求の範囲外の機能または性能. これらのニーズの実現はユーザーをより幸せにしますが、実現の失敗は購入の決定に影響しません.

1. PLECES フレームワーク:

1. 1. パフォーマンス (パフォーマンス): パフォーマンスは、企業の現在の運用効率を説明するために使用され、現在のビジネスの処理速度を分析できます (例: 応答時間、スループット)
   2. 情報: 情報およびデータ指標は、ビジネス データの入力、出力、および処理におけるさまざまな問題を説明するために使用されます。たとえば、データを取得できない、データが不正確であるなどです。
   3. 経済: 経済指標は、主にコストと利益の観点から企業の現在の問題を分析します; 例: 注文数の減少
   4. 制御: 情報システムのセキュリティと制御レベルを向上させる; 例: 身元認証
   5. 効率: 企業内の人、お金、および材料の使用効率を改善します。たとえば、時間、材料、およびリソースの無駄です。
   6. サービス: 顧客、サプライヤー、パートナー、顧客などのサービス プロバイダーに対する企業のサービス品質を向上させます。たとえば、システムの結果が不正確である、使いにくい、他のシステムと互換性がないなどです。

3. 要件開発 --- 要件取得方法

1. データの収集: システムとの接続

2. オブジェクト指向の要件分析

まず、オブジェクト指向の概念:

1. 1. オブジェクト: 属性 (データ) + メソッド (操作) + オブジェクト ID

クラス (エンティティ、コントロール、境界)

1. エンティティ クラスは要件内の各エンティティをマッピングし、エンティティ クラスは永続ストレージに保存する必要がある情報を保存します. たとえば、オンライン教育プラットフォーム システムは、学生クラスとコース クラスを抽出できます。エンティティ クラス。
2. 制御クラスは、ユースケースの作業を制御するために使用されるクラスです. 通常、動詞-目的語構造句 (動詞 + 名詞または名詞 + 動詞) から名詞に変換されます. 例: ユース ケース: "authentication" can制御クラス「authenticator」に対応し、認証に関連するすべての操作を提供します。
3. 境界クラスは、ユースケースの内外を流れる情報またはデータの流れをカプセル化するために使用されます。境界クラスは、すべてのウィンドウ、レポート、プリンター、スキャナー、その他のハードウェア インターフェイス、および他のシステムとのインターフェイスを含む、システムと外界との間のインターフェイスに配置されます。
4. 継承と一般化: 再利用のメカニズム
5. カプセル化: オブジェクトのプロパティと実装の詳細を非表示にし、インターフェイスのみを外部に公開します
6. ポリモーフィズム: 異なるオブジェクトが同じメッセージを受け取り、異なる結果を生成する
7. インターフェース: メソッド定義のみを持ち、実装を持たない特別なクラス
8. オーバーロード: クラスは、同じ名前でパラメーターの型が異なる複数のメソッドを持つことができます
9. メッセージとメッセージ通信: メッセージは非同期で通信されます

二、UML図の概念

1. 構造的問題: 最も静的な部分: クラス、インターフェース、コラボレーション、ユース ケース、アクティビティ クラス、コンポーネント、およびノー​​ドを含む
2. 行動トランザクション: メッセージ、アクション シーケンス、接続など、時間と空間でのアクションを表します。
3. グループ化取引: パッケージ、コンポーネントなどのジョイント ベンチャーと見なされる
4. 注釈トランザクション: UML モデルの解釈部分。モデルの要素を説明、図解、ラベル付けする

三、UML図の分類：

1. クラス ダイアグラム: クラス ダイアグラムは、一連のクラス、インターフェイス、コラボレーション、およびそれらの間の関係を記述します。
2. オブジェクト図: オブジェクト図は、一連のオブジェクトとそれらの間の関係を記述します。オブジェクト図は、クラス図で作成されたもののインスタンスと静的スナップショットを記述します。
3. コンポーネント図: コンポーネント図は、カプセル化されたクラスとそのインターフェイス、ポート、および埋め込みコンポーネントとコネクタで構成される内部構造を記述します。コンポーネント図は、システムの静的設計実装ビューを表すために使用されます。コンポーネント図は、小さなコンポーネントから大規模なシステムを構築するために重要です。コンポーネント図は、クラス図 (カプセル化されたクラスとそのインターフェース) のバリアントです。
4. 配置図: 配置図は、ランタイム処理ノードの構成と、それらに存在するコンポーネントを示しています。配置図は、アーキテクチャの静的な配置ビューを提供します。通常、ノードには 1 つ以上の配置図 (ソフトウェアとハ​​ードウェア間のマッピング) が含まれます。
5. 成果物図: システムの物理構造
6. パッケージ図: モデル自体によって分解された組織単位、およびそれらの間の依存関係
7. 結合構造図
8. ユース ケース ダイアグラム: システムと外部アクターとの相互作用。
9. シーケンス図 (sequence diagram): シーケンス図は、オブジェクト間の相互作用を示しながら、オブジェクト間でメッセージが送信される順序を強調する相互作用図 (Interaction diagram) の一種です。
10. コミュニケーション図 (コミュニケーション図) コラボレーション図、コミュニケーション図は相互作用図であり、メッセージを送受信するオブジェクトまたは参加者の構造的組織を強調します。
11. タイミング図: リアルタイム性を強調
12. 相互作用の概要図
13. 状態図。状態図は、状態、遷移、イベント、およびアクティビティで構成される状態マシンを記述し、状態図は、オブジェクトの動的エンティティ図を提供します。インターフェイス、クラス、またはコラボレーションの動作をモデル化するために特に重要であり、イベントによって引き起こされるオブジェクトの動作を強調します。これは、リアクティブ システムのモデル化に非常に役立ちます。状態遷移遷移。
14. アクティビティ図: アクティビティ図は、プロセスまたはその他のコンピューティング構造を、計算内の制御とデータの段階的なフローとして示します。アクティビティ図は、システムの動的ビューに焦点を当てています。これは、システムの機能モデリングとビジネス プロセス モデリングにとって特に重要であり、オブジェクト間の制御プロセスに重点を置いています。プログラム フローチャートと同様に、アクティビティ図はアクティビティの同時動作をサポートできます。

4、UML ダイアグラムの関係:

1. ユースケースの関係には、包含関係、拡張関係、汎化関係が含まれます

1. 1. 包含関係: 抽出されたパブリック ユース ケースを抽象ユース ケースと呼び、元のユース ケースを基本ユース ケースまたは基本ユース ケースと呼び、2 つ以上のユース ケースからパブリック動作を抽出できる場合、包含関係を使用して表現する必要があります。彼ら。
   2. 拡張関係: ユース ケースが明らかに 2 つ以上の異なるシナリオを混在させる場合、つまり、状況に応じて複数の分岐が発生する可能性がある場合、このユース ケースは基本的なユース ケースと 1 つ以上の拡張されたユース ケースに分けることができます。より明確になる可能性があります。
   3. 汎化関係: 複数のユース ケースが同様の構造と動作を共有する場合、それらの共通性は親ユース ケースとして抽象化でき、他のユース ケースは汎化関係のサブ ユース ケースとして使用できます。ユース ケースの汎化関係では、サブ ユース ケースは親ユース ケースの特殊な形式であり、サブ ユース ケースは親ユース ケースのすべての構造、動作、および関係を継承します。

1. クラス図、オブジェクト図の関係。

1. 1. 依存性: 1 つの変化が別の変化に影響を与える。
   2. 汎化関係、特殊、一般関係
   3. 関連関係: オブジェクト間の接続であるチェーンのセットを記述します
   4. 集約関係、全体と一部のライフサイクルが異なる
   5. 複合関係: 全体は部分と同じライフサイクルを持っています
   6. 実装関係：インターフェースとクラスの関係

3. システム設計

1.構造設計

1. 機能モジュール設計の原則

適度なモジュール サイズ: 50---10 行、500 行以下

スケジューリングの深さを最小限に抑えるための適切なシステムの深さと幅の比率

湿度制御モジュールのファンインとファンアウト: ファンアウト 3 ～ 4、通常は 7 以下、ファンインが大きいほど良い

単一のエントリ、単一の出口

モジュールのスコープはモジュール内にある必要があります

機能は予測可能であるべき

高凝集性と低カップリング

システムはレイヤーに分解されます

データの冗長性が低い

2. モジュールの独立性の測定

1. 集約: モジュール内の要素の組み合わせの緊密さを測定します

偶発的な集約: モジュールによって実行されるアクション間に関係がないか、非常に緩やかな関係しかありません

論理的集約: モジュール内の各コンポーネントは、論理的に類似した処理アクションを持っていますが、機能的な使用に関しては互いに何の関係もありません。

時間集約: モジュール内の各コンポーネントに含まれる処理アクションは同時に実行する必要があります

プロセス集約: モジュール内の各コンポーネントによって完了するアクションは関係ありませんが、特定の順序で実行する必要があります

通信の集約: モジュールの各コンポーネントによって完了するアクションは、同じデータを使用するか、同じ出力データを生成します

逐次集計: モジュール内の各部分について、前の部分によって処理されたアクションの最終的な出力は、後の部分によって処理されたアクションの入力です

機能集約: モジュールの内部部分はすべて全体に属し、同じ機能を実行し、各部分は機能を実現するために必要です。

1. カップリング: 異なるモジュール間の相互依存の程度を測定します

1. 1. 間接結合: 2 つのモジュール間に直接的な関係はなく、それらの接続はメイン モジュールの制御と呼び出しによって完全に実現されます。
   2. データ結合: 2 つのモジュールがデータ パラメータを介して相互に情報を交換します。
   3. マーカー結合: モジュールのグループは、パラメーター テーブルを介してレコード情報を渡します. このレコードは、単純な変数ではなく、特定のデータ構造のサブ構造です.
   4. 制御結合: 制御情報は、2 つのモジュール間で渡される情報に含まれます
   5. 外部結合: モジュールのグループはすべて、同じグローバル データ構造ではなく、同じグローバル単純変数にアクセスし、グローバル変数の情報はパラメーター テーブルを介して渡されません。
   6. パブリック結合: 情報は、共通データ領域を介して 2 つのモジュール間で受け渡されます
   7. コンテンツ結合: 1 つのモジュールが別のモジュールの内部情報を参照する必要がある

1. モジュールの 4 つの要素:

1. 1. 入力と出力: モジュールの入力ソースと出力先は同じ呼び出し元です。つまり、モジュールは呼び出し元から入力を取得し、それを処理してから、出力を呼び出し元に返します。
   2. 処理機能: モジュールが入力を出力に変換するために行う作業を指します。
   3. 内部データ: モジュール自体によってのみ参照されるデータを参照します。
   4. プログラムコード：モジュール機能を実現するために使用されるプログラムを指します

3. システム構成図

モジュール構造図とも呼ばれるシステム構造図（Structure Chart、SC）は、モジュール間の階層構造を含む、機能の実現とモジュール間の接続と通信を反映したソフトウェア概要設計段階のツールです。システム全体の構造。システム分析段階では、システム分析者は SA メソッドを使用して、DFD、データ ディクショナリ、および処理命令で構成されるシステムの論理モデルを取得できます。システム設計段階では、システム設計者は DFD からシステム初期化 SC を導き出すことができます。いくつかのルールに従って。一般的に使用される SC には、主に変換型、トランザクション型、および混合型が含まれます。

SC には、モジュール、モジュール間の呼び出し関係、モジュール間の通信、および補助制御シンボルの 4 つの部分が含まれます。

2. オブジェクト指向設計

1. 設計原則:

1. 1. システム設計 --- オブジェクト指向設計 --- 設計原則
   2. 単一責任の原則: 単一の目的を持つクラスを設計する
   3. 開発閉鎖原則: 拡張に対してオープン、変更に対してクローズ
   4. Li スタイルの置換原則: サブクラスは親クラスを置き換えることができます
   5. 依存性逆転の原則: 具体的な実装ではなく抽象化に依存し、実装ではなくインターフェイスへのプログラム
   6. インターフェイス分離の原則: 複数の専用インターフェイスを使用することは、単一の汎用インターフェイスを使用するよりも優れています
   7. コンポジションの再利用の原則: 継承関係ではなくコンポジションを使用して再利用を実現する
   8. デメテルの原理 (Least Known Principle): オブジェクトは、他のオブジェクトについて可能な限りほとんど知らない必要があります。

1. デザインパターン：

1. 1. 概念: C/S 構造などのソフトウェア設計における高レベルの決定は、アーキテクチャ パターンに属し、アーキテクチャ パターンは、ソフトウェア システムの開発プロセスで下された基本的な設計決定を反映します。
   2. 設計パターン: 特定の実装言語に関係なく、主にソフトウェア システムの設計に焦点を当てる
   3. 慣用的な使用法: ソフトウェア システムの設計と実装に焦点を当て、実装中に特定のプログラミング言語を使用してコンポーネント間の関係を記述する、最も低いレベルのモードです。各プログラミング言語には固有のモード、つまり言語のイディオムがあります. たとえば、参照カウントは C++ 言語のイディオムです。

1. デザインパターンの分類:

1. 1. 作成: オブジェクトの作成に関連し、インスタンス化プロセスを抽象化して、システムが確立し、そのオブジェクトを作成、構成、および表現する方法を支援します。クラス作成パターンは継承を使用してインスタンス化されるクラスを変更しますが、オブジェクト作成パターンはインスタンス化を別のオブジェクトに委譲します。

1. 1. 1. ファクトリーメソッドパターン
      2. 抽象ファクトリ メソッド パターン
      3. 試作パターン
      4. シングルトンパターン
      5. ビルダーパターン

1. 1. 構造パターンはクラスまたはオブジェクトの構成を扱い、構造設計パターンはクラスとオブジェクトを組み合わせてより大きな構造を取得する方法を扱い、構造パターンは継承メカニズムを使用してインターフェイスまたは実装を結合します。構造オブジェクトモードはインターフェースと実装の組み合わせではなく、いくつかのオブジェクトを組み合わせて新しい機能のいくつかのメソッドを実現する方法を説明します

1. 1. 1. アダプターパターン
      2. ブリッジモード
      3. コンビネーションモード
      4. デコレータパターン
      5. 外観モード
      6. フライ級モード
      7. プロキシモード

1. 1. 動作パターンには、アルゴリズムとオブジェクト間の責任の割り当てが含まれます. 動作パターンは、オブジェクトまたはクラスのパターンを記述するだけでなく、それらの間の通信パターンも記述します. 動作パターンは、継承メカニズムを使用して、クラス間の動作を割り当てます, モジュールクラスパターンとインタープリターを含むモード。Behavioral Object パターンは、継承の代わりにオブジェクト合成を使用します。一部の動作オブジェクト パターンは、ピア オブジェクトのグループがどのように協力して、単独では実行できないタスクを達成するかをモデル化します。

1. 1. 1. 責任パターンの連鎖
      2. コマンドモード
      3. 通訳モード
      4. イテレータ パターン
      5. メディエーターパターン
      6. メモモード
      7. オブザーバーパターン
      8. 状態モード
      9. 戦略パターン
      10. テンプレート メソッド パターン
      11. 来客パターン

4.WEB開発

1.寸法

1. 1. アーキテクチャの観点から: MVC、MVP、MVVM、REST、WebService、マイクロサービス
   2. 同時配信から：クラスター（負荷分散）、CDN
   3. キャッシュから: MemCache、Redis、Squid
   4. スレーブ データ: マスター スレーブ データベース (マスター スレーブ レプリケーション)、メモリ データベース、非正規化テクノロジ、NoSql、パーティションおよびテーブル テクノロジ、ビューおよびマテリアライズド ビュー
   5. 永続性の観点から: Hibernate、MyBatis
   6. 分散ストレージ: Hadoop、FastDFS、ブロックチェーン
   7. データエンコーディング: XML、JSON
   8. Web アプリケーション サーバー: Apache、WebSphere、Tomcat、Jboss、IIS
   9. セキュリティ: SQL インジェクション
   10. その他: 静的、ステートフルおよびステートレス、レスポンシブ Web デザイン、中間プラットフォーム

2.負荷分散

1. 1. アプリケーション層の負荷分散、

1. 1. 1. HTTP リダイレクト、HTTP リダイレクトはアプリケーション層のリクエスト転送です。ユーザーの要求は実際に HTTP リダイレクト負荷分散サーバーに到達し、サーバーはアルゴリズムの要件に従ってリダイレクトされます. リダイレクト要求を受信した後、ユーザーは再度実クラスターを要求します. 特徴: 導入は簡単だが、パフォーマンスは低い
      2. リバース プロキシ サーバーは、ユーザーの要求がリバース プロキシ サーバーに到着すると (Web サイトのコンピューター ルームに到着すると)、アルゴリズムに従って、リバース プロキシ サーバーがそれを特定のサーバーに転送します。一般的に使用される apache と nginx は、リバース プロキシ サーバーとして機能できます。機能: 展開は簡単ですが、プロキシ サーバーがパフォーマンスのボトルネックになる可能性があります。

1. 1. トランスポート層の負荷分散。

1. 1. 1. DNSドメイン名解決の負荷分散、DNSドメイン名解決の負荷分散は、ユーザーがDNSサーバーを要求したときにドメイン名に対応するIPアドレスを取得することであり、DNSサーバーは負荷分散後にサーバーIPを直接提供します。
      2. 特徴: HTTP リダイレクトよりも効率が高く、負荷分散サーバーを維持するコストが削減されます.ただし、アプリケーション サーバーに障害が発生した場合、DNS への通知が間に合わず、DNS 負荷分散の制御はドメイン ネーム サービス プロバイダーに委ねられます.ウェブサイトをこれ以上改善してより強力にすることはできません。
      3. NAT ベースの負荷分散、NAT ベースの負荷分散は、外部 IP アドレスを複数の IP アドレスにマップし、各接続要求を内部ノード アドレスに動的に変換します。
      4. 特徴: 技術は比較的成熟しており、一般的にはゲートウェイの位置にあり、ハードウェアで実現できます。この技術は、一般的に 4 層スイッチのように使用されます。

1. 1. ハードウェア負荷分散: F5
   2. ソフトウェア負荷分散: LVS、Nginx、HAproxy
   3. 静的アルゴリズム

1. 1. 1. ラウンドロビン アルゴリズム: サーバー要求を異なるノード (サーバー) に順番に呼び出します。
      2. 加重ラウンド ロビン アルゴリズム: 異なるノードの処理能力の違いを考慮する
      3. 送信元アドレス ハッシュ アルゴリズム: リクエストの送信元 IP アドレスに従って、それをハッシュ キーとして使用して、静的に割り当てられたハッシュ テーブルから対応するノードを見つけます。
      4. ターゲット アドレス ハッシュ アルゴリズム: 要求されたターゲット IP に従ってハッシュすることにより、対応するノードを見つけます
      5. ランダム アルゴリズム: ランダムな割り当て、シンプルだが制御不能

1. 1. 動的アルゴリズム (動的負荷)

1. 1. 1. 接続アルゴリズムの最小数: 各ノードの処理能力が同じ場合、現在アクティブなリクエストの数が最も少ないノードに新しいリクエストが割り当てられます。
      2. 加重最小接続数アルゴリズム: ノードの処理能力の違いを考慮して、最小接続数に従って割り当てます
      3. 加重パーセンテージ アルゴリズム: ノードの使用率、ハードディスクの速度、プロセスの数などを考慮して、使用率を使用して残りの処理能力を表します。

1. ステートフルおよびステートレスの問題:

1. 1. ステートレス サービスによる単一の要求の処理は、他の要求に依存しません。つまり、強力な要求を処理するために必要なすべての情報は、要求に含まれているか、外部 (データベースなど) から取得できます。サーバー自体はタスク情報を保存しません。
   2. ステートフル サービス (stateful service) はその逆で、それ自体で一部のデータを保存し、連続するリクエストは関連しています

1. CDN コンテンツ配信ネットワーク

1. 1. CND の正式名称は Content Delivery Network、つまりコンテンツ配信ネットワークです。基本的な考え方は、データ伝送の速度と安定性に影響を与える可能性のあるインターネット上のボトルネックとリンクを可能な限り回避して、コンテンツ伝送をより高速かつ安定させることです。

1. 永続化テクノロジ: ORM (オブジェクト リレーショナル マッピング): オブジェクトとリレーショナル データ間のマッピング

1. 1. クラス: データベースのテーブル
   2. オブジェクト: データベース内のレコード、行データ
   3. オブジェクト プロパティ: フィールド

1. キャッシュ

1. 1. MemCache: 動的 Web アプリケーションがデータベースの負荷を軽減するための高性能分散メモリ オブジェクト キャッシング システムです。Memcache は、メモリ内に統合された巨大なハッシュ テーブルを保持します。これを使用して、画像、ビデオ、ファイル、データベースの検索結果など、さまざまな形式でデータを格納できます。
   2. Redis: ANSIC 言語で記述されたオープン ソースであり、ネットワークをサポートし、メモリ ベースおよび永続的なログ タイプ、キー値データベース、および多言語 API を提供します。
   3. 一般的なクラスター スライス方法:

1. 1. 1. クライアントのシャーディング: クライアントは、キーのハッシュ値を介して異なるサーバーに対応します
      2. ミドルウェアはシャーディングを実装します: Codis などのアプリケーション ソフトウェアと Redis の間で、ミドルウェアはサービスからバックグラウンド Redis ノードへのルート割り当てを実装します
      3. クライアント/サーバーの共同シャーディング: クライアントとサーバーが協力してシャーディングを完了します

1. 1. 分散ストレージ

1. 1. 1. マスター/スレーブ モード (Master、Slave) モード: 1 つのマスターと複数のスレーブ、障害の場合の手動切り替え
      2. Sentinel モード (Sentinel): 1 つのマスターとセンチネルを備えた複数のスレーブ。マスター ノードの障害により、新しいマスター ノードが自動的に選択されます。
      3. クラスターモード (Cluster): ノードベースのピアツーピアクラスター、スロット、異なるスロットの情報は異なるノードに保存されます