TRAK

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

TRAK является общим фреймворк архитектуры предприятия для системных инженеров на основе MODAF 1.2.

• 1 История
• 2 Терминология
• 3 Структура TRAK
• 4 Перспективы архитектуры TRAK
  • 4.1 Перспективы предприятия
  • 4.2 Концептуальные перспективы
  • 4.3 Перспективы закупок
  • 4.4 Решение Перспектива
  • 4.5 Перспектива управления
• 5 Точки зрения и представления архитектуры TRAK
• 6 Метамодель TRAK
• 7 Представление представлений TRAK
• 8 Рекомендации по ISO 42010
• 9 Создание описания архитектуры с использованием TRAK
• 10 Лицензирование
• 11 Поддержка инструментов
• 12 Примеры описания архитектуры с использованием TRAK
• 13 Ссылки
• 14 Внешние ссылки

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

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

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

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

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

Кортеж описания архитектуры

Элемент описания архитектуры с именованным типом, который имеет именованное отношение к той же или другой архитектуре элемент описания например Организация A «имеет часть» Задания B. Она следует естественной языковой конструкции Subject - Predicate - Object - также используемой в RDF. См. Кортеж. TRAK требует, чтобы каждый кортеж был явным.

Представление основной архитектуры

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

Перспектива

ISO / IEC 42010 : 2007 относится к Архитектурная перспектива как «Совместное использование архитектурных моделей также способствует« аспектно-ориентированному »стилю архитектурного описания». Группирование связанных и перекрывающихся архитектурных представлений.

Вид

ISO / IEC 42010 относится к архитектурному представлению как «Рабочий продукт, выражающий архитектуру системы с точки зрения конкретных системных проблем». Представление TRAK определяется как продукт архитектуры в метамодели TRAK. Представление TRAK представляет собой набор кортежей описания архитектуры в соответствии с его основной точкой зрения.

Точка зрения

ISO / IEC 42010 : 2007 - точка зрения определяет набор соглашений (нотации, языки и типы моделей) для построение определенного вида. В TRAK точка обзора - это спецификация для одного вида TRAK.

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

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

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

• документе TRAK Enterprise Architecture Framework. Это контролирует TRAK в целом. Он определяет перспективы архитектуры TRAK, цвета, официальные правила (правила, влияющие на дизайн TRAK, виды архитектуры и описания архитектуры, минимальный процесс моделирования.
• Документ «Точки зрения структуры архитектуры предприятия TRAK». В нем определяются точки зрения архитектуры TRAK.
• Документ метамодели структуры архитектуры предприятия TRAK. В нем определены элементы описания архитектуры, которые могут появляться в определении точки обзора.

TRAK имеет 5 перспектив архитектуры, каждая из которых объединяет архитектуру точки зрения и представления перекрывающейся предметной области:

• Перспектива предприятия
• Перспектива концепции
• Перспектива закупок
• Перспектива решения
• Перспектива управления

Предприятие Перспектива

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

Концептуальная перспектива

Концептуальная перспектива охватывает логическое представление о том, что необходимо в ответ на возможности, необходимые предприятию с точки зрения предприятия. Он охватывает логическое соединение узлов, например, центра управления услугами, с другими узлами без понимания того, как это может быть реализовано организацией или технологией. Он также не подразумевает какой-либо определенной части жизненного цикла - он охватывает все, от концепции до утилизации («похоть в пыль»!).

Перспектива закупок

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

Перспектива решения

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

Перспектива управления

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

С точки зрения управления, можно описать применяемые нормативные стандарты. Он содержит представления, которые предоставляют вспомогательную информацию, чтобы помочь переносимости и пониманию модели (ей).

Каждое представление архитектуры в TRAK определяется соответствующей точкой обзора архитектуры. Точка обзора обозначается буквой p в нумерации, например. CVp-01 - это архитектурная точка зрения, которая определяет архитектурный вид CV-01.

Обычно используется, если есть риск путаницы с представлением с аналогичным номером в другой структуре, например DODAF или MODAF, тогда используется префикс пространства имен, например TRAK :: SV-01

TRAK определяет 24 точки зрения на архитектуру (для сравнения, 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
• Перспектива закупок
  • Структура закупок ПрВп-01
  • График закупок ПрВп-02
  • Ответственность за закупки ПрВп-03
• Перспектива решения
  • Структура решения СВП-01
  • Взаимодействие ресурсов решения SVp-02
  • Взаимодействие ресурсов решения SVp-03 с отображением функций
  • Функция решения SVp-04
  • Функция решения SVp-05 в концептуальную деятельность Сопоставление
  • Компетенция решения SVp-06
  • Последовательность решения SVp-07
  • Причина события решения SVp-11 es
  • Риск решения SVp-13
• Перспектива управления
  • Словарь описания архитектуры MVp-01
  • Описание архитектуры MVp-02 Запись проекта
  • MVp- 03 Требования и стандарты
  • MVp-04 Assurance

Они определены в спецификации TRAK Viewpoints. Дополнительная информация представлена ​​в вики сообщества.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• описание архитектуры - это ответ на задачу, которая направлена ​​на решение проблем заинтересованных сторон (это решается с помощью TRAK :: MVp-02 Architecture Description Design Record Viewpoint)
• каждое архитектурное представление TRAK определяется точкой обзора в структуре архитектуры TRAK
• каждая точка зрения TRAK определяет заинтересованные стороны, решаемые проблемы, анти-проблемы (вещи, для которых точка обзора не должна использоваться), кортежи метамодели При необходимости, разрешенные кортежи метамодели, правильность (минимально допустимое содержимое) и правила согласованности с другими представлениями в описании архитектуры
• определяются точками обзора и для описания архитектуры с использованием метамодели TRAK.

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

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

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

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

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

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

• GNU Free Documentation License (GFDL ) для логического определения - TRAK в целом, TRAK Metamodel и документы TRAK Viewpoints
• GNU Public License (GPL ) для реализации TRAK - профиль UML для TRAK для общих инструментов моделирования UML и TRAK MDG Technology для Sparx Systems Enterprise Architec t инструмент моделирования.

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

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

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

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

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

На Викискладе есть материалы, связанные с TRAK.

• Архитектура предприятия TRAK
• Профиль UML для TRAK
• Сайт поддержки сообщества TRAK