Материал: Методика проектирования архитектуры приложений с использованием языка ArchiMate

L=

4,06

ИС=

0,02

ОС=

2,06%

n=

4

ИС случ=

0,9

Ориентировка на снижение затрат в организации

Модель Захмана

TOGAF

FEA

Gartner

среднее геометрическое

приоритеты

Модель Захмана

1

 1/7

1

 1/8

0,37

0,06

TOGAF

7

1

7

 1/3

2,01

0,31

FEA

1

 1/7

1

 1/8

0,37

0,06

Gartner

8

3

8

1

3,72

0,58

сумма

17,00

4,29

17,00

1,58

итого

6,46

1,00

L=

4,17

ИС=

0,06

ОС=

6,2%

n=

4

ИС случ=

0,9

Структурная и функциональная декомпозиция

Модель Захмана

TOGAF

FEA

Gartner

среднее геометрическое

приоритеты

Модель Захмана

1

 1/5

 1/8

 1/5

0,27

TOGAF

5

1

 1/3

1

1,14

0,21

FEA

8

3

1

3

2,91

0,53

Gartner

5

1

 1/3

1

1,14

0,21

сумма

19,00

5,20

1,79

5,20

итого

5,45

1,00

L=

4,05

ИС=

0,02

ОС=

1,92%

n=

4

ИС случ=

0,9

Независимость от поставщика услуг

Модель Захмана

TOGAF

FEA

Gartner

среднее геометрическое

приоритеты

Модель Захмана

1

 1/4

1

2

0,84

0,15

TOGAF

4

1

4

8

3,36

0,61

FEA

1

 1/4

1

3

0,93

0,17

Gartner

 1/2

 1/8

 1/3

1

0,38

0,07

сумма

6,50

1,63

6,33

14,00

итого

5,52

1,00

L=

4,02

ИС=

0,01

ОС=

0,57%

n=

4

ИС случ=

0,9

Доступность информации о методологии

Модель Захмана

TOGAF

FEA

Gartner

среднее геометрическое

приоритеты

Модель Захмана

1

 1/6

1

3

0,84

0,14

TOGAF

6

1

6

8

4,12

0,68

FEA

1

 1/6

1

2

0,76

0,12

Gartner

 1/3

 1/8

 1/2

1

0,38

0,06

сумма

8,33

1,46

8,50

14,00

итого

6,10

1,00

L=

4,06

ИС=

0,02

ОС=

2,38%

n=

4

ИС случ=

0,9

Окупаемость

Модель Захмана

TOGAF

FEA

Gartner

среднее геометрическое

приоритеты

Модель Захмана

1

 1/8

1

 1/8

0,35

0,06

TOGAF

8

1

8

1

2,83

0,45

FEA

1

 1/8

1

 1/7

0,37

0,06

Gartner

8

1

7

1

2,74

0,44

сумма

18,00

2,25

17,00

2,27

итого

6,28

1,00

L=

4,00

ИС=

0,00

ОС=

0,08%

n=

4

ИС случ=

0,9

Стоимость проектирования

Модель Захмана

TOGAF

FEA

Gartner

среднее геометрическое

приоритеты

Модель Захмана

1

 1/2

3

4

1,57

0,32

TOGAF

2

1

4

3

2,21

0,45

FEA

 1/3

 1/4

1

 1/2

0,45

0,09

Gartner

 1/4

 1/3

2

1

0,64

0,13

сумма

3,58

2,08

10,00

8,50

итого

4,87

1,00

L=

4,14

ИС=

0,05

ОС=

5,26%

n=

4

ИС случ=

0,9

Полнота модели

Простота создания модели

Эталонные модели

Эффективность использования и адаптация

Ориентировка на снижение затрат в организации

Деокмпозиция

Независимость от рынка поставщиков услуг

Доступность информации о методологии

Окупаемость

Стоимость проектирования

ИТОГО

0,12

0,09

0,02

0,07

0,17

0,03

0,03

0,03

0,20

0,22

Модель Захмана

0,59

0,17

0,09

0,07

0,06

0,05

0,15

0,14

0,06

0,32

0,199

TOGAF

0,28

0,65

0,23

0,16

0,31

0,21

0,61

0,68

0,45

0,45

0,404

FEA

0,08

0,05

0,62

0,65

0,06

0,53

0,17

0,12

0,06

0,09

0,143

Gartner

0,05

0,13

0,06

0,12

0,58

0,21

0,07

0,06

0,44

0,13

0,255

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

Таким образом, метод анализа иерархий помогает решить задачу выбора альтернатив с помощью многокритериальной системы рейтингования. Метод Саати позволяет провести оценку важности учета каждого решения, а также оценку важности каждого фактора, влияющего на приоритет этих решений.

Для дальнейшей работы был выбран язык ArchiMate, разработанный специально для проектирования архитектуры, основанной на методологии TOGAF [24].

2. Применение архитектурного языка для моделирования сервис-ориентированной архитектуры предприятия

2.1 Основные концепции языка ArchiMate

Архитектура предприятия обычно разрабатывается, для того чтобы «ключевые» люди в организации смогли рассмотреть проблемы бизнеса и ИТ-систем в компании. Таких людей, как правило, называют «заинтересованными сторонами» в системе. Роль архитектора в процессе построения заключается в решении проблем путем уточнения требований «заинтересованных лиц». Чтобы отобразить различные точки зрения разных «заинтересованных сторон» используются «виды» архитектуры, на которых отражаются требования и видение архитектуры каждой конкретной стороны. Основная задача архитектора найти компромиссные решения, чтобы удовлетворить требования различных сторон и их взгляды на проблемы в компании [25].

Для обеспечения единообразного представления диаграмм, описывающих архитектуру предприятия, был разработан язык моделирования ArchiMate.

Он предлагает комплексный подход к проектированию архитектуры предприятия визуализируя различный виды архитектур (бизнес-архитектуру, архитектуру приложений и технологическую архитектуру), а также их отношения и зависимости. Он предлагает комплексный подход к архитектуре, которая описывает и визуализирует различную область архитектуры и их глубинные отношения и зависимость [30,31,32].

Основной ролью стандарта ArchiMate является предоставление графического языка для проектирования и описания архитектуры предприятия на длительный срок. Эволюция стандарта тесно связана со стандартом TOGAF и новых результатов с форумов Open Group и рабочих групп, действующих в этой области [33,34]. Как следствие, стандарт ArchiMate не предоставляет свой собственный набор определенных терминов, а опирается на предусмотренные стандартом TOGAF [35].

Ядро языка состоит из трех основных типов элементов: активные структурные элементы, элементы поведения и пассивные структурные компоненты[36].

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

Данные аспекты были перенесены из естественного языка, где в предложении существуют субъект (активная структура), глагол (поведение), и объект (пассивная структура) [36,37].

Сервисы являются поведением системы видимым извне, они доступны через интерфейсы, которые представляют собой внешний вид для активного структурного элемента и скрывают внутреннюю структуру сервисов [38]. На рисунке 2.1. представлена общая метамодель ArchiMate.

Рисунок 2.1. Общая Метамодель: основные концепции ArchiMate

Сотрудничество определяется как совокупность двух или более структурных элементов, работающих вместе, для выполнения некоторого коллективного поведения (см. рис.2.2).

Рисунок 2.2. Сотрудничество [39]

ArchiMate содержит базовый набор отношений. Некоторые из этих отношений были приняты из соответствующих концепций отношений, которые возникают в существующих стандартах; например, отношения, такие как состав, агрегация, ассоциация и специализация, взяты из UML 2.0, в то время запуска используются во многих языках моделирования бизнес-процессах.

Язык ArchiMate определяет три основных слоя:

.        Бизнес-слой.

.        Слой приложений.

.        Технологический слой.

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

Рисунок 2.3. Architectural Framework [39]

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

Размеры каркаса заключаются в следующем:

Слои: три уровня, на которых строится архитетура предприятия:

·        -Бизнес - слой предлагает продукты и услуги внешних клиентов, которые реализуются в бизнес - процессах организации.

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

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

Аспекты:

·        Активная структура. Аспект представляет структурные понятия (бизнес - актер, компоненты приложений и устройства, которые отображают реальное поведение; т.е. «субъекты» деятельности).

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

·        Пассивная структура аспект представляет собой объекты, на которых осуществляется поведение.

Помимо основных аспектов работа архитектора предприятия затрагивает другие аспекты, не охваченые ArchiMate Framework. (цели, принципы и требования; риск и безопасность; управление; политика и бизнес - правила; затраты; производительность; сроки; планирование и развитие).

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

Основные понятия ArchiMate сосредотачиваются на описании архитектуры систем, которые поддерживают предприятие. Но остаются неохваченными элементы, мотивирующие на проектирование и эксплуатацию предприятия.

Расширение мотивации ArchiMate добавляет такие мотивационные понятия, как цель, принцип, и требование. Мотивационный элемент определяется как элемент, который обеспечивает контекст или причины. Кроме того, расширение мотивации определяет концепцию заинтересованных сторон, драйверов и оценок. Заинтересованные стороны представляют группы лиц или организации, которые оказывают влияние на предприятие. Драйвера представляют собой внутренние или внешние факторы, которые влияют на планы и цели предприятия. На рис.5 изображены основные элементы архитектурного описания, связаные с мотивационными элементами через требования [40].

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

Рисунок 2.4. Взаимосвязь между элементами ядра и мотивационной в ArchiMate [39]

ArchiMate поддерживает процесс управления требованиями с помощью мотивационных понятий.

Расширение внедрение и миграция в ArchiMate добавляет концепции для поддержки поздних фаз ADM, связанные с реализацией и миграции архитектур: Фаза E (Возможности и решения), фаза F (Планирование миграции), и фазы G (Управление внедрения). Это расширение включает в себя концепцию для моделирования программ и проектов внедрения для поддержки программы, портфолио и управления проектами, а также концепцию плато для поддержки планирования миграции.

На рисунке 2.5 показана взаимосвязь между концепциями расширения внедрения и миграции, концепций основного ядра и расширения мотивации в ArchiMate.

Рисунок 2.5.Отношения между мотивационной, Core, и реализации и миграции элементов [39]

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

Основная структура языка ArchiMate тесно соотносится с тремя основными архитектурами, как в TOGAF ADM. Это показано на рисунке 2.6. Это соответствие между видами TOGAF и точками зрения в ArchiMate можно достаточно просто отобразить.

Рисунок 2.6. Соответствие между ArchiMate и TOGAF [39]

Некоторые виды TOGAF не совпадают с ядром ArchiMate. Частично это объясняется тем, что сфера TOGAF шире и, затрагивает больше стратегических вопросов на высоком уровне, а также инженерно - технические аспекты более низкого уровня развития системы, в то время как ядро ArchiMate ограничивается достоточно абстракным уровнем архитектуры предприятия. Рисунок 2.7 иллюстрирует соответсвие ядра TOGAF и основных принципов языка ArchiMate.

Рисунок 2.7. Соответствие между ArchiMate (включая расширение) и TOGAF [39]

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

В метамодели, изображеной в пределах этой спецификации, цвета используются для различения понятий, относящихся к различным аспектам ArchiMate Framework: зеленый для пассивной структуры, желтый для элементов поведения, и синий для активной структуры. Для моделей, представленных в данной спецификации, цвета используются для проведения различия между слоями ArchiMate Framework: желтым для бизнеса-слоя, синий для прикладного уровня, и зеленый для технологического уровня.

2.2 Бизнес-архитектура

На рисунке 2.8 показана метамодель понятий бизнес-слоя. Метамодель повторяет структуру общей метамодели, но этот слой также включает в себя ряд дополнительных информационных концепций, которые относятся к бизнеес-архитектуре.

Рисунок 2.8. Метамодель бизнес - слоя [39]

2.2.1 Активные элементы бизнес-архитектуры

·        Бизнес-актор.

Бизнес-актор определяется как организационная единица, которая способна выполнять поведение. Он выполняет поведение, назначенное бизнес - роли. Бизнес актер является частью организационной структуры. Акторы может включать в себя объекты, находящиеся за пределами фактического предприятия; например, клиенты и партнеры. Название бизнес - актера, предпочтительно должно быть существительным. На рисунке 2.9 представлен графический элемент «Бизнес-актор» для языка ArchiMate.

Рисунок 2.9. Бизнес-актор

Модель ниже иллюстрирует использование бизнес - субъектов. Преподаватель и студент - являются бизнес-объектами и моделируются как бизнес - актеры (рисунок 2.10).

Рисунок 2.10. Пример моделирования бизнес-актера

·        Бизнес-роль.

Бизнес-роль определяется как ответственность за выполнение конкретного поведения, на которое может быть назначен актер. Бизнес-актер, который присваивается бизнес-роли, выполняет соответствующее поведение. Бизнес-роль может быть назначена на один или более бизнес-процессов или бизнес-функций. Название бизнес-роли предпочтительно должно быть существительным. На рисунке 2.10 представлен графический элемент «Бизнес-роль» для языка ArchiMate.

Рисунок 2.11. Бизнес-роль

В приведенной ниже модели бизнес - роль руководителя и исполнителя. сервис бизнес программный

Рисунок 2.12: Бизнес - роль

·        Бизнес-сотрудничество.

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

Рисунок 2.13: Бизнес сотрудничество Notation

Бизнес-интерфейс.

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

Рисунок 2.14: Бизнес Интерфейс Notation

Местоположение

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

Рисунок 2.15: Расположение Notation

2.2.2 Поведенческие концепции бизнес-архитектуры

·        Бизнес-процесс

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

Рисунок 2.16: бизнес - процессов нотация

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

Рисунок 2.17: бизнес - процесс

Бизнес-функции

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

Рисунок 2.18: бизнес - функция Notation

Бизнес-взаимодействие. Бизнес-взаимодействие определяется как поведение элемента, который описывает поведение делового сотрудничества. Взаимодействие осуществляется в сотрудничестве с нескольких ролей. Роли в сотрудничестве разделяют ответственность за выполнение взаимодействия. Название бизнес-взаимодействия предпочтительно должно быть глаголом в настоящее время просто.

Рисунок 2.19: Бизнес Взаимодействие Notation

Бизнес-событие

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

Рисунок 2.20: Бизнес-событие

В приведенной ниже модели приказ о написании курсовой работы запускает бизнес-процесс «Проектирование курсовой работы».

Рисунок 2.21: Бизнес-собюытие

·        Бизнес-сервис

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

Рисунок 2.22: Бизнес-сервис

2.2.3 Пассивные элементы бизнес-архитектуры

·        Бизнес-объект

Бизнес-объекты представляют собой важные «информационные» или «концептуальные» элементы. Бизнес-объекты представляют собой реальные примеры информации, производимые и потребляемые элементами поведения. Бизнес-объекты являются пассивными в том смысле, что они не вызывают или выполняют процессы. Имя бизнес-объекта предпочтительно должно быть существительным.

Рисунок 2.23: Бизнес Обозначение объекта

Представление

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

Название представления предпочтительно должно быть существительным.

Рисунок 2.24: Представление нотация

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

Рисунок 2.25: Значение Обозначение

Важность

Важность определяется как относительная ценность, полезность, или важность бизнес-сервиса или продукта.

Рисунок 2.26: Значение Обозначение

Продукт

Продукт определяется как набор услуг, которые предлагаются клиентам.Название продукта, как правило, имя, которое используется в связи с клиентами.

Рисунок 2.27: Обозначение продукта

·        Ниже модель показывает продукт «курсовая работа», который разрабатывается в ходе бизнес-процесса «Проектирование курсовой работы».

Рисунок 2.28: Продукт

Договор

Договор определяется как договор в формальной или неформальной спецификации, который определяет права и обязанности, связанные с продуктом. Название контракта предпочтительно существительное.

Рисунок 2.29: Обозначение контракта

2.2.4 Краткое описание элементов бизнес-уровня

Таблица дает обзор концепций на бизнес-уровне с их определениями.

Таблица 2.1: Бизнес Layer Концепция

2.3 Архитектура приложений

На рисунке 2.30 приведен обзор концепций прикладного уровня и их отношений.

Рисунок 2.30: Применение слоя Метамодель [39]

2.3.1 Активные элементы архитектуры приложений

·        Компонент приложения

Компонент приложения определяется как модульная, разворачиваемая и заменяемая часть системы программного обеспечения, которая инкапсулирует свое поведение и данные, и выполняет их через набор интерфейсов. Имя компонента приложения предпочтительно должно быть существительным.

Рисунок 2.31: Применение компонентов Обозначение

В приведенной ниже модели, компоненты приложения RUNA отображаются как компоненты приложения для проектирования бизнес-процесса.

Рисунок 2.32: Компонент приложения

Сотрудничество приложений

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

Рисунок 2.33: Применение Collaboration Notation

Интерфейс приложения

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

Рисунок 2.34: Применение интерфейса Notation

2.3.2 Поведенческие концепции архитектуры приложений

·        Функция приложения

Функция приложения определяется как поведение элемента, которое может быть выполнено с помощью компонента приложения.

Рисунок 2.35: Применение функции Notation

Взаимодействие приложений

Взаимодействие приложений определяются как поведение элемента, который описывает поведение совместной работы приложений.

Рисунок 2.36: Применение Взаимодействие обозначений

Сервис приложений

Сервис приложений определеются как сервис, который предоставляет автоматизированное поведение.

Рисунок 2.37: Применение Обслуживание нотация

2.3.3 Пассивные элементы архитектуры приложений

·        Объект данных

Объект данных определяется как пассивный элемент, необходимый для автоматизированной обработки. Название объекта данных предпочтительно должно быть существительным.

Рисунок 2.38: Обозначение объекта данных

2.3.4 Краткое описание элементов уровня приложений

В таблице приведен обзор концепций на уровне приложений, с их определениями.

Таблица 2.2: Применение Layer Концепции

.4 Технологическая архитектура

На рисунке 2.39 приведен обзор концепций уровня технологий и их отношений.

Рисунок 2.39: Технология слоя Метамодель [39]

2.4.1 Элементы активной структуры

·        Узел

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

Рисунок 2.40: Узел Обозначение

Устройство

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

Рисунок 2.41: Обозначение устройства

Программное обеспечение системы

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

Рисунок 2.42: Системное программное обеспечение Notation

Интерфейс инфраструктуры

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

Рисунок 2.43: Инфраструктура интерфейс нотация

Сеть

Сеть определяется как коммуникационная среда между двумя или более устройствами. Сеть может состоять из подсетей.

Рисунок 2.44: Сеть нотации, как соединение и в коробке

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

Рисунок 2.45: Связь Путь нотации, как соединение и в коробке

2.4.2 Поведенческие концепции технологической архитектуры

·        Функция инфраструктуры

Функция инфраструктуры определяется как поведение элемента, которое может быть выполнено с помощью узла. Название функции инфраструктуры предпочтительно должно быть глаголом.

Рисунок 2.46: Инфраструктура Функция Notation

Сервис инфраструктуры

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

Рисунок 2.47: Инфраструктура Сервис нотация

2.4.3 Элементы пассивной структуры

·        Артефакты

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

Рисунок 2.48: Артефакт нотация

2.4.4 Краткое описание элементов уровня технологий

Таблица дает обзор концепций на технологической архитектуры с их определениями.

Таблица 2.3: Технологии Layer Концепции

2.5 Взаимосвязи между различными архитектурными слоями

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

На рисунке показаны отношения между бизнес-уровнем и уровнем приложений. Есть три основных типа отношений между этими слоями:

.Использование - отношение между сервисами приложений и различных типов элементов бизнес-поведения, а также между интерфейсом приложений и бизнес - роли. Эти отношения представляют поведенческие и структурные аспекты поддержки бизнеса с помощью приложений.

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

.Назначение - отношение между компонентами приложений и бизнес - процессов, функции или взаимодействия, а также между интерфейсом приложений и бизнес - сервером.

Рисунок 2.49: Взаимосвязь между бизнес - слоем и нижним слоем Концепцией [39]

Рисунок 2.50 показывает взаимосвязь между уровнем приложений и концепциями технологических слоев. Есть два типа отношений между этими слоями:

1.Использование - отношения между службой инфраструктуры и различными типами элементов поведения приложений, а также между интерфейсом инфраструктуры и компонентами приложения.

2.Реализация - отношения между артефактами и объектами данных, а также между артефактами и компонентами приложений.

Рисунок 2.50: Отношения между уровнем приложений и технологиями Layer Концепцией [39]

2.6 Отношения

2.6.1 Структурные отношения

·        Композиция

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

Рисунок 2.51: Состав нотация

Агрегация

Отношения агрегации указывает на отношения между целым и его частями.

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

Рисунок 2.52: Агрегация

Назначение

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

Рисунок 2.53: Назначение Обозначение

Реализация

Отношения реализации связывает логическую сущность с той, которая ее реализует.

Рисунок 2.54: Реализация нотация

Использование

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

Рисунок 2.55: Используется Notation

Доступ

Отношение доступа означает, что процесс, функция, взаимодействие, сервис, или событие «делает что - то» с объектом; например, создает новый объект, считывет данные из объекта, изменет данные объекта или удалет его.

Рисунок 2.56: Обозначение доступа

Ассоциация

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

Рисунок 2.57: Ассоциация Notation

2.6.2 Динамические отношения

·        Инициирование

Инициирование описывает временные или причинно-следственные связи между процессами, функциями, взаимодействиями и событиями.

Рисунок 2.58: Запуск нотация

Поток

Поток описывает обмен или передачу, например, информацию или значение между процессами, функцией, взаимодействием и событием.

Рисунок 2.59: Поток Обозначение

2.6.3 Другие отношения

·        Группировка

Группировка указывает на то, что объекты связаны друг с другом на основе некоторой общей характеристике. В отличие от других концепций языка, группировка не имеет формальной семантики. Он используется только, чтобы показать графически, что элементы модели имеют нечто общее.

Рисунок 2.60: Группировка нотация

Соединение

Соединение используется для подключения динамических отношений одного и того же типа.

Рисунок 2.61: Соединительная нотация

Специализация

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

Рисунок 2.62: Специализация нотация

2.6.4 Краткое описание отношений

Таблица дает обзор отношений в ArchiMate с их определениями.

Таблица 2.4: Отношения

2.7 Расширение. Мотивация

На рисунке 2.63 показана метамодель мотивационных понятий. Она включает в себя фактические мотивы и намерения - то есть, цели, принципы, требования и ограничения, - и источники этих намерений; т.е., заинтересованные стороны, драйверы и оценки.

Мотивационные элементы связаны с основными элементами через требование или ограничение концепции.

Рисунок 2.63: мотивация выдвижения Метамодель [39]

2.7.1 Мотивационные концепции

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

·        Заинтересованная сторона

Заинтересованная сторона определяется как роль личности, команды или организации (или их классы), которая представляет их интересы при моделировании архитектуры предприятия.

Это определение основано на определении в TOGAF. Заинтересованная сторона имеет один или более интересов.

Рисунок 2.64 Обозначение заинтересованных сторон

·        Драйвер

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

Рисунок 2.65: Драйвер Notation

Оценка

Оценка определяется как исход какого - либо анализа некоторого водителя.

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

Название оценки предпочтительно должно быть существительным или (очень) коротким предложением.

Рисунок 2.66: Оценка нотация

Цель

Цель определяется как конечное состояние, это то, что заинтересованное лицо намерено добиться .

Рисунок 2.67: Цель нотация

·        Требования

Требование определяется как заявление о необходимости, которая должна быть реализована с помощью системы.

Рисунок 2.68: Требование Обозначения

Ограничение

Ограничение это определяется как ограничение на пути, в котором реализуется система.

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

Рисунок 2.69: Ограничение нотация

Принцип

Принцип определяется как нормативное свойство всех систем в данном контексте, или способ, в котором они реализуются.

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

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

Рисунок 2.70: Принцип нотация

2.7.2 Краткое описание мотивационных концепций

Таблица дает обзор мотивационных концепций, с их определениями.

Таблица 2.5: Мотивационные Концепции

2.8 Расширение миграция

2.8.1 Концепции расширения миграции

·        Рабочий пакет

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

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

Рисунок 2.71: Рабочий пакет Notation

Поставка

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

Поставка определяется как точно определенный результат пакета работ.

Рисунок 2.72: Поставка

Плато

Важной предпосылкой в TOGAF является то, что различные архитектуры описаны для различных этапов. В каждой из фаз B, C, и D от ADM, базовая архитектура и целевая архитектура созданы, описывающая текущую ситуацию и желаемый будущую ситуацию. В фазе Е (возможности и решение), так называемые переходные архитектуры определены, показывающее предприятие в дополнительных состояниях, отражающих периоды перехода между базовым и целевыми архитектурами. Переходные архитектуры используются для обеспечения отдельных пакетов работ и проектов, которые будут сгруппированы в управляемые портфели и программы, иллюстрирующие стоимость бизнеса на каждом этапе.

Для того, чтобы поддержать это, мы вводим плато понятие.

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

Рисунок 2.73: Плато Notation

Рисунок 2.74

Разрыв

Разрыв является важным результатом анализа пробелов в фазах B, C и D в TOGAF ADM, и образует важный вклад для последующего осуществления и планирования миграции. Концепция разрыва связана с два плато (например, базовых и целевые архитектуры, или два последующих переход архитектур), и представляет собой разницу между этим плато.

Разрыв определяется как исход анализа пробелов между двумя плато.

Рисунок 2.75: Разрыв нотация

2.8.2 Обзор реализации и миграции Концепции

Таблица 2.6 дает обзор реализации и миграции концепций, с их определениями.

Таблица 2.6: Реализация и миграция Концепция

2.9 Инструменты реализации языка ArchiMate в программном средстве Archi

Проектирование архитектуры предприятия предполагает необходимость определения, изучения и формализации всех различных аспектов деятельности предприятия. Также обязательно нужно учитывать различные точки зрения на архитектуру и интересы заинтересованных сторон. При разработке архитектуры одним из важных шагов является выстраивание механизмов взаимодействия постоянно меняющихся требований бизнеса и информационных технологий для поддержания требований и задач, которые также постоянно развиваются.Чтобы грамотно моделировать архитектуру и управлять ей применяются различные инструме нты разработки архитектуры предприятия [41].

В открытом доступе отсутствуют русскоязычные публикации, в которых рассмотрены функциональные возможности программного средства Archi 3.

Программное средство Archi - это бесплатный инструмент с открытым кодом для проектирования архитектуры предприятия на всех уровнях (бизнес-архитектура, архитектура приложений и ИТ-инфраструктура) в терминах языка ArchiMate.разработан и является зарегистрированной торговой маркой Филиппа Бовуара (Phillip Beauvoir) и доступен для скачивания на сайте производителя [42].

Основа инструмента Archi - это язык ArchiMate. ArchiMate - стандарт языка моделирования архитектуры предприятия с открытым исходным кодом, разрабатываемый консорциумом Open Group. Язык ArchiMate полностью согласован с моделью архитектуры предприятия TOGAF, также поддерживаемой консорциумом Open Group. ArchiMate поддерживает описание, анализ и визуализацию архитектуры предприятия на различных уровнях. Согласно требованиям языка ArchiMate модель архитектуры предприятия в Archi определена для трех основных уровней: уровня бизнеса, уровня приложений и уровня технологий, и двух дополнительных уровнях, называемых расширениями (мотивация и миграция).

Рабочее пространство в инструменте Archi разделено на 8 окон:

Главное окно, необходимо для просмотра и редактирования диаграмм;

Дерево моделей (Models), необходимо для отображения всех спроектированных моделей архитектуры,

Свойства (Properties) отображает все существующие свойства и параметры выбранного элемента модели;

Схема (Outline) позволяет просматривать ArchiMate-диаграммы в уменьшенном масштабе, это необходимо для удобства просмотра больших диаграмм и навигации по ним;

Навигатор (Navigator) отображает выбранные элементы построенной модели и все их связи с другими элементами модели, используется для навигации между связанными элементами модели через существующие связи;

Палитра (Palette) - набор графических образов элементов языка ArchiMate для построения диаграмм

Визуализатор (Visualiser) позволяет просматривать все выбранные элементы модели и все их связи с другими элементами в графическом виде, эквивалент окно Навигатор;

Подсказки (Hints) содержит подсказку для типа объекта, выбранного в окнах Дерево моделей и Палитра

Рисунок 2.76

В Archi 3 имеется две встроенные подсказки: «Create a Map View» и «Create a New Model». Предполагается, что в дальнейших версиях все процедуры процесса моделирования архитектуры будут сопровождаться пошаговыми интерактивными инструкциями.

Модель архитектуры предприятия в Archi отображается в форме древовидной структуры (Model Tree, Дерево модели) элементов, сгруппированных в папки, представленной на рисунке и в таблице.

Рисунок 2.77 - Структура папок верхнего уровня модели архитектуры в Archi

Таблица 2.7 - Назначение папок верхнего уровня в Archi

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

Все элементы созданной в Archi модели архитектуры предприятия и связей между ними могут быть представлены графически с помощью одного или нескольких представлений (View). Архитекторы и другие заинтересованные стороны (stakeholders) могут создавать собственные представления архитектуры предприятия. Archi позволяет определять точки зрения (Viewpoints), которые позволяют отразить подмножество элементов и отношений между ними. Инструмент поддерживает 26 точек зрения [43].

Для генерации отчетов Archi использует специализированное средство Jasper Reports, Archi может экспортировать созданные модели архитектуры предприятия в различные форматы: HTML, RTF, PPTX, PDF, DOCX, ODT, используя шаблоны Jasper Reports. В режиме моделирования Archi позволяет распечатать лишь открытую диаграмму. Наличие встроенных примеров моделей архитектуры предприятия, различные контекстные подсказки и инструкции и открытая спецификация архитектурного языка ArchiMate позволяют новичку в моделировании с легкостью разобраться в инструменте и делают инструмент Archi незаменимым для обучения моделированию. архитектуры. Такжесуществование открытого исходного кода позволяет применять программный продукт в организациях. Его можно дорабатывать и улучшать.

3. Применение архитектурного языка для моделирования сервис-ориентированной архитектуры предприятия

3.1 Описание алгоритма

Ниже представлен алгоритм построения архитектурной модели на языке ArchiMate в программном средстве Archi для BPMS-системы.

.        Сбор и анализ сведений для построения перспективы управления.

.        Определить состояние зрелости бизнес-процессов организации.

.        Если в организации не идентифицированы и не регламентированы бизнес-процессы, то выполнить описание бизнес-процессов (словесное, IDEF0, eEPC и тд.) .

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

.        Выполнить сбор и анализ исходных данных для построения перспективы ресурсов.

.        Если в организации реализовано только функциональное управление, то описать иерархическую организационную структуру на языке ArchiMate.

.        Выполнить сбор и анализ данных о сквозных процессах организации.

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

.        Построить матрицу связности (какие роли на какие операции назначаются).

.        Назначить владельца каждого бизнес-процесса.

.        Собрать информацию и построить модель данных для всех бизнес-процессов.

.        Выполнить сбор и анализ данных для перспективы операций (портал).

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

.        Построить матрицу связности функций существующих приложений с операциями перспективы управления.

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

.        Построить матрицу связности функций и операций.

.        Выполнить дизайн пользовательских форм.

.        Выполнить описание видов в программном средстве Archi.

Выполение описания видов:

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

.        Выполнить анализ словесного описания.

.        Подобрать метамодель ArchiMate, которую можно применить для описания данной ситуации.

.        Выполнить построение вида.

.        Показать вид заинтересованным лица для его уточнения. Исправить ошибки.

Рисунок 3.1

Чтобы правильно спроектировать архитектурную модель организации необходимо сначала проанализировать предметную область, затем построить модель в ArchiMate и только потом моделировать бизнес-процессы организации. Завершающий этап настройки - запуск бизнес-модели в Runa WFT.

Заключение

В ходе выполнения работы рассмотрена архитектура BPMS (компоненты системы); изучены существующие методики и языки построения архитектуры BPMS; выполнен сравнительный анализ существующих методик проектирования системной архитектуры и выбрана нотация BPMN; с помощью метода анализа иерархии выбрана методика TOGAF наиболее подходящая для проектирования архитектуры приложений. Изучен и описан синтаксис языка ArchiMate, описаны инструменты реализации языка ArchiMate в программном средстве Archi; разработан алгоритм построения архитектурной модели на языке ArchiMate в программном средстве Archi для построения BPMS-системы и исследованы методы верификации модели.

Результатом работы является алгоритм построения архитектурной модели на языке ArchiMate в программном средстве Archi для BPMS-системы. Результат методики: архитектура BPMS c разработкой перспективы управления, перспективы ресурсов, перспективы операций.

Некоторые результаты исследования были представлены на следующих конференциях:

•        на всероссийской научно-практической конференции молодых ученых с международным участием «Математика и междисциплинарные исследования - 2016», посвященной 100-летию Пермского государственного национального исследовательского университета (диплом II степени)

•        на VII студенческой конференции «Информационные технологии - фактор успеха в бизнесе» НИУ ВШЭ - Пермь (доклад является победителем в секции «Технологии, методы и инструментальные средства программной инженерии и бизнес-информатики»).

В дальнейшем планируется доработка и детализация разработанной методики и программная реализация модели с помощью системы Runa WFE.