✖


Jump to content

ОТСЛЕЖИВАТЬ

    Add links

    Структура 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.

    Команда разработчиков 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]
    (Архитектура) Посмотреть
    В ISO/IEC 42010 представление об архитектуре называется «рабочим продуктом, выражающим архитектуру системы с точки зрения конкретных проблем системы». Представление TRAK определяется как архитектурный продукт в метамодели TRAK. Представление TRAK представляет набор кортежей описания архитектуры в соответствии с его основной точкой зрения.
    (Архитектура) Точка зрения
    ISO/IEC 42010 :2007 — Точка зрения определяет набор соглашений (нотаций, языков и типов моделей) для построения определенного вида представления. [6] В TRAK точка обзора — это спецификация одного представления TRAK. Каждая точка обзора TRAK определяет как разрешенный контент, так и минимально допустимый контент представления в виде наборов кортежей описания архитектуры.

    Структура ТРАК [ править ]

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

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

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

    • Документ TRAK Enterprise Architecture Framework. [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 Компетенция решения
      • Последовательность решения СВп-07
      • Решение SVp-11 Причины событий
      • Риск решения СВп-13
    • Перспектива управления
      • Словарь описания архитектуры MVp-01
      • MVp-02 Описание архитектуры Запись проекта
      • Требования и стандарты MVp-03
      • МВп-04 Гарантия

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

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

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

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

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

    Имеется онтологическое описание элементов метамодели TRAK с использованием RDF по адресу. [14] Это также представлено в виде HTML. [15]

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

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

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

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

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

    Презентация взглядов TRAK [ править ]

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

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

    • ' Система . А - настраивается -> Программное обеспечение . Б'
    • ' Требовать . Система A соответствует требованию ... -about-> Standard . Климатические экологические характеристики».
    • ' Физическое . Здание щита -имеет-> Уязвимость . Структурная слабость <-эксплойты- угроза . Умышленное столкновение с самолетом»

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

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

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

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

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

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

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

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

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

    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 Total, TRAK Metamodel и TRAK Viewpoints.
    • Стандартная общественная лицензия GNU ( GPL ) для реализаций TRAK — профиля UML для TRAK для общих инструментов моделирования UML и TRAK MDG Technology для инструмента моделирования Sparx Systems Enterprise Architect .

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

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

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

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

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

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

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

    1. ^ Форумы IET - TRAK - Структура железнодорожной архитектуры
    2. ↑ Перейти обратно: Перейти обратно: а б Исследование соотношения цены и качества железнодорожных перевозок. Отчет об управлении программой всей системы. 25 мая 2011 г. https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/4203/realising-the-potential-of-gb-rail-summary.pdf
    3. ^ Премия рабочей группы INCOSE 2010 https://www.incose.org/about-incose/incose-recognition/working-group-awards#2010
    4. ^ Транспортная рабочая группа INCOSE http://www.incose.org/practice/techactivities/wg/transport/
    5. ^ IET Innovation Awards 2001 — финалисты http://conferences.theiet.org/innovation/finalists/index.cfm
    6. ↑ Перейти обратно: Перейти обратно: а б с д и ж ТРАК00002 ТРАК. Структура архитектуры предприятия. Метамодель
    7. ↑ Перейти обратно: Перейти обратно: а б Плам, Ник (8 июня 2020 г.). «Использование ориентированных графов для определения точек зрения, чтобы обеспечить согласованность метамодели, архитектурной структуры и представлений, использующих разные языки моделирования» . Инженерные отчеты . 2 (6). дои : 10.1002/eng2.12168 .
    8. ^ ANSI/IEEE Std 1471 :: ISO/IEC 42010 Рекомендуемая практика для описания архитектуры систем с интенсивным программным обеспечением
    9. ↑ Перейти обратно: Перейти обратно: а б с Структура архитектуры предприятия TRAK
    10. ↑ Перейти обратно: Перейти обратно: а б ТРАК00001 ТРАК. Структура архитектуры предприятия. точки зрения
    11. ^ Trak-community.org::Wiki::Сравнение архитектурных рамок http://trak-community.org/index.php/wiki/Architecture_Framework_Comparison
    12. ^ «Сообщество TRAK :: Wiki :: TRAK: Точки зрения TRAK» .
    13. ^ «Сообщество TRAK :: Wiki :: TRAK: Начальная базовая линия TRAK против MODAF — стереотипы» .
    14. ^ «Метамодель TRAK — описание RDF» .
    15. ^ «Метамодель TRAK (HTML-описание)» .
    16. ^ Метамодель MODAF 1.2.004 Версия MODAF 1.2.004
    17. ^ Точка зрения системы MODAF (SV), 26 апреля 2010 г.
    18. ^ Сорсфордж. Трекеры ошибок/изменений проекта TRAK. https://sourceforge.net/tracker/?group_id=393432
    19. ^ Сорсфордж. Трекеры ошибок/изменений проекта метамодели TRAK. https://sourceforge.net/tracker/?group_id=304403
    20. ^ Сорсфордж. TRAK Viewpoints Проектные трекеры ошибок/изменений. https://sourceforge.net/tracker/?group_id=304405
    21. ^ Метамодель TRAK (RDF) https://trakmetamodel.sourceforge.io/vocab#
    22. ^ Архитектура предприятия TRAK
    23. ^ ТРАК00015 ТРАК. Описание архитектуры. Краткое содержание. Оценка соответствия – ISO/IEC/IEEE 42010:2011. http://sourceforge.net/projects/trak/files/ISO%2042010/TRAK00015_TRAK_AD_Summary_Conformance_with_42010_2011.pdf/download
    24. ↑ Перейти обратно: Перейти обратно: а б ТРАК00013 ТРАК. Описание архитектуры. Оценка соответствия – ISO/IEC/IEEE 42010:2011 http://trak.sourceforge.net/TRAK%20vs%20ISO_42010_AD/index.htm
    25. ↑ Перейти обратно: Перейти обратно: а б ТРАК00014 ТРАК. Матрица соответствия. Оценка соответствия – ISO/IEC/IEEE 42010:2011 http://sourceforge.net/projects/trak/files/ISO%2042010/TRAK00014_TRAK_vs_ISO42010_compliance.ods/download
    26. ^ Технология ЦРТ для TRAK
    27. ^ Проект trakmoodtemp на Sourceforge
    28. ^ Проект trakomnigraffle на Sourceforge
    29. ^ Проект trakforvisio на Sourceforge
    30. ^ проект trak на Sourceforge
    31. ^ Группа руководства технической стратегией (TSLG). Железнодорожная функциональная архитектура. http://www.futurerailway.org/Research/Pages/Railway-Function-Architecture.aspx
    32. ^ Электронный информационный бюллетень RSSB по исследованиям и разработкам. Выпуск 66. Октябрь 2010 г. Тема T912 Функциональная архитектура железных дорог http://www.rssb.co.uk/SiteCollectionDocuments/research/enews/rd_enewsletter66.htm
    33. ^ Сводный отчет о функциональной архитектуре железных дорог http://www.rssb.co.uk/sitecollectiondocuments/pdf/reports/research/T912_rpt_final.pdf
    34. ^ РССБ. Проект Т912 Функциональная архитектура железной дороги. http://www.rssb.co.uk/RESEARCH/Lists/DispForm_Custom.aspx?ID=955
    35. ^ Функциональная архитектура железных дорог (HTML) http://www.futurerailway.org/research/Pages/EA%20HTML/index.htm
    36. ^ Результаты InfraGuidER http://www.infraguider.eu/prodotti_7.html
    37. ^ Протокол: D22: 2-й семинар по полюсам передового опыта EURNEX http://infraguider.eu/doc/INFRAG_WP5_NIT_DV_022_B.pdf
    38. ^ Интегрированный EA 2011: Управление рисками и затратами с помощью подхода EA http://www.integrated-ea.com/file_download/101/

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

    Викискладе есть медиафайлы по теме TRAK .
    Retrieved from "https://en.wikipedia.org/w/index.php?title=TRAK&oldid=1223601902"
    Arc.Ask3.Ru: конец переведенного документа.
    Arc.Ask3.Ru
    Номер скриншота №: 3835e7bbbd4acb66c83a71d8d98212d6__1715569200
    URL1:https://arc.ask3.ru/arc/aa/38/d6/3835e7bbbd4acb66c83a71d8d98212d6.html
    Заголовок, (Title) документа по адресу, URL1:
    TRAK - Wikipedia
    Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)