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

Вид работы:

Курсовая работа (т)
Предмет:

Информационное обеспечение, программирование
Язык:

Русский
,
Формат файла:
MS Word

1,47 Мб
Опубликовано:

2017-08-25

Все курсовые работы по информационному обеспечению

Скачать курсовую работу Читать текст online Заказать курсовую
*Помощь в написании! Посмотреть все курсовые работы

Вы можете узнать стоимость помощи в написании студенческой работы.

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

Введение

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

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

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

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

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

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

• Объект: автоматизация управления бизнес-процессами.

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

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

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

Задачи работы:

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

• рассмотреть архитектуру BPMS (компоненты и связи), сервис - ориентированную архитектуру и архитектуру, управляемую моделями. Определить место в архитектуре предприятия;

• сравнить существующие методики и языки построения архитектуры BPMS;

• выделить основные методики проектирования архитектуры предприятия;

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

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

• рассмотреть и описать синтаксис языка ArchiMate;

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

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

• исследовать методы верификации модели.

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

Структура работы.

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

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

Во второй главе представлено описание синтаксиса языка ArchiMate, описаны инструменты реализации языка ArchiMate в программном средстве Archi Описаны несколько примеров.

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

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

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

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

.1 Функциональный и процессный подходы

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

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

Далее подробнее рассмотрим концепции как функционального подхода к управлению, так и процессного.

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

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

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

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

Для большинства современных предприятий характерна сложная организационная структура, когда ответственность за конечный продукт разделяется между несколькими структурными единицами компании. В таком случае ярко выражены преимущества процессного подхода, особенно для предприятий, бизнес-процессы которых часто приходится менять из-за изменений требований рынка с высоким уровнем конкуренции [3].

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

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

В условиях современного развивающегося рынка и конкуренции намного эффективнее и целесообразнее использовать процессный подход к управлению. Его основными достоинствами являются прозрачность, ориентированность команды на положительный результат и гибкость системы управления. Несмотря на различия подходов к управлению организацией, они не являются полным противопоставлением друг другу. При применении сразу двух подходов компания будет иметь систему взаимосвязанных процессов, объединяющих похожие функции в рамках различных бизнес-процессов. Для достижения наилучших результатов предприятию целесообразней использовать эти подходы параллельно [5].

1.2 Анализ понятия архитектура предприятия. Определение границ системной архитектуры

На данный момент информационные технологии являются базой в управлении любым предприятием. С их помощью можно повысить эффективность каждого бизнеса, их использование позволяет автоматизировать многие сложные операции и бизнес-процессы организации, сократить время, затрачиваемое на них и снизить стоимость [22]. Но новые возможности часто вызывают новые трудности, многие из которых и связаны со сложностью разработки единой системы управления разнородной архитектурой предприятия. Часто подобные проблемы вызываются двумя аспектами: на предприятии существуют несколько информационных систем, созданных и внедренных разными компаниями, а также жизненный цикл вырабатываемого продукта и внешние изменения рынка требуют адаптации структуры предприятия к новым условиям в короткие сроки [7]. Эффективным инструментом, помогающим в решении проблем с адаптацией бизнеса к новым условиям рынка и осуществляющим организационные изменения в компаниях различных областей с использованием ИТ, и стала архитектура предприятия. Единая архитектура предприятия позволяет корректировать бизнес-процессы компании без потери времени, так, чтобы все изменения незамедлительно отражались в работе управляющей системы [6].

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

Самое простое из множества определений термина «архитектура предприятия» (АП) можно получить, применяя термин «архитектура» к системе «предприятие»: «Архитектура предприятия - это способ понимания всех различных элементов, из которых состоит предприятие, и того, как эти элементы взаимосвязаны. Элементы включают в себя людей, процессы, бизнес и технологии» [18].

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

Согласно стандарту ISO 15704 «архитектура предприятия должна включать роль людей, описание процессов (функции и поведение) и представление всех вспомогательных технологий на протяжении всего жизненного цикла предприятия» [21].

Архитектура определяется как стратегическая информационная основой, включающая в себя следующие части:

• структуру бизнеса;

• информацию, необходимую для ведения бизнеса;

• технологии и программные средства, применяемые для поддержания и реализации бизнес-процессов компании;

• процессы адаптации к изменениям условий рынка, реализацией новых процессов производства и внедрением новых технологий в ответ на появление новых, бизнес-потребностей [31].

Наиболее часто архитектуру предприятия изображают в виде нескольких слоев. Верхний слой - бизнесы-процессы организации, следующий слой - сервисы, данные/информация, прикладные системы, инфраструктура и связь [26]. Достаточно часто выделяют три следующих слоя: миссия и стратегия организации, бизнес-архитектура (которая разделяется на ресурсы, бизнес-процессы и корпоративные стандарты) и ИТ-архитектура (которая состоит из программных систем, данных и инфраструктуры) [15].

В американской федеральной модели FEA выделяются пять моделей-уровней: справочная модель оценки результативности (Performance Reference Model, PRM), справочная модель бизнеса (Business Reference Model, BRM), справочная модель сервисных компонентов (Service Component Reference Model, SRM), справочная модель данных (Data Reference Model, DRM), техническая справочная модель (Technical Reference Model, TRM)[27,28,31]. Однако довольно быстро определилось, что связь между слоями не иерархическая и строение архитектуры должно быть усложнено. Так появились: матрица Захмана, пирамида CIO Council, параллелограмм GERAM (Generalized Enterprise Reference Architecture and Methodology) и девятицветник TOGAF (The Open Group Architecture Framework).

На рисунке 1.1 представлена структура архитектуры предприятия.

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

· миссия и стратегия организации;

· ее цели и задачи;

· бизнес-архитектура;

· системная архитектура [15,16].

Далее немного подробнее рассмотрим каждый компонент архитектуры.

Корпоративные миссия и стратегия описывают основные направления будущего развития предприятия и ставят цели и задачи на долгосрочный период.

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

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

Архитектура приложений включает в себя:

• прикладные системы и программные средства, поддерживающие реализацию бизнес-процессов компании;

• интерфейсы взаимодействия прикладных систем между собой и с внешними системами или теми, кто использует данные;

• средства и методы разработки и сопровождения приложений[5].

Архитектура данных включает:

· базы данных и хранилища данных;

· различные системы управления базами данных или хранилищами данных;

· правила и средства доступа к данным [10].

Техническая архитектура состоит из сетевой архитектуры и архитектуры платформ. Сетевая архитектура состоит из [5]:

• локальных и территориальных вычислительных сетей;

• коммуникационных протоколов, различных сервисов и системы адресации;

• аварийныех планов по обеспечению бесперебойной работы сетей в условиях чрезвычайных обстоятельств.

Архитектура платформ включает:

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

• операционные и управляющие системы, утилиты и офисные программные системы;

• аварийные планы по обеспечению бесперебойной работы аппаратуры (главным образом - серверов) и баз данных в условиях чрезвычайных обстоятельств [15,16].

.3 Структура BPMS-системы

Организации, которые хотят получить наибольшую выгоду от процессного подхода, применяют специальные технические средства управления бизнес-процессом, называемые системами для управления бизнес-процессами (Business Process Management Systems). Этот термин обозначает информационную технологию, обеспечивающую генерацию исполняемой модели процесса непосредственно из графической модели бизнес-процесса. Системы управления бизнес-процессами относятся к классу процессно-ориентрированных систем [19].

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

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

Отличительная особенность системы управляемой моделью заключается в том, что их разработка ведется в терминах предметной области, а не используемой среды, так что разработчик оказывается защищенным от сложностей программирования. В процессно-ориентированных системах под моделью понимают графическое описание последовательности работ, выполняемых участниками. Созданием модели может заниматься даже бизнес-аналитик, не обладающий знаниями и навыками программирования. Разработанная модель преобразуется в исполняемый машинный формат. Если далее понадобится внести какие-либо изменение в логику работы системы, то модификации подвергается непосредственно исходная модель. Таким образом, в системе, управляемой моделью, именно визуальная модель является «исходным текстом программы», она и определяет логику работы проектируемой информационной системы.

Системы управления бизнес-процессами (BPMS - Business Process Management System) являются одновременно процессно-ориентированными и управляемыми моделью. Они предназначены для организации эффективного взаимодействия всех участников процесса, помогают менеджеру процесса преодолеть результаты отклонений, возникающих в ходе исполнения процесса, а также позволяют контролировать выполнение заданий по времени и качеству. Логика работы таких систем полностью основывается на исполняемой визуальной модели бизнес-процесса, а изменение логики работы осуществляется через модель процесса. Современная технология управления бизнес-процессами на базе BPM - это совокупность управленческих методологий и информационных технологий. Под управленческой методологией мы будем понимать управление предприятием с помощью бизнес-процессов. При этом вся деятельность предприятия рассматривается как совокупность взаимодействующих бизнес-процессов. Обычно, процессное управление сводится к их идентификации, стандартизации, реинжинирингу и регламентации бизнес-процессов компании. В нашем случае реинжиниринг, который изначально ориентирован на однократное радикальное преобразование бизнес-процессов компании, заменяется на постоянную целенаправленную деятельность по контролю и управлению бизнес-процессами. Суть технологии заключается в том, что непосредственно из модели бизнес-процесса, созданной с использованием стандартной для отрасли нотации моделирования бизнес- процессов BPMN, генерируется исполняемая на компьютере модель, которая позволяет выполнять операции бизнес-процесса по всей цепочке в автоматизированном режиме, отслеживать отклонения, предлагать решения по их устранению. Благодаря тому, что за основу берется графическая, интуитивно понятная пользователю модель бизнес-процесса, центр тяжести в разработке перемещается с программиста на бизнес-аналитика. При необходимости внести изменения в порядок исполнения бизнес-процесса, соответствующие коррекции проводятся аналитиком непосредственно в модели процесса. Таким образом, бизнес-аналитик получает средство разрабатывать средства автоматизации бизнес-процессов с минимальным привлечением программистов [6].

Составные части BPMS-системы:

• Веб-сервис (внешний).

• Портал организации.

• Бизнес-сервера.

• Персонал (ресурсы).

• Модели бизнес-процессов.

• Редактор описания модели бизнес-процессов (редактор веб-страниц).

Для некоторых бизнес-процессов (административных регламентов), которые могут быть выполнены в компьютерной среде, необходимо дать определение, такое, которое можно было легко перевести в представление, понимаемое компьютером [17].

Дадим определение исполнимого бизнес-процесса, основу которого составляют идеи С. Яблонского и С. Бусcлера. Исполнимый бизнес-процесс определяется при помощи задания следующих перспектив:

• перспектива управления потоком (схема бизнес-процесса);

• перспектива ресурсов (исполнители, стоимость работ, длительность…);

• перспектива данных (внутренние переменные бизнес-процесса);

• перспектива операций (список элементарных действий, совершаемых исполнителями, ручные и автоматические задачи, портал, веб-сервер - бот).

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

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

Перспектива потока управления представляет собой схему бизнес-процесса. Схема бизнес-процесса состоит из направленного графа дополнительных конструкций. Узлы бизнес-процесса могут быть трех типов - узлы, соответствующие шагам процесса, маршрутные узлы и комбинированные узлы, представляющие собой слияние шага процесса с одним или несколькими маршрутными узлами [7].

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

Перспективе ресурсов бизнес-процесса соответствует набор исполнителей, которые могут выполнять его узлы-действия. Исполнителями могут быть как сотрудники предприятия, так и информационные системы или специализированные устройства [7].

В бизнес-процессе производится связывание узлов-действий с исполнителями заданий при помощи ролей. При разработке бизнес-процесса создается роль и ставится в соответствие определенным узлам-действиям. Во время выполнения бизнес-процесса ролям назначаются конкретные исполнители. В узле-действии бизнес-процесса может быть сразу несколько возможных исполнителей роли[8].

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

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

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

В таблице 1.1. представлено соответствие различных перспектив составным частям BPMS-системы [8].

Таблица 1.1. Соответствие перспектив и составных частей BPMS-системы

Перспектива	Часть BPMS-системы
Перспектива управления	Бизнес-сервера, модели бизнес-процессов
Перспектива ресурсов	Персонал
Перспектива данных	Данные
Перспектива операций	Портал, веб-сервис, редакторы

1.4 Существующие методики и языки построения арихитектуры BPMS

Существует несколько способов описания бизнес-процессов, для этих целей используются различные языки и нотации. Рассмотрим некоторые из них:(язык исполнения бизнес-процессов, Business Process Execution Language) - индустриальный стандарт, описания выполняемых ориентированных на интеграцию моделей процессов. Выполнение бизнес-функций осуществляется путем вызова соответствующих веб-служб. Нотация не поддерживает визуальное моделирование бизнес-процессов. BPEL - язык на основе XML для формального описания бизнес-процессов и протоколов их взаимодействия между собой. BPEL расширяет модель взаимодействия веб-служб и включает в эту модель поддержку транзакций.(графическая нотация и модель бизнес-процессов, Business Process Modeling Notation) - индустриальный стандарт визуального описания исполняемых моделей процессов, ориентированных на интерактивное взаимодействие с участниками. Используется в большинстве систем BPMS в качестве основного средства для графического моделирования, имеет техническую реализацию, то есть модель может быть интерпретирована в исполняемый программный код. Спецификация BPMN описывает условные обозначения для отображения бизнес-процессов в виде диаграмм бизнес-процессов. BPMN ориентирована как на технических специалистов, так и на бизнес-пользователей. Для этого язык использует базовый набор интуитивно понятных элементов, которые позволяют определять сложные семантические конструкции. Основная цель BPMN - создание стандартного набора условных обозначений, понятных всем бизнес-пользователям. Бизнес-пользователи включают в себя бизнес-аналитиков, создающих и улучшающих процессы, технических разработчиков, ответственных за реализацию процессов и менеджеров, следящих за процессами и управляющих ими. BPMN является связующим звеном между фазой дизайна бизнес-процесса и фазой его реализации.(ориентированная на событие цепочка процессов, Event-driven Process Chains) - проприета́рная нотация описания бизнес-процессов. Широко используется для документирования рабочих процессов.(унифицированный язык моделирования, Unified Modeling Language) - язык графического описания для объектного моделирования в области разработки программного обеспечения. Язык широкого профиля. Это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы. UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но на основании UML-моделей возможна генерация программного кода.(язык описания веб-служб и доступа к ним, основанный на языке XML, Web Services Description Language) служит для описания интерфейсов веб-служб, используется для моделирования доступных операций, включая адреса их вызова.(Process Definition Language, язык описания процессов) - язык, предназначенный для описания определений и реализаций процессов. Является техническим стандартом, используемым для хранения, исполнения и переноса моделей бизнес-процесса между различными BPMS средствами. XPDL предназначен для обмена определениями процессов между различными информационными системами, как в графическом так и в семантическом виде.(язык описания структуры XML-документа, XML Schema Definition) -стандарт описания данных, которыми пользуются и обмениваются бизнес-процессы и веб-службы. Такая система состоит из спецификации новых элементов XML, их атрибутов, а также их производных элементов.

Существует несколько конкурирующих стандартов для моделирования бизнес-процессов. Проанализировав основные из них, можно сделать вывод, большинство рассмотреных языков и нотаций не позволяют описывать одновременно внутри- и межорганизационные процессы. Поэтому BPMN является более универсальным и полностью соответствует специфике выполняемых задач. Распространение BPMN поможет унифицировать способы представления базовых концепций бизнес-процессов, а также более сложные концепции [10].

1.5 Анализ существующих методик и обоснование выбора наиболее удобной методики проектирования архитектуры приложений и ИТ-инфраструктуры

В литературе широко описаны следующие методологии построения архитектуры предприятия:

· модель Захмана [11,12,13];

· TOGAF [18];

· методология Gartner [4,8];

· FEA;

· DoDAF и т.д.

Но, несмотря на существование большого количества различных методик по созданию архитектуры, ни одна из них не имеет доминирующего положения на рынке[15,16]. Процесс построения архитектуры предприятия - циклический процесс, и это не зависит от выбранной методики проектирования. Необходимо также понимать, что управление предприятием - это и есть управление архитектурой предприятия в контексте достижения наибольшей эффективности его функционирования [8,9].

Существующие ведущие методологии проектирования архитектуры предприятия достаточно сильно отличаются друг от друга. Проанализировав ГОСТы по проектированию архитектуры предприятия, были выделены требования для проектирования системной архитектуры (архитектуры приложений и системной инфраструктуры) [20,21].

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

· детальное и полное построение модели;

· понятность и простота создания модели;

· ориентированность на эталонные модели;

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

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

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

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

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

· окупаемость;

· стоимость проектирования [14].

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

«Понятность и простота создания модели» показывает, полноту описания действий в методологии при создании архитектуры предприятия по шагам. На этом сосредоточена методология TOGAF, а именно представленная методика (ADM).

«Ориентированность на эталонные модели» выражает степень полезности методологии в создании набора эталонных моделей.

«Эффективность использования и адаптация» определяет уровень воплощения представления об архитектуре предприятия. На этом сосредоточена методология Gartner.

«Ориентированность на снижение затрат организации» демонстрирует, ориентирована ли методология на бизнес-цели.

«Структурная и функциональная декомпозиция» показывает полезность методологии в эффективном разбиении предприятия на отделы.

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

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

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

«Стоимость проектирования» определяет стоимость процесса проектирования архитектуры предприятия.

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

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

Для того чтобы провести сравнительный анализ, необходимо разработать систему оценки методик. Для обоснования оценки критериев воспользуемся методом анализа иерархии. Для оценки соответствия возможностей методологии критерию будем использовать шкалу Саати. Для того чтобы сравнить степень проявления признака в методологии используем следующие оценки (таблица 1.2):

Таблица 1.2. Шкала оценки Саати

1	- равноценность
3	- умеренное превосходство
5	- сильное превосходство
7	- очень сильное превосходство
9	- высшее (крайнее) превосходство

Используем четные числа для определения промежуточных степеней. Чтобы минимизировать ошибку, рассчитываем оценку согласованности для каждой матрицы. Главное достоинство процедуры - веса критериев и оценки по субъективным критериям не назначаются прямым волевым методом, а рассчитываются с помощью формул, поэтому такой анализ позволит получить более точные результаты. Сначала проведем сравнение критериев между собой, для того чтобы определить ценность каждого критерия. Затем относительно каждого критерия будем сравнивать альтернативы, для оценки соответствия каждой методологии каждому критерию. Таким образом, сравнения значимости критериев, были выявлены следующие результаты. В таблице 1.3 указаны итоговые приоритеты по критериям. В таблице 1.4 представлен расчет оценки согласованности матрицы парных сравнений для критериев.

Таблица 1.3. Приоритеты критериев

Критерий	Приоритет
Полнота модели	12,18%
Простота создания модели	9,15%
Эталонные модели	2,24%
Эффективность использования и адаптация	6,91%
Ориентировка на снижение затрат в организации	17,29%
Разбиение предприятия на отделы	3,34%
Нет привязки к поставщику услуг	3,07%
Доступность информации о методологии	3,20%
Окупаемость	20,17%
Стоимость проектирования	22,45%

Далее приведены таблицы сравнения альтернатив по каждому критерию (см.таблица 1.5).

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

L=	11,32
ИС=	0,15
ОС=	9,87%
n=	10
ИС случ=	1,49

Далее проводя сравнение 4 выбранных методик по каждому критерию, получим 10 матриц парных сравнений (см. таблицы 1.6 - 1.25).

Для каждой матрицы посчитаем оценку согласованности матриц, чтобы уменьшить ошибки в матрице и избежать рассогласованности оценок. Согласованности матриц колеблются от 0,08% до 7,04% . В МАИ считается, что нормальный процент ошибки в матрицапх парных сравнений от 1 до 10%, от 11 до 20% - приемлемый. Если же процент ошибки больше 20%, то лучше перепроверить результаты [22].

Таблица 1.5. Сравнение критериев для выбора методики проектирования

Выбор методики проектирования	Полнота модели	Простота создания модели	Эталонные модели	Эффективность использования и адаптация	Ориентировка на снижение затрат в организации	Структурная и функциональная декомпозиция	Независимость от рынка поставщиков услуг	Доступность информации о методологии	Окупаемость	Стоимость проектирования	Среднее геометрическое	Приоритеты
Полнота модели	1	2	3	4	1/2	3	6	9	1/3	1/4	1,66	0,12
Простота создания модели	1/2	1	4	2	1/3	5	4	7	1/4	1/5	1,25	0,09
Эталонные модели	1/3	1/4	1	1/3	1/5	1/2	1/2	1/4	1/7	1/7	0,31	0,02
Эффективность использования и адаптация	1/4	1/2	3	1	1/2	3	2	3	1/2	1/3	0,94	0,07
Ориентировка на снижение затрат в организации	2	3	5	2	1	6	5	3	2	1/2	2,36	0,17
Структурная и функциональная декомпозиция	1/3	1/5	2	1/3	1/6	1	4	1/3	1/5	1/5	0,46	0,03
Независимость от рынка поставщиков услуг	1/6	1/4	2	1/2	1/5	1/4	1	2	1/5	1/5	0,42	0,03
Доступность информации о методологии	1/9	1/7	4	1/3	3	1/2	1	1/6	1/7	0,44	0,03
Окупаемость	3	4	7	2	1/2	5	5	6	1	2	2,76	0,20
Стоимость проектирования	4	5	7	3	2	5	5	7	1/2	1	3,07	0,22
Сумма	11 2/3	16 1/3	38	15 1/2	5 3/4	31 3/4	33	38 4/7	5 2/7	5

Таблица 1.6. Матрица парных сравнений альтернатив для критерия «Полнота модели»

Полнота модели
	Модель Захмана	TOGAF	FEA	Gartner	среднее геометрическое	приоритеты
Модель Захмана	1	3	7	9	3,71	0,59
TOGAF	1/3	1	4	7	1,75	0,28
FEA	1/7	1/4	1	2	0,52	0,08
Gartner	1/9	1/7	1/2	1	0,30	0,05
сумма	1,59	4,39	12,50	19,00
				итого	6,27	1

Таблица 1.7. Расчет оценки согласованности матрицы парных сравнений для критерия «Полнота модели»

L=	4,10
ИС=	0,03
ОС=	3,62%
n=	4
ИС случ=	0,9

Таблица 1.8. Матрица парных сравнений альтернатив для критерия «Простота создания модели»

Простота создания модели
	Модель Захмана	TOGAF	FEA	Gartner	среднее геометрическое	приоритеты
Модель Захмана	1	1/5	3	2	1,05	0,17
TOGAF	5	1	8	6	3,94	0,65
FEA	1/3	1/8	1	1/4	0,32	0,05
Gartner	1/2	1/6	4	1	0,76	0,13
сумма	6,83	1,49	16,00	9,25
				итого	6,06	1,00

Таблица 1.9.. Расчет оценки согласованности матрицы парных сравнений для критерия «Простота создания модели»

L=	4,15
ИС=	0,05
ОС=	5,59%
n=	4
ИС случ=	0,9

Таблица 1.10. Матрица парных сравнений альтернатив для критерия «Эталонные модели»

Эталонные модели
	Модель Захмана	TOGAF	FEA	Gartner	среднее геометрическое	приоритеты
Модель Захмана	1	1/3	1/8	2	0,54	0,09
TOGAF	3	1	1/4	5	1,39	0,23
FEA	8	4	1	6	3,72	0,62
Gartner	1/2	1/5	1/6	1	0,36	0,06
сумма	12,50	5,53	1,54	14,00
				итого	6,01	1,00

Таблица 1.11. Расчет оценки согласованности матрицы парных сравнений для критерия «Эталонные модели»

L=	4,19
ИС=	0,06
ОС=	7,04%
n=	4
ИС случ=	0,9

Таблица 1.12. Матрица парных сравнений альтернатив для критерия «Эффективность использования и адаптация»

Эффективность использования и адаптация
	Модель Захмана	TOGAF	FEA	Gartner	среднее геометрическое	приоритеты
Модель Захмана	1	1/2	1/8	1/2	0,42	0,07
TOGAF	2	1	1/5	2	0,95	0,16
FEA	8	5	1	5	3,76	0,65
Gartner	2	1/2	1/5	1	0,67	0,12
сумма	13,00	7,00	1,53	8,50
				итого	5,80	1,00

Таблица 1.13. Расчет оценки согласованности матрицы парных сравнений для критерия «Эффективность использования и адаптация»

L=	4,06
ИС=	0,02
ОС=	2,06%
n=	4
ИС случ=	0,9

Таблица 1.14. Матрица парных сравнений альтернатив для критерия «Ориентировка на снижение затрат в организации»

Ориентировка на снижение затрат в организации
	Модель Захмана	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

Таблица 1.15. Расчет оценки согласованности матрицы парных сравнений для критерия «Ориентировка на снижение затрат в организации»

L=	4,17
ИС=	0,06
ОС=	6,2%
n=	4
ИС случ=	0,9

Таблица 1.16. Матрица парных сравнений альтернатив для критерия «Структурная и функциональная декомпозиция»

Структурная и функциональная декомпозиция
	Модель Захмана	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

Таблица 1.17. Расчет оценки согласованности матрицы парных сравнений для критерия «Структурная и функциональная декомпозиция»

L=	4,05
ИС=	0,02
ОС=	1,92%
n=	4
ИС случ=	0,9

Таблица 1.18. Матрица парных сравнений альтернатив для критерия «Независимость от поставщика услуг»

Независимость от поставщика услуг
	Модель Захмана	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

Таблица 1.19. Расчет оценки согласованности матрицы парных сравнений для критерия «Независимость от поставщика услуг»

L=	4,02
ИС=	0,01
ОС=	0,57%
n=	4
ИС случ=	0,9

Таблица 1.20. Матрица парных сравнений альтернатив для критерия «Доступность информации о методологии»

Доступность информации о методологии
	Модель Захмана	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

Таблица 1.21. Расчет оценки согласованности матрицы парных сравнений для критерия «Доступность информации о методологии»

L=	4,06
ИС=	0,02
ОС=	2,38%
n=	4
ИС случ=	0,9

Таблица 1.22. Матрица парных сравнений альтернатив для критерия «Окупаемость»

Окупаемость
	Модель Захмана	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

Таблица 1.23. Расчет оценки согласованности матрицы парных сравнений для критерия «Окупаемость»

L=	4,00
ИС=	0,00
ОС=	0,08%
n=	4
ИС случ=	0,9

Таблица 1.24. Матрица парных сравнений альтернатив для критерия «Стоимость проектирования»

Стоимость проектирования
	Модель Захмана	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

Таблица 1.25. Расчет оценки согласованности матрицы парных сравнений для критерия «Стоимость проектирования»

L=	4,14
ИС=	0,05
ОС=	5,26%
n=	4
ИС случ=	0,9

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

В таблице 1.26 представлен сравнительный анализ основных наиболее популярных методик проектирования архитектуры предприятия на основе выделенных ранее критериев [23]. Данные в таблице берутся из матриц парных сравнений для каждого критерия. Приоритет за каждый критерий выставляется из соответственной матрицы парных сравнений. Итоговая оценка выставляется путем сложения произведений оценки по критерию и значимостью критерия.

Таким образом, колонка итог показывает, какой приоритет имеет каждая методология. Так как наибольшее значение у методики TOGAF, то она и будет выбрана для дальнейшей работы [26,27,28,29].

Таблица 1.26. Итоговая таблица анализа методик

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

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

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

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

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

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

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

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

Окупаемость

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

ИТОГО

0,12

0,09

0,02

0,07

0,17

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,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 Концепции

Концепция	Определение	Нотация
компонент приложения	Модульная, развертываемая и сменная часть программной системы, которая инкапсулирует свое поведение и данные, и выставляет их с помощью набора интерфейсов.
сотрудничество приложений	Совокупность двух или более компонентов приложения, которые работают вместе для выполнения коллективного поведения.
Интерфейс приложения	Точка доступа, где услуга приложения становится доступной для пользователя или другого компонента приложения.
функция Application	Поведение элемента, что группы автоматизированное поведение, которое может быть выполнено с помощью компонента приложения.
взаимодействие приложений	Элемент поведения, который описывает поведение сотрудничества приложений.
служба приложений	Служба, которая предоставляет автоматизированное поведение.
Данные объекта	Пассивный элемент, пригодный для автоматизированной обработки.

.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

№	Папка	Назначение
1	Business Бизнес	Элементы бизнес-уровня архитектуры предприятия
2	Application Приложение	Элементы уровня приложений архитектуры предприятия
3	Technology Технология	Элементы технологического уровня архитектуры предприятия
4	Motivation Мотивация	Элементы расширения «Мотивация» архитектуры предприятия
5	Implementation & Migration Реализация и миграция	Элементы расширения «Реализация и миграция» архитектуры предприятия
6	Connectors Коннекторы	Элементы типа «Перекресток» (Junction)
7	Relations Отношения	Отношения между элементами, когда они созданы на диаграммах (Views)
8	Views Диаграммы	Ссылки на диаграммы (Views)

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

Все элементы созданной в 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.

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

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

Оглавление

Введение

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

.1 Функциональный и процессный подходы

1.2 Анализ понятия архитектура предприятия. Определение границ системной архитектуры

.3 Структура BPMS-системы

1.4 Существующие методики и языки построения арихитектуры BPMS

1.5 Анализ существующих методик и обоснование выбора наиболее удобной методики проектирования архитектуры приложений и ИТ-инфраструктуры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Важность

Продукт

Договор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· Узел

Устройство

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

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

Сеть

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

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

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

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

· Артефакты

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

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

2.6 Отношения

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

· Композиция

Агрегация

Назначение

Реализация

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

Доступ

Ассоциация

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

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

Поток

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

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

Соединение

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

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

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

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

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

· Драйвер

Оценка

Цель