建築
シーン
シナリオ アーキテクチャ評価を行う場合、一般に、最初に特定の品質目標を正確に取得し、それをアーキテクチャの品質を決定する基準として使用する必要があります。シナリオ これらの目標を導き出すために使用されるメカニズム。シナリオは、利害関係者の観点からシステムとの対話を簡単に説明したものです。アーキテクチャの評価では、一般に、刺激、環境、反応の 3 つの側面を使用してシーンを説明します。
システム構造（アーキテクチャ）の評価を行う場合、一般に、まず具体的な品質目標を正確に取得し、それを基準としてアーキテクチャの品質を判断する必要があります。これらの目標に到達するために使用されるメカニズムをシナリオと呼びます。シナリオは、利害関係者の観点からシステムとの対話を簡単に説明したものです。アーキテクチャの評価では、シーンは通常、刺激、環境、反応の 3 つの側面で説明されます。刺激は、利害関係者がシステムとの対話をどのようにトリガーするかを説明または説明するシナリオの一部です。たとえば、ユーザーが特定の機能をアクティブ化したり、メンテナンスが特定の変更を加えたり、テスターが特定のテストを実行したりすることがあり、これらはすべてシナリオに対する刺激となります。環境は、刺激が発生したときの状況を表します。たとえば、システムの現在の状態はどうなっているでしょうか? 特別な制約はありますか? システムに大きな負荷がかかっていませんか? 特定のネットワーク チャネルがブロックされているかどうかなど。応答とは、システムがアーキテクチャを通じて刺激にどのように応答するかを指します。たとえば、ユーザーが要求した機能は満たされていますか? 保守者の変更は成功していますか? テスターのテストは成功していますか? などです。
ソフトウェア
ソフトウェアの再利用
垂直的再利用と水平的再利用に分けられます。
- 垂直再利用とは、電力システムのみで使用されるコンポーネントなど、特定の垂直分野に限定された再利用を指します。
- 水平再利用とは、標準関数ライブラリなど、どのソフトウェアでも利用できる一般的な分野での再利用を指しますので、水平再利用になります。
ソフトウェアの再利用
ソフトウェア再利用プロセス: 作成、再利用、サポート、管理の 4 つのプロセス
- 作成:再利用者のニーズを満たす再利用可能なアセットを定義して提供します
- 再利用: 再利用可能な資産を使用してアプリケーション ソフトウェア製品を作成します。
- サポート：リユース資産の取得・管理・保守を総合的にサポート
- 管理: 計画の実行、立ち上げ、リソース、追跡、およびその他のプロセスの調整
SDE
ソフトウェア開発環境 (SDE) は、ソフトウェアのエンジニアリング開発と保守をサポートするために使用されるソフトウェア セットを指し、ソフトウェア ツール セットと環境統合メカニズムで構成されます。
ソフトウェア開発環境は、プラットフォーム統合、データ統合、インターフェイス統合、制御統合、プロセス統合など、複数の統合メカニズムをサポートする必要があります。ソフトウェア開発環境は、チームの作業スタイルをサポートし、構成管理を提供する必要があります。環境のサービスは、分析、設計、プログラミング、デバッグ、ドキュメント化などのさまざまなソフトウェア開発活動をサポートするために使用できます。より完全なソフトウェア開発環境には、通常、ソフトウェア開発の一貫性と完全性の維持、構成管理とバージョン管理、データの複数の表現と異なる形式間の自動変換、情報の自動変換など、さまざまな機能が備わっています。制御と管理、および開発方法論のサポート。ソフトウェア開発環境には、統合、オープン性、スケーラビリティ、データ形式の一貫性、統一されたユーザー インターフェイス スタイルという特徴があり、ソフトウェアの生産性を大幅に向上させることができます。
ソフトウェア開発環境は、複数の統合メカニズムをサポートする必要があります。さまざまな機能に応じて、統合メカニズムは、環境情報ライブラリ、プロセス制御およびメッセージ サーバー、および環境ユーザー インターフェイスの 3 つの部分に分けることができます。
- 環境情報ベース。環境情報ベースはソフトウェア開発環境の中核であり、システム開発に関連する情報を保存し、情報の交換と共有をサポートするために使用されます。環境情報データベースには、主に、開発過程で生成される解析書、設計書、テストレポートなど開発対象システムに関する情報と、システムから提供されるサポート情報の2種類の情報が格納されています。ドキュメント テンプレート、システム構成、プロセス モデル、再利用可能なコンポーネントなどの環境。
- プロセス制御およびメッセージサーバー。プロセス制御サーバーとメッセージ サーバーは、プロセス統合と制御統合を実現するための基盤です。プロセス統合では、特定のソフトウェア開発プロセスの要件に応じてツールが選択され、組み合わせられますが、制御統合により、ツール間の並行通信と共同作業が可能になります。
- アンビエント ユーザー インターフェイス。環境ユーザー インターフェイスには、環境インターフェイス全体と、環境インターフェイスによって均一に制御されるさまざまな環境コンポーネントおよびツールのインターフェイスが含まれます。統一された一貫性のあるユーザー インターフェイスはソフトウェア開発環境の重要な機能であり、環境の利点を最大限に発揮し、ツールを効率的に使用し、ユーザーの学習負担を軽減することが保証されます。
道具
ソフトウェア・システムツールには多くの種類があり、統一した分類方法を確立することが困難です。ソフトウェア ツールは通常、ソフトウェア プロセスの活動に応じて、ソフトウェア開発ツール、ソフトウェア メンテナンス ツール、ソフトウェア管理ツール、およびソフトウェア サポート ツールに分類できます。
- ソフトウェア開発ツール: 要件分析ツール、設計ツール、コーディングおよびデバッグ ツール。
- ソフトウェア保守ツール: バージョン管理ツール、文書分析ツール、開発情報ベース・ツール、リバース・エンジニアリング・ツール、およびリエンジニアリング・ツール。
- ソフトウェア管理およびソフトウェア サポート ツール: プロジェクト管理ツール、構成管理ツール、ソフトウェア評価ツール、およびソフトウェア開発ツールの評価と選択。
書類
プロジェクトの成功には、予備的なプロジェクト スコープ ステートメントに文書化された主要な成果物、前提条件、および制約に基づいて、詳細なプロジェクト スコープ ステートメントを準備することが重要です。スコープ定義への入力には以下が含まれます。 ① プロジェクト憲章。プロジェクト憲章または初期範囲記述がプロジェクト実行組織内で使用されない場合は、詳細なプロジェクト範囲記述を作成するために、同じ情報をさらに収集して作成する必要があります。② プロジェクトスコープ管理計画。③組織プロセス資産。④ 変更申請を承認しました。
文書管理のルールと方法 情報システム文書の標準化された管理は、主に文書作成仕様、図表番号付けルール、文書カタログ作成基準、文書管理システムなどのいくつかの側面に反映されています。
ユーザードキュメント
ユーザードキュメントは主に、提供されたシステムの機能と使用方法を説明しており、これらの機能がどのように実装されるかについては考慮されていません。ユーザー ドキュメントはシステムを理解するための最初のステップであり、ユーザーはシステムの正確な第一印象を得ることができます。ユーザー マニュアルには、少なくとも次の 5 つの側面が含まれている必要があります。
機能の説明: システムで何ができるかを説明します。
インストール ドキュメント: システムのインストール方法と、システムを特定のハードウェア構成に適応させる方法について説明します。 ユーザー
マニュアル: システムの使用を開始する方法を簡単に説明します。 （よく使うシステム機能の使用例や、ユーザーの操作エラーからの回復・再開方法などを充実） 参考
マニュアル：ユーザーが使用できるシステム機能全般とその使用方法、発生する可能性のある諸問題について詳しく解説システム内 エラー メッセージの意味 (リファレンス マニュアルの主な要件は完全性であるため、通常は形式的な記述手法が使用されます)
オペレーター ガイド (システム オペレーターが必要な場合): オペレーターが操作中に発生するさまざまな状況にどのように対処すべきかを説明します。使用します。システムドキュメントは、問題定義、要件の説明から受け入れテスト計画に至るまで、システム実装に関連する一連のドキュメントです。システムの設計、実装、テストについて説明したドキュメントは、プログラムを理解して保守するために不可欠です。
システムドキュメント
設定項目
ソフトウェア製品の構成とは、ソフトウェア製品がライフ サイクルのさまざまな段階で作成する、さまざまな形式とバージョンのドキュメント、コンピューター プログラム、コンポーネント、およびデータの集合を指します。このセットの各要素は、製品構成では構成アイテムと呼ばれます。
構成アイテムは製品を構成する主要な要素であり、構成アイテムは主に次の 2 つのカテゴリに分類されます。
- 製品の一部である作業結果: 要件文書、設計文書、ソースコード、テストケースなど。
- プロジェクト管理および組織サポートのプロセス領域によって生成されるドキュメント: 作業計画、プロジェクト品質レポート、プロジェクト追跡レポートなど。これらのドキュメントは製品の一部ではありませんが、保存する価値があります。
構成アイテムのステータスには通常、ドラフト、正式リリース、および変更中が含まれます。
管理ツール
ソフトウェア構成管理ツールとは、構成項目の特定、バージョン管理、変更管理、監査、ステータス統計などの作業を支援するツールを指し、主に以下の機能があります。
- 構成サポート: 構成は、共通の目的を持つ中間ソフトウェア製品のグループであり、それぞれが構成アイテムと呼ばれます。ソフトウェア構成管理は、ユーザーが構成項目間のさまざまな関係を確立し、それらの関係を維持することをサポートします。これらの関係を維持することは、特定のタスク (ビルドなど) を完了し、システム開発全体に対する特定の変更の影響を特定するのに役立ちます。
- バージョン管理: バージョン管理は、ソフトウェア構成管理の基本要件です。バージョン管理はいつでも、どのバージョンでも復元できるようにすることができます。バージョン管理は、各構成アイテムの開発履歴も記録するため、バージョン間のトレーサビリティが保証され、バグの発見に役立ちます、バージョン管理は並行開発をサポートするための基礎です。
- 変更管理: ソフトウェアのライフサイクル全体にわたるソフトウェア変更の管理を指します。変更管理システムは、各変更に関する関連情報（変更の理由、変更の実施者、変更の内容など）を記録します。この情報は、発生したさまざまな問題を追跡するのに役立ちます。
- 構築サポート: ソフトウェア システムは多くの構成要素で構成されることが多く、システム全体の構築は複雑で時間のかかるプロセスです。ソフトウェア構成管理ツールは各構成要素の情報を記録および追跡できるため、ユーザーはシステムを自動的かつ迅速に構築でき、これらをバージョン管理と組み合わせることで、システムの複数バージョンの同時開発を効率的にサポートできます。
- プロセスサポート。このプロセスでは、ソフトウェアのライフサイクル全体を通じてさまざまな人々がシステム全体をどのように使用するかを詳しく説明しており、プロセス制御により、各ステップが正しい順序で適切な担当者によって実装されることが保証されます。プロセス制御はもともとソフトウェア開発環境の独立した部分であり、ソフトウェア構成管理もこの部分の機能を提供し始めました。ソフトウェア構成管理ツールはこのプロセスを完全にはサポートしておらず、サポート方法も大きく異なります。多くの管理ツールは、事前に定義されたライフサイクル モデルのみを提供し、開発のすべてのステップがこのモデルの規定に従って確実に実行されるようにします。
- チームサポート。チーム サポートとは、複数の開発者によるソフトウェア システムの同時開発を指します。ほとんどのソフトウェア システムには複数の開発者の参加が必要であり、効果的なチーム サポートは開発者にとって非常に役立ちます。チーム サポートには主に、ワークスペース管理、並行開発管理、リモート開発管理が含まれます (一部のソフトウェア構成管理ツールには開発者サポートも含まれます)。
テスト
統合テスト
ソフトウェア統合テストは、アセンブリテストや結合テストとも呼ばれます（サブシステムの場合はコンポーネントテストと呼ばれます）。単体テストに合格したモジュールを統合し、主にモジュール間の連携をテストします。
組立戦略に関しては、ワンタイム組立テストと増分組立（トップダウン、ボトムアップ、ハイブリッドを含む）の 2 つのタイプに分類できます。統合テストの計画は通常、ソフトウェアの概要設計段階で完了し、統合テストでは一般にブラック ボックス テスト手法が使用されます。
例
は、特定の参加者に表示される価値のある結果を生成する、システム内で実行される一連のアクションです。これは、システム参加者と対話し、システムによって実行できる一連のアクションを識別します。ユースケースモデルは、外部アクター (アクター) によって理解されるシステム機能を記述します。ユースケースモデルは、要件分析フェーズで使用され、システム開発者と利用者が議論を重ね、要求仕様について開発者と利用者が合意に達したものとして確立されます。2 つのユース ケース間の関係には、主に 2 つの状況があります: 1 つは、ステレオタイプ include で表される、再利用のための包含関係であり、もう 1 つは、ステレオタイプ extend で表される、異なる動作を分離するために使用される拡張です。
①包含関係：元の2つ以上のユースケースから共通の動作が抽出できる場合、またはユースケースの機能の一部をコンポーネントで実装することが重要であることが判明した場合、包含関係を用いて表現する必要がある。
②拡張関係: ユースケースが明らかに 2 つ以上の異なるシナリオを混合している場合、つまり、状況に応じて複数のことが起こる可能性がある場合、このユースケースを主要なユースケースと 1 つ以上の補助的なユースケースに分割することが可能であると結論付けることができます。より説明的で明確です。
ソフトウェアの品質
ソフトウェア品質とは、ソフトウェア システムまたはソフトウェア製品が指定または暗黙の要件を満たす能力を反映する全体的な特性と特性を指します。ソフトウェア品質管理とは、ソフトウェア開発プロセスの独立した検査活動を指します。この活動は、品質保証、品質計画、品質管理の 3 つの主要な活動で構成されます。ソフトウェア品質保証とは、ソフトウェア システムまたはソフトウェア製品の品質がユーザーの要件を完全に満たしていることを保証するために実行される計画的かつ組織的な活動を指し、高品質のソフトウェアを生産することを目的としています。ソフトウェア レビューは、ソフトウェア品質保証の主要な活動の 1 つです。
ユーザーインターフェイスのデザイン
ユーザー インターフェイス デザインの基本原則は、実践から要約されたいくつかのデザイン ルールです。Theo Maiidel は、インターフェイス デザインに関する著書の中で 3 つの「黄金律」を提案しています。
- ユーザーに制御を与える: ユーザーは、コンピューターによって制御されるのではなく、コンピューターを制御したいと考えています。そのため、人間とコンピューターのインターフェイスを設計するときは、次の原則に従う必要があります。対話モードの定義では、ユーザーに不必要または望ましくないアクションを強制することはできません。柔軟なインタラクションを提供し、ユーザーのインタラクションを中断したり取り消したりできるようにし、インタラクションを合理化し、スキル レベルの向上に応じてカスタマイズされたインタラクションを可能にし、ユーザーが内部の技術的な詳細を分離できるようにします。
- ユーザーの記憶負担を軽減する: ユーザーが覚えておく必要がある事項が増えるほど、システムとの対話時にエラーが発生する可能性が高くなります。したがって、優れたユーザー インターフェイス設計では、ユーザーの記憶負担が増加してはなりません。ユーザーのメモリ負荷を軽減するための設計原則は、短期メモリの要件を軽減すること、意味のあるデフォルトを確立すること、直感的なショートカットを定義すること、インターフェイスの視覚的なレイアウトは現実世界の比喩に基づいていること、および情報を漸進的な方法で提示することです。
- インターフェイスの一貫性を保つ: ユーザーは一貫した方法で情報を表示し、アクセスする必要があります。これは、すべての視覚情報が統一された設計標準に従って編成され、すべての画面表示がこの標準に準拠していることを意味します。入力メカニズムは限られたセットに制限され、ソフトウェア システム全体で一貫して使用されますが、タスクからタスクへのナビゲーション メカニズムは一貫して定義および実装されます。インターフェイスの一貫性を維持するための設計原則には、ユーザーが現在のタスクを意味のあるコンテキストに配置できるようにすること、アプリケーション ファミリ内の一貫性を維持すること、ユーザーがすでに使い慣れているユーザー対話モデルを変更しないことなどがあります。
EJB
EJB は、セッション Bean、エンティティ Bean、およびメッセージ駆動型 Bean に分類されます。1. セッション Bean: ビジネス ロジックの実装に使用され、ステートフルまたはステートレスにすることができます。クライアントがリクエストを行うたびに、コンテナはクライアントにサービスを提供するセッション Bean を選択します。セッション Bean はデータベースに直接アクセスできますが、多くの場合、エンティティ Bean を通じてデータ アクセスが実現されます。2. エンティティ Bean: O/R マッピングの実装に使用され、データベース内のテーブル レコードをメモリ内のエンティティ オブジェクトにマッピングする役割を果たします。実際、エンティティ Bean オブジェクトの作成は、新しいレコードの作成と同じです。エンティティ Bean を削除すると、エンティティ Bean も削除されますデータベースからレコードを削除し、エンティティ Bean を変更すると、コンテナはエンティティ Bean の状態をデータベースと自動的に同期します。3. Message-driven Bean は EJB3.0 で導入された新しい Enterprise Bean であり、JMS メッセージに基づいており、クライアントから送信された JMS メッセージのみを受信して処理できます。MDB は実際には非同期のステートレス セッション Bean です。クライアントは MDB を呼び出した後に待つ必要はなく、すぐに戻ります。MDB は顧客のリクエストを非同期に処理します。これは、注文処理など、リクエストを非同期で処理する必要がある状況に適しており、メソッド呼び出しによって結果が返されるまでクライアントが長時間待機することを回避できます。
安全性
リプレイ攻撃
リプレイ攻撃は、リプレイ攻撃、リプレイ攻撃、フレッシュネス攻撃とも呼ばれ、攻撃者がシステムを欺くという目的を達成するために、宛先ホストが受信したパケットを送信することを指し、主に身元認証プロセスで使用されます。認証の正確性を破壊します。Kerberos システムでは、リプレイ アタックを防ぐためにタイムスタンプ スキームを使用しています。このスキームでは、送信されるデータ パケットにタイムスタンプが付けられ、サーバーはタイムスタンプに基づいてそれがリプレイ パケットであるかどうかを判断できるため、リプレイ アタックを防ぐことができます。