-
ア
- アーキテクチャー
- IEEE によれば、その環境におけるシステムの最も重要な概念。特定時点でのソフトウェア・システムのアーキテクチャーとは、重要な コンポーネント間の インターフェースを通じた相互作用の構成を示します。
-
システムの組織の構成。アーキテクチャーは、インターフェースを通じて相互作用を行う部分、これらの部分を繋ぐ関係およびそれらを組み立てるための制約に、段階的に分解できます。インターフェースを通じて相互作用を行う部分には、 クラス、 コンポーネントおよび サブシステムが含まれます。
- アーキテクチャー・パターン
- [ BUS96] では、アーキテクチャー・パターンは次のように定義されています。「アーキテクチャー・パターンはソフトウェア・システム向けの基本的で構造的な組織スキーマを表現する。アーキテクチャー・パターンでは前もって定義された一連のサブシステムが提供され、その責務が明確になり、サブシステム間の関係を組織化するための規則やガイドラインが含まれる。」これが Rational Unified Process におけるアーキテクチャー・パターンの解釈です。これに少し追加すると、アーキテクチャー・パターンは特定規模におけるパターン (すなわち、ソリューション・テンプレート) であり、具体的なソフトウェア・アーキテクチャーのテンプレートです。ここではシステム規模のプロパティーおよび主としてサブシステム規模 (クラス・レベルでは ない) の関係が取り扱われます。アーキテクチャー・パターンはその性質上、アプリケーション・ドメインに依存せず、したがって特定ドメインの語彙がパターンの記述に盛り込まれないようですが、アーキテクチャー・パターンがそうなるように特殊化できないという理由は原則としては存在しません。分析パターンの場合と比較してください。ソフトウェア・アーキテクチャー説明書ではシステムで使用するアーキテクチャー・パターンを記述しています。
- アーキテクチャー・ビュー
- 与えられた視点からのシステム アーキテクチャーのビュー。主として、構造、モジュール性、基本コンポーネントおよびメイン制御フローが中心に取り上げられます。
- アーキテクチャー・メカニズム
- アーキテクチャー・メカニズムは、頻繁に遭遇する問題に対する共通の具体的なソリューションを表します。これは構造パターンであったり、振る舞いパターンであったりまたは両方のこともあります。Rational Unified Process (RUP) では、アーキテクチャー・メカニズムは分析メカニズム、設計メカニズム、そして実装メカニズムを包括する用語として使用されます。
- アーキテクチャー、実行可能
- 「 実行可能なアーキテクチャー」を参照。
- アーキテクチャーのベースライン
- 推敲フェーズが終了した時点での ベースライン。推敲フェーズでは、システムの基本構造と振る舞いが安定化されます。
- アクション
-
演算プロシージャーの抽象概念を形成する実行可能な演算の仕様。一般的なアクションによりシステムの状態が変化します。アクションはオブジェクトに対するメッセージの送信、リンクの変更または属性値の変更によって実現できます。
- アクション・シーケンス
-
連続したアクションに分解できる式。
- アクション状態
-
アトミックなアクションの実行を表す状態。 操作の呼び出しが一般的。
- アクセサー・メソッド
- オブジェクトによりそのインスタンス変数へのインターフェースを定義するために提供されるメソッド。インスタンス変数の値を戻すアクセサー・メソッドは get メソッドまたは getter メソッドと呼ばれ、インスタンス変数に値を割り当てるミューテーター・メソッドは set メソッドまたは setter メソッドと呼ばれます。
- アクセス・モディファイアー
- クラス、メソッド、属性へのアクセスを制御するキーワード。 Java におけるアクセス・モディファイアーはパブリック、プライベート、プロテクト、およびパッケージとなり、これがデフォルトとなります。
- アクター (インスタンス)
- システムまたはビジネスとやり取りする、システムの外界またはビジネスの外界にいる人や物。
- アクター (クラス)
- 一連のアクター・インスタンスが定義されるクラス。各アクター・インスタンスは、システムに対して、同じ役割を果たします。
-
ユース・ケースのユーザーがユース・ケースと相互作用する際に演じる、首尾一貫した一連の役割。アクターは通信する各 ユース・ケースにつき 1 つの役割を持ちます。
- アクターの汎化
- 子孫のアクター クラスから祖先のアクター クラスへのアクター汎化は、ユース・ケースで祖先が演じる役割が子孫のクラスによって継承されることを示します。
- アクティビティー・グラフ
-
状態マシンの特殊なもので、1 つ以上の 分類子が存在するときにプロセスのモデリングに使用されます。 ステートチャート図 の対比。「 アクティビティー図」と同義。
- アクティブ・オブジェクト
-
スレッドを所有し、制御動作を開始できる オブジェクト。 アクティブ・クラスのインスタンス。
- アクティブ・クラス
- システム内の制御を行うスレッドを示す クラス。
-
アクティブ・オブジェクトをインスタンスとして持つクラス。「 アクティブ・オブジェクト」を参照。
- アクティベーション
-
アクションを実行すること。
- アサーション
- 存在しなければばらないプログラムの状態、または、プログラムの実行中、特定のポイントでプログラム変数が満たす必要のある状態のセットを指定する論理式。
- 値
-
タイプ・ドメインの要素。
- アプリケーション
- (新しい技法を) 使用すること、技法を適用すること。
- 特定のビジネス (銀行、航空宇宙、株式仲買、保険、会計、在庫管理など) により決定される機能および業界関連のソフトウェアのこと。
- Java プログラミングにおいて、main() メソッドが存在する独立したスタンドアロンの Java プログラム。 アプレットの対比。
- アプリケーション・プログラミング・インターフェース (API)
- アプリケーション間での通信を可能にするソフトウェア・インターフェース。API はアプリケーション・プログラム内でコード化可能な一連のプログラミング言語構成体やステートメントで、基礎となるオペレーティング・システムまたはサービス・プログラムから提供される特定の機能やサービスを取得します。
- アプレット
- Web ブラウザー内で実行するために設計された Java プログラム。 アプリケーションの対比。
- 移行
- Rational Unified Process の 4 番目の フェーズ。ここでは、ソフトウェアがユーザー側に引き渡されます。
-
2 つの 状態間の関係で、最初の状態のオブジェクトが指定された特定のアクションを実行し、指定イベントが発生して条件が満たされると 2 番目の状態に移ります。このような状態の変更において、遷移が 発火するといいます。
- 委譲
-
メッセージ に応答してオブジェクトが別のオブジェクトにメッセージを発行する能力。委譲は継承の代わりに使用することもできます。 継承 の対比。
- 依存
-
モデル要素 の間の関係で、片方のモデル要素 (独立した要素) への変更が、もう一方のモデル要素 (依存した要素) に影響を与えるもの。
- 一時オブジェクト
-
スレッドまたはプロセスの実行によって生成され、その実行中にのみ存在するオブジェクト。
- イディオム
- [ BUS96] では、次のように定義されています。
「イディオムはプログラム言語特有の低レベル・パターンです。イディオムにより所定の言語の特徴を使って、コンポーネントの特別な側面あるいはコンポーネント間の関係を実装する方法が記述されます。」
これは実装パターンとも呼ばれます。UML で表現した具体的な設計を行い、たとえば、それを Java で実装する場合には、その言語向けによく使われる実装パターンを使うことになります。このようにイディオムは設計と実装をつなぎます。
- イベント
-
時間と空間の中で起こる意味のある出来事の仕様。 状態図 のコンテキストでは、イベントは 遷移を引き起こす刺激の発生を表します。
- イベントからメソッドへの接続
- Bean で生成されたイベントから、Bean のメソッドへの接続。リンクしたイベントが発生すると、メソッドが実行されます。
- 意味的な変更可能点
-
メタモデルのセマンティクスにおける変更点。メタモデル・セマンティクスをどの程度意図的に自由に解釈できるかを示します。
- インクリメンタル
- 反復開発戦略において、各 反復 サイクルでより多くの機能を追加していくことによりシステムを構築すること。
- インクリメント
- 継続した 反復の終了時点での 2 つのリリースの差分 (デルタ)。
- インスタンス
- クラス または タイプ の記述を満たす個別の実体。
-
一連の操作を適用でき、操作の結果を保存するための状態を持つ実体。「 オブジェクト」を参照。
- インターネット
- 相互接続されたネットワークの巨大な集合。ここでは、すべてのネットワークが TCP/IP プロトコルを使用し、1960 年代後半から 1970 年代前半にかけて ARPANET から発展しました。
- インターネット・プロトコル (IP)
- 基本的なインターネット機能を提供するプロトコル。
- インターネット・プロトコル・アドレス (IP アドレス)
- ネットワークに接続するコンピューターを一意に識別する数値のアドレス。たとえば、123.45.67.8 のようになります。
- インターフェース
- クラス または コンポーネント のサービスを仕様化するための 操作 の集合。
-
要素の振る舞いを特徴付ける名前の付いた一連の操作。
- インターフェース継承
-
特化された要素が汎化された要素のインターフェースを継承すること。実装は継承されません。 実装継承 の対比。
- イントラネット
- 企業または組織内のプライベート・ネットワーク。パブリック・インターネットにあるソフトウェアと同じ種類のものを使用していますが、内部でのみ使用されます。インターネットが普及するにしたがって、インターネットで使用されるツールの多くがプライベート・ネットワークで使用されるようになりました。たとえば、多くの企業には従業員のみが使用できる Web サーバーがあります。
- インポート
-
パッケージのコンテキストで、パッケージ内の クラスを特定のパッケージ (再帰的に埋め込まれているパッケージを含む) 内で参照できることを表す依存関係。 エクスポートの対比。
- インポート依存
- 元となる設計が任意の 設計パッケージにあり、対象となる設計がほかの設計パッケージにある、 ステレオタイプ化された設計の依存。インポート依存性を使用すると、対象となるパッケージのパブリック・コンテンツをソース・パッケージから参照できます。
- ウィジェット
- ここでは、ボタン、スクロールバー、ラベル、リスト・ボックス・メニュー、チェック・ボックスなどのウィンドウの形態を取るものを表す一般的な用語。
- ウォーターフォール・モデル
- [ IE610.12]では、ウォーターフォール・モデルを次のように定義しています。
「ソフトウェア開発プロセスのモデルです。このとき、概念フェーズ、要求フェーズ、設計フェーズ、実装フェーズ、テスト・フェーズ、インストールとチェックアウト・フェーズなどのアクティビティーがおそらく重複しますが、多少もしくはまったく反復することなくこの順序で実行されます。」
この定義は RUP で適用されています。このとき、「フェーズ」ではなく「作業分野」が使用されます。RUP の基本ワークフローには、ビジネス・モデリング、分析/設計、実装、テスト、導入といった名前のものがあります。ウォーターフォール型のモデル開発では、これらはたった一度、順番に、多少重複するかまったく重複せずに発生します。
- 永続オブジェクト
-
生成元のプロセスまたはスレッドが消滅した後も存在し続けるオブジェクト。
- エクスポート
-
パッケージのコンテキストで、要素を、それを含む名前空間の外から見えるようにすること。「 可視性」を参照。 エクスポート[OMA]、インポート と対比。
- 遠隔手続き呼び出し (RPC)
- 分散型プロシージャーへの関数呼び出しによって要求を出すコミュニケーション・モデル。手続きの位置は呼び出し元アプリケーションに対して透過となります。
- エンティティー・クラス
- システムと、関連する振る舞いに格納された情報をモデル化するのに使用する クラス 。汎用クラスで、多くの場合に永続的特性を持つ多数の ユース・ケース で再利用されます。エンティティー・クラスでは一連のエンティティー・オブジェクトを定義します。エンティティー・クラスは複数のユース・ケースに関与し、通常はそのユース・ケースで存続します。
- オブジェクト
-
十分に定義された 状態と 振る舞いをカプセル化した実体。状態は 属性と 関係によって表されます。振る舞いは、 操作、 メソッド、 状態マシンによって表されます。オブジェクトは、クラスのインスタンスです。「 クラス」、「 インスタンス」を参照。
- オブジェクト・クラス
- オブジェクトの属性とメソッドを定義するためのテンプレート。オブジェクト・クラスは、ほかのオブジェクト・クラスを保持できます。オブジェクト・クラスの個別表現がオブジェクトと呼ばれます。
- オブジェクト・フロー状態
-
アクティビティー・グラフ内の 状態で、オブジェクトがある状態にあるアクションの出力から別の状態にあるアクションの入力へと遷移することを示します。
- オブジェクト・モデル
- システムの実装を抽象化したもの。
- オブジェクト指向プログラミング (OOP)
- データ抽象化と継承の概念に基づくプログラミング・アプローチ。プロシージャー型プログラミング技術とは異なり、オブジェクト指向プログラミングはプログラムを構成するデータ・オブジェクト、その操作方法に焦点が絞られ、何かを達成する方法は扱われません。
- オブジェクト図
-
ある時点における一連の オブジェクトとそれらの関係を示す図。オブジェクト図は、特殊なクラス図またはコラボレーション図と見なすことができます。「 クラス図」、「 コミュニケーション図」を参照。
- オブジェクト生存線
-
シーケンス図の中にある線で、オブジェクトがある期間存在することを表します。「 シーケンス図」を参照。
- オペレーティング・システム・プロセス
- クラスやサブシステムのインスタンスが存在していて動作する、一意なアドレス空間と実行環境。実行環境は 1 つ以上の制御スレッドに分割されることがあります。「 プロセス」、「 スレッド」も参照。
- 親
-
汎化関係において、子の要素が汎化されたもの。「 サブクラス」、「 サブタイプ」を参照。 子と対比。
- 親クラス
- 別な Bean またはクラスがデータやメソッド、あるいはその両方を継承するクラス。
- オンライン・トランザクション処理 (OLTP)
- 端末ユーザーから出された要求が受け取られた時点で処理される対話型アプリケーションに対応したコンピューティング形態。結果は比較的に短時間で要求者に戻されます。オンライン・トランザクション処理システムではリソース共有の監視により、同時に複数のトランザクションを効率的に処理できます。
-
カ
- ガード条件
- 関連する 遷移を 発火できるようにするために満たすべき条件。
- 開発構想
- ユーザーまたは 顧客から見た開発対象の製品像。主要な 利害関係者のニーズのレベルおよびシステムの 機能により指定されます。
- 開発個別定義書
- 実行組織で使われるソフトウェア開発プロセス。構成として作成されるか、Unified Process 製品をカスタマイズすることによって作られ、プロジェクトのニーズに適合されます。
- 開発サイクル
- ライフサイクル、サイクル と同義。「 テスト・サイクル 」も参照。
- 開発者
- プロジェクトで採用した標準と手続きに従って、必要な機能を開発する責務を担う人。要求、分析/設計、実装とテスト作業分野における作業も遂行します。
- 開発範囲管理
- 利用可能なリソースと時間に基づいて一連の要求に優先度を付け、特定のリリース・サイクルで実装可能なものを決定するプロセスです。プロジェクトでは常に変更が行われるため、このプロセスはプロジェクトのライフサイクルを通じて継続的に行われます。「 変更管理」も参照。
- 開発プロセス
-
モデル作成やモデル実装のように、ソフトウェア開発中に特定の目的に沿って行う、部分的に順序を決めた一連のステップ。
- 外部キー
- データベース・テーブルで、別のテーブルの主キーを参照する列または列のセット。
- 外部リンク (external link)
- Web サイトにおける、外部 Web サイトの URL へのリンク。
- 外部リンク (outside link)
- 「外部リンク (external link)」と同義。
- 会話型
- つの分散型アプリケーションで会話を使用して情報が交換されるコミュニケーション・モデル。通常、1 つのアプリケーションが会話を開始 (または割り当て) し、データを送信し、もう 1 つのアプリケーションがデータを送信できるようにします。両方のアプリケーションともやり取りを、一方が終了 (または割り当ての解除) を決定するまで継続します。会話型モデルは、同期式のコミュニケーションとなります。
- 拡張
-
拡張ユース・ケースから基底ユース・ケースへの関係で、拡張ユース・ケース用に定義した振る舞いを基底ユース・ケース用に定義した振る舞いへ挿入する方法を指定します。
- 拡張依頼
- 一種の 利害関係者からの要望 で、システムに新しい 機能 または機能性を定めるもの。「 変更依頼」も参照。
- 拡張関係
- ユース・ケース・クラス A からユース・ケース・クラス B への拡張関係では、B のインスタンスに A で示される振る舞いが含まれる (拡張で指定する特殊条件に従う) ことを示します。1 つの対象ユース・ケースに対して複数の拡張者が指定した振る舞いは、単独のユース・ケース・インスタンス内で発生可能です。
- 可視性
-
参照する モデル要素がそれを包含する 名前空間の外部からどのように見えるのかを示す値 (パブリック、プロテクトまたはプライベート) の列挙。
- 仮想マシン
- ほかのコンピューター・プログラム上で稼動するソフトウェア・プログラム。物理的なマシン、つまりコンピューターが別な物理的なマシンであるかのように動作することが可能になります。
- 活動基準経営管理 (ABM)
- 作業の管理を通じて顧客価値および企業利益をもたらすことに焦点を当てた、幅広い専門分野。この主要な情報源は 活動基準原価計算です。
- 活動基準原価計算 (ABC)
- 作業、リソースとコスト対象のコストと性能を測定する方法論。リソースは作業に割り当てられ、作業は使用ベースでコスト対象に割り当てられます。活動基準原価計算を行うと、コスト増加要因と作業間の関係をその時々で認識できます。
- カプセル
- システムの制御 スレッド をカプセルに入れて表現する、特定の 設計パターン 。カプセルは、必要とされる制約付きの 関連 と プロパティー の特定の組み合わせである、 ステレオタイプ の クラス です。
- カプセル・ロール
- カプセル・ロールは、カプセルのコラボレーションまたは構造において特定の位置を占めることの可能な カプセル の種類に関する仕様を表します。カプセル・ロールは、コンテナーのカプセルに完全に所属しているため、カプセルから独立して存在することはできません。通常、カプセルの構造を分解すると、コネクターで接続された協調するカプセル・ロールのネットワークが存在します。
- カプセル化
- ソフトウェア・オブジェクトの内部表現を隠蔽すること。このオブジェクトにより、基礎となる構造を公開することなくデータを問い合わせ、操作するインターフェースが提供されます。
- 仮引数
-
「 パラメーター 」と同義。
- 環境
- (1) ソフトウェア開発プロセスの 作業分野の 1 つ。システムを開発する環境を定義し、管理することを目的とします。ここには、プロセス記述、 構成管理、開発ツールが含まれます。
- (2) ソフトウェア開発、ソフトウェア・テストのために設定される、あるいは最終製品の導入れるハードウェアとソフトウェア構成の特定のインスタンスのこと。「 テスト環境 」、「 導入環境 」も含まれます。
- 関係
-
要素間の意味的なつながり。関係の例としては、 関連 および 汎化 などがあります。
- 管理
- 作業分野 の 1 つ。開発プロジェクトの計画と管理を目的とします。
- 管理と観測のポイント
- テストの プロシージャー・フローにおけるポイントで、 テスト環境の観測が記録されたか、テストのフロー管理で決定がなされたポイント。密接に関連した概念として、管理ポイントは通常、必要な管理上の決定をする上での 1 つ以上の観測ポイントの詳細を必要とします。
- 関連
- インスタンス間の双方向の意味的なつながりをモデル化した関係。
-
インスタンス間につながりがある 2 つ以上の分類子間の意味的な関係。
- 関連クラス
-
関連と クラスのプロパティーを併せ持ったモデリング要素。関連クラスは、クラスのプロパティーをも持つ関連または関連のプロパティーをも持つクラスと見なすことができます。
- 関連端
-
関連の端点であり、関連を 分類子に接続します。
- キーワード
- Java 用に予約されている定義済みの用語 (たとえば、return など)。識別子として使用することはできません。
- 擬似状態
-
状態マシンの頂点の 1 つで、状態の形をしているが、状態としての振る舞いは行わないもの。擬似状態には初期の頂点と履歴の頂点があります。
- 技術権威者
- プロジェクトの技術権威者は変更依頼の実装を行うかどうか、どのようにして行うかについて決定を下せるだけの権威と技術的専門知識を持ち合わせています。技術権威者は変更作業を定義し、作業にかかわる工数の見積りを行います ( 変更依頼に対応)。
- 基数
-
集合内にある要素の数。「 多重度 」の対比。
- 基底クラス
- ほかのクラスまたは Bean の派生元のクラス。基底クラス自体は、別の基底クラスから派生します。 「抽象クラス」を参照。
- 基本タイプ
-
サブストラクチャーを持たない、整数や文字列などのあらかじめ定義された基本的なデータ・タイプ。
- 基本要件
- システムによって提供される外部から見えるサービスで、 利害関係者のニーズ を直接満たすもの。
-
操作や属性と同様に、分類子内でカプセル化されるプロパティー (インターフェース、クラス、データ・タイプなど)。
- 競合状態
- 2 つ以上の独立したタスクが同じ状態情報に対して同時にアクセスし、修正を行おうとするときに発生する状態。この状態はシステムの矛盾する振る舞いにつながるので、並列システム設計の根幹的問題となっています。
- 凝集 (度)
- 互いに依存する同種の コンポーネントの本来の共用体のこと。相互に固着する動作または状態。密接する共用体。 結合 (度)の対比。
- 具象
- 実際の特定の事物またはインスタンスの性質またはこれに関連すること。知覚可能で、抽象または創造上のものではありません。抽象の対比。 抽象の対比。「 具象クラス」を参照。
- 具象クラス
-
インスタンスを直接生成できる クラス。 抽象クラスの対比。
- クッキー
- 訪問する Web サイトの要求で Web ブラウザーが作成する小規模なファイル。ブラウザーは後の訪問の際、ファイルのコンテンツをサイトに送信します。
- クライアント
-
他の分類子からのサービスを要求する 分類子 。「 サプライヤー」の対比。
- クライアント/サーバー
- このモデルでは、あるロケーションにあるプログラムは要求をほかのロケーションにあるプログラムに送信して応答を待機しています。要求プログラムをクライアント、応答プログラムはサーバーと呼ばれます。
- クラス
-
同じ 属性、操作、 メソッド、関係、セマンティクスを共有するオブジェクト群の説明。クラスにより一連のインターフェースを使って、クラスの環境に提供する操作の集まりの仕様が定められます。「 インターフェース」を参照。
- クラス・メソッド
- 「 メソッド」を参照。
- クラス・ライブラリー
- クラスのコレクション。
- クラス階層
- 単一の継承を共有するクラス間の関係。Java クラスは、オブジェクトクラスから継承されます。
- クラス図
-
クラス、タイプ、その内容と 関係など、宣言 (静的) モデル要素の集合を示す図。
- グラフィカル・ユーザー・インターフェース (GUI)
- コマンドを入力するのではなくグラフィカルな機能を操作することで、ユーザーがプログラムと対話できるようにするインターフェースの一種。通常、GUI はグラフィック、ポインティング・デバイス、メニュー バーやほかのメニュー、複数のウィンドウ、アイコンが組み合されています。
- ゲートウェイ
- 異なる言語で通信しているネットワーク間を接続するホスト・コンピューター。たとえば、ゲートウェイは企業の LAN をインターネットに接続します。
- 継承
- 汎化を可能にするメカニズム。個々のクラス・セグメントから完全なクラス記述を作成するメカニズム。
-
汎化された要素の構造と振る舞いを、特化された要素に取り入れるメカニズム。「 汎化」を参照。
- 結果
- 出力と同義。「 納品可能物 」も参照。
- 欠陥
- 実装モデルのコンポーネントに要求された振る舞いの実行を 失敗させた偶発的な状況。欠陥は 1 つ以上の 障害の根本的な原因で、1 つ以上の 失敗が見出されることで識別されます。
- 欠陥ベースのテスト
- コンピューター・ソフトウェアのテスト技法で、あらかじめ定義された 欠陥セットの有無を示すテスト方式やテスト・データを使用してテストを行います。たとえば、ソフトウェアがゼロ除算による欠陥を正しく処理することを示すため、テスト・データにゼロを含むなどします。
- 欠陥モデル
- コンピューター・ソフトウェアをテストするためのモデルで、適当な 欠陥を概念の基盤とし、欠陥を検出するためのテスト方式を提供します。適切な欠陥モデルには、欠陥または根本的な原因の定義、欠陥により生じる観測可能な 失敗についての記述、欠陥を見つけるためのテスト手法、該当するテスト・データのプロファイルが含まれます。
- 結合 (度)
- コンポーネント が互いに依存する度合い。結合には、「密な」結合と「緩い」結合の 2 種類があります。拡張可能なソフトウェア・アーキテクチャーをサポートする上では緩い結合が望まれますが、最大限の性能を得るには密な結合が必要です。最大限の性能を得るには密な結合が必要です。コンポーネント間のデータ交換が大量または複雑になると、結合が増します。 凝集 (度)の対比。
- 検査
- 正式な評価技法の 1 つで、ある種の 成果物 (モデル、文書、ソフトウェア) を発案者以外の人やグループが調べて、障害や開発標準違反などの問題点を検出すること。
- 検収
- 契約書の部分的または完全な履行として、顧客がソフトウェア製品の所有権を受け入れること。
- 限定子
-
関連の属性または属性の集合であり、その値によって、そのオブジェクトと関連で結ばれた一連のオブジェクトが区別されます。
- 子
-
汎化関係の中の、親の要素が特化されたもの。「 サブクラス、「サブタイプ」を参照。 「 親」の対比。
- 公開されたモデル
-
凍結されたモデルで、リポジトリーのインスタンス化とほかのモデルの定義補助に使用可能。凍結されたモデルのモデル要素は変更できません。
- 攻撃
- 計画、方法にもとづいて、実行中のコンピューター・ソフトウェア・プログラムの通常の実行を停止または妨害しようとすること。コンピューター・ソフトウェアに対する攻撃は多くが悪質なもので、その概念は、ソフトウェア・ハッカー (AKA クラッカー) コミュニティーのメンバーがさまざまな技法によりソフトウェア・システムを攻撃し、セキュリティー・ソフトウェアを妨害したり、ホスト・システムへの違法侵入を行ったことに端を発します。よく知られている攻撃の方法には、バッファー・オーバーフロー、サービス妨害、リソース制約やトロイの木馬があります。この用語は、コンピューター・ソフトウェアのテスト専門家により、ソフトウェア・システムの潜在的なバグを見つけるための手法を説明する際に用いられるようになっています。
- 構成
- (1) 一般に、システムの機能単位の性質、番号および主要な特徴によって定義された、システムまたはネットワークの組み合わせ。ハードウェアとソフトウェアの両方に適用されます。
- (2) 特定のバージョンのシステムまたはシステム・コンポーネントを定義する要求、設計および実装。「 構成管理」を参照。
- 構成管理
- [ ISO95] 次のようなことを目的とする補助的なプロセス - 構成要素を認識し、定義し、そのベースラインを決定する。これらの要素の修正およびリリースを管理する。構成要素のステータスと変更依頼をレポートし、記録する。構成要素の完全性、一貫性、正当性を保証する。構成要素の保存、取り扱いおよび配布を管理する。
- 構成項目
- [ ISO95] エンドユーザー向けの機能を満たし、特定の参照ポイントで一意に識別可能な構成の実体。
- 構造化クラス
-
内部構造の分類子 (例: クラスまたはコンポーネント)。コネクターで接続された部分のセットが含まれます。 外部環境と外部環境の内部との間の相互作用を、ポートを介して強制的に渡すことができます。
- 構造特性
-
属性などの モデル要素静的特性。
- 構造モデルの側面
-
システム内のオブジェクトの構造に重点を置いたモデルの側面で、 オブジェクトの タイプ、 クラス、 関係、 属性、 運用があります。
- 顧客
- 製造組織の内部でも外部でもかまわないが、システムの財政責任を負える人、あるいは組織。大規模システムでは、顧客はエンドユーザーではないこともあります。顧客は開発製品と成果物の最終的な受け取り人です。「 利害関係者」も参照。
- コミット
- リソース (トランザクションまたはデータ)に対して行われた変更を、永続的なものにする作業単位を終了する操作。
- コミュニケーション関連
- アクター クラスと ユース・ケース・クラス間の関連で、これらのインスタンスが相互作用することを示します。関連の方向は通信の開始元を示します (統一プロセスの規約)。
-
配置図では、通信を行う可能性のあるノード間の関連のこと。「 配置図」を参照。
- コミュニケーション図
- (1) 以前はコラボレーション図という用語であったが、コミュニケーション図はオブジェクト間の相互作用のパターンを記述します。オブジェクト間のリンクや メッセージの送受信によるオブジェクトの相互作用を表します。
- (2) 単に分類子と関連を表すだけでなく、 分類子ロールと 関連ロールを表す クラス図。
- (3) コミュニケーション図とシーケンス図はどちらも相互作用を表すものですが、別々の側面に重点を置いています。シーケンス図では、時間の経過が明確に示されますが、オブジェクト間の関係は具体的に表現されません。コミュニケーション図ではオブジェクト間の関係が明確に表されますが、時間の経過を知るにはシーケンス・ナンバーが必要です。
-
分類子と関連またはインスタンスとリンクを使用して モデルの構造を中心に構成された相互作用を示す図。シーケンス図とは異なり、コミュニケーション図ではインスタンス
間の関係が表されます。シーケンス図とコミュニケーション図は類似の情報を表しますが、表現方法は異なります。「 シーケンス図」も参照。
- コメント
-
要素または要素のまとまりに付加された注釈。ノートにセマンティクスは備わっていません。「 制約」の対比。
- コラボレーション
- (1) 協調して、一定のコンテキスト内でなんらかの振る舞いを実装するオブジェクト集団の記述。協調して、一定のコンテキスト内でなんらかの振る舞いを実装するオブジェクト集団の記述。
- (2) オブジェクトのネットワーク間におけるメッセージ交換の振る舞いに対する、より総合的な見方を把握します。
- (3) コラボレーションにより、計算処理の基本となる 3 つの主な構造、すなわちデータ構造、制御フロー、データ・フローの統一が示されます。
- (4) コラボレーションには、静的部分と動的部分があります。静的部分では、コラボレーションの例示化においてオブジェクトやリンクが演じるロールが記述されます。動的部分は、1 つ以上の動的な相互作用から成り、演算を行うコラボレーションの長期にわたるメッセージの送受信が示されます。コラボレーションには、その動的振る舞いを表す一連の メッセージが保持されることがあります。
- (5) メッセージを持つコラボレーションは相互作用です。
-
ユース・ケースなどの <
a href="#operation">操作または 分類子が、特定の方法で使われて特定の役割を演じる分類子と 関連の集合によってどのように実現されるかを示す仕様。コラボレーションによって相互作用が定義されます。「 相互作用」を参照。
- コラボレーション図
- この用語は、UML 2.0 より「 コミュニケーション図」に変更になりました。
- コンストラクター
- クラスと同じ名前を持ち、そのクラス・タイプのオブジェクトを作成して開始も行うために使用される特別なクラス・メソッド。
- コンテキスト
-
操作 を指定するなどの特定の目的に対して、対象として使われる一連の関連する モデル要素 のビュー。
- コンテナー
-
(1) インスタンス を入れるためのインスタンスで、その内容へのアクセスや繰り返し処理のための操作を提供する (例: 配列、リスト、セット)。- (2) ほかの コンポーネント を入れるために存在するコンポーネント。
- コントロール・クラス
- 1 つまたは複数の ユース・ケース に特別な振る舞いをモデル化するのに使用する クラス。
- コンパイル時
-
ソフトウェア・モジュールのコンパイル時に起こる任意の物事を表します。「 モデリング時」、「 実行時」を参照。
- コンポーネント
- ある程度の規模を持つ、ほぼ独立した、交換可能なシステムの一部。十分に定義された アーキテクチャーにおいて、1 つの明確な機能をにないます。コンポーネントは一連の インターフェースに準拠し、インターフェースを物理的に実現したものを提供します。
-
モジュラー形式で、配置、置換可能なシステム・パーツで、実装をカプセル化し、インターフェースのセットを公開します。一般的にコンポーネントは、これに常駐する 1 つ以上の分類子 (例、実装クラス) により指定され、1 つ以上の成果物 (例、バイナリー、実行可能ファイル、スクリプト・ファイル) により実装できます。「 成果物」と対比。
- コンポーネント・モデル
- 開発者がコードの再利用可能なセグメントを定義できるようにするアーキテクチャーと API。このセグメントを組み合わせてプログラムを作成します。VisualAge for Java では、JavaBeans コンポーネント・モデルが使用されます。
- コンポーネント図
-
コンポーネントの集合内の構成やそれらの依存関係を示す図。
- コンポーネントに基づく開発 (CBD)
- コンポーネントで構成されたソフトウェア集約的なシステムを作成し、導入すること。また、そのようなコンポーネントを開発したり、導入したりすること。
- コンポジション
-
集約の 1 つの形態で、強い所有関係があり、全体のなかの部分として存続期間が完全に一致しているもの。 コンポジット自体を生成した後で、 多重度が固定されていない部分を生成できますが、いったん生成した後は、部分はコンポジットと生死を共にします。このような部分は、コンポジットが消滅する前であれば、明示的に削除できます。コンポジションは再帰的な場合もあります。「 コンポジット集約」も参照。
- コンポジット [クラス]
-
1 つ以上のクラスとコンポジション関係で結ばれている クラス。「 コンポジション」を参照。
- コンポジット・サブ状態
-
同じコンポジット状態にある、ほかの サブ状態と同時に存在できるサブ状態。「 コンポジット状態」を参照。「 領域」と同義。
- コンポジット Bean
- ほかの Bean から構成されている Bean。コンポジット Bean は目に見える Bean、目に見えない Bean、あるいはその両方から構成できます。「Bean」も参照。
- コンポジット集約
-
コンポジションと同義。
- コンポジット状態
-
並行 (直交) サブ状態または逐次 (互いに素な) サブ状態から構成される状態。「 サブ状態」を参照。
-
サ
- サーバー
- ファイル・サーバー、プリント・サーバー、またはメール・サーバーなどのネットワーク内の複数のユーザーやワークステーションを操作する際に、サービスを提供するコンピューター。
- サービス指向アーキテクチャー (SOA)
- ソフトウェア・システムの構造の概念を、そのコンポーネントと提供サービスの点から、これらコンポーネント、サービス、コンポーネント間の接続の基盤となる実装については触れずに記述したものです。
- サーブレット
- サーブレットは Java オブジェクトで、ブラウザーの要求に応答してサーバー上で実行されます。HTML または XML を直接生成することも、JSP を呼び出し出力を作成することもできます。
- サイクル
- ライフ・サイクル、開発サイクル と同義。「 テスト・サイクル」も参照。
- 最終状態
-
包含する コンポジット状態 または 状態マシン 全体が完了することを示す特殊な種類の状態。
- 最初のページ
- Web サイトにアクセスしたときに最初に表示されるページ。 デフォルト・ページ、 ホーム・ページと同義。
- 再利用
- 成果物をさらに利用する、または繰り返し利用すること。
-
元々存在している成果物の利用。
- 作業
- ある 役割が遂行を依頼される仕事の単位。
- 作業分解構造 (WBS)
- 立案のためのフレームワーク。プロジェクトを作業単位に分解し、この単位に基づいてコスト、成果物、作業を割り当て、追跡できるようにします。
- 作業分野
- 主な「対象領域」に関連した作業の集合。RUP における作業分野には、ビジネス・モデリング、要求、分析/設計、実装、テスト、導入、構成/変更管理、プロジェクト管理、環境があります。
- 索引
- データベース・テーブルの行の検索効率を向上させるためのメカニズム。
- 作成
- Unified Process の 3 番目のフェーズであり、ソフトウェアを実行可能なアーキテクチャー・ベースラインのレベルから、ユーザー・コミュニティーも提供できるレベルへと移行させます。
- サブアクティビティー状態
-
アクティビティー図の 状態で、継続期間のある非アトミックな一連のステップの実行を表します。
- サブクラス
-
汎化の関係の中で別のクラス、つまりスーパークラスを特化したもの。「 汎化」を参照。 スーパークラスの対比。
- サブシステム
- パッケージのセマンティクスを持つ モデル要素 (ほかのモデル要素が含まれる場合もある)、および クラス (振る舞いを持つもの)。サブシステムの振る舞いは、クラスか、サブシステムに含まれるほかのサブシステムによって提供されます。サブシステムによって、1 つ以上のインターフェースが実現され、これらのインターフェースによって、サブシステムによって実行される振る舞いが決定されます。
-
サブシステムはモデル要素をグループ化したものです。このモデル要素の中で、含まれている別なモデル要素から提供される振る舞いの仕様を構成するものもあります。 「 パッケージ」、「システム」も参照。
- サブ状態
-
コンポジット状態の一部である状態。「 並行サブ状態」、「 互いに素なサブ状態」を参照。
- サブ状態マシン
-
状態マシンの 状態で、 コンポジット状態に相当しますが、そのコンテンツはほかの状態マシンにより表現されます。
- サブタイプ
-
汎化の関係の中で別のタイプ、つまりスーパータイプを特化したもの。「 汎化」を参照。 スーパータイプの対比。
- サプライヤー
-
ほかの分類子により呼び出すことができるサービスを提供する分類子。 クライアントの対比。
- 参加する
-
モデル要素から関係または具体的関係への接続。たとえば、クラスは関連に参加し、アクターはユース・ケースに参加します。
- 参照
-
(1) モデル要素。- (2) ほかの分類子への移動を容易する分類子内の名前付きスロット。「ポインター」と同義。
- サンドボックス
- Web ブラウザーで提供され、Java アプレットが稼動する制約された環境。サンドボックスではアプレットにサービスが提供され、ファイルの入出力、部外者 (アプレットがロードされたサーバー以外のサーバー) との対話などの手間のかかることからアプレットを解放します。アプレットは子と類似しているため、サンドボックスを実行する環境を呼び出すことができます。
- シーケンス図
-
時間の経過で調整されたオブジェクトの相互作用を示す図。特に、交換されるメッセージの相互作用とシーケンスに参加するオブジェクトを表します。コラボレーション図とは異なり、シーケンス図には時間の経過が含まれますが、オブジェクトの関係は含まれません。シーケンス図には、一般的な形式 (すべての一般的な シナリオ) とインスタンス形式 (1 つのシナリオ・インスタンスを記述する) があります。シーケンス図とコミュニケーション図は類似の情報を表しますが、表現方法は異なります。「 コミュニケーション図」を参照。
- 時間
-
絶対的な瞬間または相対的な瞬間を示す値。
- 時間イベント
-
現状が入力されてから時間が経過したことを示すイベント。「 イベント」を参照。
- 時間限定
- RUP で推奨されている反復スケジュールの管理のアプローチ。まずプロジェクト管理者は反復の範囲とスケジュールを確立し、開発作業が予定より長引く場合には元々計画した範囲をカバーするために計画した反復終了日を延長するのではなく、この終了日に間に合うようにこの範囲 (および反復に使用するリソース) を積極的に管理することが推奨されます。RUP では、スケジュールの延期を管理するリソースを追加することよりも、範囲を縮小することの方が好まれます。このアプローチを推奨する理由は、反復の結果を利害関係者に表示でき、反復が評価されるため、教訓を次の反復に活かすことができるからです。
- 時間式
-
絶対的または相対的な時間値に分解できる式。
- 式
-
特定の種類の値に評価する式。たとえば「(7 + 5 * 3)」という式は、評価した結果として数値タイプの値を返します。
- シグナル
-
インスタンス間でやり取りされる非同期の刺激の仕様。シグナルにパラメーターが備わっている場合があります。
- シグニチャー
-
振る舞いの特徴の名前とパラメーター。シグニチャーには、オプションの戻り値パラメーターを含めることができます。
- 刺激
-
シグナルを発生する、 操作を呼び出すなどの、あるインスタンスからほかのインスタンスへの情報の受け渡し。シグナルの受信は、通常、 イベントと見なされます。「 メッセージ」を参照。
- 事後条件
- ユース・ケース終了時にシステムに課せられる制約をテキストで記述したもの。
-
操作の完了時に真となっていなければならない制約。
- システム
-
(1) 特定の目的を達成するために編成され、リンクされた単体の集合。システムは 1 つ以上のモデルで表現でき、可能であれば異なる視点から表現されます。物理的なシステムと同義。- (2) 最上位のサブシステム。
- システム要求レビュー (SRR)
- ウォーターフォール型のライフサイクルにおいて、システム仕様の完成時に開催される重要なレビューの名前。
- 事前条件
- ユース・ケース開始時にシステムに課せられる制約をテキストで記述したもの。
-
ユース・ケース開始時にシステムに課せられる制約をテキストで記述したもの。
- 実行可能アーキテクチャー
- 実行可能な アーキテクチャーとは、システムの部分的な実装で、特に機能外要求を満たす、選択したシステムの機能と特性を実証できるように作成されます。 推敲フェーズ中に、性能、スループット、容量、信頼性などの項目にまつわるリスクを軽減する目的で作成され、システムを破壊する危険を冒さずに、 作成フェーズで完全な機能的能力をシステムに付加する基礎となります。RUP では、実行可能アーキテクチャーを発展プロトタイプとして作成し、要求を満たし動作すると判明したものを残して、納品可能システムの一部として利用することを意図しています。
- 実行時
-
コンピューター・プログラムが実行される期間。 モデリング時 と対比。
- 実装
- ソフトウェア開発プロセスの 作業分野の 1 つ。その目的は、適当な品質基準を満たすソフトウェア・コンポーネントを実装することです。
-
作成方法と計算方法の定義。たとえば、クラスがタイプの実装となり、メソッドは操作の実装となります。
- 実装継承
-
特化された要素の実装を継承すること。インターフェースも継承されます。「 インターフェース継承 」の対比。
- 実装サブシステム
- コンポーネントととほかの実装サブシステムの集合。これは小さな部品に分割して、 実装モデルを構成するために使います。RUP において実装モデルと実装サブシステムは、 実装ビューの対象となるもので、開発時に最も重要となることに注意してください。実装サブシステムは、 設計パッケージに物理的に類似しています。。「実装サブシステム」という名前は、コンポーネントより規模の大きいものを示すときに「サブシステム」という用語が一般に使用されることに由来しています。ただし UML 用語では、実装サブシステムはステレオタイプ化された パッケージであって、 サブシステムとは別のものです。
- 実装パターン
- 「 イディオム」を参照。
- 実装ビュー
- 開発環境における静的なソフトウェア要素 (コード、データ、そのほかの関連する成果物) の構成を、 パッケージング、レイヤー、 構成管理 (所有権、リリース方針など) の面から記述した アーキテクチャー・ビュー。Unified Process では、実装ビューは 実装モデルに関するビューのことです。
- 実装メカニズム
- 実装プロセスで使用される アーキテクチャー・メカニズム 。実装メカニズムは 設計メカニズムをを改善したものであり、メカニズムの正確な実装を指定し、作成時に複数の実装パターン (イディオム) を使用することがよくあります。この場合でも、設計メカニズムと実装メカニズムに必ずしも規模の違いはありません。 たとえば、プロセス間コミュニケーション分析メカニズムのある 1 つの実装は、特定のオペレーティング・システムで共有メモリー 機能呼び出しを最適化する共有メモリー設計メカニズムとなります。並行性競合 (共有メモリーへの不適切な同時アクセス) はセマフォーまたはラッチング・メカニズムを使用して防ぐことができ、並行性競合はほかの実装メカニズムに依存します。
- 実装モデル
- コンポーネントとコンポーネントが含まれている 実装サブシステムの集まり。
- 失敗
- システムやコンポーネントが、指定された性能要求において要求される機能を実行できないこと [ IE610.12]。失敗は、1 つ以上の 欠陥に原因を持つ、1 つ以上の 障害がが目に見えるかたちで現れることにより特徴づけられます。
- 実パラメーター
-
引数と同義。
- シナリオ
-
振る舞いを説明する、特定の一連のアクション。シナリオは、ユース・ケース・インスタンスの相互作用や実行を説明するために使用されます。「 相互作用」、「 テスト・シナリオ」を参照。
- 射影
-
セットからそのサブセットへのマッピング。
- 集約
- 集約オブジェクト (全体側) とその一部の間の全体-部分関係をモデル化する関連。
-
集約オブジェクト (全体側) とコンポーネント部分の間の全体-部分関係を指定する関連の特別な形態。 「 コンポジション」を参照。
- 集約 (クラス)
-
集約 (全体-部分) 関係における「全体側」を示すクラス。 「 集約」を参照。
- 重要な設計レビュー (CDR)
- ウォーターフォール型のライフサイクルにおいて、詳細設計の完了時に行われる重要なレビュー。
- 主キー
- データベース・テーブルの行の識別に使用されるテーブルの列または列のセット。
- 受信
-
分類子がシグナルの受信に反応する用意ができていることを宣言すること。
- 受信 [メッセージ]
-
送信側インスタンスから渡された刺激の処理。 「 送信側」、「 受信側」を参照。
- 受信側
-
送信側オブジェクトから渡された刺激を処理するオブジェクト。 送信側 と対比。
- 出力
- (1) プロセス・ステップの結果である任意の成果物。「 納品可能物」を参照。
- (2) 行われたテストから生じる結果または製品。予期出力は、 テスト・ケースに定義されます。
- 主要メカニズム
- アーキテクチャー・パターン の実現方法を、システム要素間の相互作用パターンの面から示す記述。通常は、 ソフトウェア・アーキテクチャー 説明書に記述されています。
- 障害
- 納品済み製品の異常。たとえば、ライフサイクルの初期のフェーズで発見された遺漏や不完全さおよびテストまたは運用段階に入ったソフトウェアに起こる障害の症状など。追跡して解決すべき種類の問題はすべて障害です。「 変更依頼 」も参照。
- 仕様書
-
物事や動作を宣言する記述。 実装の対比。
- 状態
-
オブジェクトがなんらかの条件を満たし、なんらかの作業を実行し、なんらかのイベントを待機しているオブジェクトの存続期間における条件や状況。
- 状態マシン
- 状態マシンは モデル要素の振る舞いを指定して、オブジェクトのイベントやライフ・サイクルへの応答を定義します。
-
オブジェクトまたは相互作用の生存期間を通じ、イベントへの応答として通過する 状態のシーケンスを、それらの応答やアクションと一緒に指定する 1 つの振る舞い。
- 使用法
-
適切に機能し実装するために、1 つの要素 ( クライアント) には異なる要素 ( サプライヤー) の存在が必要である依存関係。
- 情報交換用米国標準コード (ASCII)
- 情報交換用米国標準コード。 多くの PC や UNIX システムで採用されている 8 ビットの文字コード化体系。 初期の 7 ビットの ASCII 規格に代わって台頭しています。
- 初期段階の設計レビュー (PDR)
- ウォーターフォール型のライフサイクルにおいて、アーキテクチャー設計の完成時に開催される重要なレビュー。
- シン・クライアント (thin client)
- シン・クライアントは、通常、リソースが制約されているマシンまたは小規模なオペレーティング・システム上で稼動するシステムを表します。シン・クライアントにはローカル・システム管理は不要であり、ネットワーク経由で配布された Java アプリケーションを実行します。
- 真偽値式
-
論理型 の値を評価する式。
- シングル・バイト文字セット
- 1 バイト・コードで表現される文字のセット。
- スーパークラス
-
汎化の関係の中で別のクラス、つまりサブクラスを汎化したもの。「 汎化」を参照。 サブクラスの対比。
- スーパータイプ
-
汎化の関係の中で別のタイプ、つまりサブタイプを汎化したもの。「 汎化」を参照。 サブタイプの対比。
- 推敲
- プロセスの第 2 の フェーズ 。製品の 開発構造 とその アーキテクチャー が定義されます。
- スキーマ [MOF]
-
MOF のコンテキストでは、スキーマは モデル要素のコンテナーである パッケージに類似します。スキーマは、MOF パッケージに一致します。 メタモデルの対比。パッケージは MOF パッケージに一致します。
- スタブ
- テスト用の機能を含むコンポーネント。スタブは、事前定義値をただ戻すだけのまったくの「ダミー」、またはより複雑な振る舞いの「シミュレーション」のいずれかです。
- ステートチャート図
-
状態マシンを示す図。「 状態マシン」を参照。
- ステレオタイプ
- 要素のメタ分類。ステレオタイプには、特定のステレオタイプ値ごとに指定可能なセマンティクス上の意味があります。RUP で使用が推奨される定義済みのステレオタイプについては、RUP の成果物の「UML 表現」を参照してください。
-
メタモデルのセマンティクスを拡張する新しい種類のモデリング要素。ステレオタイプは、メタモデル内の既存のタイプまたはクラスに基づいている必要があります。ステレオタイプはセマンティクスを拡張しますが、既に存在しているタイプやクラスの構造は拡張しません。UML で事前に定義されるステレオタイプや、ユーザーにより定義されるステレオタイプもあります。
- ストアド・プロシージャー
- データベースに関連したコードまたはスクリプトの機能単位。
- スモーク・テスト
- テストのサブセット (通常は数が制限される) の記述に用いられるフェーズ。作成されたソフトウェアごとにこれらのテストを実行して、ソフトウェアの機能が以前の作成から後戻りしていないかを判別できます。「 ビルド検証テスト」、「 ビルド照合テスト」、「 ビルド受け入れテスト」、「 ビルド回帰テスト」、「 サニティー・チェック」と同義。
- スレッド
- 包含されたオペレーティング・システムの プロセスによって定義された実行環境とアドレス空間内で実行される、独立した演算。「軽量プロセス」と呼ばれることもあります。
-
プログラムや動的モデルなど制御フローを表したものを経由する単一の実行パス。また、軽量プロセスである能動的なオブジェクトの実装用のステレオタイプでもあります。「 プロセス」を参照。
- 成果物
- (1) 1) プロセスによって作成、変更、あるいは使用される情報、 2) 責務の範囲を定義する情報、 3) バージョン管理される情報。成果物は、 モデル、 モデル要素または 文書となります。文書には、ほかの文書を追加できます。
-
ソフトウェア開発プロセスで使用あるいは作成される情報。成果物の例として、モデル、ソース・ファイル、スクリプト、バイナリー実行可能ファイルがあります。成果物の例として、モデル、ソース・ファイル、スクリプト、バイナリー実行可能ファイルがあります。成果物には、配置可能コンポーネントの実装を含むことができます。 製品と同義。 コンポーネントの対比。
- 成果物ガイドライン
- 成果物の作成方法と変更方法などの、特定の 成果物を使用した作業方法の説明。
- 成果物セット
- システムのある側面を示す関連する成果物のセット。複数の成果物が多数の作業分野で使用されるため、成果物セットは 作業分野間で共通しています。たとえば、「リスク・リスト」、「 ソフトウェア・アーキテクチャー説明書」および「 反復計画書」などがあります。
- 制御フォーカス
-
オブジェクトがアクションを直接または下位プロシージャーを通じて実行する期間を示す シーケンス図の記号。
- 生成
- サイクル終了時の最終 リリース。
- 静的情報
- アクセスごとに変更されない Web ファイル。
- 静的成果物
- プロセスで、変更を受けることなく使用される成果物。
- 静的分類
-
汎用の意味的なバリエーション。オブジェクトはタイプを変更することもロールを変更することもできません。 動的分類の対比。
- 製品
- 開発の結果であるソフトウェアとその関連する 成果物 (文書、リリース媒体、トレーニング)。
- 製品群アーキテクチャー
- 素タイプ、相互作用方法、製品機能の割り当て方法を定義します。詳細に定義するために、アーキテクチャー要素のインスタンスのいくつかを定義する場合もあります。通常、この用語は組織または企業内の製品の組み合わせに適用されます。 [ HOF99] も参照。
- 製品要求説明書 (PRD)
- 製品 (システム)、意図された使用方法、および製品で提供される一連の 機能 関する上位レベルの記述。
- 製品擁護者
- 製品の 開発構想のスポンサーとなる上層部のメンバーで、開発チームと 顧客の間で擁護者として行動します。
- 制約
-
セマンティックな条件または制限。UML で事前に定義される制約や、ユーザーにより定義される制約もあります。制約は、UML における 3 つの拡張性メカニズムの 1 つです。「 タグ付き値」、「 ステレオタイプ」も参照。
- 責務
-
分類子が持つ契約あるいは義務。
- 設計
-
ソフトウェア開発プロセスの一部。主な目的はシステムの実装方法を決定することです。システムの機能と品質に対する 要求 を満たすために、設計時に重要かつ計算された決定が行われます「 分析 」を参照。
- 設計サブシステム
- システムの一部を表す モデル要素 。設計サブシステムは、振る舞いを提供するほかのモデル要素 (クラスまたはほかの設計サブシステム) をパッケージ化することで、その振る舞いをカプセル化します。また、可能な振る舞いを定義する インターフェースのセットを公開します。
- 設計時
-
ソフトウェア開発プロセスの設計フェーズ中に起こる任意の物事を指します。「 モデリング時 」を参照。「 分析時 」の対比。
- 設計パターン
- [ GAM94] では、次にように設計パターンを定義しています。
「設計パターンはサブシステムまたはソフトウェア・システムのコンポーネント、あるいは両者の関係を改善するスキームを提供します。設計パターンはコンポーネントの通信に共通して使用される構造を記述し、この構造は特定のコンテキストで一般的な設計問題を解決するために使用されます。」
設計パターンは、中規模から小規模なパターンです。アーキテクチャー・パターンより小規模ですが、通常はプログラミング言語に依存しません。設計パターンが束縛状態にある場合は、具体的な設計モデルの一部 (おそらく、 設計メカニズムの一部) を形成します。設計パターンは、レベル的にはドメインを超えて適用可能な傾向にあります。
- 設計パッケージ
- クラス 、 関係 、 ユース・ケースの実現 、 ダイアグラム やその他の パッケージ の集合です。これは小さな部品に分割して、 設計モデル を構成するために使います。 実装サブシステム に論理的に類似しています。
- 設計メカニズム
- 設計の詳細が決定される時期に、設計プロセスで使用される アーキテクチャー・メカニズム。設計メカニズムは対応する 分析メカニズムに関連します。また、分析メカニズムの追加改善であり、1 つまたは複数のアーキテクチャーと設計のパターンを結合します。分析メカニズムと設計メカニズムには規模の点で差があるとは限りません。したがって、分析レベルと設計レベルの両方で永続メカニズムについて言う場合、異なる詳細度で同じ意味を持たせることができます。設計メカニズムではある程度、実装環境を詳細にしておく必要がありますが、( 実装メカニズムにように) 特定の実装に縛られることはありません。たとえば、プロセス間通信 (IPC: Inter-Process Communication) 用分析メカニズムは、共有メモリー、関数呼び出し風の IPC、シグナル・ベースの IPC などの複数の IPC 用設計メカニズムで改善可能です。各設計メカニズムには長所と短所があります。特定の設計メカニズムを選択するときには、メカニズムを使用するオブジェクトの特性から決定します。
- 設計モデル
- ユース・ケース の実現を表現する オブジェクト・モデル 。 実装モデル とそのソース・コードを抽象化するロールを果たします。
- 洗練
-
一定の詳細レベルで既に仕様化されているものを、より完全な仕様にすることを表す関係。たとえば、設計クラスは分析クラスを洗練したものです。
- ソープ・オペラ・テスト
- ダイナミックで誇張された使用シナリオを考慮してテスト・シナリオを定義する技法。TV のドラマのように、これらのシナリオには「実世界」が反映されますが、システムの劇的な使用状況を示すよう凝縮、誇張されています。この技法では、ベテラン・ユーザーと共同して定義を行うことで、システムの多くの機能側面を迅速にテストすることができます。この用語と関連技法の定義は、Hans Buwalda が顧客との実験的コンサルタントで考案したものです。
- 相互作用
-
特定のタスクを遂行するために行われる、 インスタンス 間での刺激の交換方法の仕様。相互作用はコラボレーションのコンテキストの中で定義されます。「 コラボレーション 」を参照。
- 相互作用図
-
オブジェクトの相互作用を強調した特定の種類の図を表す一般的な用語。これらには、 「 コミュニケーション図」と シーケンス図 」が含まれます。
- 操作
-
実行環境は 1 つ以上の制御スレッドに分割されることがあります。操作は、 シグニチャーを持つため、実パラメーターの可能範囲を制限することがあります。
- 送信
-
送信側インスタンスから受信側インスタンスへの刺激の受け渡し。「 送信側」、「 受信側」を参照。
- 送信側
-
受信側オブジェクトに刺激を渡すオブジェクト。 受信側の対比。
- 属性
- クラスまたはオブジェクトの名前付きプロパティーを表す クラスで定義される属性。属性には、インスタンスの種類を定義する タイプがあります。
-
分類子のインスタンスが保有する可能性がある値の範囲を記述する分類子内の特性。
- 組織単位
- 組織の主要コンポーネントで、管理のためのコンテキストを提供します。組織の構造により、親単位が階層内の子に関連付けられ、それぞれの単位が他のビジネス・コンポーネントの集合に対して責務を負います [ MARS00]。「 ビジネス・システム」を参照。
- ソフトウェア・アーキテクチャー
- ソフトウェア・アーキテクチャーには、次のものがあります。ソフトウェア・システムの構成についての重要な決定。 構造的な要素の選択と、システムを構成するインターフェースおよびこれらの要素間のコラボレーションとして規定される振る舞い。 構造的要素と振る舞い的要素を、徐々により大きなサブシステムにするためのコンポジション。 このような構成、要素、インターフェース、コラボレーションおよびそれらのコンポジションをガイドするためのアーキテクチャーのスタイル。
- ソフトウェア・アーキテクチャーは、構造や振る舞いだけでなく、使い方、機能、性能、障害許容力、再利用、わかりやすさ、経済性と技術的制約のトレードオフ、美的な問題も扱います。
- ソフトウェア開発プロセス管理者 (SEPA)
- プロセスの定義、評価および改善の責務を持つ組織体。
- ソフトウェア仕様レビュー (SSR)
- ウォーターフォール型のライフサイクルにおいて、ソフトウェア要求仕様の完成時に開催される重要なレビュー。
- ソフトウェア要求
- 外部から観察可能なシステム上の振る舞いの仕様。たとえば、システムへの入力、システムからの出力、システムの機能、システムの属性、システム環境の属性などがあります。
- ソフトウェア要求仕様 (SRS)
- 構築するシステムの外部的振る舞いを完全に定義する一連の要求。機能仕様と呼ばれることもあります。
-
タ
- 退状時アクション
-
この状態 を終了するために行われる遷移にかかわらず、 状態マシン に状態を終了するときに実行されるアクション。
- 対象テスト項目
- テスト作業の対象として識別される、開発製品 (一般にソフトウェアとハードウェア) の側面。対象テスト項目の範囲は、 操作、インターフェース、機能、コンポーネント、 実装サブシステム、システムのレベルで指定するか、オペレーティング・システムや周辺装置 (プリンタなど) のようなシステムの外部の側面とされる場合があります。 テスト対象、テスト項目と同義。
- ダイナミック・リンク・ライブラリー (DLL)
- コンパイルの最終段階であるリンク時ではなく実行時にプログラムにバインドされる、実行可能なコードおよびデータが含まれているファイル。つまり、使用するルーチンのコピーを含むタスクごとではなく、複数のタスクでライブラリー・コードの同じブロックを共用できることを意味します。C++ Access Builder では、Java プログラムから C++ DLL へのアクセスを可能にする Bean および C++ ラッパーが生成されます。
- タイプ
- 共通する特性、関係、属性、セマンティクスを共有する一連のエンティティーの記述。
-
オブジェクトに適用可能な操作と共にインスタンス (オブジェクト) のドメインを指定するために使用されるクラスのステレオタイプ。タイプにはメソッドは含まれません。「 クラス」、「 インスタンス」を参照。 インターフェースの対比。
- タイプ式
-
1 つ以上の タイプへの参照を評価する式。
- タイミング・マーク
-
イベントまたはメッセージが発生した時点を示します。タイミング・マークは、制約に使用される場合があります。
- ダイアグラム
- モデル のすべてまたはその一部を図示したもの。
-
モデル要素 の集合を図示する場合、円弧 (関係) と頂点 (ほかのモデル要素) が結び付けられた図としてよく表現されます。UML では次の図をサポートします。 クラス図 、 オブジェクト図 、 ユース・ケース図 、 シーケンス図 、 コミュニケーション図 , ステートチャート図 , アクティビティー図 , コンポーネント図 、および 配置図 。
- 互いに素なサブ状態
-
同じコンポジット状態にある、ほかのサブ状態と同時に存在できない サブ状態 。「 コンポジット状態 」を参照。 並行サブ状態 の対比。
- タグ付き値
-
名前付きの値のペアである、プロパティーの明示的な定義。タグ付きの値において、名前はタグを表します。UML で事前に定義されるタグや、ユーザーにより定義されるタグもあります。タグ付き値は、UML における 3 つの拡張性メカニズムの 1 つです。「 制約」、「ステレオタイプ」を参照。
- 多重継承
-
汎化の意味的バリエーションで、タイプは複数の スーパータイプを持つことができます。 単一継承の対比。
- 多重度
-
1 つの集合で許される基数の範囲を指定するもの。多重度は、関連内のロール、コンポジット内の部分、繰り返し、そのほかの目的のために指定されます。多重度は、基本的には正の整数の (無限の可能性もある) サブセットです。 基数の対比。
- 多重分類
-
汎化 の意味的なバリエーションで、オブジェクトは複数のクラスに直接所属することができます。「 動的分類」を参照。
- タスク
- 「 オペレーティング・システム・プロセス」、「 プロセス」、「 スレッド」を参照。
- 多値
-
多重度が定義されたモデル要素で、Multiplicity Type::の上限属性が 2 以上の数字に設定されています。多値という用語は、ある時点で属性やパラメーターなどが保有する値の数に関係するものではありません。 単一値の対比。
- 単一値
-
多重度が定義されたモデル要素で、Multiplicity Type:: の上限属性が 1 に定義されています。単一という用語は、単一属性 (例: ゼロの多重度の下限を持つ) が値を持たない可能性があるために、ある時点で属性やパラメーターなどが保持する値の数に関係するものではありません。 多値の対比。
- 単一継承
-
汎化の意味的なバリエーションで、 タイプは、1 つの スーパータイプしか持つことができません。 多重継承の対比。
- チーム・リーダー
- チーム・リーダーは、プロジェクト管理と開発者との仲介を行います。チーム・リーダーには、タスクが割り当てられ完了まで監視されているかを確認する責務があります。開発者がプロジェクト規約に従い、プロジェクト・スケジュールを守っているかを確認する責務もあります。
- チェックポイント
- 特定の種類の 成果物が十分に形成されている条件の組み合わせ。肯定的に答えるべき形式の質問で記述される場合もあります。
- 抽象
- 実際的な目的や意図を持たない抽象的な対象の性質またはこれに関連すること。応用や実用はされない理論上のもの。具象的な存在とは分けて考えられます。 具象の対比。 「 抽象クラス」を参照。
- 特定のインスタンスとは関連しない概念または構想。 抽象化と同義。
- 主張や理論の要旨をまとめたもの。 「 概要、大義」と同義。
- 抽象化
- 関心のある特定の詳細のみに焦点を絞るために、不要な詳細を非表示にする ビューまたは モデルの作成。
-
ほかのすべての実体から区別するために不可欠な実体の特性。抽象化によって、参照者の視点から見た境界が定義されます。
- 抽象クラス
-
一連のサブクラスを通して共通する振る舞いを提供するが、それ自身はインスタンスを持つように設計されていない クラス。抽象クラスは概念を表すもので、抽象クラスから派生したクラスが概念の実装を表します。「 基底クラス」も参照。 具象クラスの対比。
- 調査テスト
- コンピューター・ソフトウェアのテスト技法で、テストの実行に先立ち要求される計画は最小限とし、テスト対象の文書化は限定的なものにとどめられます。テスト作業の進行については、テスト担当者のスキルと知識、テスト結果のフィードバックに依存します。調査テストは、あるセッションから得られるフィードバックを以降のセッションの計画を動的に作成するような短いセッションで用いられることが多くあります。詳しくは、[ BAC01a] を参照してください。
- 頂点
-
状態マシンの中の遷移前の状態あるいは遷移後の状態。頂点は状態または擬似状態のいずれかになります。「 状態」、「 擬似状態」を参照。
- 直接アクセス記憶装置 (DASD)
- ディスク・ドライブなどのように、直接アクセスできる記憶装置 (逐次アクセス方式のテープ・ドライブと対比されます)。
- 直列化
- 分解と同義。
- ツール・メンター
- 特定のソフトウェア・ツールを使用して特定のプロセス作業あるいはステップを遂行する方法に関する実用的な手引きを提供する記述。
- 追跡可能性
- 追跡可能性は、プロジェクト要素を調べて、ほかの関連するプロジェクト要素、特に 要求に関連するプロジェクト要素を追跡します。追跡可能性に関係するプロジェクト要素は、追跡可能性アイテムと呼ばれます。
- 追跡可能性アイテム
- プロジェクト要素間の依存関係を追跡し続けるために、別なプロジェクト要素から明示的に追跡される必要のあるプロジェクト要素。Rational RequisitePro の観点ではこの定義を、RequisitePro 要求タイプのインスタンスによって RequisitePro 内に表現されるプロジェクト要素であると言い換えることができます。
- データ・タイプ
-
操作による副次的な影響が発生しない、アイデンティティーを欠く一連の値の記述子。データ・タイプには、定義済み基本タイプとユーザーによる定義が可能なタイプがあります。定義済みタイプには数字、文字列や時間などがあります。ユーザーによる定義が可能なタイプには列挙などがあります。
- データベース
- (1) 1 つ以上のアプリケーションを提供するために、スキーマに準拠して制御された冗長性と共に格納された関連データの集合。
- (2) システムに格納されているすべてのデータ・ファイル。
- (3) データベース管理システムで格納され管理されている一連のデータ。
- データベース管理システム (DBMS)
- 中央制御、データの独立性、効率的なアクセスに対する複雑な物理的な構造、信頼性、復旧、並行性の制御、プライバシー、セキュリティーなどのサービスを提供することで、データを管理するコンピューター・プログラム。
- テーブル
- 特定のエンティティーやトピックについての情報の集合を表すデータベースの要素。
- テーブル・スペース
- データベース内の記憶領域の論理単位。
- 定義モデル
-
リポジトリーのベースとなるモデル。いかなるリポジトリーも同じ定義モデルを所有できます。
- デシリアライズ
- デマーシャルされた状態からオブジェクトを作成すること。「 マーシャル」、「 リザレクト」も参照。
- テスト
- (1) ソフトウェア開発プロセスにおける 作業分野の 1 つ。その目的は、システムを統合してテストを行うことです。
- (2) 所定の テスト・ケースのインスタンス。
- (3) テストを実行すること。
- テスト・エスケープ
- テスト・チームが行う障害の検出作業で見つからずに、後に下流の実動条件で見つかる 欠陥や 障害。
- テスト・オラクル
- テストがパスするか失敗するかを知るための方策。テスト・オラクルには、テストの出力を観測できるようにする媒体と、媒体が表す内容を解釈するための技法が含まれます。観測される結果を期待される結果に対して評価するための手段となります。
- テスト・カバレッジ
- テスト範囲やその測定方法を示す用語。テストの範囲を測定する一般的な方法としては、所定のテスト・セットが、所定の システムや コンポーネントについてのテスト・ケースで指定された正式な仕様をどの程度処理するかを考慮します。
- テスト・ケース
- 対象テスト項目の特定の側面を評価する目的で識別された、テスト入力、実行条件、予期される結果のセットの (通常は正式な) 仕様。テスト・ケースは、 テスト構想と異なり、これにもとづくテストが行う内容を記述したより詳細なテスト仕様です。
- テスト・サイクル
- テストの実行や評価などを含む、テスト作業の期間。この期間は、 テスト環境へのソフトウェア・ ビルドの受け入れ (個々のテストでビルドが使用可能になる) から、そのビルドに対する現行のテスト作業期間が終了するまでとなります。多くの反復には、少なくとも 1 つのテスト・サイクルが含まれますが、サイクルなしでも、複数のサイクルがあっても構いません。
- テスト・シナリオ
- テストの実行コンテキストで対象とするふるまいを識別するアクション (実行条件) のシーケンス。テスト・シナリオにより、アクション・シーケンスの同等のクラスを一般化でき、これらは範囲などの特性にもとづいて (特定のデータ値でなく) 等しいとみなされます。テスト・シナリオは、単一の範囲レベルでの振る舞いを記述し、そのレベルでの振る舞いのインスタンスを関連付けます。たとえば、テスト・シナリオにより 1 つ以上のユース・ケース・インスタンスを関連付ける、またはユース・ケース内の振る舞いのインスタンスに関連を持つことができます。「 シナリオ」、「 ユース・ケース・インスタンス」、「 テスト・プロシージャー」を参照。
- テスト・スイート
- テスト・スクリプトをグループ化するために使用される パッケージ化された成果物で、テストの実行を順序化して、テスト結果を判別するためのテスト・ログ情報の関連セットを提供します。 テスト・ドライバー、 シェル・スクリプトと同義。
- テスト・スクリプト
- テストを実現し、実行できるようにするためのステップごとの命令の集合。テスト・スクリプトは、手動で実行されるテキスト形式の命令として文書化されるか、自動でテストを実行するコンピューターで判読可能な命令の形をとります。「 テスト・シナリオ」、「 テスト・プロシージャー」を参照。
- テスト・ドライバー
- テストを呼び出し、テスト・データを提供し、制御、モニター、実行、テスト出力のレポートを行うために使用されるソフトウェア・モジュールまたはアプリケーション。テスト・ドライバーは、テストの自動実行を順序化し制御します。「 テスト・スイート」と同義。
- テスト・プロシージャー
- 所定のテストの手続き上の側面で、通常は 1 つ以上の与えられた テスト・ケースのセットアップとステップごとの実行のための詳細な指示の集まりです。テスト・プロシージャーは、テスト・シナリオとテスト・スクリプトの両方で取り込まれます。「 テスト・シナリオ」、「 テスト・スクリプト」を参照。
- テスト可能性
- 対象テスト項目を正しくテストできること。対象項目に要求されたテストを実装できない場合、これはテスト可能性に欠けることになります。テスト可能性に関する主な側面に次の 2 つがあります。1) 対象テスト項目が、テストを行うための適切なサポートを提供すること。2) テスト・チームで使用されるプロセスとツール、これを適用するための方法が適切であること。「 テスト・インターフェース」、「 テスト・アプローチ」を参照。
- テスト環境
- 既知の制御下の条件でテストを行う目的で設けられた、ハードウェアとソフトウェアの特定の構成インスタンス。「 導入環境」、「 環境」も参照。
- テスト構想
- 行われる可能性のあるテストを識別した簡単な記述。テスト構想は、一般的に所定のテストの側面である入力、実行条件や予期される結果を表しますが、多くの場合、テストの単一の側面のみを表します。テスト構想は テスト・ケースとは異なり、テスト作業の仕様は含まず、テストの背景となる構想のみを含む不完全なかたちの定義です。 テスト要求と同義。「 テスト・ケース」も参照。
- テスト対象
- 対象テスト項目と同義。
- テストの動機付け要因
- テストを行う動機付けをするもの、テスト担当者にアクションを起こさせるもの、テストを促すもの。テスト動機付け要因により、所定の実行可能ソフトウェア・リリースの適当な側面を評価するようテスト担当者に促す要因を識別することができます。RUP のテストの動機付け要因は、汎化として、通常は特定の 品質リスクを表し、 評価目標コンテキスト内で範囲が設けられます。
- テスト目標
- 「 評価目標」を参照。
- テスト要求
- テスト作業に課せられた要求で、1 つ以上のテストの実装と実行で満たす必要のあるものです。この用語は、 テスト構想に置き換えられました。
- デッドロック
- 2 つの独立した制御スレッドが共に中断され、互いに相手方の作業が終わるのを待っている状態です。 競合条件 を回避するために同期化のメカニズムを適用することが、デッドロックの発生原因となります。
- デバイス
- プロセッサー にサポート機能を提供する ノード の一種。 デバイスが埋め込みプログラム (デバイス・ドライバー) を実行できる場合でも、汎用アプリケーションを実行することはできません。その代わりに、汎用アプリケーションを実行する プロセッサーを支援するためにのみ存在します。
- デマーシャル
- 一連のバイトとして記述できるようにオブジェクトを分解すること。「 フラット化」、「 シリアライズ」も参照。
- 展開
- JavaBean 内において、接続するために使用可能な包含 Bean の機能を作成すること。たとえば、Bean がパネル上で 3 つの押しボタンから構成されているとします。この Bean がフレームに置かれると、フレームで使用できるように押しボタンの機能が展開される必要があります。
- テンプレート
- 事前に定義された 成果物の構造。
-
パラメーターライズド・ソフトウェア要素と同義。
- 統一モデリング言語 (UML)
- ソフトウェア集約的なシステムの成果物を視覚化、指定、構築、および文書化するための言語 [ BOO98]。『Unified Modeling Language』を参照してください [ UML01]。RUP 用語集では、統一モデリング言語がシンボル
によって定義されています。
- 等価クラス
- オブジェクトの振る舞いが等しくなるよう期待される同等の値の分類のこと。この技法を応用することにより、可能な時間内で行うテストが非常に多い場合、最も重要なテストを分析するのに役立ちます。 等価パターン、 ドメインと同義。
- 同期アクション
-
送信オブジェクトが結果を待つ要求。 非同期アクションの対比。
- 同期状態
-
状態マシンの並行領域を同期化するために使用される 状態マシン内の頂点。
- 統合
- 独立したソフトウェアのコンポーネントが 1 つの実行可能な総体に組み合わされる、ソフトウェア開発の作業。
- 統合開発環境 (IDE)
- エディタ、コンパイラー、デバッガーから構成されるソフトウェア・プログラム。
- 統合ビルド計画書
- 特定の反復で実装され統合されるコンポーネントの順序を定義する。通常「 反復計画書」に含まれる。
- 動的な情報
- ユーザーからの要求があった時点で作成される情報。動的な情報は時間と共に変化するため、ユーザーが表示するごとに異なるコンテンツが表示されます。
- 動的分類
-
汎化 の意味的なバリエーションで、 オブジェクト によって タイプ または ロール が変わる可能性があります。 静的分類 と対比。
- 導入
- ソフトウェア開発プロセスの 作業分野 の 1 つ。その目的は、開発したシステムをそのユーザーに無事に移行することです。トレーニング教材、インストール手順などの 成果物 を伴います。
- 導入環境
- 開発されたソフトウェアをその用途向けにインストール、実行するために設定されるハードウェアとソフトウェア構成の特定のインスタンスのこと。「 テスト環境 」、「 環境 」も参照。
- 導入ユニット
-
プロセスやプロセッサーにまとめて割り当てられる オブジェクト または コンポーネント 。分散ユニットは、実行時 コンポジットまたは 集約 によって表すことができます。
- ドメイン
- 関連する価値のファミリーによって特徴づけられる知識または作業の領域。
-
その領域の熟練者が理解できる概念と用語で特徴づけられた、知識または作業の領域。
- ドメイン (データベース)
- データベース内のテーブルの列に有効な値範囲を定義するユーザー定義のデータ・タイプ。
- ドメイン・モデル
- ドメイン・モデルには、 ドメインの観点から重要なタイプのオブジェクトが取り込まれます。ドメイン・オブジェクトは、システム動作環境に存在するエンティティーまたは発生するイベントを表します。ドメイン・モデルは、 ビジネス分析モデルのサブセットです。
- ドメイン名サーバー
- www.software.ibm.com などのドメイン名を 123.45.67.8 などの数値で示されたインターネット・プロトコル・アドレスに変換するシステム。
- トランザクション
- 単一要求によって開始される 1 つ以上のアプリケーション・プログラムから構成される処理の単位。トランザクションには、その実行には 1 つ以上のタスクを開始することが必要です。
- トランザクション処理
- ユーザーが発行した要求を受信するとすぐに処理される対話型アプリケーションをサポートするコンピューティングのスタイル。結果は比較的に短時間で要求者に戻されます。トランザクション処理システムではリソースの共有を監視して、同時に複数のトランザクションを処理できるようにします。
- トリガー
- 最初の
遷移を除いて、
状態マシンのすべての振る舞いはオブジェクトのインターフェースの 1 つにイベントが到着するとトリガーされます。したがって、トリガーはインターフェースによって遷移が引き起こされるこれらのイベントを定義します。トリガーは、トリガー元イベントが到着することが予想されるインターフェースと関連します。しかし、移行は複数のトリガー (移行を引き起こすトリガーの 1 つを満たすイベントなど) を保有することができます。
- トリガー (データベース)
- データベースに特定のアクションまたはアクションのセットを実行させるデータベースに関連したコード。
- トレース
-
2 つのモデル要素間の履歴関係またはプロセス関係を示す依存関係。これらのモデル要素は、もう 1 つのモデル要素からモデル要素を派生するときに、特定のルールを使用することなく同じ概念を表します。
-
ナ
- 内部遷移
-
オブジェクトの 状態 を変更することなく、イベントへの応答を知らせる 遷移 。
- 名前
-
モデル要素を識別するために使用する文字列。
- 名前空間
-
名前を定義し使用できるモデルの部分。名前空間内では、名前ごとに一意の意味を持ちます。 「 名前」を参照。
- 入状時アクション
-
この 状態 を実現するために行われる遷移にかかわらず、 状態マシン に状態を入力するときに実行されるアクション。
- 入力
- (1) プロセスで使用される 成果物 。「 静的成果物 」を参照。
- (2) 実行条件の発生をシミュレートするテストで使用される値。入力値は テスト・ケースに定義されます。
- ノード
-
ノードは実行時の計算リソースを表す分類子で、一般に最低でもある程度のメモリーを保有し、通常は処理能力を備えています。実行時オブジェクトとコンポーネントはノードに常駐する場合があります。
- 納品可能物
- 値、材料などがあるプロセスから出力される、 顧客 またはほかの 利害関係者 に対する結果。
-
ハ
- バージョン
- 複数の成果物のバリエーションの 1 つ。通常、新しいバージョンの成果物は、古いバージョンを元に拡張されます。
- パースペクティブ
- 一般に、観点といった意味合いで用いられます。
- Rational Software Architecture の使用法 (Eclipse に基づく) では、異なる役割や関連事項がサポートされる UI パラダイムの一部です。特定のパースペクティブが開くとデスクトップに関連するビュー、エディタ、アクションが表示されます。
- パーティション
-
(1) アクティビティー・グラフ : アクションへの責務を編成するアクティビティー・グラフの一部。「 レーン 」も参照。- (2) アーキテクチャー :同じ抽象化レベルの分類子またはパッケージのサブセット。パーティションはアーキテクチャーの垂直面を表し、その一方でレイヤーは水平面を表します。 レイヤー の対比。
- 配置図
-
実行時処理ノードの構成とノードに存在する コンポーネント 、 プロセス 、および オブジェクト を示す図です。コンポーネントは、コード・ユニットの実行時表現です。「 コンポーネント図 」も参照。
- 配置ビュー
- 1 つまたは複数のシステム構成、これらの構成におけるソフトウェア・コンポーネント (タスク、モジュール) のコンピューティング・ノードへのマッピングを示す アーキテクチャー・ビュー 。
- ハイパーテキスト
- ほかのテキストへの隠されたリンクが存在する文書のテキスト。ハイパーテキストが存在する単語をマウスでクリックすると、リンク先のテキストに移動します。同じ文書内の関連する参照に移動するために、ハイパーテキストは Windows のヘルプ・プログラムや CD 辞書で使用されています。ハイパーリンクの優れた点は、Web 上で HTTP を使用して世界中の Web 文書をリンクできることですが、世界中を明確に移動するにはやはりシングル・クリックすることが必要です。
- ハイパーテキスト・マークアップ言語
- WWW 上でハイパーテキスト文書を作成するために使用される基本的な言語。基礎的で平易な ASCII テキスト文書に使用されますが、これらの文書が Netscape などの Web ブラウザーで解釈される (レンダリングと呼ばれる) とき、この文書にはフォーマットされたテキスト、カラー、さまざまなフォント、画像、特殊効果、ほかのインターネットへのハイパーテキスト・ジャンプ先、情報フォームが表示されます。
- ハイパーリンク
- Web ページ上の領域で、クリックするとページのほかの領域またはほかの Web ページに移動できます。
- バインディング
-
テンプレートのパラメーターに引数を提供することで、 テンプレート から行う モデル・エレメント の作成。
- バウンダリー・クラス
- システムの環境とその内部動作間のコミュニケーションをモデル化するために使用されるクラス。
- 派生要素
-
別な要素から計算可能なモデル要素。セマンティックな情報を追加しない場合でも明瞭に示され、設計用に含まれます。
- パターン
- 所定のコンテキストで有用性が証明された、繰り返し起きる問題に対するソリューションのテンプレート。適切なパターンは、問題の特徴となる矛盾点を首尾よく解決し、その解決方法にもとづいて別の問題に対してあるパターンが選択されます。パターンと見なす上では、パターンの実際の応用を少なくとも 3 とおり示す必要があります。UML では、ソフトウェアに関してパラメーターライズド・コラボレーションによるパターンの表現をサポートしますが、パターンのほかの側面 (使用の結果や使用例のリストなど) を直接モデル化せず、テキストが使用されます。ソフトウェア・パターンは、そのパラメーターに値を結び付けることでインスタンス化されます。 パターンは、 アーキテクチャー・パターン、 分析パターン、 設計パターン、テスト・パターンおよび イディオムまたは 実装パターンなど、抽象概念のあらゆる規模やレベルで存在できます。
- Rational Software Architect での使用においては、対話的、区分的な推敲に対し最適化された変換は、同レベルの抽象化において、またしばしば同モデルにおいて、基本的に単一のメタモデル内で行われる。
- 発火する
-
状態の遷移を実行すること。「 遷移 」を参照。
- パッケージ
-
要素をグループに編成する汎用的なメカニズム。パッケージはほかのパッケージ内でネストされる場合もあります。
- 発展
- 初期開発サイクルの後に来るシステムの存続期間、ここでは、製品を発展させます。
- 発展的
- ユーザーのニーズを認識する反復型開発方針が完全に理解されていないため、要求が次の各反復で改善されます ( 推敲フェーズ)。
- 発案者
- 変更依頼 (CR) の発行者。標準の変更依頼メカニズムでは、発案者はまず現在の問題に関する情報を提供し、次にその変更依頼用紙に沿った形でソリューション提案を提出する必要があります。
- パラメーター
-
変更、受け渡し、返すことが可能な変数の仕様。パラメーターには、名前、タイプ、方向などを含めることができます。パラメーターは操作、メッセージ、イベントに使用されます。「 仮引数」と同義。 引数と対比。
- パラメーター接続
- プロパティーの値、またはアクション、メソッド、スクリプトの戻り値のいずれかを提供することで、アクションまたはメソッドのパラメーターを満たす接続。パラメーターは常に接続のソースです。「接続」も参照。
- パラメーターライズド要素
-
束縛されていないパラメーターが1 つ以上あるクラスの記述子。「 テンプレート」と同義。
- パレット
- Bean -パレットを参照。
- 汎化
-
汎化された要素と特化された要素の間の分類学的な関係。特化された要素は、汎化された要素と一貫性がありますが、より多くの情報を含みます。特化された要素のインスタンスは、汎化された要素が許可されている場所に代入できます。「 継承」を参照。
- 汎化可能要素
-
汎化関係に関与する可能性のあるモデル要素。「 汎化」を参照。
- 反復
- ベースライン化した計画と評価基準に基づいた明確な一連の作業。この結果が (内部的または外部的な) リリースとなります。
- 引数
-
実行時インスタンスに分解されるパラメーターの束縛。 実パラメーターと同義。 パラメーターの対比。- メソッド・コールにパラメーターとして存在するデータ要素、または値。引数により追加情報が提供され、呼び出されたメソッドがこの情報を使用して要求された操作を実行できます。
- ビジネス・アーキテクチャー
- ビジネス・アーキテクチャーとは、互いに明確な関連を持つエレメント要素の編成セットで、エレメント要素はその機能により定義され全体を構成します。これらのエレメント要素は、ビジネスの編成と振る舞いにおける構成を表現し、ビジネスの主要プロセスと構成を抽象化して表します。
- ビジネス・アクター (インスタンス)
- ビジネス外からビジネスと相互作用を行う人や物。
- ビジネス・アクター (クラス)
- 一連のビジネス・アクター・インスタンスが定義されるクラス。各ビジネス・アクター・インスタンスは、ビジネスに対して、同じ役割を果たします。
- ビジネス・イベント
- ビジネス・イベントは、空間と時間の中で起こるビジネスにとって意味のある出来事を記述します。ビジネス・イベントは、ビジネス・プロセス間でのシグナルに使用され、通常は ビジネス・エンティティーに関連付けられます。
- ビジネス・エンジニアリング
- 特定の目標に従ってビジネスを設計するために、企業が使用する一連の技法。ビジネス・エンジニアリング的な技法は、 ビジネス・リエンジニアリング、 ビジネス改善 、および ビジネスの創出 に使用できます。
- ビジネス・エンティティー
- ビジネス・エンティティーは、 ビジネス・アクター と ビジネス・ワーカー が操作する重要な永続情報を表します。
- ビジネス・ゴール
- ビジネス・ゴールは、ビジネスによって満たされる必要のある要求。ビジネス・ゴールは、将来の特定の時点にける特定の基準により要求される値を記述するもので、ビジネスの作業の計画、管理に使用できます。「 ビジネス目標 」も参照。
- ビジネス・システム
- ビジネス・システムは、特定の目的を実現する役割とリソースのセットをカプセル化し、その目的を達成するための一連の責務を定義します。
- ビジネス・プロセス
- 論理的に関連したアクティビティーをまとめたもので、組織のリソースを使用して組織の目的をサポートする形で、定義済みの結果をもたらします。RUP では、ビジネスに期待される振る舞いを示す ビジネス・ユース・ケース と、 ビジネス・ワーカー と ビジネス・エンティティー で実現される振る舞いを示す ビジネス・ユース・ケースの実現 を使用して、ビジネス・プロセスを定義します。「 プロセス」も参照。
- ビジネス・プロセス・エンジニアリング
- 「 ビジネス・エンジニアリング」を参照。
- ビジネス・モデリング
- ビジネスを視覚的にモデル化するときに使用できるモデリング技法をすべて包含したものです。これらは、 ビジネス工学に使用できる手法のサブセットです。
- ビジネス・ユース・ケース (インスタンス)
- 特定のビジネス・アクターとって価値のある観測可能な結果が得られるビジネスで遂行される、一連のアクション。
- ビジネス・ユース・ケース (クラス)
- ビジネス・ユース・ケース (クラス) では、一組の ビジネス・ユース・ケース・インスタンスを定義します。各インスタンスは特定のアクターにとって価値のある観測可能な結果が得られるシステムで遂行される、一連のアクションです。ビジネス・ユース・ケース・クラスには、「観測可能な値の結果」の生成に関係する、すべての主要ワークフローと代替ワークフローが含まれます。
- ビジネス・ユース・ケース・パッケージ
- ビジネス・ユース・ケース・パッケージは、ビジネス・ユース・ケース、ビジネス・アクター、関係、図などのパッケージを集めたものです。これは小さな部品に分割して、ビジネス・ユース・ケース・モデルを組み立てるのに使います。
- ビジネス・ユース・ケース・モデル
- ビジネスにおいて意図される機能のモデル。ビジネス・ユース・ケース・モデルは、組織内でのロールと納品可能物を明確にするための重要な入力情報として使用されます。
- ビジネス・ユース・ケースの実現
- ビジネス・ユース・ケースの実現では、 ビジネス分析モデル内で特定のビジネス・ユース・ケースのワークフローを実現する方法を、ビジネス・オブジェクトのコラボレーションの観点から記述します。
- ビジネス・リエンジニアリング
- 変更作業に既存のビジネス全体を包括的な視点でとらえ、必要な作業やその作業を行う理由を熟慮することが伴う ビジネス・リエンジニアリング を実施すること。既存のビジネス・プロセスをすべて調査し、これらのプロセスを再構築して大幅な改善を実現するまったく新しい方法を発見します。ビジネス・プロセス・リエンジニアリング (BPR) やプロセス革新とも呼ばれます。
- ビジネス・ルール
- ビジネス内で満たされるべきポリシーや条件をいいます。ビジネス・ルールは、モデルまたは文書 (あるいはその両方) に取り込むことができます。
- ビジネス・ワーカー
- ビジネス・ワーカーは、ビジネス内の 1 つのロールあるいは一連のロールを表します。ビジネス・ワーカーはほかのビジネス・ワーカーと相互作用し、 ビジネス・エンティティー を操作し、一方で ビジネス・ユース・ケースの実現 の実現に参加します。
- ビジネス改善
- 変更作業が局所的でビジネス全体にまたがらない ビジネス工学 を実行すること。コストやリード・タイムの削減、サービスと品質のモニターなどが行われます。
- ビジネス戦略
- ビジネス戦略は、ビジネス構想を実現するための原則やゴールを定義します。これは、最終的にビジネス構想の達成を導く長期の ビジネス目標 を集約したものです。
- ビジネスの創出
- 新しい ビジネス・プロセス の生成、新しい分野のビジネスの開拓、新しい組織の創設を目標に、 ビジネス・エンジニアリング を実現すること。
- ビジネス分析モデル
- ビジネス・ユース・ケース の実現を記述する オブジェクト・モデル 。「 ビジネス・オブジェクト・モデル」と同義。
- ビジネス目標
- 一般的に上位の ビジネス・ゴールを表す用語。通常、ビジネス目標は抽象的なことから測定が困難であるため、より測定のしやすい下位のビジネス・ゴールへと置き換えます。
- ビジュアル・プログラミング・ツール
- グラフィカルにプログラムを指定する手段となるツール。アプリケーション・プログラマーはコンポーネントのグラフィカルな表現を操作して、アプリケーションを作成します。
- 非同期アクション
-
送信オブジェクトが結果を待つことがない要求。 同期アクションの対比。
- 非武装地帯 (DMZ)
- サブネットワークを表すために、この業界で最近よく使用される用語です。通常、外部インターネットと企業内の内部ネットワークの両方からファイアウォールで保護されている Web サーバーに使用されます。
- ビュー
- 与えられた視点から見たモデルの単純化された記述 (抽象化) で、この視点に関係のないエンティティーは省略されます。「 アーキテクチャー・ビュー」も参照。
-
特定の観点または見解によるモデルへの射影。この観点に関係のないエンティティーは省略されます。
- ビュー (データベース)
- データベースの 1 つ以上の物理テーブルの列情報からなる仮想テーブル。
- ビューの射影
-
モデル要素の ビュー要素への射影。それぞれのビュー要素に対し、ビューの射影が位置とスタイルを提供します。
- ビュー要素
-
モデル要素の集まりをテキストまたはグラフィック、あるいは両方の形式に射影したものです。
- 評価目標の決定
- 所定の作業スケジュールにおけるテスト・チームの作業目標の要点を記した簡単な記述。通常、反復ごとに検討が繰り返され、テストの利害関係者に利益をもたらすよう生産的に作業を行えるようにします。評価目標の決定の記述には、「重要な問題を迅速に見つける」、「知覚できる品質についての助言」、「仕様に対する検証」などがあります。
- ビルド
- システムまたはシステムの一部の動作可能なバージョン。最終製品で提供される能力の一部を実証します。
- 品質
- 製品やサービスついて、明示または暗黙の要求を満たすための能力に影響する機能や特徴の総体のこと。
- 品質保証 (QA)
- 製品やサービスが所定の品質要求を満たしていることを正しく保証するため計画的、体系的に行われるアクション。
- 品質リスク
- ソフトウェア製品の品質に悪影響を与える可能性が高い、起こり得るまたは現在進行中の事態。品質リスクを評価する上では、おそらく無数の品質の特性が存在しますが、RUP では FURPS+ 要求モデルにもとづき、品質の特性を扱います。
- ファイアウォール
- コンピューター、またはプログラマブル・デバイスで、そのソフトウェアを使用してトラフィックの通過を定義したルールに従って制限します。通常、制御は起点アドレスまたは宛先アドレス、および TCP/IP ポート番号に基づいて適用されます。
- ファイル転送プロトコル (FTP)
- コンピューター間のファイル転送を可能にする基本的なインターネット機能。FTP を使用すると、離れているホスト・コンピューターからファイルをダウンロードしたり、自分のコンピューターから離れているホスト・コンピューターにファイルをアップロードすることができます。
- ファクトリー
- (1) オブジェクトの作成や、インスタンス化を扱う 設計パターンの特定グループを表す用語。例として、「 抽象ファクトリー」、「 ファクトリー・メソッド」、 [ GAM94] などがあります。
- (2) Java - 目に見えない Bean の機能で、特定の Bean の新規インスタンスを動的に作成します。
- フィールド
- 「 属性 」を参照。
- フェーズ
- プロジェクトの 2 つの主マイル・ストーンに挟まれた期間。この間に、十分に定義された一連の目標が達成され、成果物が完成し、次のフェーズへの移行についての決定がなされます。
- フラット化
- 「 デマーシャル 」と同義。
- プラットフォーム
- [ OMG03] では次のように定義されています。
「インターフェースおよび指定された使用パターンを介して、機能のコヒーレントなセットを提供するシステム/テクノロジーのセットです。プラットフォームに依存するサブシステムはいずれも、プラットフォームにより提供されている機能がいかに実装されているのかを考慮せずに使用できます。
- プラットフォーム・モデル (PM)
- プラットフォーム・モデルとは、概念 (パーツとサービスを表す)、仕様、インターフェース定義、制約定義、およびそのほか特定のプラットフォームを使用するにあたりアプリケーションが必要とするもののセットです。」 MDA では、プラットフォーム・モデルは、UML などに詳細に形式化されています。MOF 準拠のリポジトリーにもあります。たとえば、プラットフォーム・モデルは J2EE、.NET などに対しビルドできます。
- プラットフォーム依存モデル (PSM)
- [ OMG03] では次のように定義されています。
「特定のプラットフォーム上で、特定テクノロジーの具現化の際に使用する情報を含むサブシステムのモデル。プラットフォーム特有の要素も含む場合があります。
- プラットフォーム独立モデル (PIM)
- [ OMG03] では次のように定義されています。
「プラットフォーム特有の情報を含まないサブシステムのモデル、またはそれを具現化するテクノロジー。」
- 振る舞い
-
操作やイベントの明確な影響で、結果も該当します。
- 振る舞いから見たモデルの側面
-
メソッド 、 コラボレーション 、および 状態 の履歴などのシステムの インスタンス の振る舞いを強調する モデルの側面 。
- 振る舞い特性
-
操作 や メソッド などの モデル要素 の動的特性。
- ブレーク・ポイント
- コンピューター・プログラムの実行が停止するポイント。
- フレームワーク
-
特定の ドメイン内で、アプリケーション向けの拡張可能な テンプレートと提供する、小 アーキテクチャー。
- プロキシー
- 特定のネットワーク・アプリケーション (たとえば FTP の Telnet) に対応したネットワーク間に設置されるアプリケーション・ゲートウェイ。たとえば、ファイアウォールのプロキシーである Telnet サーバーを使用すると、ユーザーの認証を実行した後で、トラフィック・フローをそこにプロキシーがない場合と同じように通過させることができます。機能はクライアント・ワークステーションではなくファイアウォールで実行されるため、ファイアウォールでの負荷がさらに増大することになります。SOCKSと比較してください。
- プロジェクト
- プロジェクトは人間よって実行され、限られたリソースによる制約を受けて計画、実行、制御されます。プロジェクトは、一意の製品またはサービスを作成するために実行される暫定的な試みです。暫定的とは、プロジェクトには明確な開始と明確な終了が設定されていることを意味しています。一意とは、製品またはサービスが類似した製品とサービスから特徴的な方法で区別されていることを意味します。プロジェクトはしばしば組織のビジネス戦略を実行する際に重要なコンポーネントとなります。
- プロジェクト・レビュー委員会 (PRA)
- プロジェクト管理者が報告を行う組織体。PRA はソフトウェア・プロジェクトが方針、実践原則、規約に準拠しているかを確認する必要があります。
- プロジェクト管理者
- プロジェクトに対するすべての責務が課せられた役割。プロジェクト管理者はプロジェクト・スケジュールや予算、品質要求に従ってタスクがスケジュールされ、割り当てられ、完了するようにする必要があります。
- プロセス
- (1) ほかのプロセス (特にオペレーティング・システム) と並行して論理的に実行で きる制御のスレッド。「 スレッド」も参照。
- (2) 目標の達成を目的として部分的に順序付けられた一連のステップ。ソフトウェア工学における目標とは、ソフトウェア製品の構築または既存のものに対する機能の追加です。プロセス工学における目標とは、プロセス・モデル (ビジネス工学のビジネス・ユース・ケースに相当する) の開発または改良です。
-
(1) オペレーティング・システムにおける並行性と実行の重量単位。 「 スレッド」と対比。スレッドは重量プロセスと軽量プロセスから構成されます。必要に応じて、ステレオタイプを使用して実装を区別できます。- (2) ソフトウェア開発プロセス (システムを開発するために使用されるステップとガイドライン)。
- (3) アルゴリズムの実行、または何かを動的に扱うこと。
- プロセス・ビュー
- タスク (プロセッサー) とその対話などのシステムの並行性に関する側面を表す アーキテクチャー・ビュー 。
- プロセッサー
- 1 つ以上のプロセスを実行する機能を有するノード・タイプ。通常、演算機能、メモリー、入出力デバイスなどが必要になります。「 ノード 」、「 プロセス 」、「 デバイス 」も参照。
- プロトコル
- カプセル間の通信に使用される互換メッセージ・セットの仕様。プロトコルでは、一連の入出力メッセージのタイプ (操作、シグナルなど) が定義され、オプションとして一連のシーケンス図が定義されます。このシーケンス図では、メッセージに必要な順序付けが定義され、プロトコルへの参加者の抽象的な振る舞いを指定する状態マシンが定義されます。
- プロトコル (TCP/IP)
- インターネット経由で世界中にコンピューター・メッセージを伝達する基本的なプログラミングの基礎。インターネットを定義するプロトコルのスイート。元々 UNIX オペレーティング・システム向けに設計されていたものですが、TCP/IP ソフトウェアは主要なコンピューター・オペレーティング・システムで使うことができます。インターネット上に存在するためには、コンピューターには TCP/IP ソフトウェアが必要となります。
- プロトタイプ
- 変更管理t と 構成管理で管理する必要のないリリース。
- プロパティー
-
要素の特性を示す名前付きの値。プロパティーにはセマンティクスな影響力があります。UML で定義済みのプロパティーと、ユーザーによる定義が可能なプロパティーがあります。「 タグ付き値 」を参照。
- プロパティー間接続
- あるオブジェクトのプロパティーから、別のオブジェクトのプロパティーへの接続。「接続」も参照。
- 分散型コンピューティング環境 (DCE)
- 分散型コンピューティング環境。分散型コンピューティングの事実上の業界標準としてコンピューター業界で採用されています。DCE により、さまざまなベンダーからのコンピューターが透過的に通信したり、ネットワークにあるコンピューティング・パワー、ファイル、プリンタなどのリソースを共有できるようになりました。
- 分散型処理
- 分散型処理は、機能やデータをLAN または WAN で接続された複数のコンピューティング・リソースの間で分散可能にするアプリケーションまたはシステム・モデルです。「 クライアント/サーバー コンピューティング」を参照。
- 文書
- 文書は、紙、またはそれに類するものを使用する媒体で表現される情報の集合です。紙に類するものとは、ページという概念が存在し、暗示的または明示的な一連のコンテンツがあるものです。この情報は文章や 2 次元の図で表現されます。紙に類するものの例として、ワード・プロセッサーの文書、スプレッドシート、スケジュール、ガント・チャート、Web ページ、またはオーバーヘッド・スライド資料などがあります。
- 文書記述
- 特定の文書のコンテンツを記述すること。
- 文書テンプレート
- Adobe(R) FrameMaker(R) や Microsoft(R) Word(R) などのツールで使用できる具体的なツールのテンプレート。
- 分析
- ソフトウェア開発プロセスの一部。主な目的は問題 ドメインのモデルを定式化することです。分析では何をすべきかに重点が置かれ、設計では方法に重点が置かれます。Analysis focuses on See: 「 設計」を参照。
- 分析クラス
- システムの設計要素によって演じられる 役割を抽象化したもので、 通常は、 ユース・ケースの実現のコンテキストの中で使用されます。 分析クラスでは複数の役割に対する抽象化が提供され、これらの役割に共通する振る舞いが示されます。通常、分析クラスは 1 つまたは複数の設計要素に発展します。たとえば、設計 クラスや カプセル (あるいはその両方)、または設計 サブシステムに発展します。
- 分析時
-
ソフトウェア開発プロセスの分析フェーズ中に起こる任意の物事を指します。「 設計時」、「モデリング時」を参照。
- 分析者
- 利害関係者のニーズを聞き出し解釈し、チーム全体に伝える責務があるプロジェクト・チームのメンバー。
- 分析と設計
- システムの機能と品質に対する 要求を満たすために、重要かつ計算された決定が行われる (一般的な) 作業。「 設計モデル」も参照。
- Unified Process における 作業分野であり、その目的は、実装時にシステムの ユース・ケースを実現する方法を示すことです。
- 分析パターン
- [ FOW97a] では、分析パターンを「ビジネス・モデリングにおける共通作成を示す概念のグループ。 つのドメインにのみ関係することも、多数のドメインにも関係できる」と表されています。 したがって、このリファレンスではドメインという語彙をパターンの説明に引用してあります。[ FOW97a] での定義はビジネス・モデリング以外のドメインに拡張されるべきです。分析パターンのもう 1 つの側面は、分析モデルのインスタンス化向けに (パターンと同様に結合を通じて) 意図された抽象的で概念的なテンプレートであると言えます。この場合、設計を通じてさらに改良が必要となります。 [ FOW97a] で示されている分析パターンの規模は中規模でアプリケーション全体の分析モデルを形成するように構成されていますが、分析パターンの規模はさまざまです。
- 分析メカニズム
- 設計プロセス初期の、中心となる クラスおよび サブシステムを明確にする発見段階で使用するアーキテクチャー・メカニズム。 通常、分析メカニズムでは実装に依存しない方法でソリューションの中心となる要素が取得されます。分析メカニズムは通常、問題領域には関係ありませんが、例外もあります。分析メカニズムは「コンピューターサイエンス」の概念です。分析メカニズムは領域に関連する クラスまたは コンポーネントに特定の振る舞いを提供します。あるいは、クラス同士、コンポーネント同士、または両者の間における協調作業の実現に対応します。分析メカニズムは フレームワークとして実装できます。 その例として、永続性、プロセス間通信、エラーまたは障害処理、通知、メッセージを処理するメカニズムが挙げられます。
- 分析モデル
- 設計モデルの抽象化の役割をする オブジェクト・モデル。 ユース・ケースの実現の初期定義を提供します。
- 分類子
-
振る舞いと構造の特徴を示すメカニズム。 分類子は、 インターフェース、 クラス、データ・タイプ、 コンポーネントから構成されます。
- ベースライン
- 今後の進化や開発に対する合意した基準を構成し、正式な手続き ( 変更管理や 構成管理) を通してのみ変更できる、レビューされ承認された 成果物。
- ベータ・テスト
- 意図的な顧客ベースのサンプリングによって製品が試されるリリース前のテスト。
- 並行サブ状態
-
同じコンポジット状態にある、ほかのサブ状態と同時に存在できる サブ状態。 「 コンポジット・サブ状態」を参照。 互いの素なサブ状態の対比。
- 並行性
-
同じ時間枠で 2 つ以上の作業が発生すること。 2 つ以上のスレッドを織り交ぜる、または同時に実行することで、並行性を実現できます。「 スレッド」も参照。
- 変換 (transform)
- Rational Software Architect の用法で、主にメタモデル、モデル、および抽象化のレベル間のバッチ処理用に最適化される変換。
- 変換 (transform) は、変換の実行の行為を表す動詞としても使用されます (例:「ユーザーがモデル A をモデル B に変換する」)。
- 変換 (transformation) (またはモデル変換)
- 一般的には、ルールの一部に従って (場合によっては、パラメーターやその他のデータの一部によって)、ソース・モデルからターゲット・モデルを生成するプロセス。
- また、「変換 (transformation)」は、ソース言語のモデルがターゲット言語のモデルに変換される方法を判別する成果物 (定義、仕様、ルール・セット、その他データなど) を表すために使用される場合があります。変換 (transformation) は、 変換 (transform) や パターンにさらに専門化され、Rational Software Architect の用法では抽象概念として扱われます。
- 変換定義
- [ KLE03] では、次のように定義されます。
"ソース言語のモデルがターゲット言語のモデルに変換される方法を、まとめて記述した変換ルールのセット"
- 変更依頼 (CR)
- 利害関係者 からの 成果物 または プロセス の変更依頼を表す一般的な用語。変更依頼には、現在の問題の原因と影響、提案するソリューションとそのコストに関する情報が記述されます。 「拡張依頼」と 「障害も参照。
- 変更管理
- 成果物 に対する変更を制御して追跡する作業。「 開発範囲の管理 」も参照。
- 変更審査委員会 (CCB)
- CCB の役割は、すべての 変更依頼 が適切に検討され、承認され、調整されるようにするための中心的な管理メカニズムを提供することです。
- 変数
- (1) データ特性用のオブジェクト内の格納場所。データ特性は数値や日付などのオブジェクトで、包含オブジェクトの属性として格納されます。
- (2)実行時にアイデンティティーを受け取る Bean。変数自体にはデータやプログラム・ロジックは含まれません。アプリケーションにある Bean から実行時アイデンティティーを受け取るなどのように、変数は結合される必要があります。
- ポート
- カプセル・インスタンスに対して、メッセージの受け渡しが行われるインターフェースとして機能するバウンダリー・オブジェクト。カプセルと共に作成され、カプセルと共に消失するため、ポートはカプセル・インスタンスに「所有」されているといえます。各ポートには、所有元のカプセル・インスタンスのアイデンティティーと状態とは異なるアイデンティティーと状態があります (同様に、どの部分もそのコンテナーとは異なります)。
- TCP/IP 用語。アプリケーションの接続先となる、個々にアドレスを指定することが可能なポイント。たとえば、デフォルトの HTTP はポート 80 を、Secure HTTP (HTTPS) はポート 443 を使用します。
- 異なるマシンやプラットフォームで使用するよう (ソフトウェア) を変更すること。
- ホーム・ページ
- 「 開始ページ」を参照。
- 包含
-
基底ユース・ケースから包含ユース・ケースへの関係で、包含ユース・ケース用に定義した振る舞いを基底ユース・ケース用に定義した振る舞いに挿入する方法を指定します。
- 包含階層
-
モデル要素 から構成される名前空間階層と、モデル要素間に存在する包含関係。包含階層によって、閉路のないグラフが作成されます。
- 包含関係
- 包含関係は、基底ユース・ケースから包含ユース・ケースへの関係で、包含ユース・ケース用に定義した振る舞いを基底ユース・ケース用に定義した振る舞いに明示的に挿入する方法を指定します。
- 包含文書
- 文書 はほかの文書に包含することができ、一連の文書は全体に集められます。包含する文書も個別の包含物も異なる 成果物 とみなされます。
- 方向づけ
- Unified Process の第 1 フェーズ。元になるアイデアや、前の世代の製品に対する提案を、 推敲フェーズに進めるだけの資金を (少なくとも内部的に) 獲得できるレベルまで成長させます。
-
マ
- マーシャル
- 「 デシリアライズ」と同義。
- マイルストーン
- 反復が正式に終了する時点。 リリース 時点に対応します。
- 未解釈
-
その実装が UML で指定されないタイプ用のプレースホルダー。未解釈値には、対応する文字式で表現されたものがあります。 任意の [CORBA] を参照。
- メカニズム
- メカニズムは、 パターンのインスタンスです。特定のモデルのコラボレーションになるには、さらに改良が必要になる場合もあります。つまり、メカニズムとは 1 つのコンテキストにおける (繰り返し起きる問題への) 特定のソリューションです。また、メカニズムは、パターンに当てはまるまたは準拠することと言えます。どのようなコラボレーションでもメカニズムと呼ぶことができますが、通常この用語は、ソフトウェア・アプリケーションで繰り返し発生する一般的な問題 (たとえば、永続的な処理の問題や、パターンが適用されるものなど) に対してソリューションを提供するコラボレーションにのみ用いられます。分析と設計では、メカニズムの概念は「プレースホルダー」として使用されます。たとえば、永続性が必要と特定されると、分析者と設計者は、問題が自動的に一貫して処理されるようにするため、永続性メカニズムを使用すると決断することがあります。
- メソッド
- (1) 物事を遂行する規則的かつ系統的な方法。タスクを遂行または目的を達成するために、詳細かつ論理的に指示された計画、実行手順のこと。
- (2) UML 1.1:操作の結果に影響する操作、アルゴリズム、プロシージャーを実装する方法。
-
操作の実装。操作に関連するアルゴリズムとプロシージャーを指定します。
- メソッド呼び出し
- メッセージ と同義。
- メタ-メタモデル
-
メタモデルを表す言語を定義するモデル。メタ-メタモデルとメタモデルの関係は、メタモデルと モデルの関係に似ています。
- メタオブジェクト
-
メタ・モデリング言語に含まれるすべてのメタ実体を表す一般的な用語。 たとえば、メタタイプ、メタクラス、メタ属性、メタ関連などがあります。
- メタクラス
-
クラスをインスタンスとして持つクラス。通常、メタクラスは メタモデルを作成するために使用されます。
- メタモデル
-
モデルを表す言語を定義するモデル。
- メッセージ
-
インスタンス間の通信の仕様であり、アクティビティーが発生することを想定したもの。メッセージには、操作のシグナルまたは呼び出しの送信を指定できます。
- メッセージ送信
- 分散型アプリケーションが互いにメッセージを送信して対話するときに使用するコミュニケーション・モデル。通常、メッセージは、返信を必ずしも必要としない情報の小パケットです。メッセージ送信は、非同期コミュニケーション・メソッドを実装します。特定のタスクを実行するときには、呼び出され、一連のパラメーターが渡されるクラス内の Java コードの断片化。
- モジュール
-
ソフトウェアの格納と操作の単位。モジュールには、ソース・コード・モジュール、バイナリー・コード・モジュール、実行可能コード・モジュールがあります。「 コンポーネント」を参照。
- 文字列
-
一連のテキスト文字。文字表現の詳細は実装に依存し、国際標準の文字やグラフィックをサポートする文字セットから構成されています。
- モデリング規則
- プロジェクトチーム管理が決定した概念の表現方法や、モデリング言語に対する制約 (「サブシステム間では継承を使用しない」、「ユース・ケース・モデルでは拡張関係や包含関係を使用しない」、「C++ ではフレンド構造体を使用しない」といった公式見解)。「ソフトウェア・アーキテクチャー 説明書」に記述されています。
- モデリング時
-
ソフトウェア開発プロセスのモデリング・フェーズ中に起こる任意の物事を指します。分析時と設計時も含まれます。使用上の注意:オブジェクト・システムを検討する際には、多くの場合、モデリング時と実行時の考慮事項の違いを明確にすることが重要になります。「 分析時」、 「 設計時」を参照。 実行時と対比。
- モデル
- あるシステムの意味的に閉じた抽象化。Rational Unified Process では、1 つの視点からのシステムの完全な記述 (「完全な」とは、その視点からシステムを理解するために、追加情報がまったく必要ないという意味)、すなわち一連のモデル要素のことを言います。モデルの重複はできません。
-
意味的に閉じた対象システムの抽象化。「 システム」を参照。- 使用上の注意: メタ-メタモデルを記述する MOF 仕様のコンテキストでは、メタ-メタモデルは単純にモデルと呼ばれることがよくあります。
- モデル推敲
-
公開されたモデルから リポジトリー・タイプを作成するプロセス。遂行されたモデルに基づき、また準拠してリポジトリーをインスタンス化および挿入できる、インターフェースや実装の作成などがあります。
- モデル・ビュー・コントローラー (MVC)
- アプリケーションのコンポーネントを分離するアプリケーション・アーキテクチャー。モデルはビジネス・ロジックまたはデータを表し、ビューはユーザー・インターフェースを表します。コントローラーはユーザー入力、場合によってはアプリケーション・フローを管理します。
- モデル駆動型アーキテクチャー (MDA)
- [ OMG03] では次にように定義されています。
「特定のテクノロジー・プラットフォーム上への機能実装仕様に依存しない、当該機能の IT システム仕様へのアプローチ。」
- モデル駆動型開発 (MDD)
- 抽象化の高位レベルにあるモデル (正確なモデル記述が要求されていなくても) から行うシステム開発のアプローチ (モデル記述に。モデルを単なる開発中の成果物と見るのではなく、オペレーション・システムが生成し得る正確な記述であると見ます。
- モデルの側面
-
メタモデルの特定の特性を強調するモデリングの次元。たとえば、構造モデルの側面はメタモデルの構造的な特性を強調します。
- モデル要素
-
モデル化するシステムから抽象化して取り出した要素。 ビュー要素と対比。- MOF 仕様では、モデル要素は メタオブジェクトと見なされます。
-
ヤ
- 役割
- ソフトウェア開発団体の中で、個人またはチームを組んでいる複数の人からなるグループの振る舞いと責務の定義。
-
特定のコンテキストに加わるエンティティーの名前付きの振る舞い。役割には、静的 (関連端など) と動的 (コラボレーション役割など) なものがある。
- ユーザー・インターフェース
- (1) ユーザーがコンピューターと対話できるようにするハードウェアやソフトウェア、あるいはその両方。
- (2) 通常、ユーザー・インターフェースという用語はユーザーが対話する視覚的な表現とその基底ソフトウェアを表します。
- ユース・ケース
- システムの振る舞いを、連続したアクションとして記述したもの。ユース・ケースでは結果として、 アクターにとって明らかに認められる値が生み出されます。ユース・ケースには、「明らかに認められる値」の出力に関連するイベントのフロー (代替フローと例外フローを含む) がすべて含まれます。すなわち、一連の ユース・ケース・インスタンスまたは シナリオは、ユース・ケースによって定義されるということです。
-
システム (またはほかのエンティティー) がシステムの アクターと対話することで実行できる一連のアクションの仕様 (変形など)。「 ユース・ケース・インスタンス」、「 シナリオ」を参照。
- ユース・ケース・インスタンス
-
ユース・ケースで指定される一連のアクションのパフォーマンス。ユース・ケースのインスタンス。ユース・ケース・インスタンスは、ユース・ケースを通じた特定の「エンドツーエンド」の明確なパスです。 アクターは、特定の人物 (アクター・インスタンス) で置き換えられ、特定の値と応答が与えられて、ユース・ケースの可能なフローを通じて 1 つのパスのみが取られます。「 シナリオ」、「 テスト・シナリオ」を参照。
- ユース・ケース・セクション
- ユース・ケース・セクションは、事前条件、事後条件、サブフロー、ステップ、およびテキストなどのユース・ケースの任意のセクション。ユース・ケース・セクションは、 追跡可能性アイテムとしてよく使用されます。
- ユース・ケース・パッケージ
- ユース・ケース・パッケージは、ユース・ケース、アクター、関係、図、そのほかのパッケージの集合体のことで、小さな部品に分割してユース・ケース・モデルを構成するために使います。
- ユース・ケース・ビュー
- アーキテクチャー上重要なコンポーネント (オブジェクト、タスク、ノード) に焦点を絞り、重要なユース・ケースがシステムで実行される方法を示す アーキテクチャー・ビュー。RUP において、ユース・ケース・ビューは ユース・ケース・モデルのビューのことを言います。
- ユース・ケース・モデル
-
システムの機能的な 要求を ユース・ケースの観点から説明するモデル。
- ユース・ケース図
-
システム内の アクターと ユース・ケースの関係を示す図。
- ユース・ケースの実現
- ユース・ケースの実現では、特定のユース・ケースの 設計モデルにおける実現方法が、オブジェクトのコラボレーションの観点から説明されます。
- ユーティリティー
-
クラス宣言の形式でグローバル変数とプロシージャーをグループ化するステレオタイプ。ユーティリティー属性とその操作は、それぞれグローバル変数とグローバル・プロシージャーになります。ユーティリティーは基本的なモデリング要素ではなく、プログラミングに使用する便利なツールです。
- ユニコード
- 現在使用されているさまざな言語で書かれたテキストの交換、処理、表示を行うために設計された文字コーディング・システム。通常、ユニコード文字は 16 ビットの符号のない整数を使用してコード化されています。
- 要求 (requirement)
- システムが満たす必要のある条件や能力を記述したもの。要求はユーザーのニーズから直接導き出されるか、または契約、規約、仕様あるいは正式に施行されたほかの文書に記されています。「 ソフトウェア要求 」を参照。
-
システムに対して期待される機能、プロパティーまたは振る舞い。
- 要求 (requirements)
- ソフトウェア開発プロセスにおける 作業分野 の 1 つ。その目的はシステムの動作を定義することです。最も重要な作業は、「 開発構想書 」、「 ユース・ケース・モデル 」および「 補足仕様書」を作成することです。
- 要求管理
- システムの ソフトウェア要求を割り出し、体系化、文書化し、顧客とプロジェクト・チームの間におけるシステムの要求変更についての合意を確立し保持するための、系統的なアプローチ。
- 要求属性
- 要求とほかのプロジェクト要素間のリンクを提供する特定の要求に関連づけられる情報。たとえば、優先度、スケジュール、ステータス、設計要素、リソース、コスト、危険要因などがあります。
- 要求タイプ
- 共通する特性や属性に基づく、要求の分類。要求タイプは、たとえば、利害関係者のニーズ、特性、ユース・ケース、補足仕様要求書、テスト要求、文書化要求、ハードウェア要求、ソフトウェア要求など、要求ソースや影響を与える領域に基づく場合があります。また、 FURPS+ などのように、その表すソフトウェア品質の特性をもとに分類することもできます。
- 要求追跡
- 要求をほかの要求やほかの関連づけられているプロジェクト要素とリンクさせること。
- 要素
-
モデル の最小構成要素。
- 呼び出し
-
分類子 に対し 操作 を呼び出す アクション状態 。
-
ラ
- ライフサイクル
- 方向づけ 、 推敲 、 作成 、および 移行 の 4 フェーズを含めた開発の全行程。方向づけフェーズの最初から、移行フェーズの最後までの期間。 開発サイクル、 サイクル と同義。 「 テスト・サイクル 」も参照。
- ランク
- アーキテクチャーへの影響度、 リリースにおける重要性を表す ユース・ケースまたは シナリオの属性。
- 利害関係者
- システムの出力結果によって著しい影響を受ける個人。
- 利害関係者のニーズ
- 購入あるいは利用を正当化するために満たす必要のあるビジネス上あるいは運用上の問題 (機会)。
- 利害関係者の要望
- 利害関係者から出される、多様なタイプの要望。たとえば、 変更依頼、拡張依頼、要求変更の依頼、欠陥などがあります。
- リザレクト
- 「 デシリアライズ」を参照。
- リスク
- 主要なマイルストーンの成功を妨げる可能性が高い、現在進行中のまたは差し迫った懸念。
- リスナー
- JDK 1.1 で、イベントを受け取り、処理するクラス。
- リソース・ファイル
- Java プログラムから参照されるファイル。たとえば、グラフィック・ファイルやオーディオ・ファイルなどです。
- リポジトリー
-
プロセスを制定する際の製品 (成果物) 出力 (要求、結果 (メトリクス)、オブジェクト・モデル、インターフェース、実装など) の保管場所。
- リリース
- エンド・プロダクトのサブセットで、主要マイルストーンでの評価の目的。リリースは、製品の安定した実行可能なバージョンであり、リリースノートやインストールガイドなどのリリースの使用に必要な一連の成果物を含みます。リリースには、内部向けのものと外部向けのものがあります。内部リリースは、マイルストーンの一部として開発組織のみで使用されるか、ユーザーや顧客向けのデモンストレーションに使用されます。外部リリース (納品バージョン) はエンドユーザーに納品されます。リリースは完全な製品であるとは限らず、エンジニアリングの視点から有用性を測定した場合の、1 ステップにすぎないこともあります。リリースは、開発チームが定期的な間隔で作業を完了させるための強制機能として働きます。これにより、いつになっても「あと一歩」で、なかなか作業を完了できない状態を防ぐことができます。「 プロトタイプ 」、「 ベースライン 」も参照。
- リリース管理者
- リリース管理者は、全ソフトウェア資産が管理され、必要に応じて、内部および外部 リリースに構成可能であることを確認する責務があります。
- リンク
-
オブジェクトどうしを意味的に接続するもの。関連のインスタンス。「 関連」を参照。
- リンク端
-
関連のインスタンス。「 関連端 」を参照。
- レーン
-
アクティビティー図において、アクションの責務を整理するための区切り。レーンは一般に、ビジネス・モデルの組織単位と対応します。「 パーティション」を参照。
- レイヤー
- 抽象度に応じてモデル内の パッケージ をグループ化する特定の方法。
-
分類子またはパッケージの同じ抽象化レベルでの編成。レイヤーはアーキテクチャーを横方向に切断し、パーティションは縦方向への分割を表します。 パーティションの対比。
- 列
- データベース内のテーブルの属性。
- 列挙
-
属性 タイプの範囲として使用される名前付きの値のリスト。たとえば、RGBColor = {red, green, blue} などがあります。論理値は、{false, true} の組み合わせの値を使用して事前定義された列挙です。
- レビュー
- レビューは、潜在的な欠陥を発見して一連の 成果物の品質を評価するために行われるグループ作業です。
- レポート
- 1 つまたは複数の 成果物 を記述することによって自動的に生成されるドキュメント。レポートそのものは、成果物ではありません。多くの場合、レポートは開発プロセスの暫定的な製品であり、発展するシステムのある側面と対話する伝達手段です。レポートは文書ではない成果物のスナップショット的な記述です。
- ローカル・エリア・ネットワーク (LAN)
- 地理的に限定されたエリア内で確立されたコンピューター・ネットワーク。通常、LAN は 1 台以上のサーバー・マシンから構成され、多数のクライアント・ワークステーションにサービスを提供します。
- 論理型
-
真と偽の値を持つ列挙。
- 論理ビュー
- システムの設計における主要なクラスを記述した アーキテクチャー・ビュー。 これには、主要なビジネス関連クラスと、主な振る舞いおよび構造の基本メカニズム (永続性、コミュニケーション、フォールト・トレランス、ユーザー・インターフェース) を定義するクラスがあります。Unified Process では、論理ビューは 設計モデルの ビューです。
-
ワ
- ワークステーション
- オペレーターが作業する入出力装置の構成。通常、メインフレームまたはネットワークに接続し、ユーザーがアプリケーションを実行する端末またはマイクロコンピューター。
- ワークスペース
- 作業領域には、現在作業をしているコード、つまり、現行の版が含まれます。ワークスペースには、標準 Java クラス・ライブラリーとほかのクラス・ライブラリーも含まれます。
- ワークフロー
- ビジネスの個々のアクターに対して、目に見える値としての結果を生成する、ビジネスで実行する一連のアクション。
- ワークフローの詳細
- なんらかの結果を達成するために緊密に協調して行われる作業のグループ化。通常、作業は並行または反復的に実行され、ほかの作業への入力として機能するある 1 つの作業からの出力が発生します。ワークフローの詳細は作業をグループ化して、より高度な抽象化を提供し、ワークフローの包括度を向上させるために使用されます。
-
数字
- 2 項関連
-
2 つの クラス の間の関連。 n 項関連 の特別なケース。
- 2 バイト文字セット (DBCS)
- 各文字を 2 バイトで表現する文字セット。 日本語、中国語、韓国語などの言語には 256 種類のコードだけでは表現できない記号が使用されているため、2 バイト文字セットが必要となります。 シングル・バイト文字セットと対比。
-
A
- ABC
- 「 活動基準原価計算 (ABC)」を参照。
- ABM
- 「 活動基準経営管理 (ABM)」を参照。
- ACL
- アクセス管理リスト。
- Advanced Program-to-Program Communication (APPC)
- IBM 環境で主に使用される通信プロトコル。
- API
- 「 アプリケーション・プログラミング・インターフェース」を参照。
- APPC
- 「 Advanced Program-to-Program Communication」を参照。
- ASCII
- 「 情報交換用米国基準コード」を参照。
- ASP
- 「 Active Server Page」を参照。
- ASP (Active Server Page)
- Web アプリケーションに動的な振る舞いを提供する技術メカニズムである Active Server Page (Microsoft(R))。
-
B
- BASIC
- Beginner's All-purpose Symbolic Instruction Code、プログラミング言語。「 VB」を参照。
- Bean
- アプリケーションの構築に使用できる小規模なコンポーネント。 「 JavaBean」を参照。
- BeanInfo
- Bean のプロパティー、イベント、メソッドに関する情報を検索するためにアクセス可能な一連のメソッドを定義する Bean の付随クラス。
-
C
- Call-Level Interface (CLI)
- データベース・アクセス用の呼び出し可能な API。埋め込み SQL アプリケーション・プログラム・インターフェースの代わりとなるものです。埋め込み SQL と比較した場合、CLI にはユーザーによる事前コンパイルや結合は必要ありませんが、その代わりに SQL ステートメントと関連するサービスを実行時に処理する標準的な一連の機能が提供されます。
- CBD
- 「 コンポーネントに基づく開発 」を参照。
- CCB
- 「 変更審査会 」を参照。
- CDR
- 「 重要な設計のレビュー」を参照。
- CGI
- 「 CommonGateway Interface 」を参照。
- CLI
- 「 Call Level Interface」を参照。
- CM
- 「 構成管理 」を参照。
- COBOL
- Common Business Oriented Language。
- COM
- Component Object Model (Microsoft)。DEC と Microsoft によるソフトウェア・アーキテクチャーで、ObjectBroker と OLE (Object Linking and Embedding) を間の相互作用を可能にします。Microsoft は後に COM を、 DCOM に発展させています。
- Common Gateway Interface (CGI)
- サーバー・マシン上で実行されているプログラムを Web サーバーで実行するための標準プロトコル。CGI プログラムは、Web クライアント・ブラウザーからの要求に応答して実行されます。
- Common Object Request Broker Architecture (CORBA)
- インフラストラクチャーを提供するソフトウェア・バス (Object Request Broker (ORB)) を定義するミドルウェア仕様。
- Computation Independent Model (CIM)
- [ OMG03] では次にように定義されています。
「ComputationIndependent Model とは、コンピューター技術に依存しない観点からのシステムへの観点。CIM ではシステムの詳細な構造は表示しません。CIM はドメイン・モデルとも言われ、ドメインの熟達者にはこの用語の方が周知されているので仕様にはこちらが使用されます。」
- CORBA
- 「 Common Object Request Broker Architecture 」を参照。
- CR
- 「 変更依頼 」を参照。
- CRC
- Class-Responsibility Collaborator。オブジェクト指向の開発における技法で、最初に Ward Cunningham と Kent Beck により提案されました。この技法を使用すると、オブジェクトがシステム内で行うべきこと (責務) の定義や、責務の遂行に関係するほかのオブジェクト (コラボレーター) の特定を容易に行うことができます。この技法については、[ WIR90] を参照してください。 CRC カードは、通常の索引カードを使用してこれらの結果を記録する 1 つの手段です。
- CRUPIC STMPL
- 製品要求の定義と製品品質の評価の両方で使用することのできるカテゴリーを表します。最初の部分は、運用上のカテゴリーである機能 (Capability)、信頼性 (Reliability)、使いやすさ (Usability)、性能 (Performance)、インストールのしやすさ (Installability)、互換性 (Compatibility) を表し、2 番目の部分は開発上のカテゴリーであるサポートのしやすさ (Supportability)、テストのしやすさ (Testability)、保守のしやすさ (Maintainability)、移植のしやすさ (Portability)、各国語対応のしやすさ (Localizability) を表します。「 FURPS+」も参照。
-
D
- DASD
- 「 直接アクセス記憶装置 」を参照。
- DBA
- データベース管理者。
- DBCS
- 「 2 バイト文字セット 」を参照。
- DBMS
- 「 データベース管理システム 」を参照。
- DCE
- 「 分散型コンピューティング環境 」を参照。
- DCOM
- Distributed Component Object Model (Microsoft)。Microsoft による Component Object Model (COM) の拡張で、ネットワークに分散されたオブジェクトをサポートします。
- DLL
- 「 ダイナミック・リンク・ライブラリー 」を参照。
- DMZ
- 「 非武装地帯 」を参照。
- DNS
- 「 ドメイン名サーバー 」を参照。
-
E
- e-ビジネス
- (1) インターネットなどの電子媒体を介した取引 。
- (2) インターネット・ビジネス・プロセスにおいてインターネット技術とネットワーク・コンピューティングを使用したビジネス (インターネット経由)、ビジネス関係 (エクストラネット経由)、品物やサービス、情報の購買、販売 (e-コマース経由)。
- Earned Value
- [ MSP97] では次にように定義されています。
「行われている作業の値の測定。 Earned Value はオリジナルの見積もりと進捗状況判断をもって、実際のコストと基本計画から見たタスクの進捗状況を提示します。」
- EJB
- 「 EnterpriseJavabean 」を参照。
- Enterprise JavaBean (EJB)
- EJB はサーバーで実行され、クライアントによって呼び出される目に見えないリモート・オブジェクトです。EJB は複数の目に見えない JavaBean から構築されます。EJB は 1 つのマシンに常駐し、ほかのマシンからリモートで呼び出されるように意図されています。プラットフォームには依存しません。Bean がいったん書かれると、Java をサポートするどのようなクライアントやサーバーのプラットフォームでも使用することができます。
- ERP
- 統合業務。
-
F
- Facade
- <<facade>> としてステレオタイプ化され、サブシステムのクライアントが必要とする全情報の編成とエクスポートを行う、サブシステム内にある特殊なパッケージ。このパッケージには、 インターフェース (インターフェースはサブシステムに対して一意)、サブシステム外インターフェースへの実現関係、そしてサブシステムを使うに当たってサブシステム・クライアントが必要とする文書類が含まれます。
- FTP
- 「 ファイル転送プロトコル」を参照。
- FURPS
- 機能 (Functionality)、使いやすさ (Usability)、信頼性 (Reliability)、性能 (Performance)、サポートのしやすさ (Supportability) などを表します。[ GRA92] では、この語は、製品要求の定義や製品品質の評価で使用可能なカテゴリーを表します。代わりのカテゴリー方式を使用することも可能です。「 CRUPIC STMPL」を参照。
-
G
- Green-field Development
- 最初から開発すること。既存システムを発展させること、または既存部分のリエンジニアリングとは対極をなします。まだ草の生えた未開拓の土地に新しい工場を建てることの意味が転じて、この用語となりました。
- GUI
- 「 グラフィカル・ユーザー・インターフェースe」を参照。
-
H
- HotJava
- Sun Microsystems, Inc. で開発された Java 対応 Web とインターネット・ブラウザー。HotJava は Java で作成されています。
- HTML
- 「 ハイパーテキスト・マークアップ言語」を参照。
- HTML ブラウザー
- 「 Web ブラウザー」を参照。
- HTTP
- Hypertext Transport Protocol。
- HTTP 要求
- Web ブラウザーが開始するトランザクションで、HTTP に準拠しています。通常、サーバーは HTML データを使用して応答しますが、ほかの種類のオブジェクトも送信できます。
-
I
- I/T
- 情報科学。
- IDE
- 「 統合開発環境 (IDE)」を参照。
- IE
- Internet Explorer (Microsoft)。
- IEEE
- 電気電子技術者学会 (The Institute of Electrical and Electronics Engineers, Inc.)。
- IIOP
- 「 Internet Inter-ORB Protocol」を参照。
- IMAP4
- Internet Message Access Protocol - Version 4。
- Internet Inter-ORB Protocol (IIOP)
- General Inter-ORB Protocol (GIOP) メッセージを TCP/IP ネットワーク経由でやり取りする方法を定義する、業界標準のプロトコル。IIOP では、インターネット自体を、ほかの ORB を中継するバックボーン ORB として使用できます。
- IP
- 「 インターネット プロトコル 」を参照。
- IP セキュリティー・プロトコル (IPSec)
- ネットワーク層でセキュリティー・サービス (暗号化) を提供すること。
- IP 番号 (IP アドレス)
- ドットで区切られた4 組から成る一意の番号であるインターネット・アドレス 。ドット付きクワッドとも呼ばれる(たとえば、123.45.67.8)。各インターネット・コンピューターに IP 番号が割り当てられ、多くのコンピューターはドット付きクワッドに対してマッピングまたは別名となる 1 つ以上のドメイン名を有しています。
- IPSec
- 「 IP セキュリティー・プロトコル 」を参照。
- ISAPI
- インターネット・サーバー API。
- ISO
- 国際標準化機構 (International Organization for Standardization)。
- ISP
- インターネット・サービス・プロバイダー。企業または個人向けに、インターネットへのアクセスやインターネット上での存在を提供する企業のこと。ほとんどの場合、ISP は IAP (インターネット・アクセス・プロバイダー) でもあります。
-
J
- JAR
- 「 Java archive (JAR)」を参照。
- Java
- Java は Sun Microsystems で開発されたプログラミング言語です。特に、Java はインターネットからコンピューターに安全にダウンロードでき、コンピューターやファイルへのウィルス感染などの危害を心配することなくすぐに実行できるプログラムを作成するために設計されています。アプレットと呼ばれる小さい Java プログラムを使用して、Web ページに動画、計算器、ほかの優れた機能を追加できます。通常のコンピューター・プログラムで行われることのほとんどができる Java プログラムを作成し、Web ページに Java プログラムを挿入できるため、Java を使用することで Web ページに広範な機能を追加できると考えることができます。
- Java archive (JAR)
- 多数のファイルを 1 つにまとめるプラットフォーム非依存のファイル形式。JAR ファイルは圧縮、ダウンロード時間の削減、セキュリティーのために使用されます。JAR 形式は Java で書かれているため、JAR ファイルを完全に拡張可能です。
- Java Database Connectivity (JDBC)
- JDK 1.1 における、この基準に準拠したデータベースへのプログラムのアクセスを可能にする API を定義する仕様。
- Java Development Kit (JDK)
- Java Development Kit は、Sun Microsystems からライセンスが与えられた開発者であれば使用できます。JDK の各リリースには、Java Compiler、Java Virtual Machine、Java Class Libraries、Java Applet Viewer、Java Debugger などのツールが同梱されています。
- Java Foundation Class (JFC)
- Netscape、Sun、IBM により開発された JFC は、Java アプリケーションへのインターフェースを作成するときに役立つブロックを構築します。JFC によって Java アプリケーションが既存のオペレーティング・システムと完全に対話することができます。
- JavaBean
- JavaBean は、別々に開発された Bean と併せて 1 つのアプリケーションに統合できるコンポーネントです。この単一アプリケーションはブラウザー内でスタンドアロンで使用でき、ActiveX コンポーネントとしても使用できます。JavaBean は単一プロセスに対してローカルになるように設計され、実行時に実行内容を見ることができることもよくあります。たとえば、この可視コンポーネントにはボタン、リスト・ボックス、グラフィック、チャートなどがあります。
- JDBC
- 「 Java Database Connectivity」を参照。
- JDK
- 「 JavaDevelopment kit 」を参照。
- JFC
- 「 JavaFoundation Class 」を参照。
- JIT
- Just in time。
- JVM
- Java Virtual Machine。バイト・コードにコンパイルされ、通常は「.class」ファイルにコンパイルされた Java プログラムを解釈するソフトウェアの仕様。JVM 自体は C 言語で記述されており、移植してほとんどのプラットフォームで実行が可能です。JVM の命令セットは、スタック指向であり、可変長の命令を持ちます。他の命令セットとは異なり、JVM は、オブジェクトのメソッド呼び出しの命令を組み込むことにより (他の命令セットのサブルーチン呼び出しに類似)、オブジェクト指向プログラミングを直接にサポートします。
-
L
- LAN
- 「 ローカル・エリア・ネットワーク (LAN)」を参照。
- LDAP
- Lightweight Directory Access Protocol。オンライン・ディレクトリー・サービスにアクセスするためのプロトコル。LDAP は、 TCP/IP 経由で実行されるディレクトリーの更新と検索を行うための比較的単純なプロトコルを定義します。
-
M
- MIB
- Management Information Base。
- MIME
- 「 MultipurposeInternet Mail Extension (MIME) 」を参照。
- MOF
-
OMG により定義された技術。Meta-Object Facility (MOF) 仕様により、一連の CORBA IDL インターフェースが定義されています。これを使用して、相互運用メタモデルとその関連するモデルのセットを定義して操作します。これらの相互運用メタモデルには、メタモデルを使用して指定される UML メタモデル、MOF メタ-メタモデル、これから OMG に採用される技術などがあります。MOF では、CORBA 準拠の設計と再利用リポジトリーを実装するインフラストラクチャーが提供されます。この定義は、MOF 仕様バージョン 1.3 に基づいています。
- MOM
- Message-Oriented Middleware。
- Multipurpose Internet Mail Extension (MIME)
- テキスト、イメージ、オーディオ、ビデオをサポートするメール用のインターネット規格。
- mutator メソッド
- オブジェクトによりそのインスタンス変数へのインターフェースを定義するために提供されるメソッド。インスタンス変数の値を戻すアクセサー・メソッドは get メソッドまたは getter メソッドと呼ばれ、インスタンス変数に値を割り当てるミューテーター・メソッドは set メソッドまたは setter メソッドと呼ばれます。
- MVC
- 「 モデル・ビュー・コントローラー 」を参照。
- MVS
- Multiple Virtual Storage。
-
N
- n 項関連
-
3 つ以上のクラス間の関連。関連の各インスタンスは対応するクラスの n 組の値を持ちます。 2 項関連と対比。
- NC
- ネットワーク・コンピューターまたはネットワーク・コンピューティング。
- NCF
- ネットワーク・コンピューティング・フレームワーク。
- NO TERM ENTRY
- NSAPI
- Netscape Server API。
- NT
- Windows NT (New Technology)。
-
O
- Object Request Broker (ORB)
- オブジェクトが透過的に要求を作成してローカルまたはリモートのオブジェクトから応答を受け取る方法を表す CORBA 用語。
- ODBC
- 「 Open Database Connectivity」を参照。
- ODBC ドライバー
- ODBC ドライバーはダイナミック・リンク・ライブラリー (DLL) であり、ODBC ファンクション・コールを実装してデータ・ソースと対話します。
- ODBC ドライバー・マネージャー
- Microsoft から提供されている ODBC ドライバー・マネージャーは、インポート・ライブラリーを伴う DLL です。ドライバー・マネージャーの主な目的は、ODBC ドライバーをロードすることです。また、ドライバー・マネージャーは各ドライバーに対する ODBC 機能へのエントリ・ポイント、ODBC コールに対するパラメーター検証やシーケンス検証も提供します。
- OLTP
- 「 オンライン・トランザクション処理 (OLTP)」を参照。
- OMG
- Object Management Group。
- OO
- オブジェクト指向。
- OOP
- 「 オブジェクト指向プログラミング (OOP)」を参照。
- Open Database Connectivity (ODBC)
- Microsoft が開発した C データベース・アプリケーション・プログラミング・インターフェース (API) であり、呼び出し可能な SQL を呼び出すデータベース管理システムへのアクセスを可能にします。この場合、SQL プリプロセッサーを使用する必要はありません。さらに、ODBC では、ユーザーがデータベース・ドライバーと呼ばれるモジュールを追加できるようにするアーキテクチャーが提供されます。このモジュールは、実行時に選択したデータベース管理システムにアプリケーションをリンクします。つまり、アプリケーションをサポート対象の全データベース管理システムのモジュールに直接リンクさせる必要はないのです。
- ORB
- 「 Object Request Broker (ORB)」を参照。
-
P
- PCO
- 「 管理と観測のポイント 」を参照。
- PDR
- 「 初期段階の設計のレビュー 」を参照。
- PERL
- Practical Extraction & Reporting Language。
- PGP
- Pretty Good Privacy。
- PKI
- 公開鍵インフラストラクチャー。
- POP3
- Post Office Protocol 3。
- PRA
- 「 プロジェクト・レビュー委員会 (PRA)」を参照。
- PRD
- 「 製品要求説明書 (PRD)」を参照。
- private
- クラス・メンバーと関係づけられているアクセス・モディファイアー。クラスのみにメンバーへのアクセスを許可します。
- protected
- クラス・メンバーと関係づけられているアクセス・モディファイアー。クラス自身、サブクラス、同一パッケージの全クラスがメンバーにアクセスできるようにします。
-
Q
- QA
- 「 品質保証 (QA) を参照。
- QE
- 品質工学。「 品質保証 (QA) も参照。
-
R
- Rational Process Workbench (RPW)
- プロセスをカスタマイズし、公開するツール。このツールによって、プロセス・エンジニアはカスタマイズ済みソフトウェア開発プロセスの納品を早め、UML を使用してプロセスを視覚的にモデリングし、RUP に取り入れられている最善の実践原則を活用できます。
- RDBMS
- リレーショナル・データベース管理システム。
- Remote Method Invocation (RMI)
- JDK 1.1 において、分散型 Java プログラムを作成するための API。リモート Java オブジェクトのメソッドにほかの Java 仮想マシンからアクセスできます。
- RFC
- (1) Request For Change。開発における変更の提案に対して資金を用いるよう求める購入または販売側の要求。この要求には、技術上または契約上の問題、プロジェクトに対する影響または利益、コストとスケジュールへの影響の評価が記されます。
- (2) Request For Comment。インターネット規格は RFC と呼ばれる文書で定義されています。
- RFI
- Request For Information。市場における正式な問い合わせで、一般的に「入札意向書」について、請負側が業務を請け負う能力があるか、要請文書に記載された作業に入札する能力があるかを確認すること。
- RFP
- Request For Proposal (提案書の要求)。作業の範囲を含んだ正式な案内で、契約の基盤となる方法論と補償上の内容を記した正式な応答 (提案) を求めます。
- RFQ
- Request For Quotation (見積もり要求)。指定の商品/サービスを依頼する正式の案内。
- RMI
- 「 Remote Method Invocation (RMI)」を参照。
- RMI コンパイラー
- RMI コミュニケーションを容易にするスタブ・ファイルとスケルトン・ファイルを生成するコンパイラー。このコンパイラーは自動的に [ツール] メニュー項目から呼び出すことができます。
- RMI レジストリー
- リモート・クライアントがサーバー Bean を参照できるようにするサーバー・プログラム。
- RPC
- 「 遠隔手続き呼び出し (RPC) 」を参照。
- RPW
- 「 RationalProcess Workbench (RPW) 」を参照。
- RSA
- Rivest-Shamir-Adleman アルゴリズム。
- RUP
- Rational Unified Process。
-
S
- S/MIME
- Secure MIME
- SAP
- 「 Systems,Applications, and Products (SAP) 」を参照。
- SEPA
- 「 ソフトウェア開発プロセス管理者」を参照。
- SET
- Secure Electronic Transaction。
- SHTTP
- Secure Hypertext Transfer Protocol。
- SMTP
- Simple Mail Transport Protocol。
- SNMP
- Simple Network Management Protocol。
- Socket Secure (SOCKS)
- 準拠クライアント・コード (クライアント・コードがソケットを安全にする) がリモート・ホストとのセッションを確立できるようにするゲートウェイ。
- SOCKS
- 「 Socket Secure (SOCKS)」を参照。
- SQL
- Structured Query Language。
- SRR
- 「 システム要求レビュー」を参照。
- SRS
- 「 ソフトウェア要求仕様」を参照。
- SSL
- Secure Sockets Layer。
- SSR
- 「 ソフトウェア仕様レビュー」を参照。
- Systems, Applications, and Products (SAP)
- 最初の社名は「Systemanalyse und Programmentwicklung」であり、現在「Systems, Applications, and Products in Data Processing」に変更しています。SAP は幅広く使用されている統合業務ソリューションを提供しています。
-
T
- TCP
- Transmission Control Protocol。
- TCP/IP
- Transmission Control Protocol/Internet Protocol。
- Telnet
- 米国国防総省の仮想端末プロトコル。
-
U
- UI
- 「 ユーザー・インターフェース」を参照。
- UML
- 「 統一モデリング言語 (UML)」を参照。
- UML プロファイル
UML メタモデルに対する一連の拡張です。ステレオタイプ、制約、タグ定義、およびタグ付き値を使用した新しいセマンティクスにより、特定の UML モデル要素をカスタマイズや拡張する方法を指定します。一貫性のある一連の拡張などが特定の目的で定義され、UML プロファイルを構成します。
- Uniform Resource Locator (URL)
- World Wide Web 上のリソースの標準識別子。接続を開始するために、Web ブラウザーで使用されます。URL は使用する通信プロトコル、サーバー名、パス情報から構成され、サーバーで受け取るオブジェクトを特定します。
- URL
- 「 Uniform Resource Locator (URL)」を参照。
-
V
- VB
- Visual Basic。特殊バージョンの BASIC (プログラミング言語)。Microsoft の IDE に関連しています。
- VM
- 「 仮想マシン」を参照。
- VPN
- バーチャル・プライベート・ネットワーク。
-
W
- Web アプリケーション
- システム・ユーザーとシステムとのコミュニケーションの主な手段としてインターネットを使用するシステム。「 Web システム」も参照。
- Web サーバー
- World Wide Web のサーバー・コンポーネント。Web ブラウザーからの情報への要求に対応する責務があります。情報は、サーバーのローカル・ディスクから取り出されたファイルか、または特定のアプリケーション機能を実行するためにサーバーによって呼び出されたプログラムによって作成されたファイルです。
- Web サイト
- 1 台のサーバー上にすべてが載っている Web システム。ユーザーはブラウザーで Web サイトをナビゲーションします。
- Web システム
- 階層構造や線形ではなく、グラフ形式で互いに結び付けられた情報ページを持つハイパーメディア・システム。Web システムは、ブラウザーからアクセスできる Web サーバーの形態を取ります。
- Web ブラウザー
- クライアント上で動作し、ユーザーが HTML ページを要求し表示できるようにするソフトウェアの 1 つ。
- Windows レジストリ
- Microsoft(R) Windows(R) の登録データベースで、PC にインストールされたソフトウェア・プログラムの構成とユーザー・オプションの保管に使用されます。
- World Wide Web (WWW または Web)
- グラフィカルでハイパーテキスト的なマルチメディアのインターネット・サービス。
- WYSIWYG
- What You See Is What You Get の略。
-
X
- XML
- 拡張可能マークアップ言語。
- XP
- エクストリーム・プログラミング。