UMLでは幾つかの「標準プロファイル」が規定されています．
UML仕様書(2.5.1)では22章(Standard Profile) にあたります．
Papyrus でも Standard Profile はサポートされており，Software Designer でコード生成する際に Standard Profile にて規定のステレオタイプが必要になることもあります．
UML 2.5.1 仕様書に規定されている Standard Profile モデルとしては以下の図で示される33個ほどあります．
また Table 22.1 Description of the Stereotypes in the UML StandardProfile に，その詳細な説明が記載されています．以下参考として同内容を転記しておきます． なお34個記載されていますが，これは«Create»の適用先が2つあるためで，ステレオタイプの個数としては33個となります．
若干機械的に翻訳したため説明が分かりにくいものも多々ありますが，詳細な情報を確認し，適宜updateしていければと考えています．
| 名前 | 適用先 | 説明 |
|---|---|---|
| «Auxiliary» | Class |
通常，二次的なロジックまたはコントロールフローを実装することで，より中心的な別のクラスまたは基本クラスをサポートするクラス． 補助クラスは通常，フォーカスするクラスと一緒に使用され，設計中に二次的なビジネスロジックやコンポーネントの制御フローを指定する場合に特に便利． «Focus»も参照のこと． |
| «BuildComponent» | Component |
コンパイルやバージョン管理など，システムレベル開発活動の目的のために定義された要素の集合． |
| «Call» | Usage |
そのソースが操作であり，そのターゲットが操作である使用法の依存関係． この関係は，依存関係が適用されるクラス内に操作が存在するという意味で，操作を含むクラスに包含されることもある． コール依存関係は，ソース操作またはソースクラス内の操作が，ターゲット操作またはターゲットクラス内の操作を呼び出すことを指し示す． コール依存関係は，ソース操作を，範囲内にある任意のターゲット操作（これに限定されるものではないが，囲み分類器の操作および他の可視分類器の操作）に接続することができる． |
| «Create» | Usage |
クライアント分類子がサプライヤ分類子のインスタンスを作成することを示す使用依存関係． |
| «Create» | BehavioralFeature |
指定されたフィーチャが，フィーチャが関連付けられている分類子のインスタンスを作成することを指し示す． |
| «Derive» | Abstraction |
通常同じタイプのモデル要素間の派生関係を指定するが，必ずしもそうである必要はない． 派生した依存関係は，クライアントがサプライヤから計算されることを指し示す． マッピングは計算を指定する． クライアントは，たとえ論理的に冗長であっても，効率性などの設計上の理由で実装することができる． |
| «Destroy» | BehavioralFeature |
指定された機能が，その機能が接続されている分類子のインスタンスを破棄することを示す． |
| «Document» | Artifact |
人間が読める形式のファイル． «ファイル» のサブクラス． |
| «Entity» | Component |
ビジネスコンセプトを表す永続的な情報コンポーネント． |
| «Executable» | Artifact |
コンピュータシステム上で実行可能なプログラムファイル． «ファイル»のサブクラス． |
| «File» | Artifact |
開発システムのコンテキストにおける物理ファイル． |
| «Focus» | Class |
サポートする1つ以上の補助クラスのコアロジックまたはコントロールフローを定義するクラス． フォーカスクラスは，通常，1つ以上のAuxiliaryクラスとともに使用され， 設計中にコアとなるビジネスロジックやコンポーネントの制御フローを指定する場合に特に便利． «Auxiliary»を参照． |
| «Framework» | Package |
システムの全部または一部に対して再利用可能なアーキテクチャを指定するモデル要素を含むパッケージ． フレームワークには通常，クラス，パターン，またはテンプレートが含まれる． フレームワークがアプリケーションドメインに特化している場合， フレームワークはアプリケーションフレームワークと呼ばれることもある． |
| «Implement» | Component |
仕様自体を持たないことを意図したコンポーネント定義． むしろ依存性を持つ別個の「仕様」の実装． |
| «ImplementationClass» | Class | インスタンスが複数のクラスを持たないプログラミング言語（C++，Smalltalk，Javaなど）のクラス実装． これは，Classとは対照的である． インスタンスは，一度に複数のクラスを持ち，時間の経過とともにクラスを獲得したり 失ったりする可能性があり，オブジェクトは複数のクラスを動的に持つことがある． Implementationクラスは，Classifierのオペレーションに指定されたのと同じ振る舞いで， Classifierに対して定義されたすべてのオペレーションを提供する場合，Classifierを実現すると言われている． インプリメンテーション・クラスは，いくつかの異なるタイプを実現することができる． Implementationクラスの物理的属性および関連は，それが実現する任意のClassifierのものと同じである必要はなく， Implementation Classは，その物理的属性および関連性に関して操作のためのメソッドを提供することができる． «Type»も参照のこと． |
| «Instantiate» | Usage |
クライアント上の操作がサプライヤのインスタンスを作成することを示す分類子間の使用依存関係． |
| «Library» | Artifact |
静的または動的なライブラリーファイル． «File»のサブクラス． |
| «Metaclass» | Class |
インスタンスもクラスであるクラス． |
| «Metamodel» | Model |
いくつかのモデリング言語（たとえば，MOFモデル）のモデリング概念を指定するモデル． «Metaclass»を参照． |
| «ModelLibrary» | Package |
他のパッケージによって再利用されることを意図したモデル要素を含むパッケージ． いくつかのプログラミング言語では，クラスライブラリに類似している． モデルライブラリには，プロファイルおよびステレオタイプなど， 12.3節で指定されたメタモデル拡張メタクラスのインスタンスは含まれない場合がある． ただし，ProfileApplicationsおよびStereotypeアプリケーションが含まれている場合があり， モデルライブラリはしばしば適用されたプロファイルと共に使用される． |
| «Process» | Component |
トランザクションベースのコンポーネント． |
| «Realization» | Classifier |
オブジェクトのドメインを指定し，それらのオブジェクトの物理的な実装も定義する分類子． 例えば«Realization»によってステレオタイプ化されたコンポーネントは， 別個の«Specification»コンポーネントで指定された動作を実装する分類子を実現するのみ． «仕様»を参照． «ImplementationClass»は，システム設計者にとって有益な属性やメソッドなどの機能を持つことができるクラスの実現であるため， «ImplementationClass»とは異なります． |
| «Refine» | Abstraction |
異なる意味レベルでのモデル要素間の洗練された関係（分析や設計など）を指定． マッピングは，2つの要素または要素のセットの間の関係を指定する． マッピングは計算可能であってもなくてもよく，単方向または双方向であってもよい． リファインメントを使用し，分析から設計およびその他の変更に至るまでの変換をモデル化することができる． |
| «Responsibility» | Usage |
要素の他の要素との関係における契約または義務． |
| «Script» | Artifact |
コンピュータシステムによって解釈可能なスクリプトファイル． «File»のサブクラス． |
| «Send» | Usage |
オペレーションがシグナルを送信することを指定， クライアントがオペレーションでありサプライヤがシグナルである使用法． |
| «Service» | Component |
ステートレスで機能的なコンポーネント． |
| «Source» | Artifact |
実行可能ファイルにコンパイルできるソースファイル． «File»のサブクラス． |
| «Specification» | Classifier |
これらのオブジェクトの物理的な実装を定義せずにオブジェクトのドメインを指定する分類子． 例えば，«Specification»によってステレオタイプ化されたコンポーネントは，インタフェースを提供し， 必要とするだけであり，その定義の一部として実現クラスを持たないことを意図している． «Type»は，アナリストのモデリングシステムにとって有用な属性やメソッドなどの機能を持つことができるため， «Type»とは異なります． «Realization»を参照． |
| «Subsystem» | Component |
大規模システムにおける階層分解の単位． サブシステムは一般的に間接的にインスタンス化される． サブシステムの定義はドメインやメソッドによって大きく異なり， ドメインとメソッドのプロファイルがこの構造を特化することが期待される． サブシステムは，仕様と実現要素を持つように定義することができる． «Specification»と«Realization»を参照． |
| «SystemModel» | Model |
SystemModelは，同じシステムのモデルのコレクションを含むステレオタイプのモデル． SystemModelには異なるモデルに含まれるモデル要素間のすべての関係と制約も含まれる． |
| «Trace» | Abstraction |
異なるモデルで同じ概念を表すモデル要素またはモデル要素のセット間のトレース関係を指定する． トレースは，主にモデル間の要件と変更を追跡するために使用される． モデルの変更は両方向で発生する可能性があるため，依存関係の方向性はしばしば無視できる． マッピングは2つの間の関係を指定するが，ほとんど計算可能ではなく通常は形式でない． |
| «Type» | Class |
それらのオブジェクトの物理的な実装を定義することなく， オブジェクトに適用可能な操作と共にオブジェクトのドメインを指定するクラス． ただし属性と関連性を持つことがある． タイプ操作の動作仕様は，例えばアクティビティ図を用いて表現することができる． オブジェクトは実装クラスを最大で1つ持つことができるが，複数の異なる型に準拠することができる． «ImplementationClass»も参照． |
| «Utility» | Class |
インスタンスを持たないクラスで，属性と操作の名前付きコレクションを表す． これらはすべて静的である． |