システム アーキテクチャ: ソフトウェア エンジニアリングの実際の試験問題の知識ポイント

リソース

情報システム開発手法

知識のポイント

トップダウンとボトムアップ

トップダウン設計は、与えられた問題を再帰的に分析して、与えられた問題に基づいて多数の小さな基本問題を生成することを指しますが、ボトムアップはその逆の設計手法で、既存のコンポーネント (基本問題) に基づいて、特定の順列を介して設計することを指します。と組み合わせて、解決すべき問題が最終的に解決されます。2 つの手法の定義から、トップダウン設計手法は問題の分解を重視するのに対し、ボトムアップ設計手法はコンポーネント (基本的な問題) の再利用を重視することがわかります。トップダウンでレイヤーごとに分解する方法を使用すると、問題をより適切に解決できます。また、一般的な問題の場合は、既存のコンポーネントを使用すると、より早く目標を達成できます。

形式的手法

形式的手法は、システムや開発プロセスの厳密な処理と実証を可能にする強固な数学的基礎を備えた手法であり、その主な利点は、アプリケーションの問題や実装を数学的に表現して検討できることにあります。ただし、高度な数学的基礎が必要であり、複雑なシナリオには適しておらず、広く使用されていません。

構造化されたアプローチ

  • 構造化手法は機能指向開発手法としても知られ、構造化分析、構造化設計、構造化プログラミングなどの段階が含まれます。上から下までシステムを開発し、段階的に改善を図ります。
  • デメリットは、開発サイクルが長く、需要の変化に対応するのが難しいことです。
  • 構造化分析の核となるのはデータフロー図とデータディクショナリであり、データフロー図を解析することでプログラム構造図を導き出すことができます。
  • 構造化分析手法では、機能モデリングにはDFD、動作モデリングには状態遷移図、データモデリングにはER図が用いられます。

アジャイル手法

アジャイル手法はオブジェクト指向であり、次の 3 つの特徴があります。

  • 適応性: 変化を受け入れ、常に変化することを指します。
  • 人間本位: 人間本位であり、人間の特性を最大限に発揮することを指します。
  • 反復的かつ増分: 各リリースでは、元のバージョンに基づいて機能要件が拡張され、最終的にすべての要件が満たされます。

アジャイル手法は、要件が大幅に変更されるか、初期の要件が十分に明確ではないプロジェクトに適しています。

クリーンルームソフトウェアエンジニアリング

エラーを発見して排除するための主なメカニズムとして (従来のテストではなく) 正確性の検証を使用し、統計的品質管理手法を強調するのは理論的すぎます。

サービス指向のアプローチ

粗粒度で疎結合の標準ベースのサービスに基づいて、システムの柔軟性、再利用性、進化性が強化されます。

オブジェクト指向アプローチ

オブジェクト指向開発手法を使用する場合、状態図とアクティビティ図を使用してシステムの動的な動作をモデル化できます。
ここに画像の説明を挿入しますオブジェクト指向設計では、境界クラスはインターフェイス制御、外部インターフェイス、および環境分離を実装します。コントロール クラスは、他のクラスを調整および制御して、一緒に機能を完了します。
ここに画像の説明を挿入します

迅速なアプリケーション開発

基本コンポーネント開発手法の考え方を利用し、多数のスレッドを使用してシステムを開発するため、高速ですが、モジュール性の高いシステムにのみ適しています。

スパイラルモデル

プロトタイプモデルをベースに拡張され、ソフトウェア開発プロセス全体を目標設定、リスク分析、開発、効果検証、レビューという複数の段階に分割します。小規模な開発チームによるプロジェクトに適しています。
ここに画像の説明を挿入します

ソフトウェアのプロセスとアクティビティ

ここに画像の説明を挿入します

オープンソースの開発手法

プログラム開発者が地理的に広く分散している開発チームに適しています

ユーティリティ主導の開発アプローチ

プログラミング開発者は、リード プログラマと「クラス」プログラマに分かれます。

統合プロセスモデル RUP

3 つの主要な機能:

  • アーキテクチャ中心:
  • ユースケース主導:
  • インクリメントと反復: ユーザーの積極的な参加を重視し、初期の反復で高リスクで価値の高い問題を解決します。

ここに画像の説明を挿入します
開発サイクルは 4 つの段階で構成されます

  • 初期: ビジネス モデルを確立し、プロジェクトの境界を決定します。
  • 改良: 問題を分析し、完​​全な構造を確立します。
  • ビルド: すべての機能が開発され、製品に統合されます。
  • 引き継ぎ: リリースバージョンを作成し、フィードバックに基づいて調整を行います。

コンポーネントベースのソフトウェア開発

不一致問題の
ここに画像の説明を挿入します論理コンポーネント モデルは、システムが適切な機能を提供することを保証するシステム設計の青写真を記述し、物理コンポーネント モデルは、システムのパフォーマンス、スループット レート、その他の非機能的属性を理解するために使用されます。

リバースエンジニアリング

いわゆるリバース エンジニアリングは、既存のプログラムを分析し、ソフトウェアの特定の形式の記述をより抽象的な形式のアクティビティに変換することです。
ここに画像の説明を挿入します

リバース エンジニアリングから得られる情報は次のように分類できます。

ここに画像の説明を挿入します

UML

4+1ビュー
ここに画像の説明を挿入します
ここに画像の説明を挿入しますここに画像の説明を挿入します

必要

  • すべての要件を同等に重要なものとして扱うのではなく、優れた要件ステートメントを優先する必要があります。
  • 要件変更プロセス: 問題分析と変更の説明、変更分析とコスト計算、および変更の実装。
  • プロセス能力成熟度モデルのレベル 2 に到達するには、組織には 6 つの主要なプロセス領域が必要です。
  • 要件の属性には次のものが含まれますここに画像の説明を挿入します。 JRP (共同要件計画) は、要件を取得するためのよりコストのかかる方法です。
  • 需要追跡機能チェーンここに画像の説明を挿入します
  • 要件定義方法ここに画像の説明を挿入します

おすすめ

転載: blog.csdn.net/weixin_43249758/article/details/132568966