Расширение языка, связанное с реализацией и переходом

Copyright © Рубенчик А.В. 2016. Все права защищены 1 2 3 4 5 6 7 80 9 Лекция № 10 Расширение языка, связанное с реализацией и переходом Плато Разрыв Поставляемый результат Пакет работ 132 / 142 Copyright © Рубенчик А.В. 2016. Все права защищены 1. Метамодель расширения На рис. 10-1 представлена метамодель расширения, связанного с реализацией и переходом (Рис. 10-1): Элемент поведения запускается запускает реализуется Плато реализует Поставляемый результат реализуется Пакет работ реализует ассоциированный с запускается/ передача от запускает/ передача к ассоциированный с Разрыв Рис. 10-1. Метамодель расширения, связанного с реализацией и переходом [4] В данном расширении водятся понятия для моделирования фазы E «Возможности и решения», фазы F «Планирование перехода» и фазы G «Руководство реализацией» метода разработки архитектуры TOGAF [8]. 2. Элементы расширения 2.1. Пакет работ предназначенных для определяется выполнения как последовательность однозначно определенной определенное время (Рис. 10-2): Пакет работ Рис. 10-2. Обозначение элемента «Пакет работ» 133 / 142 действий, цели за Copyright © Рубенчик А.В. 2016. Все права защищены Пакет работ является элементом поведения. Пакет работ имеет четко определенные даты начала и завершения работ и набор целей или результатов. Понятие пакета работ может быть использовано для моделирования проектов, подпроектов или задач внутри проекта или программ проектов. В примере показана программа по рационализации портфеля приложений, которая моделируется пакетом работ «Программа по рационализации портфеля приложений» (Рис. 10-3): Рис. 10-3. Пример элемента «Пакет работ» Данная программа включает два проекта, которые выполняются последовательно. Каждый из проектов также моделируется пакетом работ. Первый проект выполняется для интеграции систем бэк-офиса (кроме CRMсистем) в единую систему бэк-офиса. Следующим выполняется проект по интеграции CRM-систем. 2.2. Поставляемый результат определяется как четко определенный результат (выход) пакета работ (Рис. 10-4): Поставляемый результат Рис. 10-4. Обозначение элемента «Поставляемый результат» 134 / 142 Copyright © Рубенчик А.В. 2016. Все права защищены Поставляемые результаты создаются пакетами работ. Поставляемый результат может представлять реализацию (части) архитектуры. Поставляемые результаты могут быть любого вида. Например, отчеты, исследования, сервисы, программное обеспечение, физические продукты и т.п. или неосязаемые (нематериальные) результаты, такие как организационные изменения. В примере показана декомпозиция продукта проекта «Интегрированная система бэк-офиса» в виде иерархической структуры продукта (Рис. 10-5): Рис. 10-5. Пример элемента «Поставляемый результат» 2.3. Плато определяется как относительно стабильное состояние архитектуры, которое существует в течение ограниченного периода времени (Рис. 10-6): Плато Рис. 10-6. Обозначение элемента «Плато» 135 / 142 Copyright © Рубенчик А.В. 2016. Все права защищены На фазах B (Бизнес-архитектура), C (Архитектура информационных систем) и D (Технологическая архитектура) метода разработки архитектуры TOGAF создаются исходная и целевая архитектуры, описывающие текущее состояние и желаемое будущее состояние [8]. На фазе E (Возможности и Решения) определяются переходные архитектуры, показывающие предприятие в постепенно прирастающих (инкрементных) состояниях, которые отражают периоды перехода между исходной и целевой архитектурами [8]. Для поддержки такого подхода и вводится понятие «плато». Переходные архитектуры используются для группирования пакетов работ и проектов в управляемые портфели работ и программы, демонстрирующие бизнесценности на каждой из стадий. В примере показано использование понятия «плато» для моделирования перехода от исходной к целевой архитектуре, при этом определяется ряд промежуточных (возможно альтернативных) переходных архитектур (Рис. 10-7): Рис. 10-7. Пример элемента «Плато» 136 / 142 Copyright © Рубенчик А.В. 2016. Все права защищены 2.4. Разрыв определяется как результат гэп-анализа между двумя плато (Рис. 108): Разрыв Рис. 10-8. Обозначение элемента «Разрыв» Понятие «разрыв» является важным результатом гэп-анализа на фазах B, C и D метода разработки архитектуры TOGAF и формирует входные данные для последующего планирования реализации и перехода [8]. Понятие «разрыв» связано с двумя плато (например, исходная и целевая архитектуры, или две последовательных транзитных архитектуры) и представляет различие, разность между этими плато. В примере показан разрыв между целевой и исходной инфраструктурой (показано, какие элементы инфраструктуры добавлены и какие удалены) (Рис. 109): Рис. 10-9. Пример элемента «Разрыв» 137 / 142 Copyright © Рубенчик А.В. 2016. Все права защищены 3. Отношения расширения В расширении используются стандартные отношения языка. 4. Отношения между понятиями расширения и базовыми понятиями На рисунке 10-10 показано, как элементы расширения, связанного с реализацией и переходом, могут быть связаны с базовыми элементами языка (Рис. 10-10): ассоциированный с Разрыв ассоциированный с Базовый элемент реализуется объединяется реализует Плато объединяет Поставляемый результат Пакет работ назначается Бизнес-роль назначается назначается назначается назначается Площадка назначается Рис. 10-10. Отношения между понятиями расширения и базовыми понятиями [4] Плато может объединять любые базовые понятия языка, что позволяет обозначить, какие части архитектуры принадлежат данному плато. Плато действительно для определенного промежутка времени. Разрыв ассоциируется с базовыми понятиями, которые являются уникальными для одного из плато, связанных разрывом, и которые составляют различие между этими плато. Поставляемый результат может реализовывать внедрение архитектуры или ее части. Любой базовый элемент может быть связан с поставляемым результатом посредством отношения «реализация». Пакету работ может быть назначена бизнес-роль. 138 / 142 Copyright © Рубенчик А.В. 2016. Все права защищены Пакету работ или поставляемому результату может быть назначена площадка. 5. Отношения между понятиями расширения и мотивационными понятиями Строго говоря, отношения между элементами расширения, связанного с реализацией и переходом, и мотивационными элементами являются косвенными отношениями. Например, поставляемый результат реализует требование или цель через реализацию базового элемента (компонента приложений, бизнес-процесса или сервиса). Однако имеет смысл сделать эти отношения явными, чтобы непосредственно показать, что поставляемый результат необходим для реализации определенных требований и целей (Рис. 10-11): Цель (из расширения, связанного с мотивацией) объединяется объединяется Требование/ Ограничение (из расширения, связанного с мотивацией) реализуется объединяет объединяет реализует Поставляемый результат Плато Рис. 10-11. Отношения между понятиями расширения и мотивационными понятиями [4] Также цели и требования могут быть связаны с определенным плато. 139 / 142 Copyright © Рубенчик А.В. 2016. Все права защищены Например, одни требования могут быть применимы только к целевой архитектуре, в то время, как другие могут применяться к определенной переходной архитектуре. Это может быть смоделировано посредством отношения «объединение». 6. Способы представления Имеется 3 стандартных способов представления для моделирования аспектов, связанных c реализацией и переходом (Таблица 10-1): Таблица 10-1 № 1 Название Проекты Назначение Моделирование управления изменениями архитектуры. 2 Переход Моделирование перехода от существующей архитектуры к целевой архитектуре. 3 Реализация и переход Моделирование отношений между программами и проектами и частями архитектуры, которые они реализуют. 140 / 142