Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Структура TRAK - сформирована из 1 метамодели, 5 архитектурных точек зрения и 24 архитектурных точек зрения.

TRAK - это общая структура архитектуры предприятия, предназначенная для системных инженеров, основанная на MODAF 1.2.

История [ править ]

TRAK был первоначально заказан London Underground Limited. [1] [2] Разработка началась в 2009 году и была основана на текущих представлениях архитектурного описания в Лондонском метро, ​​которые основывались на ISO / IEC 42010 и были привязаны к жизненному циклу системной инженерии, определенному в ISO / IEC 15288 .

Хотя первоначальная цель заключалась в разработке структуры архитектуры для конкретных железных дорог с адаптацией MODAF к местным потребностям, любой защитный или предметно-ориентированный контент был удален, и в результате появилась метамодель, не зависящая от предметной области, и точки зрения, основанные только на представлении сложных систем .

TRAK был выпущен под лицензиями с открытым исходным кодом в феврале 2010 года.

Он был официально принят Министерством транспорта Великобритании, который возглавляет Руководящую группу TRAK, которая управляет общим направлением, стратегией и официальными выпусками TRAK.

Команда разработчиков ТРАК получила награду Рабочей группы. [3] (фото на странице Транспортной рабочей группы INCOSE [4] ). TRAK стал финалистом конкурса IET Innovation Awards 2011. [5]

Терминология [ править ]

Элемент описания архитектуры
Отдельный объект описания архитектуры, который используется для описания или представления элемента реальной архитектуры. Элемент описания архитектуры может появляться в описании архитектуры. [6] Для формирования архитектурных представлений TRAK используются только элементы описания архитектуры. Элемент описания архитектуры может быть узловым элементом или соединительным элементом. Элемент коннектора и два элемента узла используются для формирования кортежа описания архитектуры.
Кортеж описания архитектуры
Именованный элемент описания архитектуры, связанный именованным отношением с именованным элементом описания архитектуры. т.е. подлежащее - сказуемое, объект - основа предложения. [6] например, Организация A «имеет часть» Задания B. Она следует конструкции естественного языка Субъект - Предикат - Объект - также используемой в RDF . См. Кортеж . TRAK требует, чтобы каждый кортеж был явным. Кортежи описания архитектуры определяются метамоделью TRAK. Метамодель TRAK предоставляет по крайней мере 750 троек или утверждений описания архитектуры. [7]
Главный вид архитектуры
Каждый узел метамодели TRAK имеет представление основной архитектуры. В описании архитектуры или модели каждый элемент (отдельный) должен быть объявлен или показан в его главном архитектурном представлении, прежде чем его можно будет использовать в любом другом архитектурном представлении. Например, перед описанием функций с использованием, скажем, «Система выполняет функцию» в представлении функций решения SV-04, элемент системы должен быть сначала создан и представлен в представлении структуры решения TRAK SV-01.
Перспектива
ISO / IEC 42010 : 2007 относится к архитектурной перспективе как «Совместное использование архитектурных моделей также способствует« аспектно-ориентированному »стилю архитектурного описания» [8] . Группирование связанных и перекрывающихся архитектурных представлений. [6]
(Архитектура) Просмотр
ИСО / МЭК 42010 называет архитектурный вид «рабочим продуктом, выражающим архитектуру системы с точки зрения конкретных системных проблем». Представление TRAK определяется как продукт архитектуры в метамодели TRAK. Представление TRAK представляет собой набор кортежей описания архитектуры в соответствии с его основной точкой зрения.
(Архитектура) Точка зрения
ISO / IEC 42010 : 2007 - Точка зрения определяет набор соглашений (нотации, языки и типы моделей) для построения определенного вида представления. [6] В TRAK точка обзора - это спецификация для одного просмотра TRAK. Каждая точка обзора TRAK определяет как разрешенный контент, так и минимально допустимый контент просмотра как наборы кортежей описания архитектуры.

Структура TRAK [ править ]

TRAK определяется логически, то есть без каких-либо представлений о том, как TRAK реализован в каком-либо инструменте или на любом языке описания архитектуры.

TRAK имеет 24 архитектурные точки зрения, которые сгруппированы в 5 точек зрения. Каждая точка обзора принадлежит одной перспективе и определяет один вид (тип). Каждая точка обзора определяет, какие наборы типов элементов описания архитектуры и отношений (кортежи) могут появиться. Типы и отношения элементов описания архитектуры задаются метамоделью TRAK.

Логическое определение TRAK состоит из 3 документов, каждый из которых является проектом с открытым исходным кодом на Sourceforge :

  • Документ о структуре архитектуры предприятия TRAK. [9] Это контролирует TRAK в целом. Он определяет перспективы архитектуры TRAK, цвета, официальные правила (правила, влияющие на дизайн TRAK, виды архитектуры и описания архитектуры, минимальный процесс моделирования.
  • Документ «Точки зрения» на структуру архитектуры предприятия TRAK. [10] Это определяет точки зрения архитектуры TRAK.
  • Документ метамодели структуры архитектуры предприятия TRAK. [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 подвидов [11] ).

  • Перспектива предприятия
    • EVp-01 Корпоративные цели
    • EVp-02 Иерархия возможностей
    • EVp-03 фазировка возможностей
  • Концепция перспективы
    • Необходимость концепции CVp-01
    • Обмен концептуальными предметами CVp-03
    • CVp-04 от концептуальной деятельности до сопоставления возможностей
    • CVp-05 Концептуальная деятельность
    • Последовательность концепции CVp-06
  • Перспектива закупок
    • Структура закупки ПрВп-01
    • График закупок ПрВп-02
    • ПрВп-03 Ответственность за закупки
  • Перспектива решения
    • Структура решения СВп-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. Дополнительная информация представлена ​​в вики сообщества. [12]

Метамодель TRAK [ править ]

Метамодель структуры архитектуры предприятия TRAK. Определяет разрешенные элементы метамодели, включая отношения для использования в описаниях архитектуры TRAK.
Определяет элементы описания архитектуры (тройки / кортежи, которые могут появляться в представлениях архитектуры TRAK), которые описывают безопасность, защищенность и риск.
Часть метамодели TRAK (используется в структуре архитектуры предприятия TRAK). Описывает элементы перспективы управления и их отношения (кортежи).

Метамодель TRAK [6] одновременно упрощает и расширяет базовые концепции метамодели MODAF 1.2. Он удалил и переопределил стереотипы, и все защитные конструкции были удалены. Спецификация метамодели TRAK содержит сравнение метамодели TRAK в первоначальном выпуске с MODAF 1.2.003. Об этом также говорится отдельно. [13]

Метамодель TRAK показана ниже. Обратите внимание, что это не контролируемая копия .

Существенные изменения по сравнению с MODAF включают:

  • метамодель TRAK нацелена на пользователей (MODAF M3 - это абстрактный профиль UML, предназначенный как спецификация для поставщиков инструментов для реализации MODAF - нет метамодели для пользователей, только фрагменты «упрощенной метамодели», которые стремятся представить более сложный M3). В TRAK показанная метамодель является основной.
  • Система является центральной для TRAK и может представлять жесткие системы и программные системы (в MODAF 1.2.003 система является артефактом [14] и частью физической архитектуры и не может включать нефизические части [15] )
  • TRAK может представлять любой тип интерфейса / потока обмена - информацию, энергию или ресурс.
  • TRAK может отображать характеристики обмена, связанные с человеческими ресурсами - организации, должности и роли.
  • TRAK включает средства для представления требований с помощью элементов метамодели Standard (документ / коллекция) и Requirement (атомарная) и обеспечивается Контрактом.
  • TRAK включает средства для планирования и описания задачи архитектуры и описания архитектуры и ее организации в виде представления (запись проекта описания архитектуры MV-02)
  • могут быть представлены другие типы зависимости и ассоциаций - физическая, членство, степень ответственности
  • TRAK включает средства для описания случаев уверенности (включая верификацию проекта) с использованием конструкции "утверждение - аргумент - свидетельство".
  • TRAK включает средства для описания безопасности / защиты - угроз / опасностей, уязвимостей, смягчения и рисков, а также причин / воздействий.
  • добавление концепций ISO / IEC 42010 для представления архитектурной задачи, описания архитектуры и архитектурных представлений - чтобы дать возможность описания объема задачи, цели, результатов.
  • добавление правил согласованности для контента, которые применяются ко всей коллекции представлений и контекста, для улучшения навигации и видимости контента
  • правила, которые ограничивают то, как и в каком порядке могут быть установлены отношения для улучшения согласованности набора представлений, которые формируют описание архитектуры

Конструктивно есть и другие изменения:

  • TRAK имеет 24 точки обзора (против 47 просмотров в MODAF)
  • содержимое каждой точки обзора определено в терминах кортежей (конструкция элемента узел - отношение - узел, т.е. тройка или 1, кортеж ) и имеет разрешенные и минимально допустимые правила содержимого и соответствия по отношению к другим представлениям в описании архитектуры, потому что это необходимо для указания однозначно адресуемого пути в метамодели (указания элемента метамодели блока недостаточно, если существует несколько взаимосвязей, включающих элемент).
  • Поскольку ISO / IEC / IEEE 42010: 2011 определяет архитектуру в терминах отношения системы к ее среде, наименьшей единицей описания архитектуры, которая может появиться в представлении архитектуры TRAK, является кортеж описания архитектуры, то есть узел - отношение - узел.

Способ, которым TRAK управляется и выпускается через набор проектов с открытым исходным кодом, также сильно отличается от других структур архитектуры предприятия. Все запросы на изменение и запросы функций, а также приговоры к ним полностью видны всем, а не только тем, кто определяет или разрабатывает фреймворк. [16] [17] [18] Релизы находятся под контролем изменений, и вся история ведется с помощью программного обеспечения для управления версиями ( Subversion (SVN) ).

Презентация просмотров TRAK [ править ]

TRAK не определяет язык нотации или представления (язык описания архитектуры в терминологии ISO / IEC 42010), на котором должны быть представлены архитектурные представления. Таким образом , описания архитектуры TRAK не являются моделями UML , SysML или BPMN, хотя любая из этих нотаций может использоваться для подготовки по крайней мере некоторых представлений (ADL может не содержать необходимых концепций / стереотипов или может не позволять их соединять таким образом). необходимо для представления архитектурного представления TRAK).

TRAK требует, чтобы имя элемента метамодели каждого элемента описания архитектуры в представлении архитектуры TRAK было явно показано, чтобы каждое представление TRAK можно было читать как набор декларативных операторов, например

  • ' System . A -конфигурирован с-> Software . B '
  • ' Претензия . Система A соответствует требованиям ... -о-> Стандарт . Климатические условия окружающей среды ».
  • ' Физический . Shield Building -has-> Уязвимость . Структурная слабость <-exploits- Угроза . Преднамеренное столкновение с самолетом '

Кортежи могут быть представлены с помощью узлов и отношений с направлениями ( ориентированный граф ).

Пример представления рисков решения TRAK SV-13 в виде графика, показывающего кортежи из метамодели TRAK

TRAK также позволяет строить представление из текстовых утверждений. Поскольку представление TRAK представляет собой набор кортежей / троек, можно использовать граф или набор троек RDF для представления представления TRAK. Онтологическое описание RDF элементов метамодели TRAK находится в стадии разработки. [19] Здесь используются определения элементов из выходных данных спецификации метамодели TRAK из графической модели TRAK в базе данных графов Neo4J . [7] Архитектурное представление TRAK, состоящее из троек RDF, может быть связано с онтологией метамодели RDF TRAK для формирования графа знаний . Каждая тройка представляет собой факт или утверждение.

TRAK также требует, чтобы каждый блок и каждый соединитель имел имя и чтобы они были видимыми (явными). Это сделано для того, чтобы представление архитектуры TRAK читалось так, как это имел в виду автор представления, и улучшить семантическую согласованность. Правила представления, которые применяются ко всем представлениям архитектуры TRAK, указаны в общей спецификации TRAK [9] [20] (как «Официальные разъяснения»).

TRAK - это логическое определение: оно указывает, что нужно показывать, и минимально приемлемый контент, но не определяет, как этого добиться. TRAK просто определяет элементы узла и соединителя, а также допустимые комбинации (тройки), которые должны / могут появляться в каждом виде. Он не определяет и не требует каких-либо конкретных обозначений или языка. Например, допустима простая блок-схема и схема коннекторов (как указано выше), а также набор текстовых операторов, диаграмма с использованием UML., граф или набор троек RDF. По той же причине содержимое TRAK View определяется с использованием абстрактной и отличной от любой записи, которая может использоваться для реализации архитектуры TRAK View, чтобы избежать общей ошибки, возникающей из-за ошибки в одной записи, влияющей как на определение содержимого точки обзора TRAK, так и на «дизайнерский ответ» - содержание определенного вида TRAK.

Рекомендации по ISO 42010 [ править ]

TRAK применяет ISO / IEC 42010 следующим образом:

  • Описание архитектуры - это ответ на задачу, которая решает проблемы заинтересованного лица (это решается с помощью TRAK :: MVp-02. Архитектура Описание Описание Проектная запись Точка зрения, на основе которой может быть создано представление для определения задачи, решаемых проблем и выводов)
  • каждое архитектурное представление TRAK определяется точкой зрения в рамках архитектуры TRAK. Например, точка зрения доверия MVp-04 определяет содержимое любого представления доверия MV-04.
  • каждая точка зрения TRAK определяет заинтересованные стороны, решаемые проблемы, анти-проблемы (вещи, для которых не следует использовать точку обзора), необходимые кортежи метамодели, разрешенные кортежи метамодели, правильность (минимально допустимое содержание) и правила согласованности с другими представлениями в рамках описание архитектуры, например, в MV-04 Assurance View до того, как можно утверждать, что «Доказательства подтверждают утверждение», там должно существовать «Доказательства поддерживают аргумент поддерживает (то же самое) утверждение»
  • Правила соответствия определяются точками зрения и для описания архитектуры с использованием метамодели TRAK. Правила определяются с использованием троек из метамодели TRAK.

Общее сравнение между TRAK и ISO / IEC 42010 проводится в документе TRAK Enterprise Architecture Framework. Более подробное сравнение с версией стандарта 2011 г. проводится отдельно [21] и доступно для просмотра в виде набора веб-страниц. [22] Они, вместе с матрицей соответствия, [23] сравнивают: -

  1. TRAK как структура архитектуры в соответствии с требованиями раздела 6.1 (Структуры архитектуры) ISO / IEC / IEEE 42010: 2011 и;
  2. описание архитектуры, соответствующей TRAK, согласно разделу 5 (Описание архитектуры) ISO / IEC / IEEE 42010: 2011.

Создание описания архитектуры с помощью TRAK [ править ]

Сам TRAK не требует обязательного процесса. Тем не менее, здесь представлен элемент процесса, поскольку TRAK придерживается стандарта ISO / IEC 42010, в котором говорится, что описание архитектуры создается в ответ на задачу и интересы заинтересованных сторон, а также потому, что TRAK имеет основные представления архитектуры, которые создают зависимости между представлениями и приводит к минимально допустимым наборам архитектурных представлений.

Это приводит к минимальному процессу, который:

  • определить заинтересованную сторону задачи и их проблемы
  • с помощью точек обзора TRAK выберите точки обзора, необходимые для решения проблем заинтересованных сторон
  • выработать взгляды , соответствующие этим точкам зрения, чтобы решить эти проблемы
  • это, в свою очередь, может потребовать подготовки дополнительных представлений для формирования легитимного разрешенного набора представлений.
  • задокументировать цель, проблемы, результаты и описание архитектуры, используя представление записи проекта архитектуры MV-02, дополненное представлением словаря архитектуры MV-01

Лицензирование [ править ]

TRAK выпускается под двумя формами лицензии с открытым исходным кодом:

  • Лицензия свободной документации GNU ( GFDL ) для логического определения - документы TRAK в целом, метамодели TRAK и точки зрения TRAK
  • Общественная лицензия GNU ( GPL ) для реализации TRAK - профиль UML для TRAK для общих инструментов моделирования UML и TRAK MDG Technology для инструмента моделирования Sparx Systems Enterprise Architect .

Поддержка инструментов [ править ]

TRAK поддерживает инструменты моделирования с помощью следующих механизмов:

  • профиль UML для ТРАКА - для использования с любым инструментом моделирования UML , который может импортировать профиль UML
  • плагин для Sparx Systems Enterprise Architect на основе профиля UML для TRAK. Выпущено с открытым исходным кодом на Sourceforge [24]
  • шаблон для программной платформы MooD International от MooD 2010 (разработан Vega Consulting Services Ltd - частью Leonardo ). Выпущено с открытым исходным кодом на Sourceforge. [25]
  • трафарет для OmniGraffle ( Mac OS X , iPad ). Выпущено с открытым исходным кодом на Sourceforge. [26]
  • шаблон для Microsoft Visio . Выпущено с открытым исходным кодом на Sourceforge. [27]

Сравнение стереотипов (концепций) в UML со стереотипами в метамодели TRAK [28] обеспечивает анализ профиля UML для TRAK, какие точки обзора TRAK и, следовательно, представления TRAK UML могут представлять полностью, частично и не отображать вообще. . Это является следствием конструкций, доступных в UML, и конкретной реализации в профиле UML для TRAK, и возникает из-за того, что разные языки описания архитектуры ( ADL ) часто разрабатываются для разных целей, а иногда и для разных доменов, например, в ISO / IEC 42010 проблемы, которые они решают. отличаются от тех, что используются в структуре архитектуры, в данном случае TRAK.

Поскольку инструменты представляют собой реализацию логического определения TRAK, они могут содержать ограничения или ошибки из-за используемого языка обозначений (языка описания архитектуры) и возможностей конкретных инструментов.

Примеры описания архитектуры с использованием TRAK [ править ]

  • Программа модернизации подповерхности (SSUP). Модернизация сигнального и подвижного состава на линиях Circle, Hammersmith, Metropolitan и District на лондонском метро. Цитируется в исследовании «Соотношение цены и качества железных дорог». Отчет об управлении программой всей системы. 25 мая 2011 г. [2]
  • Группа руководства технической стратегией (TSLG). Функциональная архитектура железной дороги [29]
  • Совет по безопасности и стандартам на железнодорожном транспорте (RSSB). Функциональная архитектура железных дорог Великобритании. Текущее исследование - Электронный бюллетень по исследованиям и разработкам RSSB. Выпуск 66. Октябрь 2010 г. [30] Обоснование выбора / использования TRAK представлено в итоговом отчете по задаче. [31] Проект функциональной архитектуры железной дороги T912 описывается отдельно. [32] Функциональная архитектура железной дороги доступна в виде набора HTML-страниц. [33]
  • Бирмингемский университет. InfraGuidER (Руководство по инфраструктуре для экологической эффективности железных дорог), материалы 9 и 18., [34] минуты: D22: 2-й семинар по полюсам передового опыта EURNEX (Европейская сеть исследований в области железных дорог) [35]
  • Интегрированный EA 2011. Управление рисками и затратами с помощью подхода EA. Майк Браунсворд (Атего) и Джо Силмон (Центр железнодорожных исследований и образования)., [36]
  • Описание архитектуры [22], описывающее требования соответствия TRAK как структуры архитектуры и описание архитектуры, соответствующей TRAK, требованиям ISO / IEC / IEEE 42010: 2011. Включает примеры следующих представлений: MV-02 Архитектура Описание Проектная запись, Требования и стандарты MV-03 и Гарантия MV-04. Затем базовая модель была использована для создания матрицы соответствия [23] в качестве примера системного проектирования на основе моделей .

Ссылки [ править ]

  1. ^ Форумы IET - TRAK - Структура железнодорожной архитектуры
  2. ^ a b Исследование соотношения цены и качества железных дорог. Отчет об управлении программой всей системы. 25 мая 2011 г. http://www.rail-reg.gov.uk/upload/pdf/rvfm-atkins-programme-management-250511.pdf
  3. ^ Награда Рабочей группы INCOSE 2010 http://www.inosis.org/practice/techactivities/wg/transport/
  4. ^ Рабочая группа INCOSE по транспортировке http://www.inosis.org/practice/techactivities/wg/transport/
  5. ^ IET Innovation Awards 2001 - Финалисты http://conferences.theiet.org/innovation/finalists/index.cfm
  6. ^ a b c d e f TRAK00002 TRAK. Структура архитектуры предприятия. Метамодель
  7. ^ a b Слива, Ник (8 июня 2020 г.). «Использование ориентированных графов для определения точек обзора для сохранения согласованности метамодели, структуры архитектуры и представлений с использованием различных языков моделирования» . Инженерные отчеты . 2 (6). DOI : 10.1002 / eng2.12168 . Дата обращения 10 ноября 2020 .
  8. ^ ANSI / IEEE Std 1471 :: ISO / IEC 42010 Рекомендуемая практика для архитектурного описания программно-интенсивных систем
  9. ^ a b c Структура корпоративной архитектуры TRAK
  10. ^ a b TRAK00001 TRAK. Структура архитектуры предприятия. Точки обзора
  11. ^ Trak-community.org::Wiki::Architecture Framework Comparison http://trak-community.org/index.php/wiki/Architecture_Framework_Comparison
  12. ^ http://trak-community.org/index.php/wiki/TRAK:TRAK_Viewpoints
  13. ^ http://trak-community.org/index.php/wiki/TRAK:Initial_TRAK_Baseline_vs_MODAF_-_Stereotypes
  14. ^ MODAF Метамодель 1.2.004 MODAF версия 1.2.004
  15. ^ The MODAF System Viewpoint (SV) 26 апреля 2010 г.
  16. ^ Sourceforge. Трекеры ошибок / изменений проекта TRAK. http://sourceforge.net/tracker/?group_id=393432
  17. ^ Sourceforge. Трекеры ошибок / изменений проекта метамодели TRAK. http://sourceforge.net/tracker/?group_id=304403
  18. ^ Sourceforge. TRAK Viewpoints Project Bug / Change Trackers. http://sourceforge.net/tracker/?group_id=304405
  19. ^ Метамодель TRAK (RDF) https://trakmetamodel.sourceforge.io/vocab#
  20. ^ Архитектура предприятия TRAK
  21. ^ TRAK00015 TRAK. Описание архитектуры. Резюме. Оценка соответствия - ISO / IEC / IEEE 42010: 2011. http://sourceforge.net/projects/trak/files/ISO%2042010/TRAK00015_TRAK_AD_Summary_Conformance_with_42010_2011.pdf/download
  22. ^ a b TRAK00013 TRAK. Описание архитектуры. Оценка соответствия - ISO / IEC / IEEE 42010: 2011 http://trak.sourceforge.net/TRAK%20vs%20ISO_42010_AD/index.htm
  23. ^ a b TRAK00014 TRAK. Матрица соответствия. Оценка соответствия - ISO / IEC / IEEE 42010: 2011 http://sourceforge.net/projects/trak/files/ISO%2042010/TRAK00014_TRAK_vs_ISO42010_compliance.ods/download
  24. ^ Технология ЦРТ для TRAK
  25. ^ Проект trakmoodtemp на Sourceforge
  26. ^ Проект trakomnigraffle на Sourceforge
  27. ^ Проект trakforvisio на Sourceforge
  28. ^ проект trak на Sourceforge
  29. ^ Группа руководства технической стратегией (TSLG). Функциональная архитектура железных дорог. http://www.futurerailway.org/Research/Pages/Railway-Function-Architecture.aspx
  30. ^ Электронный бюллетень по исследованиям и разработкам RSSB. Выпуск 66. Октябрь 2010 г. Тема T912 Функциональная архитектура железной дороги http://www.rssb.co.uk/SiteCollectionDocuments/research/enews/rd_enewsletter66.htm
  31. ^ Краткий отчет о функциональной архитектуре железной дороги http://www.rssb.co.uk/sitecollectiondocuments/pdf/reports/research/T912_rpt_final.pdf
  32. ^ RSSB. Проект Т912 Функциональная архитектура железной дороги. http://www.rssb.co.uk/RESEARCH/Lists/DispForm_Custom.aspx?ID=955
  33. ^ Функциональная архитектура железной дороги (HTML) http://www.futurerailway.org/research/Pages/EA%20HTML/index.htm
  34. ^ Результаты InfraGuidER http://www.infraguider.eu/prodotti_7.html
  35. ^ Минуты: D22: 2-й семинар по полюсам передового опыта EURNEX http://infraguider.eu/doc/INFRAG_WP5_NIT_DV_022_B.pdf
  36. ^ Integrated EA 2011: Управление рисками и затратами с помощью подхода EA http://www.integrated-ea.com/file_download/101/

Внешние ссылки [ править ]

  • Сайт проекта TRAK Enterprise Architecture Framework
  • Структура архитектуры предприятия TRAK. Сайт проекта метамодели
  • Структура архитектуры предприятия TRAK. Сайт проекта Viewpoints
  • UML-профиль для TRAK
  • Сайт поддержки сообщества TRAK