ソフトウェア試験システムアーキテクチャのケーススタディ（ソフトウェアエンジニアリング関連の概念）

その他の関連推奨事項:
ソフトウェア試験システム アーキテクチャのケース スタディ (アーキテクチャ設計に関連する概念)
ソフトウェア試験システム アーキテクチャのケース スタディ (Redis)関連概念)
システム アーキテクチャのマイクロサービス アーキテクチャ
システム アーキテクチャ設計のマイクロカーネル アーキテクチャ

コラム:システム アーキテクト

1. フローチャートとデータフロー図の違いと関連性

フローチャート: データ入力から出力までのアプリケーションの論理プロセスをグラフィカルに表示し、処理プロセスの制御フローを説明します。

データ フロー図: グラフィカル ツールとして、ビジネス処理プロセス、システム境界内に含まれる機能、およびシステム内のデータ フローを示すために使用されます。

この 2 つの主な違いは次のとおりです。
(1) データ フロー図の処理プロセスは並列化できます
< a i=3 >;フローチャートは、ある時点では 1 つの処理プロセスにのみ存在できます。 (2) データ フロー図はシステムのデータ フローを示し、フローチャートはシステムのを示します。 制御フロー。
(3) データ フロー図はグローバル処理プロセスを示しており、プロセスは異なるタイミング標準に従います。フローチャート処理は一貫したタイミング標準に従います。 (4) データ フロー図はシステム分析のロジック モデリング段階に適しており、フローチャートはシステム分析に適しています。 物理モデリング段階で設計します。

2. ステート図とアクティビティ図の意味と違い

状態チャート: 主にオブジェクトの存続期間中の動的な動作を説明するために使用され、オブジェクトが経験する状態シーケンス、状態遷移を引き起こすイベント、およびそれに伴うアクションを示します。状態遷移。

アクティビティ図は、システムのワークフローと同時動作を説明するために使用できます。アクティビティ図は実際には状態図の特殊な形式とみなすことができ、アクティビティ図内の 1 つのアクティビティが終了すると、すぐに次のアクティビティに入ります (状態図では、状態の転送にはイベントのトリガーが必要な場合があります)。

この 2 つの最大の違いは次のとおりです。
状態図は動作の結果の記述に重点を置いています、一方、アクティビティ この図は、動作を説明するアクションに焦点を当てています。第 2 に、アクティビティ ダイアグラムは同時動作を記述できますが、ステートチャートでは記述できません。

3. アクティビティ図とフローチャートの違い

• アクティビティ図は、オブジェクトのアクティビティの順序関係に続くルールを記述します。アクティビティ図は、処理プロセスではなくシステムの動作を示すことに重点を置いているのに対し、フローチャートは処理プロセスの記述に重点を置いています。

• フローチャートは通常、順次プロセスに限定されますが、アクティビティ図は同時プロセスをサポートできます。

• アクティビティ図はオブジェクト指向ですが、フローチャートはプロセス指向です。
  
  

4. データフロー図に含まれる基本要素とその機能

データ フロー: データ フローはシステム内でデータが移動するパスであるため、固定コンポーネントを含む一連のデータで構成されます。

外部エンティティ: システムの外部のエンティティを表します。これには、人、物、その他のソフトウェア システムなどがあります。

プロセッシング (処理): プロセッシングはデータを処理する単位であり、特定のデータ入力を受け取り、それを処理して出力を生成します。

データ ストレージ: 情報の静的ストレージを表します。これには、ファイル、ファイルの一部、データベースの要素などが含まれます。

5. データフロー図のバランス原則:

(1) サブグラフと親グラフのバランス:
は、DFD サブグラフの境界上の入出力データ フローがその親グラフに応じて処理される必要があることを意味します。入出力データ フローの一貫性が維持されます。

親グラフ内の特定のプロセスのデータ フローがサブグラフ内の複数のデータ フローに対応し、サブグラフ内のこれらのデータ フローを構成するすべてのデータ項目が親グラフ内のこのデータ フローと正確に等しい場合、それらは次のようになります。まだバランスが取れています。

(2) サブグラフ内: 処理の入力と出力のバランスをとる必要があります。
 その中には、データ フロー図によくあるエラーが 3 つあります。

• [ブラックホール] プロセスには入力データ フローのみがあり、出力データ フローはありません。
• [奇跡] プロセスには出力データ ストリームのみがあり、入力データ ストリームはありません。
• [グレーホール] 処理された入力データ ストリームを処理して出力ストリームを生成できない場合。
  
  

6. ユースケース間の関係

ユースケース間の主な関係は一般化、包含、拡張です。

（１）２つ以上のユースケースから共通の動作を抽出できる場合、包含関係を用いて表現できる。

(2) ユースケースが 2 つ以上の異なるシナリオを混在させる場合、つまり状況に応じて複数の分岐が発生する可能性がある場合、ユースケースは基本ユースケースと 1 つ以上の拡張ユースケースに分けることができます。

(3) 複数のユースケースが同様の構造と動作を共有する場合、その共通性を親ユースケースに抽象化し、他のユースケースを汎化関係の子ユースケースとして使用することができます。

7. クラス間の関係とその基本的な意味

依存関係: あるものの変更は別のものに影響を与えます。

一般化関係: 特殊/一般関係。

関連付け: オブジェクト間の接続であるチェーンのセットを記述します。

集約関係: 全体と部分のライフサイクルは異なります。

結合関係: 全体と部分のライフ サイクルは同じです。

実装関係: インターフェイスとクラスの関係。

8. オブジェクトモデル、動的モデル、機能モデルの意味とそれらの関係

• オブジェクト モデル: システム データ構造を記述するために使用されます。
• 動的モデル: システム制御構造を記述するために使用されます。
• 機能モデル: システム機能を説明するために使用されます。

これら 3 つのモデルは、データ、制御、操作などの共通概念を持ちながらも重点が異なり、システムの実質的な内容をさまざまな側面から反映し、対象となるシステムの要件を包括的に反映します。

機能モデルはシステムが「何を行うべきか」を指定し、動的モデルはそれをいつ実行するかを明確に指定し、オブジェクト モデルは物事を実行するエンティティを定義します。

9. デザイン カテゴリは通常 3 つのカテゴリに分類され、これら 3 つのカテゴリの責任は次のとおりです。

(1)エンティティ クラス。エンティティ クラスは要件内の各エンティティをマップし、ユーザーや製品など、永続的なストレージに保存する必要がある情報を保存します。

(2)コントロール クラス。コントロール クラスは、ユース ケースの作業を制御するために使用されるクラスであり、1 つまたは複数のユース ケースに固有のコントロールの動作をモデル化するために使用されます。例えば、決済、仕入れなどです。

(3)境界クラス。境界クラスは、ユースケースの内外を流れる情報またはデータ フローをカプセル化するために使用されます。たとえば、ブラウザ、ショッピング カートなどです。

10. 非機能要件の分類とその意味

• 動作要件: システムがタスクを完了するために必要な動作環境要件と、将来起こり得るシステム要件の変更に対応する方法を指します。
• パフォーマンス要件: システム パフォーマンス要件の指標。一般的なものには、応答時間、スループット レートが含まれます。
• セキュリティ要件: システムのクラッシュを防ぎ、データのセキュリティを確保するために必要な保護手段または予防措置。
• 文化的要件: このシステムを使用するさまざまなユーザー グループによって提示される、システム固有の要件。

その他の関連推奨事項:
ソフトウェア試験システム アーキテクチャのケース スタディ (アーキテクチャ設計に関連する概念)
ソフトウェア試験システム アーキテクチャのケース スタディ (Redis)関連概念)
システム アーキテクチャのマイクロサービス アーキテクチャ
システム アーキテクチャ設計のマイクロカーネル アーキテクチャ

コラム:システム アーキテクト