成果物:
|
![]() |
分類子のモデル要素 (特にクラス、サブシステムまたはコンポーネント) によって提供される振る舞い (操作) の集合を定義するモデル要素。分類子は 1 つ以上のインターフェースを実現可能です。インターフェースは 1 つ以上の分類子によって実現可能です。同じインターフェースを実現する分類子は、システム内で互いに置換可能です。各インターフェースでは、十分に定義された固有の操作の集合を提供する必要があります。 |
---|---|
Other Relationships: |
一部設計モデル
|
役割: | ソフトウェア アーキテクト |
オプション性/オカレンス: | 設計サブシステムとの組み合わせで使用します。推敲フェーズ |
テンプレートとレポート: |
|
例: | |
UML の表現: | インターフェース |
詳細情報: |
成果物を入力とする作業: | 成果物を出力とする作業: |
インターフェースは操作の集合を宣言します。操作には、分類子モデル要素 (クラス、コンポーネント、サブシステムなど) で提供されるサービスを仕様化するために使用されるシグニチャーやパラメーターが含まれます。
プロパティー名 | 概要 | UML の表現 |
---|---|---|
name | インターフェースの名前 | 属性 |
description | インターフェースの簡単な説明 | 属性 |
operations | インターフェースの操作 | 操作 |
インターフェースは推敲フェーズで作成され、システムの重要な「継ぎ目」を定義します。すべてのインターフェースはアーキテクチャー上重要です。
ソフトウェア・アーキテクトは次の事柄を徹底し、インターフェースの整合性に責任を持ちます。
インターフェースは一般に成果物: 設計サブシステムとの組み合わせで使用されます。成果物: 設計クラスとの組み合わせでインターフェースを使用することは、通常は必要でもなければ望ましいことでもなく、public の操作を使用すれば十分です。インターフェースは一般に、振る舞いを実現する要素から独立した形で振る舞いを (操作のシグニチャーの形式で) 定義する必要がある場合に使用します。これが暗示するのは、より粒度の大きい抽象的振る舞いまたは置換可能性の存在であり、それらは設計サブシステムとしてモデリングされます。これらの特徴が当てはまらないプロジェクトでは、インターフェースを省略できます。
Rational Unified Process
|