トラック

TRAK は、システム エンジニアを対象とした一般的なエンタープライズ アーキテクチャ フレームワークです。MODAF 1.2 に基づいています。

TRAKはもともとロンドン地下鉄株式会社によって委託されました。^{[1] [2]開発は2009年に開始され、ISO/IEC 42010に基づき、} ISO/IEC 15288で定義されたシステムエンジニアリングライフサイクルに関連付けられたロンドン地下鉄内の当時のアーキテクチャ記述のビューに基づいていました。

当初の目的は鉄道固有のアーキテクチャ フレームワークを開発することでしたが、MODAF をローカルのニーズに合わせて調整する際に、防御やドメイン固有のコンテンツはすべて削除されました。その結果、複雑なシステムを表現することだけに基づいた視点を持つドメインフリーのメタモデルが生まれました。

TRAK は 2010 年 2 月にオープン ソース ライセンスの下でリリースされました。

これは、TRAK の全体的な方向性、戦略、および正式なリリースを管理する TRAK 運営グループの議長を務める 英国運輸省によって正式に採用されています。

TRAK開発チームはワーキンググループ賞を受賞しました。^[3] （INCOSE Transportation Working Groupページの写真^[4]）。TRAKは2011年のIET Innovation Awardsのファイナリストに選ばれました。^[5]

アーキテクチャ記述要素

現実世界のアーキテクチャの項目を記述または表現するために使用される個別のアーキテクチャ記述オブジェクト。アーキテクチャ記述要素は、アーキテクチャ記述に出現することができます。^[6] TRAKアーキテクチャビューを形成するために、アーキテクチャ記述要素のみが使用されます。アーキテクチャ記述要素は、ノード要素またはコネクタ要素である場合があります。コネクタ要素と2つのノード要素のいずれかを使用して、アーキテクチャ記述タプルが形成されます。

アーキテクチャ記述タプル

名前付きアーキテクチャ記述要素は、名前付き関係によって名前付きアーキテクチャ記述要素に接続されます。つまり、主語 - 述語 - 目的語 - 文の基礎です。^[6] 例: 組織 A は職務 B に「関与している」。これは、RDFでも使用される自然言語の主語 -述語- 目的語の構成に従います。タプルを参照してください。TRAK では、各タプルが明示的である必要があります。アーキテクチャ記述タプルは、TRAK メタモデルによって定義されます。TRAK メタモデルによって提供されるアーキテクチャ記述トリプルまたはアサーションは少なくとも 750 あります。^[7]

マスターアーキテクチャビュー

各 TRAK メタモデル ノードには、マスター アーキテクチャ ビューがあります。アーキテクチャ記述またはモデル内の各要素 (個別) は、他のアーキテクチャ ビューで使用する前に、そのマスター アーキテクチャ ビューで宣言または表示する必要があります。たとえば、SV-04 ソリューション機能ビューで「システムが機能を実行する」などを使用して機能を記述する前に、まずシステム要素を作成し、TRAK SV-01 ソリューション構造ビューで表示します。

視点

ISO/IEC 42010 :2007では、アーキテクチャパースペクティブを「アーキテクチャモデルの共有は、アスペクト指向のアーキテクチャ記述スタイルも促進する」と呼んでいます。 ^[8]関連し重複するアーキテクチャビューのグループ化。^[6]

（建築）ビュー

ISO/IEC 42010 では、アーキテクチャ ビューを「特定のシステム問題の観点からシステムのアーキテクチャを表現する作業成果物」と呼んでいます。TRAK ビューは、TRAK メタモデルではアーキテクチャ プロダクトとして定義されています。TRAK ビューは、その管理視点に従って、一連のアーキテクチャ記述タプルを提示します。

（建築）視点

ISO/IEC 42010 :2007 - ビューポイントは、特定の種類のビューを構築するための一連の規則（表記法、言語、モデルタイプ）を定義します。^[6] TRAKでは、ビューポイントは単一のTRAKビューの仕様です。各TRAKビューポイントは、許可されたコンテンツと最小限許容可能なビューコンテンツの両方をアーキテクチャ記述タプルのセットとして定義します。

TRAK は論理的な方法で定義されます。つまり、TRAK がどのツールまたはアーキテクチャ記述言語でどのように実装されるかという概念から解放されます。

TRAK には 24 のアーキテクチャ ビューポイントがあり、5 つのビューポイントにグループ化されています。各ビューポイントは 1 つのビューポイントに属し、1 つのビュー(タイプ) を指定します。各ビューポイントは、表示できるアーキテクチャ記述要素のタイプと関係 (タプル) のセットを指定します。アーキテクチャ記述要素のタイプと関係は、TRAK メタモデルによって指定されます。

TRAK の論理的な定義は 3 つのドキュメントで構成されており、それぞれがSourceForge上のオープン ソース プロジェクトです。

• TRAKエンタープライズアーキテクチャフレームワークドキュメント。^[9]これはTRAK全体を制御します。TRAKアーキテクチャパースペクティブ、色、細則（TRAKの設計に影響を与える規則）、アーキテクチャビューとアーキテクチャの説明、最小限のモデリングプロセスを定義します。
• TRAKエンタープライズアーキテクチャフレームワークの視点ドキュメント。^[10]これはTRAKアーキテクチャの視点を定義します。
• TRAKエンタープライズアーキテクチャフレームワークメタモデルドキュメント。^[6]これは、ビューポイント定義に出現できるアーキテクチャ記述要素を定義します。

TRAKには5つのアーキテクチャの視点^[9]があり、それぞれが重複する主題領域のアーキテクチャの視点とビューをグループ化しています。

• 企業の視点
• コンセプトの視点
• 調達の観点
• ソリューションの観点
• 経営の視点

この観点は、より大きな企業の一部として必要とされる永続的な能力をカバーします。これらは、他のすべてが貢献する高レベルのニーズであり、管理が必要な長期的な戦略目標の一部を形成します。

コンセプトの観点は、エンタープライズの観点でエンタープライズに要求される機能に応じて何が必要かという論理的な視点をカバーします。これは、サービス コントロール センターなどのノードと他のノードの論理的な接続をカバーしますが、組織またはテクノロジによってこれがどのように実現されるかは認識しません。また、ライフ サイクルの特定の部分を意味するものではなく、コンセプトから廃棄 (「欲望から塵へ」!) まですべてをカバーします。

調達の観点は、エンタープライズの観点で概説され、コンセプトの観点で開発されたエンタープライズ機能のニーズに対するソリューションのトップレベルのビューを提供します。これは、ソリューションの観点で説明されているソリューションをプロジェクトがどのように提供して機能を提供するかを示す方法を提供します。これは、プロジェクト間の時間依存性を示す方法を提供し、機能のギャップを調査するために不可欠です。

ソリューションの観点は、提案されているか実現されているかにかかわらず、ソリューションに関する見解を提供します。ソリューションは、人間または機械の「システム」の部分、それらの交換およびプロトコルをカバーします。ソリューションの観点は、組織と機器がどのように組織化され、管理されるかを説明します。ソリューションの観点は、コンセプトの観点で概説された論理要件がどのように実現されるかを説明し、ソリューションが企業に必要な機能と企業の観点で説明されている機能をどのように実現するかを示します。

管理の観点は、アーキテクチャ タスクと、他の観点に共通する関係を説明するビューを提供します。アーキテクチャ タスクの範囲と結果を定義する方法、つまりアプローチとモデリングの構造化の方法を提供します。

管理パースペクティブは、適用される規範的な標準を記述する方法を提供します。これには、モデルの移植性と理解を助けるサポート情報を提供するビューが含まれます。

TRAK の各アーキテクチャ ビューは、対応するアーキテクチャ ビューポイントによって指定されます。ビューポイントは、番号付けで「p」を使用して指定されます。たとえば、CVp-01 は、CV-01 アーキテクチャ ビューを指定するアーキテクチャ ビューポイントです。

一般的な使用では、 DODAFやMODAFなどの別のフレームワークの同様の番号のビューと混同するリスクがある場合は、名前空間プレフィックスが使用されます（例：TRAK::SV-01）。

TRAKは24のアーキテクチャビューポイントを定義している^[10]（比較するとDODAF 2.0には52のビュー/モデルがあり、MODAF 1.2.004には47のビューがあり、NAF 3.1には49のサブビューがある^[11]）。

• 企業の視点
  • EVp-01 企業目標
  • EVp-02 能力階層
  • EVp-03 能力フェージング
• コンセプトの視点
  • CVp-01 コンセプトの必要性
  • CVp-03 コンセプトアイテム交換
  • CVp-04 概念活動から能力へのマッピング
  • CVp-05 コンセプトアクティビティ
  • CVp-06 コンセプトシーケンス
• 調達の観点
  • PrVp-01 調達構造
  • PrVp-02 調達タイムライン
  • PrVp-03 調達責任
• ソリューションの観点
  • SVp-01 ソリューション構造
  • SVp-02 ソリューション リソースの相互作用
  • SVp-03 ソリューション リソースの相互作用と機能のマッピング
  • SVp-04 ソリューション機能
  • SVp-05 ソリューション機能とコンセプトアクティビティのマッピング
  • SVp-06 ソリューションコンピテンス
  • SVp-07 ソリューションシーケンス
  • SVp-11 ソリューション イベントの原因
  • SVp-13 ソリューションリスク
• 経営の視点
  • MVp-01 アーキテクチャ記述辞書
  • MVp-02 アーキテクチャ記述設計記録
  • MVp-03 要件と標準
  • MVp-04 保証

これらはTRAK Viewpoints仕様で定義されています。追加情報はコミュニティウィキで提供されています。^[12]

TRAKメタモデル^[6]は、MODAF 1.2メタモデル内の基本概念を簡素化し、拡張しています。ステレオタイプを削除して再定義し、防衛固有の構成はすべて削除されています。TRAKメタモデル仕様には、初期リリースのTRAKメタモデルとMODAF 1.2.003との比較が含まれています。これも別途概説されています。^[13]

TRAK メタモデルを以下に示します。これは制御されたコピーではないことに注意してください。

TRAKメタモデル要素のRDFを使用したオントロジー記述がここにあります。^[14]これはHTMLとしても提供されています。^[15]

MODAF と比較した重要な変更点は次のとおりです。

• TRAK メタモデルはユーザーを対象としています (MODAF M3 は、ツール ベンダーが MODAF を実装するための仕様として意図された抽象的な UML プロファイルです。ユーザー向けのメタモデルはなく、より複雑な M3 を表現することを目的とした「簡略化されたメタモデル」のフラグメントのみです)。TRAK で表示されるメタモデルはマスター メタモデルです。
• システムはTRAKの中心であり、ハードシステムとソフトシステムを表すことができます（MODAF 1.2.003では、システムは人工物^[16]であり、物理アーキテクチャの一部であり、非物理的な部分を含めることはできません^[17]）
• TRAKは、情報、エネルギー、リソースなど、あらゆるタイプのインターフェース交換/フローを表すことができます。
• TRAKは、人材に関連する交換特性（組織、仕事、役割）を表すことができます。
• TRAKには、標準（ドキュメント/コレクション）と要件（アトミック）メタモデル要素を通じて要件を表現し、契約によって強制する手段が含まれています。
• TRAKには、アーキテクチャタスクとアーキテクチャ記述を計画および記述する手段と、その構成をビューとして含む（MV-02アーキテクチャ記述設計記録）
• 他の種類の依存関係や関連性も表現できます - 物理的、メンバーシップ、責任の範囲
• TRAKには、クレーム-議論-証拠構造を使用して保証ケース（設計検証を含む）を記述する手段が含まれています。
• TRAKには、安全性/セキュリティ（脅威/危険、脆弱性、緩和策、リスク、原因/影響）を記述する手段が含まれています。
• アーキテクチャタスク、アーキテクチャ記述、アーキテクチャビューを表すISO/IEC 42010の概念の追加 - タスクの範囲、目的、調査結果の説明を可能にする
• コンテンツのナビゲーションと可視性を向上させるために、ビューとコンテキストのコレクション全体に適用されるコンテンツの一貫性ルールの追加
• アーキテクチャ記述を形成するビューセットの一貫性を向上させるために、関係をどのように、どのような順序で作成できるかを制約するルール

構造的には他にも変更点があります:

• TRAK には 24 の視点があります (MODAF には 47 の視点があります)
• 各ビューポイントのコンテンツはタプル（ノード - リレーションシップ - ノード要素の構成、つまりトリプルまたは 1 つのタプル）で定義され、アーキテクチャ記述内の他のビューに関して許容される最小限のコンテンツと対応ルールを持ちます。これは、メタモデル内で一意にアドレス指定可能なパスを指定するために必要であるためです（要素に関係する複数のリレーションシップがある場合、ブロック メタモデル要素を指定するだけでは不十分です）。
• ISO/IEC/IEEE 42010:2011 では、システムとその環境の関係の観点からアーキテクチャを定義しているため、TRAK アーキテクチャ ビューに表示されるアーキテクチャ記述の最小単位は、アーキテクチャ記述タプル (つまり、ノード - 関係 - ノード) になります。

TRAKがオープンソースプロジェクトを通じて管理され、リリースされる方法も、他のエンタープライズアーキテクチャフレームワークとはまったく異なります。すべての変更要求と機能要求、およびその判定は、フレームワークを指定または開発した人に限定されず、誰でも見ることができます。^{[18] [19] [20]リリースは変更管理下にあり、すべての履歴はバージョン管理ソフトウェア（} Subversion（SVN） ）によって管理されます。

TRAK は、アーキテクチャ ビューを表現する表記法やプレゼンテーション言語 ( ISO/IEC 42010 用語ではアーキテクチャ記述言語) を指定しません。したがって、TRAK アーキテクチャ記述はUML、SysML、またはBPMNモデルではありませんが、これらの表記法のいずれかを使用して少なくとも一部のビューを準備できます (ADL には必要な概念/ステレオタイプが含まれていない可能性があり、TRAK アーキテクチャ ビューを表現するために必要な方法でそれらを接続できない可能性があります)。

TRAKでは、TRAKアーキテクチャビュー内のすべてのアーキテクチャ記述要素のメタモデル要素名を明示的に表示する必要があります。これにより、各TRAKビューは宣言文のセットとして読み取ることができます。例：

• 「システム. A は、-> ソフトウェア. B で構成されています」
• 「主張。システム A は ... に関する要件を満たしています。 -about-> 標準。気候環境仕様。」
• 「物理的。シールド ビルディングに は 脆弱性がある。構造上の弱点が、脅威 を悪用する 。意図的な航空機の衝突」

タプルは、方向のあるノードと関係 (有向グラフ) を使用して表現できます。

TRAK では、テキスト ステートメントからビューを構築することもできます。TRAK ビューはタプル/トリプルのセットであるため、グラフまたはRDFトリプルのセットを使用して TRAK ビューを表示できます。TRAK メタモデル要素の RDFオントロジー記述が開発中です。^{[21]これは、} Neo4Jグラフ データベース内の TRAK のグラフ モデルから出力される TRAK メタモデル仕様から要素の定義を取得します。^[7] RDF トリプルで構成される TRAK アーキテクチャ ビューは、RDF TRAK メタモデル オントロジーにリンクしてナレッジ グラフを形成できます。各トリプルは、事実またはアサーションを表します。

TRAKでは、すべてのブロックとコネクタに名前を付け、それらを表示（明示的）にする必要があります。その目的は、TRAKアーキテクチャビューがビューの作成者の意図どおりに読み取られ、意味の一貫性が向上するようにすることです。すべてのTRAKアーキテクチャビューに適用されるプレゼンテーションルールは、全体的なTRAK仕様^{[9] [22]}（「Bye Laws」として）で指定されています。

TRAK は論理的な定義です。表示する必要のある内容と最小限許容可能なコンテンツを指定しますが、それを実現する方法は指定しません。TRAK は、各ビューに表示する必要がある/表示できるノード要素とコネクタ要素および許容される組み合わせ (トリプル) を定義するだけです。特定の表記法や言語を指定または指定することはありません。たとえば、単純なブロックとコネクタの図 (上記) は、プレーンテキスト ステートメントのセット、UML を使用した図、グラフ、または RDF トリプルのセットと同様に許容されます。同じ理由で、TRAK ビュー コンテンツは、TRAK アーキテクチャ ビューを実装するために使用される可能性のある表記法とは異なる抽象的表記法を使用して指定されます。これは、単一の表記法の障害によって TRAK ビューポイント コンテンツ定義と「設計応答」(特定の TRAK ビューのコンテンツ) の両方に影響する共通の障害が発生するのを防ぐためです。

TRAK はISO/IEC 42010を次のように適用します。

• アーキテクチャ記述は、利害関係者の懸念に対処するタスクへの応答です (これは、タスク、対処された懸念、および調査結果を定義するビューを生成するための TRAK::MVp-02 アーキテクチャ記述設計記録ビューポイントを使用して対処されます)
• 各 TRAK アーキテクチャ ビューは、TRAK アーキテクチャ フレームワーク内のビューポイントによって指定されます。たとえば、MVp-04 保証ビューポイントは、任意の MV-04 保証ビューの内容を指定します。
• 各 TRAK ビューポイントは、利害関係者、対処される懸念事項、反懸念事項 (ビューポイントが使用されない事項)、必要なメタモデル タプル、許可されるメタモデル タプル、整形式 (許容される最小コンテンツ)、およびアーキテクチャ記述内の他のビューとの一貫性ルールを識別します。たとえば、MV-04 保証ビューでは、「証拠がクレームを証明する」とアサートする前に、「証拠が (同じ) クレームをサポートする議論をサポートする」が存在する必要があります。
• 対応ルールは、TRAK メタモデルを使用して、視点とアーキテクチャ記述によって定義されます。ルールは、TRAK メタモデルのトリプルを使用して定義されます。

TRAKとISO/IEC 42010の全体的な比較は、TRAKエンタープライズアーキテクチャフレームワーク文書で行われています。2011年版の標準とのより詳細な比較は別途行われ^[23]、一連のWebページとして閲覧できます。^{[24]これらは、コンプライアンスマトリックス[25]}とともに、次の点を比較します。

1. TRAK は、ISO/IEC/IEEE 42010:2011 のセクション 6.1 (アーキテクチャ フレームワーク) の要件に準拠したアーキテクチャ フレームワークです。
2. ISO/IEC/IEEE 42010:2011 のセクション 5 (アーキテクチャ記述) に準拠した TRAK 準拠のアーキテクチャ記述。

TRAK 自体はプロセスを義務付けていません。ただし、TRAK は ISO/IEC 42010 に準拠しており、アーキテクチャ記述はタスクとタスクの利害関係者の懸念に応じて作成されると規定されているため、また TRAK にはマスター アーキテクチャ ビューがあり、ビュー間の依存関係が作成され、最小限のアーキテクチャ ビュー セットが許容されるため、プロセスの要素が導入されています。

これにより、次のような最小限のプロセスが発生します。

• タスクの関係者とその懸念事項を特定する
• TRAKの視点を使用して、利害関係者の懸念に対処するために必要な視点を選択する
• これらの懸念に対処するこれらの視点に適合する見解を展開する
• これらにより、正当な許可されたビューセットを形成するために追加のビューを準備する必要が生じる可能性がある。
• MV-02 アーキテクチャ設計記録ビューと MV-01 アーキテクチャ辞書ビューを使用して、目的、懸念事項、調査結果、アーキテクチャの説明を文書化します。

TRAK は 2 種類のオープン ソース ライセンスに基づいてリリースされます。

• 論理定義のためのGNU フリー ドキュメンテーション ライセンス ( GFDL ) - TRAK 全体、TRAK メタモデル、および TRAK ビューポイント ドキュメント
• TRAK の実装のためのGNU 一般公衆ライセンス ( GPL ) - 一般的な UML モデリング ツール用の TRAK 用 UML プロファイルおよびSparx Systems Enterprise Architectモデリング ツール用の TRAK MDG テクノロジー。

TRAK は、次のメカニズムを通じてモデリング ツールをサポートします。

• TRAK用のUMLプロファイルとSysMLプロファイル - UMLプロファイルをインポートできる任意のUMLモデリングツールで使用可能
• TRAKのUMLおよびSysMLプロファイルに基づいたSparx Systems Enterprise Architectのプラグイン。Sourceforgeでオープンソースとしてリリースされました^[26]
• MooD InternationalのMooD 2010ソフトウェアプラットフォームのテンプレート（Vega Consulting Services Ltd（Leonardoの一部）が開発）。Sourceforgeでオープンソースとしてリリースされました。^[27]
• OmniGraffle（Mac OS X、iPad ）用のステンシル。Sourceforgeでオープンソースとしてリリースされました。^[28]
• Microsoft Visioのテンプレート。Sourceforgeでオープンソースとしてリリースされました。^[29]

UMLのステレオタイプ（概念）とTRAKメタモデル^[30]のステレオタイプ（概念）を比較すると、TRAKのUMLプロファイルについて、TRAKビューポイント、ひいてはTRAKビューUMLが完全に表現できるもの、部分的に表現できるもの、まったく表現できないものが分析されます。これは、UMLで使用可能な構成要素とTRAKのUMLプロファイルの特定の実装の結果であり、異なるアーキテクチャ記述言語（ADL）は多くの場合、異なる目的、場合によっては異なるドメイン向けに設計されているため発生します。つまり、ISO/IEC 42010では、それらが対処する懸念事項は、アーキテクチャフレームワーク（この場合はTRAK）が対処する懸念事項とは異なります。

ツールは TRAK の論理定義の実装を表すため、使用される表記言語 (アーキテクチャ記述言語) やツール固有の機能によって制限やエラーが含まれる場合があります。

• 地下改良プログラム（SSUP）。ロンドン地下鉄サークル線、ハマースミス線、メトロポリタン線、ディストリクト線の信号と車両の改良。鉄道の費用対効果に関する研究で引用。全システムプログラム管理レポート。2011年5月25日。^[2]
• 技術戦略リーダーシップグループ（TSLG）。鉄道機能アーキテクチャ^[31]
• 鉄道安全基準委員会 (RSSB)。英国鉄道機能アーキテクチャ。進行中の研究 - RSSB 研究開発電子ニュースレター。第 66 号。2010 年 10 月。^[32] TRAK の選択/使用の正当性は、タスクの概要レポートに記載されています。^[33] T912 鉄道機能アーキテクチャ プロジェクトについては別途説明します。^[34]鉄道機能アーキテクチャは、HTML ページのセットとして利用できます。^[35]
• バーミンガム大学。InfraGuidER（環境鉄道パフォーマンスのためのインフラガイドライン）成果物9および18、^[36]議事録：D22：EURNEX（欧州鉄道研究卓越ネットワーク）卓越性の極のための第2回ワークショップ^[37]
• 統合EA 2011。EAアプローチによるリスクとコストの管理。マイク・ブラウンズワード（Atego）＆ジョー・シルモン（鉄道研究教育センター）、^[38]
• TRAKのアーキテクチャフレームワークとしての準拠の主張と、ISO/IEC/IEEE 42010:2011の要件に対するTRAK準拠のアーキテクチャ記述を記述したアーキテクチャ記述^{[24] 。次のビューの例が含まれています：MV-02アーキテクチャ記述設計記録、MV-03要件と標準、およびMV-04保証。基礎となるモデルは}、モデルベースシステムエンジニアリングの例としてコンプライアンスマトリックス^[25]を作成するために使用されました。

ウィキメディア・コモンズにはTRAKに関連するメディアがあります。

• TRAK エンタープライズ アーキテクチャ フレームワーク プロジェクト サイト
• TRAK エンタープライズ アーキテクチャ フレームワーク。メタモデル プロジェクト サイト
• TRAK エンタープライズ アーキテクチャ フレームワーク。Viewpoints プロジェクト サイト
• TRAK の UML プロファイル
• Sparx Systems の Enterprise Architect プロジェクト サイト向け TRAK MDG
• TRAK プロジェクト サイト用の OmniGraffle ステンシル
• TRAK プロジェクト サイト用の Visio ステンシル
• TRAKコミュニティサポートサイト