分類子のモデル要素 (特にクラス、サブシステムまたはコンポーネント) によって提供される振る舞い (操作) の集合を定義するモデル要素。分類子は 1 つ以上のインターフェースを実現可能です。インターフェースは 1 つ以上の分類子によって実現可能です。同じインターフェースを実現する分類子は、システム内で互いに置換可能です。各インターフェースでは、十分に定義された固有の操作の集合を提供する必要があります。 
Other Relationships:  一部設計モデル
役割:  ソフトウェア アーキテクト 
オプション性/オカレンス:  設計サブシステムとの組み合わせで使用します。推敲フェーズ
テンプレートとレポート: 
     
例: 
     
UML の表現:  インターフェース 
詳細情報:   
成果物を入力とする作業:    成果物を出力とする作業:   

目的 ページの先頭へ

インターフェースは操作の集合を宣言します。操作には、分類子モデル要素 (クラス、コンポーネント、サブシステムなど) で提供されるサービスを仕様化するために使用されるシグニチャーやパラメーターが含まれます。

プロパティー ページの先頭へ

プロパティー名  

概要  

UML の表現  

name   インターフェースの名前   属性  
description   インターフェースの簡単な説明   属性  
operations  インターフェースの操作  操作 

タイミング ページの先頭へ

インターフェースは推敲フェーズで作成され、システムの重要な「継ぎ目」を定義します。すべてのインターフェースはアーキテクチャー上重要です。

責務 ページの先頭へ

ソフトウェア・アーキテクトは次の事柄を徹底し、インターフェースの整合性に責任を持ちます。

  • 別のインターフェースの操作と重複しない、操作の固有の集合を定義していること
  • 関連する操作群をわかりやすく論理的にグループ化していること

カスタマイズ ページの先頭へ

インターフェースは一般に成果物: 設計サブシステムとの組み合わせで使用されます。成果物: 設計クラスとの組み合わせでインターフェースを使用することは、通常は必要でもなければ望ましいことでもなく、public の操作を使用すれば十分です。インターフェースは一般に、振る舞いを実現する要素から独立した形で振る舞いを (操作のシグニチャーの形式で) 定義する必要がある場合に使用します。これが暗示するのは、より粒度の大きい抽象的振る舞いまたは置換可能性の存在であり、それらは設計サブシステムとしてモデリングされます。これらの特徴が当てはまらないプロジェクトでは、インターフェースを省略できます。



Rational Unified Process   2003.06.15