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