- описание этапа разработки концептуальной модели данных;

- описание этапа разработки логической модели данных;

- описание этапа разработки физической модели данных.

Сформированные требования к архитектуре данных были представлены в виде иерархии (см. рис. 1.10).

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

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

Суть метода заключается в составлении матриц парных сравнений, с помощью которых оцениваются критерии и альтернативы. Чтобы сравнить степень проявления признака в методологии, используются следующие оценки: 1 - равноценность, 3 - умеренное превосходство, 5 - сильное превосходство, 7 - очень сильное превосходство, 9 - высшее превосходство. Для определения промежуточных степеней используются также чётные числа. Веса критериев и оценки по субъективным критериям не назначаются прямым волевым методом, а рассчитываются с помощью формул, поэтому такой анализ позволяет получить достаточно обоснованные результаты.

Чтобы посчитать приоритеты критериев верхнего уровня, строится матрица 3Ч3. На первой шаге необходимо сравнить между собой альтернативы (строчку и столбец). На втором шаге - рассчитать среднее геометрическое для каждого критерия (среднее геометрическое по строке). Третий этап - рассчитать приоритеты, разделив значение среднего геометрического (для строки) на сумму средних геометрических всех критериев. Результаты расчетов для критериев 1 уровня представлены в Таблице 1.9. Полная матрица приведена в Приложении А (см. табл. А.1).

Таблица 1.9. Приоритеты критериев 1 уровня

Критерий	Приоритет
Удобство использования	60%
Полнота метамодели	20%
Полнота процесса разработки	20%

Для расчета приоритетов 2 уровня учитывались рассчитанные ранее приоритеты 1 уровня, т.е. сумма приоритетов 2 уровня дает значение приоритета критерия на 1 уровне. Матрицы оценки критериев 2 уровня приведены в Приложении А (см. табл. А.2, табл. А.3, табл. А4). Результаты расчета приоритетов критериев 2 уровня указаны в табл. 1.10, 1.11, 1.12.



Таблица 1.10. Приоритеты 2 уровня критерия «Удобство использования»

Критерий	Приоритет
Доступность	30%
Наличие шаблонов	15%
Рекомендации по построению моделей данных	6%
Методы формирования АД	6%
Критерии эффективности	3%

Таблица 1.11. Приоритеты 2 уровня критерия «Полнота метамодели»

Критерий	Приоритет
Полнота модели обработки информации	2%
Полнота плана перехода	9%
Полнота модели данных	9%

Таблица 1.12. Приоритеты 2 уровня критерия «Полнота процесса разработки»

Критерий	Приоритет
Полнота описания разработки модели обработки данных	1%
Полнота описания разработки архитектуры TO BE	4%
Полнота описания разработки плана перехода	2%
Полнота описания разработки концептуальной модели данных	4%
Полнота описания разработки логической модели данных	4%
Полнота описания разработки физической модели данных	4%

В итоговой таблице представлены результаты сравнительного анализа основных методик проектирования архитектуры данных (Таблица 1.13.) на базе выделенных ранее критериев. Были построены 14 матриц размером 5Ч5. Все матрицы приведены в Приложении А (см. табл. А.13-А18), итоговая матрица в таблице А.19.



Таблица 1.13. Итоговые результаты

Методика	Приоритет
TOGAF	36%
Модель Захмана	10%
Gartner	5%
FEAF	30%
DoDAF	19%

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

1.7 Проектирование архитектуры данных по TOGAF

Рассмотрим более детально процесс формирования архитектуры данных в стандарте TOGAF. Согласно TOGAF, архитектура данных объединена с архитектурой приложений в одну стадию: стадию «C. Архитектура информационных систем». Процесс разработки архитектуры данных указан в части 2 «ADM», раздел 10 «Phase C: Information Systems Architectures - Data Architecture».

Цели процесса разработки архитектуры данных:

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

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

TOGAF предлагает использовать для описания заданный набор артефактов (Таблица .1.14) [17]:



Таблица 1.14. Документация по описанию архитектуры данных TOGAF

Класс артефакта	Артефакты архитектуры данных
Каталог	Перечень используемых данных (Data Entity/Data Component Catalog)
Матрицы	Матрица Данные/Функции (Data Entity/Business Function Matrix)
	Матрица Приложения/Данные (Application/Data Matrix)
Основные диаграммы	Концептуальная модель данных (Conceptual Data Diagram)
	Логическая модель данных (Logical Data Diagram)
	Диаграмма передачи данных (Data Dissemination Diagram)
Дополнительные диаграммы	Диаграммы защиты данных (Data Security Diagram)
	Диаграммы перемещения данных (Data Migration Diagram)
	Диаграммы жизненного цикла данных (Data Lifecycle Diagram)

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

- Каталоги - списки строительных блоков.

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

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

Также на официальном сайте выложены некоторые шаблоны указанных выше документов [17].

1. Матрица «Данные/Функции» - таблица, отображающая связь между сущностями данных и бизнес-функциями. Матрица является соединительным слоем с бизнес-архитектурой.

2. Матрица «Приложения/Данные» - таблица, отображающая связь между приложениями и сущностями данных, которые используются этими приложениями. Данная матрица является слоем между архитектурой данных и приложений.

3. Концептуальная модель данных - модель отношений между критическими сущностями данных в рамках предприятия. Эта диаграмма отражает понятия, доступные для понимая заинтересованным сторонам. Модель имеет вид ERD-диаграммы или диаграммы классов (UML class diagrams).

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

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

6. Диаграмма защиты данных - модель доступа к данным. Доступ к информации определяется 4 категориями действий: создание (C), чтение (R), изменение (U), удаление (D). Диаграммы защиты данных может быть также представлена CRUD-матрицей. Основной акцент делается на акторе, поэтому рекомендуется строить диаграммы защиты данных отдельно для каждого актора.

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

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

2 

1.8 Выводы по Главе 1

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

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

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

Наиболее применяемый подходом при разработке архитектуры является гибридный подход, то есть сочетание нескольких методик. Самые используемые методики, на сегодняшний день, - TOGAF, Модель Захмана, Gartner, FEAF, DoDAF. Данные методики были выбраны для дальнейшего анализа, согласно сформированным критериям. Для анализа использовался метод анализа иерархий (МАИ), позволяющий математически обосновать выбор методики. Согласно МАИ, наиболее эффективной методикой является стандарт TOGAF. Однако стандарт TOGAF не полностью удовлетворяет всем обозначенным выше критериям. Далее будут предложены рекомендации по улучшению данной методики.

Глава 2. Формирование методики проектирования целевой АД

В данной главе планируется рассмотреть следующие задачи:

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

2) сформировать основные шаги проектирования целевой архитектуры данных.

2.1 Интеграция BPM и архитектуры предприятия

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

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

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

Однако данные, используемые приложениями, не всегда развиваются строго организованными и контролируемыми. Часто приложения представляют одни и те же данные множеством способов, в ходе чего может появляться избыточная или несогласованная информация. Для оптимизации многократного использования информации компании внедряют сервис-ориентированную архитектуру (Service-Oriented Architecture, SOA).

Согласно IBM: «Сервис-ориентированная архитектура - это ИТ-архитектура уровня предприятия, предназначенная для установления связи с ресурсами по требованию. Эти ресурсы представлены в виде ориентированных на задачи бизнеса сервисов, которые могут быть включены в пул ресурсов предприятия или направления бизнеса и модифицированы для удовлетворения соответствующих бизнес-потребностей» [18].

Идеи SOA и BPMS дополняют друг друга: реализация SOA превращает корпоративные системы в функции, доступные извне, а BPMS является потребителем этих функций, использующим их для построения бизнес-процессов.

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

2.2 Проектирование целевой данных на основе модели BPMN

2.2.1 Определение объекта управления

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

По сути, объектом управления является результат выполнения процесса. Результат процесса всегда заранее определен, так как процесс всегда направлен на выполнение конкретной цели. Поэтому проблем с определением объекта управления процесса не возникает. Приведем пример выделения объекта управления из процесса (Таблица 2.1).

Таблица 2.1. Пример выделения объекта управления

Процесс	Объект управления
Закупка материалов	Заявка на закупку
Монтажные работы	Акт приемки-передачи
Проведение тендеров	Заявка на участие в тендере
Продажи	Заказ
Прием на работу	Трудовой договор

С определением объекта управления на исполняемой модели могут возникнуть сложности, так как на модели много объектов данных с разными наименованиями. Рассмотрим на примере процесса «Обработка заказа» (Рисунок 2.1).

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

Рисунок 2.1. Обработка заказа

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

Хотелось бы отметить, что на модели объект управления отображается как цельный объект, однако он состоит из набора атрибутов (полей). Это будет следующим шагом в построении архитектуры. Требуется определить атрибуты объектов и то, откуда приходят данные для их заполнения. Рассмотрим на примере заказа на производство (Рисунок 2.2).



Рисунок 2.2. Атрибуты объекта

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

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



Рисунок 2.3. Выделение атрибутов

Важно обратить внимание на объекты, которые выпадают из цепочки процесса. Например, если бы была такая ситуация (Рисунок 2.4).

Рисунок 2.4. Выпадающие объекты

Здесь необходимо ответить на следующие вопросы:

1. Нужен ли этот объект для процесса?

2. Если он нужен, то должен ли он передаваться дальше по процессу или он должен сохраниться в хранилище?

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

2.2.2 Описание потоков данных

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

1. Объект данных:

- входные данные;

- выходные данные.

2. Набор данных.

3. Сообщение.

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

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

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

Набор данных - коллекция или массив однотипных данных: множества, списки, массивы.

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

Для описания потоков данных стандарт TOGAF предлагает применять диаграмму перемещения данных (Data Migration Diagram). Данная диаграмма может отражать как общую картину перемещения данных, так и максимально детализированную информацию, например, отражать перемещения не только сущностей, но и отдельных атрибутов. Нотация диаграммы перемещения данных приведена в Таблице 2.2.

Таблица 2.2. Нотация диаграммы перемещения данных

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

Пример диаграммы представлен на Рисунке 2.5.

Рисунок 2.5. Диаграмма перемещения данных

Учитывая, что на модели BPMN данные могут быть представлены 3 способами, внесем доработки в нотацию TOGAF (Таблица 2.3).

Таблица 2.3. Нотация диаграммы перемещения данных

Графическое представление	Тип объекта	Описание
	Объект данных	Товарно-материальные ценности или информация
	Набор данных	Коллекция или массив однотипных данных
	Сообщение	Информация, передаваемая между участниками 2 процессов
	Объект / Набор данных (детализированный до атрибутов)	Конкретный объект, в рассматриваемой предметной области, детализированный до атрибутов
	Перемещение	Перемещение данных между сущностями

Эту диаграмму можно считать логическим уровнем архитектуры данных.

2.2.3 Определение источников данных

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

1. Корпоративное хранилище данных.

2. Учетные системы.

3. Аналитические системы.

4. Системы ERP.

5. Web-источники.

6. Файлы.

7. Бумажные документы.

К внутренним источникам данных относятся:

1. База данных системы.

2. Внутренние переменные.

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

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

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

Вначале определим все источники. Для более удобного визуального восприятия, эту информацию можно представить в виде матрицы «Приложения/Данные» (Таблица 2.4).

Таблица 2.4. Матрица Приложения/Данные

	Система 1	Система 2	…	Система N
Задача 1	+
Задача 2	+	+
…
Задача N				+

2.2.4 Интеграция данных

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

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

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

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

Для отображения интеграции данных между системами, сервисами, приложениями TOGAF предлагает использовать диаграмму передачи данных (Data Dissemination Diagram). Цель диаграммы передачи данных - показать связь между сущностями данных, бизнес-службами и компонентами приложений. Диаграмма отображает, как логические сущности физически реализованы программными компонентами, что в дальнейшем позволит измерить необходимый размер памяти приложений и рассчитать их мощность. Нотация диаграммы передачи данных приведена в Таблице 2.5.

Таблица 2.5. Нотация диаграммы передачи данных

Графическое представление	Тип объекта	Описание
	Сущность	Конкретный или абстрактный объект в рассматриваемой предметной области
	Компонент сущности	Компонент приложения, обеспечивающий доступ к сущностям и сохраняющий их целостность
	Компонент взаимодействия	Компонент приложения, отвечающий за обеспечение графического интерфейса пользователя, например, веб-интерфейс
	База данных	Хранилище

Пример диаграммы передачи данных представлен на Рисунке 2.6.



Рисунок 2.6. Диаграмма передачи данных

2.2.5 Преобразование данных

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

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

По степени структурированности выделяют следующие формы представления данных [22]:

- неструктурированные (данные, произвольные по форме, включающие тексты и графику, мультимедиа (видео, речь, аудио);

- структурированные (базы данных, списки, графы, структуры);

- слабоструктурированные (публикации, RDF, XML).

Все структурированные данные делятся на пять типов:

- целый (количество товара, код товара и т. п.);

- вещественный (цена, скидка и т. п.);

- строковый (фамилия, наименование, адрес, пол, образование и т. п.);

- логический;

- дата/время.

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

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

1. Неэлектронный документ. В этом случае происходит распознавание в том или ином виде: распознавание текста отсканированных бумажных документов, распознавание речи, введенной с микрофона и т.д.

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

3. Структурированный документ. Здесь необходимо преобразование данных из одного формата в другой, например, из DBF в XML.

2.2.6 Доступ к данным

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

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

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

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

TOGAF использует диаграммы защиты данных для описания доступа к данным. Цель диаграммы защиты данных - отобразить, какой актор может иметь доступ к данным. Доступ к информации определяется 4 категориями действий: создание (C), чтение (R), изменение (U), удаление (D). Основной акцент делается на акторе, поэтому рекомендуется строить диаграммы защиты данных отдельно для каждого актора.

Диаграмма защиты данных может быть также представлена CRUD-матрицей. Нотация диаграммы защиты данных указана в Таблице 2.6.

Таблица 2.6. Нотация диаграммы защиты данных

Графическое представление	Тип объекта	Описание
	Сущность	Конкретный или абстрактный объект в рассматриваемой предметной области
	Внешний актор	Актор, не принадлежащий организационной структуре организации
	Внутренний актор	Актор, принадлежащий организационной структуре организации
	Поток данных	Доступ и права на данные сущности

Пример диаграммы защиты данных приведен на Рисунке 2.7.

Рисунок 2.7. Диаграмма защиты данных

2.2.7 Синхронизация данных по времени

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

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

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

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

- шлюзы, основанные на событиях, и параллельные шлюзы, основанные на событиях, инициируют появление нового экземпляра процесса;

- шлюзы, включающие условия и объединения;

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

- параллельные шлюзы, представляющие собой раздвоение и слияние.

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

- стартовое событие указывает на то, в какой точке берет начало тот или иной процесс;

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

- конечное событие указывает на то, в какой точке завершится тот или иной процесс.

Помочь в анализе синхронизации может матрица зависимости «Данные/Функции» (Таблица 2.7).

Таблица 2.7. Матрица Данные/Функции

	Задача 1	Задача 2	…	Задача N
Задача 1	Набор данных	-		Набор данных
Задача 2	-	Набор данных		-
…
Задача N	Набор данных	-		Набор данных

2.3 Методика проектирования архитектуры данных для BPMS-систем с помощью TOGAF

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

1. Этап формирования концептуального уровня:

1.1. Определение объекта управления.

- Что является результатом выполнения процесса?

- Как связаны данные с операциями?

- Из каких составляющих состоит объект управления?

1.2. Описание потоков данных.

- Как связаны данные между собой?

2. Этап формирования логического уровня:

2.1. Определение источников данных.

- Какие используются источники данных?

- Как связаны данные с источниками?

2.2. Интеграция данных.

- Как передаются данные между системами, приложениями, сервисами?

3. Этап формирования физического уровня:

3.1. Преобразование данных.

- Какие трансформации данных требуются при переносе их из одного источника в другой?

3.2. Доступ к данным.

- Какие операции выполняются над данными?

- Кто выполняет операции над данными?

3.3. Синхронизация данных по времени.

- Где должна быть задержка выполнения операции?

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

Таблица 2.8. Набор артефактов АД

Этап	Инструмент описания
Концептуальный уровень
Определение объекта управления	Модель BPMN
Описание потоков данных	Диаграмма перемещения данных
Логический уровень
Определение источников данных	Матрица Приложения/Данные
Интеграция данных	Диаграмма передачи данных
Физический уровень
Преобразование данных	Табличное описание
Доступ к данным	Диаграмма защиты данных
Синхронизация данных по времени	Матрица Данные/Функции

2.4 Выводы по Главе 2

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

Данная методика определяет семь этапов проектирования целевой архитектуры данных, включающих следующие шаги:

1) определение объекта управления;

2) описание потоков данных;

3) определение источников данных;

4) интеграция данных;

5) преобразование данных;

6) доступ к данным;

7) синхронизация данных по времени.

Для всех этапов приведены инструменты проектирования, среди которых диаграммы и матрицы. В качестве основы для формирования этапов использовался стандарт TOGAF. Например, матрица «Приложения/Данные» для определения источников данных и матрица «Данные/Функции» для описания синхронизации данных по времени. Из диаграмм использовались:

- диаграмма передачи данных для описания потоков данных;

- диаграмма защиты данных для описания доступа к данным.

Некоторые элементы были доработаны с учетом специфики модели BPMS. Так нотация диаграммы перемещения данных была расширена за счет объектов нотации BPMN.

Глава 3. Реализация методики

3.1 Описание процесса

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

Описание процесса «Как должно быть» приведено в таблице ниже (Таблица ).

Таблица 3.1. Описание процесса

Функция	Входы функции (документы/ данные)	Выходы функции документы /данные	Исполнитель	ИС, участвующая при выполнении
Формирование заявки	Набор документов	Заявка	Студент	ЛМС
Проверка заявки	Заявка		Стипендиальная комиссия структурного подразделения	ЛМС
Оценка заявки	Заявка	Список претендентов	Стипендиальная комиссия структурного подразделения
Формирование общеуниверситетского рейтинга студентов	Список претендентов	Список претендентов	ЦСиБП
Рассмотрение	Список претендентов		Общеуниверситетская комиссия
Утверждение	Список претендентов	Список победителей	Общеуниверситетская комиссия
Подготовка проекта приказа	Список победителей	Приказ (проект)	ЦСиБП	СЭД
Подписание приказа	Приказ (проект)	Приказ	Ректор

Модель процесса сформирована в нотации BPMN и представлена на Рисунке 3.1.

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



Рисунок 3.1. Назначение повышенной государственной стипендии

3.1. 

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

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

Далее проследим, как передаются данные между операциями (Рисунок 3.2).

Рисунок 3.2. Поток данных

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

- «Проверка заявки» и «Оценка заявки»;

- «Рассмотрение» и «Утверждение».

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

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

Рисунок 3.3. Поток данных

Выделим составляющие объекта управления. Согласно документу «Списки получателей повышенных государственных академических стипендий за особые достижения», выложенному на официальном сайте ЦСиБП, определены следующие атрибуты (Таблица 3.2):

Таблица 3.2. Описание атрибутов объекта управления

Атрибут	Описание
№	Номер по порядку
ФИО	Фамилия Имя Отчество
Курс	1/2/3/4
Степень	Специалитет/ Бакалавриат/ Магистратура
Факультет	Факультет, на котором обучается студент
Филиал	Москва/ Пермь/ Санкт-Петербург/ Нижний Новгород
Область	Область, в которой будет назначена стипендия
Количество баллов	Количество набранных баллов
Уровень стипендии	1/2/3/4

А также разберем, из каких составляющих состоит заявка и приказ (Таблица 3.3 и Таблица 3.4).

Таблица 3.3. Описание атрибутов заявки

Атрибут	Описание
ФИО	Фамилия Имя Отчество
Курс	1/2/3/4
Степень	Специалитет/ Бакалавриат/ Магистратура
Факультет	Факультет, на котором обучается студент
Филиал	Москва/ Пермь/ Санкт-Петербург/ Нижний Новгород
Область	Область, в которой будет назначена стипендия
Файл	Набор файлов, прикрепленных студентом

Таблица 3.4. Описание атрибутов заявки

Атрибут	Описание
ФИО	Фамилия Имя Отчество
Курс	1/2/3/4
Степень	Специалитет/ Бакалавриат/ Магистратура
Факультет	Факультет, на котором обучается студент
Филиал	Москва/ Пермь/ Санкт-Петербург/ Нижний Новгород
Область	Область, в которой будет назначена стипендия
Файл	Набор файлов, прикрепленных студентом
Период выплаты стипендии	Период выплаты стипендии
Месячный размер стипендии	Размер стипендии в месяц, руб.
Общий размер стипендии	Общая сумма выплат, руб.

Перейдем к описанию потоков данных (Рисунок 3.4).



Рисунок 3.4. Перемещение данных

3.3 Описание логического уровня

Далее перейдем к описанию интеграции данных с внешними источниками данных. Согласно модели список внешних источников включает:

- систему LMS;

- СЭД.

А также базу данных по заявкам. Составим матрицу Приложения/Данные (Таблица 3.5).

Таблица 3.5. Матрица Приложения/Данные

Задачи	ЛМС	СЭД	БД
Формирование заявки	+
Проверка заявки
Оценка заявки
Формирование общеуниверситетского рейтинга студентов			+
Утверждение
Подготовка проекта приказа		+
Подписание приказа

В ЛМС происходит формирование заявки, далее эта заявка поступает в систему BPMS. Все заявки попадают в базу данных, из которой формируется общеуниверситетский рейтинг. В СЭД выполняется формирование приказа и его согласование.

Представим перемещение данных между системами с помощью модели передачи данных (Рисунок 3.5).

Рисунок 3.5. Передача данных

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

3.4 Описание физического уровня

Рассмотрим, как происходят преобразования объектов данных. Обратимся к диаграмме перемещения данных (Рисунок 3.4). На модели видно, что данные полностью передаются из одного объекта в другой, не требуя преобразования форматов. Особое внимание обратим на пункт «Файлы». Файлы здесь представляют собой набор разноформатных документов (это могут быть файлы формата docx, pdf, png, jpeg). Однако эти файлы оцениваются вручную пользователем, после чего дальше они не фигурируют.

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

Рисунок 3.6. Диаграмма защиты данных

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

Создадим матрицу Данные/Функции, где на пересечении функций (операций), проставим данные, через которые они связаны (Таблица 3.6).

Таблица 3.6. Матрица Данные/Функции

	1	2	3	4	5	6	7
1.Формирование заявки	-	заявка	-	-	-	-	-
2.Проверка заявки	заявка	-	заявка	-	-	-	-
3.Оценка заявки	-	заявка	-	список претендентов	-	-	-
4.Формирование общеуниверситетского рейтинга студентов	-	-	список претендентов	-	список претендентов	-	-
5.Утверждение	-	-	-	список претендентов	-	список победителей	-
6.Подготовка проекта приказа	-	-	-	-	список победителей	-	приказ
7.Подписание приказа	-	-	-	-	-	приказ	-

3.5 Выводы по Главе 3

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

На основе методики, описанной в главе 2, сформирована целевая архитектура данных. Архитектура данных формировалась по 3 уровням: концептуальный, логический, физический.

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

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

Физический уровень описывает доступ к данным и способы синхронизации данных по времени.

Таким образом, создано 5 таблиц, включая 2 матрицы, и 5 рисунков, включая диаграммы.



Заключение

В главе 1 был проанализирован понятийный аппарат архитектуры данных, описана структура архитектуры, включающая в себя 3 уровня: концептуальный, логический, физический. Выполнен анализ моделей данных, применяемых на каждом уровне архитектуры данных. Данный анализ показал, что модели BPMS-систем не имеют четкой логической структуры. Учитывая данную проблему были сформированы критерии для проектирования архитектуры данных. Для анализа было выбрано 5 стандартов: TOGAF, модель Захмана, Gartner, FEAF, DoDAF, так как они являются наиболее востребованными на рынке. Был проведен сравнительный анализ выбранных методик с применением метода анализа иерархий. Анализ выполнялся по 14 сформированным критериям. Таким образом, было сформировано 19 матриц парных сравнений, которые показали, что наиболее полно требованиям удовлетворяет методология TOGAF. Однако стандарт TOGAF не полностью удовлетворяет всем обозначенным выше критериям. В частности, он не дает четкой последовательности шагов процесса проектирования, а также не определяет, для какого уровня модели формируются артефакты архитектуры данных.

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

В главе 3 в качестве примера был выбран процесс «Назначение повышенной стипендии». Были выполнены основные шаги проектирования архитектуры данных, для описания применялась методика, сформированная в Главе 2. На концептуальном уровне определен основной объект управления, описаны потоки данных между процессами, перемещение атрибутов между данных.

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

Физический уровень описывает доступ к данным и способы синхронизации данных по времени.

Таким образом, разработаны артефакты архитектуры, а именно, создано 5 таблиц и 5 диаграмм.

Результаты работы представлены в следующих публикациях [23, 24]:

- Вотинцева В. О., Сахипова М. С. Выбор эффективной методики проектирования архитектуры данных в рамках архитектуры предприятия // В кн.: Технологии разработки информационных систем - ТРИС-2016: материалы VII Международной научно-технической конференции. Том 2 Т. 2. Таганрог: Издательство ЮФУ, 2016. С. 32-36.

- Вотинцева В. О., Сахипова М. С., Дерябин А. И. Применение метода анализа иерархий для выбора методик проектирования системной архитектуры предприятия // В кн.: Математика и междисциплинарные исследования - 2016. Пермь: Пермский государственный национальный исследовательский университет, 2016. С. 201-207.



Библиографический список

1. Лекция 1: Тенденции развития информационных технологий. Архитектурный подход как основа управления развитием информационных систем [Электронный ресурс] // Национальный открытый университет «ИНТУИТ» - Режим доступа: http://www.intuit.ru/studies/courses/532/388/lecture/9001?page=4&keyword_content=architecture [Проверено: 19.05.2017].

2. Олейник А. И. ИТ-инфраструктура: учеб.-метод. пособие / А. В. Сизов. Нац.-исслед. ун-т «Высшая школа экономики». -- М.: Изд. дом Высшей школы экономики, 2012. -- 134 с.

3. Лекция 10: Процесс разработки архитектур: цели и задачи, общая схема. Архитектура предприятия [Электронный ресурс] // Национальный открытый университет «ИНТУИТ» - Режим доступа: http://www.intuit.ru/studies/courses/995/152/lecture/4240 [Проверено: 19.05.2017].

4. Коротков А. Архитектура Предприятия. Как заставить ИТ работать на вашу компанию / А. Коротков. - 2013. - 96 с.

5. Коптелов А. Принципы управления архитектурой предприятия [Электронный ресурс] / А. Коптелов // Проблемы теории и практики управления. - 2010. - №1. - Режим доступа: http://bpm.ucoz.ru/publ/upravlenie_arkhitekturoj_predprijatija/principy_upravlenija_arkhitekturoj_predprijatija/30-1-0-31 [Проверено: 19.05.2017].

6. Brand S. (2015, June) Magic Quadrant for Enterprise Architecture Consultancies.

7. Зиндер Е.З. Архитектура предприятия в контексте бизнес-реинжиниринга [Электронный ресурс] / Е.З. Зиндер // Intelligent Enterprise. - 2008. - №4. - Режим доступа: http://www.iemag.ru/master-class/detail.php?ID=15745.html [Проверено: 19.05.2017].

8. Лекция 1: Информационные системы с базами данных. Основы проектирования реляционных баз данных [Электронный ресурс] // Национальный открытый университет «ИНТУИТ» - Режим доступа: http://www.intuit.ru/studies/courses/1095/191/lecture/4967?page=4 [Проверено: 19.05.2017].

9. Лекция 5: Первая стадия концептуального проектирования базы данных (концептуальное моделирование). Академия Microsoft: Базы данных [Электронный ресурс] // Национальный открытый университет «ИНТУИТ» - Режим доступа:http://www.intuit.ru/studies/courses/508/364/lecture/8647?page=2 [Проверено: 19.05.2017].

10. Башкатова Ю.И. Виды информационных систем и технологий в системе наращения качества управленческих решений и конкурентоспособности организаций // Экономика и современный менеджмент: теория и практика: сб. ст. по матер. XXXVI междунар. науч.-практ. конф. № 4(36). Часть II. - Новосибирск: СибАК, 2014.

11. Schekkerman J. How to Survive in the Jungle of Enterprise Architecture Framework: Creating or Choosing an Enterprise Architecture Framework. Trafford, 2006. p. 224.

12. Cameron B.H., McMillian E. (2013, February). Analyzing the current trends in enterprise architecture frameworks. Journal of Enterprise Architecture [Электронный ресурс]. Режим доступа: http://ea.ist.psu.edu/documents/journal_feb2013_cameron_2.pdf [Проверено: 19.05.2017].

13. Zachman J.P. (2009, April). The Zachman Framework Evolution [Электронный ресурс] Режим доступа: https://www.cob.unt.edu/itds/faculty/becker/BCIS5520/Readings/The%20Zachman%20Framework%E2%84%A2%20Evolution.pdf [Проверено: 19.05.2017].

14. Bittler R.S., Kreizman G. (2005, October). Gartner Enterprise Architecture Process: Evolution. Gartner [Электронный ресурс] Режим доступа: http://www.idi.ntnu.no/emner/tdt4175/pdfs/GartnerEA.pdf [Проверено: 19.05.2017].

15. Federal Enterprise Architecture Framework, Version 2 (2013). [Электронный ресурс] Режим доступа: https://www.whitehouse.gov/sites/default/files/omb/assets/egov_docs/fea_v2.pdf [Проверено: 19.05.2017].

16. The DoDAF Architecture Framework, Version 2 (2011, February). [Электронный ресурс] Режим доступа: http://dodcio.defense.gov/Portals/0/Documents/DODAF/DoDAF_v2-02_web.pdf [Проверено: 19.05.2017].

17. TOGAF, Version 9.1 (2011) [Электронный ресурс] Режим доступа: http://pubs.opengroup.org/architecture/togaf9-doc/arch/ [Проверено: 19.05.2017].

18. Калянов Г.Н. Построение архитектуры предприятия [Электронный ресурс] / Г.Н. Калянов // Корпоративные системы. - 2005. - №3. - Режим доступа: http://cde.osu.ru/demoversion/course158/glava1_2.html [Проверено: 19.05.2017].

19. Амсден Д. Моделирование SOA: Часть 2. Спецификация сервиса [Электронный ресурс] / Д. Амсден // IBM developerWorks Россия - 2008. - Режим доступа: https://www.ibm.com/developerworks/ru/library/1009_amsden/ [Проверено: 19.05.2017].

20. Зауфер Г. Шаблоны для информационного сервиса: Часть 1. Шаблоны интеграции данных [Электронный ресурс] / М. Сельваж, Э. Лейн, Б. Мэтьюс // IBM developerWorks Россия - 2007. - Режим доступа: https://www.ibm.com/developerworks/ru/library/ws-soa-infoserv1/ [Проверено: 19.05.2017].

21. Зауфер Г. Шаблоны информационных сервисов: Часть 2. Шаблон консолидации данных [Электронный ресурс] / Б. Мэтьюс, М. Сельваж, Э. Остик // IBM developerWorks Россия - 2008. - Режим доступа: https://www.ibm.com/developerworks/ru/library/ws-soa-infoserv2/ [Проверено: 19.05.2017].

22. Энгельс В. Методы работы с моделью мастер-данных в SOA-проектах [Электронный ресурс] / В. Энгельс // Interface.ru - 2009. - Режим доступа: http://www.interface.ru/home.asp?artId=21057 [Проверено: 19.05.2017].

23. Вотинцева В. О. Выбор эффективной методики проектирования архитектуры данных в рамках архитектуры предприятия/ М. С. Сахипова // В кн.: Технологии разработки информационных систем - ТРИС-2016: материалы VII Международной научно-технической конференции. Том 2 Т. 2. Таганрог: Издательство ЮФУ, 2016. С. 32-36.

24. Вотинцева В. О., Сахипова М. С., Дерябин А. И. Применение метода анализа иерархий для выбора методик проектирования системной архитектуры предприятия // В кн.: Математика и междисциплинарные исследования - 2016. Пермь: Пермский государственный национальный исследовательский университет, 2016. С. 201-207.