Материал: Методы проектирования целевой архитектуры данных при формировании BPMS систем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 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. Описание атрибутов объекта управления

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

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

Таблица 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. Матрица Данные/Функции

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

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

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

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

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