트락

TRAK는 MODAF 1.2에 근거한 시스템 엔지니어들을 목표로 하는 일반적인 기업 아키텍처 프레임워크다.

역사

TRAK는 원래 런던 지하 유한회사가 위탁 운영했다.^[1][2] 개발은 2009년에 시작되었고, ISO/IEC 42010에 기초하여 ISO/IEC 15288에 정의된 시스템 엔지니어링 수명 카일에 묶인, 당시 런던 언더그라운드 내의 아키텍처 설명에 대한 현재의 관점에 기초하였다.

비록 원래 목적은 MODAF를 지역적 요구에 맞게 적응시키는 데 있어서 철도 고유의 아키텍처 프레임워크를 개발하는 것이었지만, 어떤 방어 또는 도메인 고유의 컨텐츠는 제거되었고 그 결과는 단지 복잡한 시스템을 대표하는 것에만 기초하는 도메인 없는 메타모델과 관점이었다.

TRAK는 2010년 2월에 오픈 소스 라이센스로 출시되었다.

TRAK의 전반적인 방향, 전략 및 정식 릴리즈를 관리하는 TRAK 스티어링 그룹을 의장으로 하는 영국 교통부에 의해 공식적으로 채택되었다.

TRAK 개발팀은 워킹 그룹 상을 받았다.^[3] (INSOE Transportation Working Group 페이지에 있는 사진). TRAK는 2011 IET 혁신상 최종 수상자였다.^[5]

용어.

아키텍처 설명 요소

실제 아키텍처의 항목을 설명하거나 나타내기 위해 사용되는 개별 아키텍처 설명 개체. 아키텍처 설명 요소는 아키텍처 설명에 나타날 수 있다.^[6] 오직 아키텍처 설명 요소만이 TRAK 아키텍처 뷰를 형성하는데 사용된다. 아키텍처 설명 요소는 노드 요소 또는 커넥터 요소일 수 있다. 커넥터 요소와 두 노드 요소 중 하나를 사용하여 아키텍처 설명 튜플을 형성한다.

건축기술 튜플

명명된 아키텍처 설명 요소(예: 제목 - 술어 개체)와 명명된 관계에 의해 연결된 명명된 아키텍처 설명 요소 - 문장의 기초(^[6]예: 조직 A는 '부분이 있다' Job B). 그것은 RDF에서도 사용되는 제목 - 술어 - 오브젝트의 자연어 구조를 따른다. 튜플을 참조하라. TRAK는 각 튜플이 명시적일 것을 요구한다. 아키텍처 설명 튜플은 TRAK 메타모델에 의해 정의된다. TRAK 메타모델에 의해 제공되는 최소 750개의 아키텍처 설명 3배 또는 주장이 있다.^[7]

마스터 아키텍처 뷰

각 TRAK 메타모델 노드는 마스터 아키텍처 뷰를 가지고 있다. 아키텍처 설명이나 모델 내에서 각 요소(개별자)는 다른 아키텍처 뷰에서 사용하기 전에 마스터 아키텍처 뷰에 선언되거나 표시되어야 한다. 예를 들어, SV-04 Solution Function View에서 'System performs Function'을 사용하는 기능을 설명하기 전에 시스템 요소가 먼저 생성되어 TRAK SV-01 Solution Structure View에서 제시될 것이다.

원근법

ISO/IEC 42010:2007은 건축적 관점을 '건축적 모델 공유도 건축적 설명의 "예상 지향적" 스타일을 촉진한다'^[8]라고 언급한다. 관련되고 중복되는 건축적 관점의 그룹화.^[6]

(Architecture) 보기

ISO/IEC 42010은 아키텍처 뷰를 '특정 시스템 관심의 관점에서 시스템의 아키텍처를 표현하는 워크 제품'이라고 한다. TRAK 뷰는 TRAK 메타모델에서 아키텍처 제품으로 정의된다. TRAK 뷰는 관리 관점에 따라 일련의 아키텍처 설명 튜플을 제공한다.

(건축학) 관점

ISO/IEC 42010:2007 - 관점은 특정 종류의 관점을 구성하기 위한 일련의 규약(공지, 언어 및 모델 유형)을 정의한다.^[6] TRAK에서 관점은 단일 TRAK 보기에 대한 규격이다. 각 TRAK 관점은 허용되는 내용과 허용되는 최소 뷰 콘텐츠를 모두 아키텍처 설명 튜플 집합으로 정의한다.

TRAK 구조

TRAK는 논리적인 방법으로 정의된다. 즉, TRAK가 어떤 도구 또는 어떤 아키텍처 설명 언어에서 구현되는지에 대한 어떤 개념도 없는 것이다.

TRAK는 5개의 관점으로 분류되는 24개의 아키텍처 관점을 가지고 있다. 각 관점은 단일 관점에 속하며 단일 관점(유형)을 지정한다. 각 관점은 어떤 유형의 구조적 설명 요소와 관계(튜플)가 나타날 수 있는지 명시한다. 아키텍처 설명 요소 유형과 관계는 TRAK 메타모델에 의해 지정된다.

TRAK의 논리적 정의는 3개의 문서로 구성되며, 각 문서는 소스포지의 오픈 소스 프로젝트:

• TRAK Enterprise Architecture Framework 문서.^[9] 이것은 TRAK 전체를 제어한다. TRAK 아키텍처 관점, 색상, 바이 법(TRAK 설계에 영향을 미치는 규칙, 아키텍처 뷰 및 아키텍처 설명, 최소 모델링 프로세스)을 정의한다.
• TRAK 엔터프라이즈 아키텍처 프레임워크 관점 문서.^[10] 이것은 TRAK 아키텍처 관점을 정의한다.
• TRAK Enterprise Architecture Framework Metatodel 문서.^[6] 이것은 관점 정의에 나타날 수 있는 아키텍처 설명 요소를 정의한다.

TRAK 건축의 관점

TRAK는 5개의 아키텍처 관점을 가지고 있으며,^[9] 각 그룹은 중복되는 주제 영역의 아키텍처 관점과 관점을 함께 사용한다.

• 엔터프라이즈 관점
• 개념 관점
• 조달 관점
• 솔루션 관점
• 관리 관점

엔터프라이즈 관점

이러한 관점은 더 큰 기업의 일부로서 필요한 지속적 능력을 포함한다. 이것들은 다른 모든 것들이 관리되어야 하는 장기적인 전략적 목표의 일부에 기여하고 형성되는 높은 수준의 요구들이다.

개념 관점

개념적 관점은 기업 관점에서 기업이 요구하는 역량에 대응하여 필요한 것에 대한 논리적 관점을 다룬다. 그것은 조직이나 기술에 의해 실현될 수 있는 방법에 대한 인식 없이 서비스 제어 센터와 다른 노드에 대한 노드의 논리적 연결을 다룬다. 그것은 또한 수명 주기의 특정한 부분을 의미하지 않는다 – 그것은 개념에서 폐기까지 모든 것을 포함한다.

조달 관점

조달 관점은 엔터프라이즈 관점에 요약되어 있고 개념 관점에 따라 개발된 엔터프라이즈 기능 니즈에 대한 솔루션에 대한 최상위 관점을 제공한다. 그것은 프로젝트들이 어떻게 솔루션 관점에서 기술된 솔루션을 제공하여 역량을 제공하는지를 보여주는 방법을 제공한다. 프로젝트 간의 시간 의존성을 보여주는 방법을 제공하며, 역량 격차를 조사하는데 필수적이다.

솔루션 관점

솔루션 관점은 제안하든 실현하든 솔루션에 대한 관점을 제공한다. 그것은 인간이든 기계든, 그들의 교환과 프로토콜이든 '시스템'의 부분을 다룬다. 솔루션 관점은 조직과 장비가 어떻게 조직되고 통제되는지를 설명한다. 솔루션 관점은 개념 관점에 요약된 논리적 요구사항이 실현되는 방법을 설명하고, 솔루션이 기업이 필요로 하는 기능을 실현하고 기업 관점에 기술하는 방법을 보여준다.

관리 관점

관리 관점은 다른 관점에 걸쳐 공통적인 구조적 과제와 그러한 관계를 설명하는 관점을 제공한다. 그것은 접근과 모델링의 구조화라는 구조적 과제의 범위와 발견을 정의하는 방법을 제공한다.

경영진의 관점은 적용되는 규범적 표준을 기술하는 방법을 제공한다. 그것은 모델의 이동성과 이해를 돕기 위해 뒷받침되는 정보를 제공하는 뷰를 포함한다.

TRAK 건축의 관점 및 관점

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개의 하위 뷰를 가지고 있다).

• 엔터프라이즈 관점
  • 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 Points 규격에 정의되어 있다. 추가 정보는 커뮤니티 위키에서 제공된다.^[12]

TRAK 메타모델

TRAK Metatodel은^[6] MODAF 1.2 Metatodel 내의 기본 개념을 단순화하고 확장한다. 그것은 고정관념을 없애고 재정립했으며 방어에 특화된 어떤 구조도 제거되었다. TRAK Metaodel 규격은 MODAF 1.2.003과 초기 방출 시 TRAK 메타모델의 비교를 포함하고 있다. 이것 또한 별도로 윤곽이 잡힌다.^[13]

TRAK 메타모델은 아래와 같다. 이것은 통제된 복사본이 아니라는 점에 유의하십시오.

MODAF와 비교했을 때 다음과 같은 중요한 변화가 있다.

• TRAK 메타모델은 사용자를 대상으로 한다(MODAF M3는 MODAF를 구현하기 위한 툴 벤더의 규격으로 의도된 추상 UML 프로필이다 - 보다 복잡한 M3를 나타내기 위한 '간단한 메타모델'의 단편만 사용자에 대한 메타모델은 없다). TRAK에서 보여지는 변광성은 마스터다.
• 시스템은 TRAK의 중심이며 하드 시스템과 소프트 시스템을 대표할 수 있다(MODAF 1.2.003 시스템은 실제적이고^[14] 물리적 아키텍처의 일부로서 비 물리적 부분은^[15] 포함할 수 없음).
• TRAK는 모든 유형의 인터페이스 교환/흐름(정보, 에너지 또는 자원)을 나타낼 수 있다.
• TRAK는 인적 자원과 관련된 교환 특성(조직, 직업 및 역할)을 나타낼 수 있다.
• TRAK는 계약에 의해 시행되고 표준(문서/수집) 및 요구사항(원자) 메타모델 요소를 통해 요구사항을 나타내는 수단을 포함한다.
• TRAK는 아키텍처 작업 및 아키텍처 설명과 그 조직을 뷰로 계획하고 설명하는 수단을 포함한다(MV-02 아키텍처 설명 설계 기록).
• 다른 유형의 종속성 및 연관성(물리적, 구성원 자격, 책임 범위)을 나타낼 수 있음
• TRAK는 클레임 - 주장 - 증거 구조를 사용하여 보증 사례(설계 검증 포함)를 기술하는 수단을 포함한다.
• TRAK는 안전/보안 - 위협/위험, 취약성, 완화, 위험 및 원인/충돌을 설명하는 수단을 포함한다.
• 아키텍처 작업, 아키텍처 설명 및 아키텍처 뷰를 나타내는 ISO/IEC 42010 개념 추가 - 작업 범위, 목적, 결과물에 대한 설명 허용
• 전체 보기 및 컨텍스트 모음에 적용되는 컨텐츠에 대한 일관성 규칙을 추가하여 컨텐츠 탐색 및 가시성 향상
• 아키텍처 설명을 구성하는 보기 집합의 일관성을 개선하기 위해 관계를 어떻게 그리고 어떤 순서로 만들 수 있는지 제약하는 규칙

구조적으로 다른 변화가 있다.

• TRAK는 24개의 관점을 가지고 있다(MODAF의 c 47 뷰 vs)
• 각 관점 컨텐츠는 튜플(노드 - 관계 - 노드 요소 구성, 즉 3중 또는 1,tuple )의 관점에서 정의되며, 메타모델(사양)에서 고유하게 어드레싱 가능한 경로를 지정하기 위해 필요하기 때문에 아키텍처 설명 내의 다른 뷰와 관련하여 허용되는 컨텐츠 및 대응 규칙을 허용하고 최소한으로 허용한다.요소와 관련된 여러 관계가 있는 블록 메타모델 요소만으로는 충분하지 않은 경우).
• ISO/IEC/IEEE 42010:2011은 시스템 환경과의 관계 측면에서 아키텍처를 정의하기 때문에 TRAK 아키텍처 뷰에 나타날 수 있는 아키텍처 설명의 최소 단위는 그러므로 아키텍처 설명 튜플(즉, 노드 관계 - 노드) 노드일 수 있다.

일련의 오픈 소스 프로젝트를 통해 TRAK를 관리하고 출시하는 방식도 다른 엔터프라이즈 아키텍처 프레임워크와는 사뭇 다르다. 모든 변경 요청과 기능 요청 및 이의 양형은 프레임워크를 지정하거나 개발하는 자에 국한되지 않고 누구에게나 충분히 볼 수 있다.^[16][17][18] 릴리스는 변경 관리 하에 있으며 버전 관리 소프트웨어(SVN)에 의해 모든 기록이 유지된다.

TRAK 뷰 표시

TRAK는 아키텍처 뷰를 제시할 표기법이나 프리젠테이션 언어(ISO/IEC 42010 용어의 아키텍처 설명 언어)를 명시하지 않는다. 따라서 TRAK 아키텍처 설명은 UML, SysML 또는 BPMN 모델이 아니지만 최소한 일부 뷰를 준비하는 데 사용될 수 있다(ADL은 필요한 개념/스티레오타입을 포함하지 않거나 TRAK 아키텍처 뷰를 나타내는 데 필요한 방식으로 연결되지 않을 수 있음).

TRAK는 각 TRAK 보기가 선언문 집합으로 읽힐 수 있도록 TRAK 아키텍처 뷰에 있는 모든 아키텍처 설명 요소의 메타모델 요소 이름을 명시적으로 표시하도록 요구한다.

• '시스템. A - is 구성 with-> 소프트웨어. B'
• 'Claim. 시스템 A는 표준의 요건을 충족한다. 기후 환경 사양.'
• '물리적이지. Shield Building -has-> 취약성. 구조적 취약점 <-폭발-위협>. 의도적 항공기 영향'

튜플은 노드 및 방향과의 관계(방향 그래프)를 사용하여 표시할 수 있다.

TRAK는 또한 텍스트 문장으로 뷰를 구성할 수 있도록 허용한다. TRAK 뷰는 튜플/트리플 집합이므로 그래프 또는 RDF 트리플 집합을 사용하여 TRAK 뷰를 표시할 수 있다. TRAK 메타모델 요소에 대한 RDF 온톨로지 설명이 개발되고 있다.^[19] 이것은 Neo4J 그래프 데이터베이스 내의 TRAK의 그래프 모델에서 TRAK 메타모델 사양 출력물로부터 요소들의 정의를 취한다.^[7] RDF 3중으로 구성된 TRAK 아키텍처 뷰는 RDF TRAK 메타모델 온톨로지(tatomodel ontotology)와 연계되어 지식 그래프를 구성할 수 있다. 각각의 세 쌍은 사실이나 주장을 나타낸다.

TRAK는 또한 모든 블록과 모든 커넥터에 이름을 지정하고 이러한 이름을 볼 수 있도록(설명) 요구한다. 이것의 목적은 TRAK 아키텍처 뷰가 의도한 뷰의 작성자로 읽히도록 하고 의미적 일관성을 향상시키기 위함이다. 모든 TRAK 아키텍처 뷰에 적용되는 프레젠테이션 규칙은 전체 TRAK 규격('Bye Laws'로 지정된다.

TRAK는 논리적인 정의로, 보여야 할 것과 최소한의 허용 가능한 내용을 명시하지만, 그것을 달성하는 방법을 의무화하지는 않는다. TRAK는 단순히 노드 및 커넥터 요소와 각 보기에 나타나야 하는 허용된 조합(트리플)을 정의한다. 특정 표기법이나 언어를 명시하거나 의무화하지 않는다. 예를 들어 단순 블록 및 커넥터 다이어그램(위)은 일반 텍스트 문 집합, UML을 사용한 다이어그램, 그래프 또는 RDF 3중 집합과 같이 허용된다. 동일한 이유로 TRAK 뷰 콘텐츠는 TRAK 시점 콘텐츠 정의와 '설계 응답' - 특정 TRAK vi의 콘텐츠에 영향을 미치는 단일 표기법에서 결함으로 인해 발생하는 공통적인 결함을 방지하기 위해 TRAK 아키텍처 뷰를 구현하는 데 사용될 수 있는 어떤 표기법과는 추상적이고 다른 표기법을 사용하여 지정된다.ew.

ISO 42010 고려 사항

TRAK는 다음과 같은 방법으로 ISO/IEC 42010을 적용한다.

• 아키텍처 설명은 이해관계자의 우려를 다루는 과제에 대한 대응이다(TRAK를 사용하여 설명됨:MVP-02 아키텍처 설명 설계 기록 관점(작업, 문제 해결 및 결과 정의에 대한 뷰 생성)
• 각 TRAK 아키텍처 뷰는 TRAK 아키텍처 프레임워크 내의 관점으로 지정된다. 예를 들어 MVP-04 보증 관점은 MV-04 보증 보기의 내용을 명시한다.
• 각 TRAK 관점은 이해관계자, 우려사항, 반의견(관점을 사용하지 않아야 하는 사항), 필요한 메타모델 튜플, 허용되는 메타모델 튜플, 적절한 형태(최소 수용 가능한 내용) 및 아키텍처 설명 내에서 다른 견해와의 일관성 규칙(예: 'Evii' 이전 MV-04 보증 뷰)을 식별한다.Dence는 '청구를 증명한다'는 주장이 존재할 필요가 있다고 주장할 수 있다. '증거가 주장 지지 (동일한) 청구를 지지한다'
• 대응 규칙은 관점 및 TRAK 메타모델을 사용한 아키텍처 설명에 의해 정의된다. 규칙은 TRAK 메타모델의 3배수를 사용하여 정의된다.

TRAK와 ISO/IEC 42010의 전반적인 비교는 TRAK Enterprise Architecture Framework 문서에서 이루어진다. 2011년 버전의 표준과 보다 자세한 비교는 별도로 만들어지며 웹 페이지 세트로 볼 수 있다.^[22] 이러한 항목을 컴플라이언스 매트릭스와 함께 비교하십시오.-^[23]

1. ISO/IEC/IEEE 42010:2011의 6.1절(건축 프레임워크) 요건에 대한 아키텍처 프레임워크로서의 TRAK 및;
2. ISO/IEC/IEEE 42010:2011의 섹션 5(건축학 설명)에 대한 TRAK 적합 아키텍처 설명.

TRAK를 사용하여 아키텍처 설명 작성

TRAK 자체는 과정을 명령하지 않는다. 그러나 TRAK는 과제와 작업 이해당사자의 우려에 대응하여 아키텍처 설명이 생성된다는 ISO/IEC 42010을 준수하고 또한 TRAK는 최소 허용 아키텍처 뷰 집합에서 뷰와 결과 사이에 의존성을 생성하는 마스터 아키텍처 뷰를 가지고 있기 때문에 도입된 프로세스 요소가 있다.s

이는 다음과 같은 최소 프로세스를 발생시킨다.

• 업무 이해 관계자와 그 관심사를 확인한다.
• TRAK 관점을 사용하여 이해관계자 문제를 해결하는 데 필요한 관점을 선택하십시오.
• 이러한 우려를 다루는 관점에 부합하는 관점을 개발하다.
• 이러한 경우 합법적인 허용된 보기 집합을 형성하기 위해 추가 보기를 준비할 필요가 있을 수 있다.
• MV-01 Architecture Dictionary View로 보완된 MV-02 Architecture Design Record View를 사용하여 목적, 우려 사항, 발견 사항 및 아키텍처 설명을 문서화한다.

라이센싱

TRAK는 두 가지 형태의 오픈 소스 라이센스로 출시된다.

• 논리적 정의에 대한 GNU 자유 문서 라이센스(GFDL) - TRAK 전체, TRAK 메타모델 및 TRAK 관점 문서
• 일반 UML 모델링 도구를 위한 TRAK용 TRAK - UML 프로파일 구현을 위한 GNU 공용 라이센스(GPL)와 스파렉스 시스템 기업 설계 모델링 도구를 위한 TRAK MDG 기술.

도구 지원

TRAK는 다음과 같은 메커니즘을 통해 모델링 도구를 지원한다.

• TRAK용 UML 프로필 - UML 프로필을 가져올 수 있는 모든 UML 모델링 도구와 함께 사용
• TRAK용 UML 프로필을 기반으로 하는 Sparx Systems Enterprise Architect용 플러그인 Sourceforge에서 오픈 소스로 릴리스됨
• MoD International의 MoD 2010 소프트웨어 플랫폼용 템플릿(Vega Consulting Services Ltd - Leonardo의 일부) Sourceforge에서 오픈 소스로 릴리즈됨.^[25]
• 옴니그레이플(Mac OS X, iPad)용 스텐실. Sourceforge에서 오픈 소스로 릴리즈됨.^[26]
• 마이크로소프트 비시오용 템플릿 Sourceforge에서 오픈 소스로 릴리즈됨.^[27]

TRAK Metaodel의 UML 프로파일과 UML의 고정관념(개념)을 비교하면 TRAK Points와 TRAK Views UML이 전체, 부분, 그리고 전혀 표현할 수 없는 것을 분석할 수 있다. 이는 UML에서 이용할 수 있는 구조와 TRAK에 대한 UML 프로파일에서 특정 구현의 결과로서, 서로 다른 ADL(구조 설명 언어)이 종종 다른 목적으로 설계되고 때로는 다른 도메인(즉, ISO/IEC 42010)에서 다루는 우려사항이 아치와는 다르기 때문에 발생한다.Tecture 프레임워크, 이 경우 TRAK가 한다.

도구는 TRAK의 논리적 정의 구현을 나타내기 때문에 사용된 표기 언어(건축 기술 언어)와 도구별 기능 때문에 제한이나 오류를 포함할 수 있다.

TRAK를 이용한 건축설명의 예

• 하위 표면 업그레이드 프로그램(SSUP). 런던 지하철의 서클, 해머스미스, 메트로폴리탄 및 지구 라인에 대한 신호 전달 및 롤링 스톡 업그레이드. 금전 연구에 대한 철도 가치에 인용. 전체 시스템 프로그램 관리 보고서. 2011년 5월 25일.^[2]
• TSLG(Technical Strategy Leadership Group) 철도기능건축^[29]
• 철도안전표준위원회(RSSB) 영국 철도 기능 건축 지속적인 연구 - RSSB Research & Development E-newsletter. 66호. 2010년 10월.^[30] TRAK의 선택/사용에 대한 정당성은 과제 요약 보고서에 수록되어 있다.^[31] T912 철도 기능 아키텍처 프로젝트는 별도로 기술되어 있다.^[32] 철도 기능 아키텍처는 HTML 페이지의 집합으로 이용 가능하다.^[33]
• 버밍엄 대학교. InfraGuider(Infrastructure Guider for Environmental Trail Performance) 결과물 9 및 18,^[34] 분: D22: 유럽철도기술개발원(EURNEX: European Rail Research Network of Excellence) 폴을 위한 제2차 워크숍
• 통합 EA 2011. EA 접근 방식을 통한 리스크 및 비용 관리. Mike Brownsword (Atego) & Joe Silmon (Centre for Railway Research and Education),^[36]
• ISO/IEC/IEEE 42010:2011의 요건에 대한 아키텍처 프레임워크 및 TRAK 준수 아키텍처 설명을 기술하는 아키텍처 설명^[22]. MV-02 Architecture Description Design Record, MV-03 Requirements and Standards, MV-04 Assurance 등의 뷰의 예를 포함한다. 그 다음, 기본 모델은 모델 기반 시스템 엔지니어링의 예로서 컴플라이언스^[23] 매트릭스를 생산하기 위해 사용되었다.

참조

외부 링크

• TRAK Enterprise Architecture Framework 프로젝트 현장
• TRAK 엔터프라이즈 아키텍처 프레임워크 메타모델 프로젝트 현장
• TRAK 엔터프라이즈 아키텍처 프레임워크 관점 프로젝트 현장
• TRAK용 UML 프로파일
• TRAK 커뮤니티 지원 사이트