UAFとは
Unified Architecture Framework（UAF：統合アーキテクチャフレームワーク）は、複雑なシステムやシステム群（SoS: System of Systems）を、ビジネス・運用・技術の観点から一貫して記述・分析・設計するための国際的なアーキテクチャフレームワークです。
UAFの主な目的は次の3点です。
- ステークホルダ間の共通理解を確立
- 複雑な要求・運用・システム・技術を統合的に可視化
- 意思決定（投資、設計、運用）の質を向上
UAFは「図を描くためのルール」ではなく、「なぜそのシステムが必要か」から「どう実装し、どう運用するか」までを一貫して整理する思考の枠組みです。
UAFの成り立ちと位置づけ
| フレームワーク | 説明 |
|---|---|
| DoDAF | 米国国防総省アーキテクチャフレームワーク |
| MODAF | 英国国防省アーキテクチャフレームワーク |
| NAF | NATO向けフレームワーク |
これらをOMG（Object Management Group）が統合し、UML/SysMLベースで標準化（OMG UAF 1.x）しました。
ドメイン
| ドメイン | 何を表現するか |
|---|---|
| Strategic | 目的、ビジョン、能力、KPI |
| Operational | 業務・運用、アクティビティ、情報の流れ |
| Services | 提供されるサービスの視点 |
| Resources | 人・組織・システム・技術 |
| Security | セキュリティポリシー、脅威、対策 |
| Standards | 規格・制約条件 |
IBM RhapsodyのUAF Toolkitを使ってUAFモデリングができるというので調べてみます。
以下、下記リンク先Webページの内容抜粋となります。
Working with the new UAF 1.2 profile for Rhapsody Engineering Systems Design
Rhapsodyのインストール
IBM Rhapsody評価版（無償）をインストールする をご覧ください。
新しい UAF プロファイルのインストール
UAF 1.2 プロファイルの新しいバージョンは、ここからダウンロードできます。
UAF 1.2 プロファイルには、緊急対応システムのサンプルモデル（WildfireUAF1.2.zip）も含まれています。
このプロファイルは標準的な ZIP ファイルに含まれているため、ファイルを解凍してください。解凍すると UAF12 パッケージとして開きます。
UAF12 フォルダの中には UAF フォルダがありますが、これは Rhapsody のインストール先にある Share/Profiles フォルダ（別名 $OMROOT/Profiles）内の既存の UAF フォルダを置き換える必要があります。
すでに UAF 1.1 をインストールしている場合は、そのパッケージ名を UAF11 に変更し、新しい 1.2 プロファイルを UAF フォルダとしてインストールしてください。
図：UAF フォルダのインストールパス
UAF フォルダがこの場所に配置されていることは非常に重要です。
この場所に存在しない場合、追加されたヘルパーやウィザードは一切動作しません。
図：ログ出力ウィンドウ
既存の UAF モデルを開く、または新しい UAF プロジェクトを作成すると、Rhapsody のログウィンドウに上記ダイアログと同様の出力が表示されるはずです。この出力が表示されない場合、Rhapsody が誤った場所にインストールされている可能性が非常に高いです。
UAF プロファイルの利用開始
UAF プロファイルをインストールしたら、新しいプロジェクトを作成し、Project Type のドロップダウンリストから UAF を選択することで、新しい UAF アーキテクチャを作成できます。これにより、UAF をベースとした新しい Rhapsody プロジェクトが作成されます。
UAF における主要なパッケージ構造は ArchitecturalDescription（アーキテクチャ記述） です。
これは UML パッケージであり、UML や SysML のパッケージと同様に、アーキテクチャを構造化するために使用できます。
また、このパッケージには、内包するアーキテクチャを記述するための複数のタグが関連付けられています。
Rhapsody で新しい UAF プロジェクトを作成すると、各ドメインごとに 1 つずつ、標準的な ArchitecturalDescription が自動的に作成されます
（必要に応じて、さらに追加の ArchitecturalDescription を内部に作成することも可能です）。
図：UAF アーキテクチャのメインパッケージ構造
この構造は作成方法の都合上、ルートの Rhapsody ファイルに埋め込まれた単一のユニットとして存在します。
そのため、プロジェクトの個々の部分を分割して作業しやすくするために、ユーザーには以下の操作が推奨されます。
それぞれの ArchitecturalDescription（パッケージ） を選択し、
「Create Unit」操作を使用して、それらを Unit に変換してください。
Rhapsody UAF Toolkit
UAF 1.1 プロファイルには、複数の ヘルパー および ウィザード が用意されています。
本セクションは、それらの使い方を詳細に解説するチュートリアルではなく、概要紹介を目的としています。
すべてのメニューは、Rhapsody のメインメニュー下部にある「UAF Toolkit」セクションからアクセスできます。
View Creator
View Creator は、「新規追加」メニューを開かなくても、特定の ArchitecturalDescription 内にダイアグラムを素早く作成できる機能です。
パッケージまたは要素を選択し、UAF Toolkit メニューから 「View Creator」 を選択すると、以下のような画面が表示されます。
図：View Creator グリッド
グリッド内のいずれかのボックスをクリックすると、選択したパッケージ内に該当するダイアグラムが作成されます。
作成されるダイアグラムの形式は、一般的に最もよく使われる標準的なものになります。
このウィザードを使って別の場所にダイアグラムを作成したい場合は、モデル内で新しいパッケージまたは要素を選択する必要があります。
なお、状態ベースのダイアグラム（Strategic States を除く）は、
OperationalPerformer、Resource、System、Software などの 構造要素をベースとした要素の配下でのみ作成可能です。
新しいモデル要素の追加
このヘルパーは、モデル内に任意のタイプの要素を素早く作成するための別の簡易機能です。
作成したい要素の所有先となる 要素またはパッケージを選択し、UAF Toolkit メニューから 「Add New Model Element」 を選択します。
図：Add New Model Element ウィンドウ
表示された入力ボックスに、作成したい要素名を入力し始めます。その後、スペースキーと Ctrl キーを押すと、入力された文字パターンに一致する要素のドロップダウンリストが表示されます。
マウスを使って適切な要素タイプを選択し、Enter キーを押すと、その要素が作成されます。
要素の作成は UAF メタモデルによって制約されているため、UAF メタモデルで許可された正しい場所にのみ要素を作成することができます。
分解（Decomposition）を用いた正しいアーキテクチャ構築に関する注意
メタモデル制約が自動的に適用される良い例として、DataElement と InformationElement の間では分解（Decomposition）関係を使用できないという点があります。これは、2 つの要素間に分解関係を使用すると、正しい役割（Role）を持つ要素が自動的に作成されるためです。例えば、Resource 間で分解を行うと、自動的に ResourceRole が作成されます。
これと同様に、InformationElement と DataElement の間で分解を試みると DataRole が作成されますが、InformationElement は DataRole を所有することが仕様上許可されていません（仕様内の制約によるものです）。
UAF における設計上の意図は、ドメイン間のレイヤーを分離することにあります。
つまり、Data は Information を「実装（Implements）」する関係として扱われます。
要素間の分解や全体‐部分（whole-part）関係を示すために 集約（Aggregation） を使用した場合、アーキテクチャは UAF 的に正しくない構造となり、UAF 仕様で要求される適切なロールを 手動で作成しなければならなくなります。
実現コネクタの設定
ポート間のコネクタ上に InformationExchange（情報フローの一種） を追加すると、そのコネクタの値を引き継いだ realization タグ が自動的に追加されます。
UAF では、この情報は 「realizingConnector」タグに設定される必要があります。
このタグを設定するには、対象となる IBD（コネクタおよび情報フローを含むもの） を選択し、UAF Toolkit メニューから 「Set Realizing Connector」 を選択します。
これにより、「realizingConnector」タグが自動的に設定されます（下図ではピンク色で表示されています）。
図：Exchanges のタグを表示した Features ウィンドウ
Locate tags
UAF を使用する場合、アーキテクチャ内の多くの情報は、要素同士を関連付ける タグ によって表現されます。代表的な例が、前述の InformationExchange（InformationFlow ベース） に設定される RealizingConnector タグです。
図：Locate tags ウィンドウ
InformationExchange を選択した状態で、UAF Toolkit から 「Locate Tags」 ヘルパーを実行すると、その要素に関連付けられた、他のモデル要素参照を持つ すべてのタグを表示する小さなウィンドウが開きます。表示された一覧から Locate をクリックすると、関連付けられている要素がブラウザ上で表示され、さらにその要素が配置されているダイアグラムへ簡単にナビゲートできます。
この例では、前述の Set Realizing Connector ヘルパーで設定されたタグが使用されています。
Create Activities from Actions
このヘルパーは、以下の処理を行います。
- Call Behavior に基づく要素 （OperationalActivityActions、FunctionActions など）から 参照アクティビティを作成する
- Operational / Resource / Service Process Diagram など （アクティビティ図ベース）に Activities （OperationalActivities、Functions など）をドラッグした際に xxxxAction を作成する
このウィザードは、これらのダイアグラム上で使用されるプロセス／アクティビティ間の正しい依存関係と、ロールによるスイムレーン実装を構築するために不可欠なステップです。
図：「Create Activities from Actions」実行前
一般的なワークフローとしては、以下のいずれかを行います。
- ResourceProcess 上に FunctionAction を作成 （この時点では、モデル内の Function を参照していない）
- ブラウザから Function を ResourceProcess にドラッグ （この場合、FunctionAction ではなく Call Behavior として扱われる）
図：「Create Activities from Actions」メニュー
Process Diagram の背景、またはブラウザ上でその図を選択した状態でUAF Toolkit → 「Create Activities from Actions」 を選択します。これにより、以下のいずれかが行われます。
- Call Behavior を参照する要素に対応する Activity がブラウザ内に作成される
- Call Behavior が適切な要素型に変換される
図：「Create Activities from Actions」実行後
上図の例では、新たに Function「functionaction_9」 が作成され、「function_6」には FunctionAction ステレオタイプが付与されています。
Synchronize Performs Dependencies
このヘルパーは、非常に重要な機能であり、フレームワーク内の各ドメインにおいて、Activitiesとそれらを実行可能な要素の間に必要な 割り当て依存関係 を自動生成します。
例：スイムレーンの割り当て
前の例において、2 つのスイムレーンを追加し、ブラウザから ResourceRole をドラッグしてスイムレーンのヘッダに割り当てています。
図：「Synchronize Performs Dependencies」のメニューと使い方
アクティビティベースのダイアグラムを、ブラウザ上で選択あるいはダイアグラム背景をクリックすると UAF Toolkit が表示されます。そこから 「Synchronize Performs Dependencies」 を選択すると、以下が自動的に作成されます。
- スイムレーン内の インスタンス（ResourceRole） からAction（この例では FunctionAction） へのPerformsInContext 依存関係（下図・紫枠）
- インスタンスを型付けする要素（System、CapabilityConfiguration など）からActivity 要素（この例では Function） へのCapableOfPerforming 依存関係（下図・青枠）
図：ブラウザ上での Performs 依存関係の表示
プロセス図上で要素の割り当てを変更すると、新しい依存関係を生成することは可能ですが、このウィザードは 既存の依存関係を削除することはできません（どれが正しいかを判断するロジックを持たないためです）。
そのため、すべてのアクティビティの割り当てが確定した後にSynchronize Performs Dependencies ウィザードを使用することが推奨されます。