Программа анализа матриц типа "функции-данные" и интерпретации деревьев бизнес-процессов

Размещено на http://www.allbest.ru/

Правительство Российской Федерации

Федеральное государственное автономное образовательное

учреждение высшего образования

«Национальный исследовательский университет

«Высшая школа экономики»

Факультет Компьютерных наук

Департамент программной инженерии

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

по направлению 09.03.04 «Программная инженерия»

подготовки бакалавра

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

Студентки группы БПИ122

Кузменковой Валентины Александровны

Научный руководитель

преподаватель

Департамента программной инженерии Климов Борис Анатольевич

Москва, 2016



Реферат

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

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

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

Для визуализации результатов анализа используются средства системы построения клиентских приложений Windows Presentation Foundation.

Работа содержит 32 страницы, 3 главы, 9 рисунков, 2 таблицы, 1 схему, 16 источников, 6 приложений.

Ключевые слова: архитектура данных, кластерный анализ, матрица «функции-данные», CRUD-матрица.



Abstract

This work is dedicated to analysis of data architecture of a company based on description of business processes.

In the paper the methodology is presented that describes business processes with the help of CRUD- matrices and Function-Data matrices. Furthermore, the plan of the analysis of the matrices has been developed and is demonstrated, too, along with the usage of clustering.

The object under the development is a program enabling the automaticity of the analysis of Function-Data matrices. Moreover, one can interpret the results of the analysis with the help of the program; finally, those results can be presented in a user-friendly manner. The program can be used in a process of building or reengineering of data architecture.

The tools of client-oriented applications of Windows Presentation Foundation are adapted to visualize the results of the analysis.

The paper contains 32 pages, 3 chapters, 9 illustrations, 2 tables, 1 scheme, 16 bibliography items, and 6 appendices.

Keywords: data architecture, cluster analysis, Function-Data matrices, CRUD-matrices.

Список сокращений

БП - бизнес-процесс;

БФ - бизнес-функция;

ЭД - элемент данных;

COBIT - Control Objectives for Information and Related Technologies;

GUI - Graphical User Interface;

IEEE - Institute of Electrical and Electronics Engineers;

ISO - International Organization for Standardization;

ITIL - IT Infrastructure Library;

SDK - Software Development Kit;

WPF - Windows Presentation Foundation;

XML - eXtensible Markup Language.



Оглавление

Введение

Глава 1

1.1 Методы и инструменты описания и анализа архитектуры данных организации

1.2 CRUD-матрицы

1.3 Выбор методов анализа

Глава 2

2.1 Матрицы типа «функции-данные»

2.2 Анализ матриц типа «функции-данные»

2.3 Кластеры бизнес-процессов и метрики их анализа

Глава 3

3.1 Инструменты разработки

3.2 Чтение и хранение данных

3.3 MVVM

Заключение

Список используемых источников

Список приложений и сопроводительных документов

Приложение



Введение

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

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

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

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

Перед системными аналитиками одного из отделов компании ООО «РН-Информ» стоит необходимость оценки архитектуры данных бизнес-процессов отдела в соответствии с используемыми объектами данных, одним из внутренних инструментов описания которых являются матрицы типа «функции-данные» - подвид CRUD-матриц. Эта проблема послужила основанием для данной работы.

Целью выпускной квалификационной работы является реализация программы, позволяющей выявить особенности и неточности описания архитектуры данных, в используемой нотации ООО «РН-Информ», а также анализировать ее текущее состояние на основе их описания в разрезе используемых объектов данных. Для достижения данной цели требуется выполнить следующее:

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

Изучить методологию использования CRUD-матриц и вывести описание матриц «функции-данные»;

Рассмотреть и разработать подходы к анализу данных матриц «функции-данные»;

Рассмотреть подходы к анализу архитектуры данных и выделению кластеров на основании матриц «функции-данные»;

Выбрать способы визуализации и представления результатов анализа;

Разработать программу анализа матриц «функции-данные», визуализации и интерпретации результатов анализа;

Разработать техническую документацию.

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

архитектура матрица программа нотация



Глава 1

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

1.1 Методы и инструменты описания и анализа архитектуры данных организации

За последние годы было разработано большое количество методологий и стандартов построения и описания различных уровней архитектуры организации, в том числе архитектуры данных. Эти методологии содержат описание стандартов, процессов, инструментов описания моделей для определения элементов архитектуры данных и их взаимодействия друг с другом. Также методологии включают в себя список стандартов (к примеру, таких как IEEE и ISO, которые описаны в ITIL, COBIT), набор документов и планов. Наиболее распространенные методологии, включающие в себя описание архитектуры данных, представлены в Таблице 1.

Таблица 1 - Методологии, включающие в себя описание архитектуры данных

Наименование методологии	Направленность методологии
Методология аналитического центра Gartner	Выявление логических связей между используемыми технологиями, важностью данных технологий для бизнеса и непосредственно его потребностей.
Методология META Group	Формализованное и детальное описание процесса разработки архитектуры и ее составляющих.
Модель TOGAF	Создание программной инфраструктуры IT-комплекса для описания его интеграционных компонент.

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

В настоящее время существует большое количество программных продуктов и шаблонов моделирования и анализа архитектуры данных, поддерживающих описания на основе объектов данных. Наиболее популярными из них являются NASCIO Architecture Toolkit, Alfabet, Avolution, BiZZdesign, Architect, Vizualizer, SAP PowerDesigner и др. Они рассматривают описание архитектуры данных с различных сторон, предоставляют её комплексный анализ и инструментарий для обеспечения наглядности. Данные продукты ориентированы на использование широким кругом организаций и реализуют наиболее часто используемые методологии для большей универсальности.

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

Большая часть программных продуктов, поддерживающих работу с CRUD-матрицами, таких как Alphabet, IBM Rational System Architect Matrix Editor, и др. дают возможность хранения описаний, но не их анализа; также данные продукты не имеют наглядных средств визуализации.

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

1.2 CRUD-матрицы

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

Согласно Кодлу [2], CRUD-матрица отражает влияние элементарных (т.е. неделимых) бизнес-операций (например, отправка отчета, запрос набора данных) на те или иные объекты. Данная структура представляет собой таблицу, где в строках содержатся наименования бизнес-операций, в столбцах - наименования объектов, а в ячейках - семантические связи: “C”,“R”,“U”,“D” (Create, Read, Update, Delete) c различной интенсивностью, где C>U>D>R; пустая ячейка означает, что семантическая связь отсутствует или не определена (Рисунок 1). Интенсивность связей между бизнес-операциями и объектами неодинакова. Например, создание элемента данных имеет более сильную связь, в то время как чтение имеет самую слабую связь.

Рисунок 1. Пример CRUD-матрицы



CRUD-матрица в качестве модели описания архитектуры данных может являться достаточно мощным инструментом её анализа, так как позволяет исследовать зависимость между процессами и данными [2].

Выбор методов анализа

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

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

Кластеризация данных CRUD-матрицы[5] (соответственно, и матриц «функции-данные») помогает выделить области высокой плотности архитектуры, где большое количество процессов взаимозависимы и взаимодействуют с общим набором данных. Таким образом, кластеры автоматически объединяют виды деятельности, которые действуют на одних и тех же объектах данных, и, следовательно, такие кластеры можно оценивать в качестве изолированных групп работы с данными.

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



Таблица 1 - Критерии анализа

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

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

Выводы по главе

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



Глава 2

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

2.1 Матрицы типа «функции-данные»

Матрицы типа «функции-данные» являются внутренним инструментом описания бизнес-процессов в организации ООО «РН-Информ» и являются вариацией CRUD-матриц. Матрицы типа «функции-данные» реализуют аналогичный поход к описанию связей, но используют численные метрики и иную терминологию.

Строки матрицы содержат бизнес-функции, столбцы - информационные объекты, или элементы данных; связи между ними выражены следующими значениями:

0 - связь между бизнес-функцией и элементом данных отсутствует;

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

2 - бизнес-функция создает, изменяет или удаляет элемент данных;

Таким образом, элемент данных может быть определен как

где - наименование элемента данных, .

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

Бизнес-функция определяется как:

,

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

Существует ряд особенностей описания бизнес-функций:

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

Если бизнес-функция не использует ни один элемент данных, считается, что бизнес-функция не используется.

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

Тогда матрица типа «функции-данные» может быть определена следующим образом:

,

где - количество бизнес-функций, - общее количество элементов данных. Пример матрицы в формате электронной таблицы изображен на Рисунке 2:

Рисунок 2. Пример матрицы "функции-данные"

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

,

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

,

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

Пример таблицы ассоциирования бизнес-процессов и бизнес-функций представлен на Рисунке 3:

Рисунок 3. Пример таблицы ассоциирования бизнес-функций и бизнес-процессов

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

2.2 Анализ матриц типа «функции-данные»

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

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



Таблица 2 - Проблемы описания архитектуры данных с помощью матриц «функции-данные» и методы их выявления

Проблема описания	Метод выявления
Неполнота описания. Выражается в отсутствии/некорректности описания тех или иных логических элементов (ЭД, БФ, БП).	Проверка полноты входных данных. В рамках данного метода выявляются следующие проблемы описания: Нет корректных данных об использовании бизнес-функцией элемента данных (значение отличается от заданного набора значений или не определено), т.е. , , где - общее количество элементов данных. Отсутствие уникального идентификатора для логических элементов., т.е. множество натуральных чисел. Отсутствие идентификатора не дает возможности корректно идентифицировать и ассоциировать данные. Несоответствие количества описанных бизнес-функций: , определяющее отсутствие данных.
Отсутствие зависимостей. Выражается в отсутствии семантических связей между логическими элементами.	Проверка зависимостей. В рамках данного метода выявляются следующие проблемы описания: Наличие неиспользуемых элементов данных из определения (1): где (6) Наличие неиспользуемых бизнес-функций из определений (2) и (6): , где (7) Наличие неиспользуемых бизнес-процессов из определений (3) , (6) и (7): , где , (8)
Смысловое несоответствие. Выражается в несоответствии табличного описания базовому определению бизнес-процесса.	Проверка соответствий. В рамках данного метода выявляется следующая проблема описания: определение бизнес-процесса предполагает, что для него всегда определен набор выходных и выходных данных. Из этого следует, что бизнес-процесс должен иметь хотя бы один входной и один выходной параметр. Из определений (1), (3), (5): , где , (9)

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

2.3 Кластеры бизнес-процессов и метрики их анализа

Кластер представляет собой набор бизнес-процессов, использующих общие элементы данных:

,

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

Кластеры обладают следующими свойствами:

. Это означает, что кластеры не имеют пересечений по используемым элементам данных.

. Это означает, что объединение кластеров эквивалентно их сложению.

Алгоритм кластеризации, выведенный на основании определения (10), выглядит следующим образом:

1: for all business_processes i do

2: for all clusters j do

3:if (intersect(business_processes[i].datums,

4:clusters[j].datums).Count > 0)

5:clusters[j].Add (business_processes[i])

6:else

7:clusters.AddNewCluster(business_processes[i]);

8: end for

9: end for

Схема 1. Псевдокод алгоритма кластеризации.

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

Total Semantic Relationship (TSR). Данная метрика определяется общей суммой семантических отношений кластера:

,

где k - количество кластеров, m - количество бизнес-процессов в кластере, l - количество ЭД, используемых бизнес-процессом, . Метрика позволяет оценить уровень воздействия на информационные объекты. Влияет на критерий: Уровень взаимодействия с информационными объектами (см. Глава 1).

Internal Semantic Dependency (ISR). Данная метрика определяет связь между парой бизнес-процессов внутри кластера. Значение метрики определяется суммой значений семантических отношений между двумя бизнес-процессами и отражается в матрице зависимостей бизнес-процессов MЗ:

где i , j - номера элементов в матрице МЗ , - множество элементов данных, используемых бизнес-процессом, . Влияет на критерий: Связность бизнес-процессов. Пример матрицы зависимостей бизнес-процессов представлен на Рисунке 4 .



Рисунок 4. Пример матрицы зависимостей бизнес-процессов, созданной в программе

External Semantic Dependency (ESR). Данная метрика определяет зависимость элементов данных от внешних информационных объектов и выражается в количестве внешних элементов данных (), используемых бизнес-процессами в кластере:

,

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

Считаем, что распределение метрики по кластерам является нормальным [6]. Отклонение от метрики определяется стандартным среднеквадратичным отклонением:

, ,

где n - количество кластеров, - значение метрики для i - кластера. Значительным отклонением по метрике, требующим внимания аналитика, будем считать 2.

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

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



Глава 3

В этой главе рассматривается описание инструментов и методов, которые были использованы при разработке программы. Особое внимание уделяется описанию технологии OpenXML и особенностям разработки с использованием модели MVVM.

3.1 Инструменты разработки

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

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

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

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

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

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

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

Для визуализации были выбраны следующие средства: библиотека Graph# [4], предоставляющая удобные алгоритмы рисования и компоновки графов для WPF [16]. WPF, в свою очередь, обладает средствами для создания удобного и привлекательного пользовательского интерфейса. Также была использована библиотека QuickGraph [11], предоставляющая структуры и алгоритмы для создания графов.

Так как в качестве входных данных используются файлы Excel с расширением .xlsx. для чтения и работы с ними был задействован стандарт OpenXML[9]. Для сохранения матрицы зависимости бизнес-процессов в виде электронной таблицы используется библиотека ClosedXML[3].

Интерфейс приложения представлен на Рисунке 5:

Рисунок 5. Интерфейс приложения



Диаграмма классов приложения представлена в Приложении 1.

3.2 Чтение и хранение данных

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

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

Основные логические единицы представлены следующими классами: BusinessProcess (бизнес-процесс), BusinessFucntion (бизнес-функция), Datum (элемент данных), которые показаны на Рисунке 6. Каждый из классов содержит строковое поле name (наименование) и уникальный численный идентификатор ID. Каждый экземпляр класса BusinessFucntion и BusinessProcess содержит списки data_elements и business_functions соответственно, хранящие данные об используемых элементах данных (ненулевых элементах таблицы) и бизнес-функций.

Рис 6. Основные классы

Для хранения списков данных был выбран List<T>, который представляет собой типизированный список объектов и позволяет не только хранить большое количество элементов (до Int32.MaxValue), но и предоставляет удобные и быстрые методы поиска и доступа к элементам списка.

Как было отмечено ранее, в качестве входных данных программа получает таблицы формата .xlsx. Изначально планировалось использование библиотеки работы с OLE-объектами Microsoft Excel 14.0 Object Library v. 1.7. Но реализация показала, что при больших размерностях таблицы чтение данных из нее вызывает значительные временные затраты (для таблицы N = ~100 сек.), что не является приемлемым. Появилась необходимость использования иных способов чтения.

OpenXML представляет собой стандарт (набор форматов файлов) для хранения различных документов, реализованный во множестве приложений, в том числе и Microsoft Office Excel. OpenXML позволяет использовать файлы, созданные Microsoft Office, в других приложениях. Данный формат, по сути, является zip-архивом, который содержит данные в виде XML. Версии Microsoft Office 97-2003 не поддерживают данный формат, поэтому если исходная таблица представлена в формате .xls пользователю необходимо вручную сохранить её как электронную таблицу с расширением .xlsx. Для управления пакетами OpenXML и их элементами используется OpenXML SDK 2.5 [9]. Классы данного пакета позволяют выполнять большое количество стандартных задач.

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

using (SpreadsheetDocument ssDocument =

SpreadsheetDocument.Open(file, false)

Далее с помощью программного интерфейса SAX (Simple API для XML) производится считывание данных ячейки. Данный подход позволяет не загружать файл в память целиком (т.к. это может вызвать переполнение), а считывать по одному элементу:

WorkbookPart wbPart = spreadSheetDocument.WorkbookPart;

WorksheetPart wsPart = wbPart.WorksheetParts.First();

SheetData sData = wsPart.Worksheet.Elements<SheetData>().First();

string temp;

foreach (Row _row in sData.Elements<Row>())

foreach (Cell _cell in _row.Elements<Cell>())

temp = _cell.CellValue.Text;

Считанные данные ассоциируются между собой, заполняя списки List<BusinessFunction> bf_list и List<BusinessProcess> bp_list.

Использование OpenXML для чтения файла обеспечивает существенное сокращение времени загрузки входной таблицы (для таблицы N = с ~170 сек. до 5 сек.).

Для сохранения матрицы связывания бизнес-процессов в виде электронной таблицы была использована библиотека ClosedXml.dll [], предоставляющая простые и понятные методы для создания Excel-файлов с помощью классов XLWorkbook ( документ Excel ), Worksheets ( лист таблицы Excel ), Cell (ячейка таблицы Excel) . Сохранение документа осуществляется с помощью метода SaveAs(“FileName.xlsx”).

3.3 MVVM

При проектировании визуализации была использована модель Model-View-ViewModel (MVVM) [1]- основной паттерн, используемый при работе с Windows Presentation Foundation, Silverlight, и др. MVVM используется для того, чтобы разделить модель и её представление и обеспечить возможность изменять их независимо друг от друга. Основные элементы шаблона и их взаимодействие представлены на Рисунке 7: 

Рисунок 7. Схема взаимодействия элементов MVVM.

Model (Модель) представляет собой набор данных, обеспечивающих логику работы приложения. Уровень модели написан на языке C#. Логические элементы программы реализованы в соответствующих классах.

View (Представление) - это непосредственно графический интерфейс, через который пользователь взаимодействует с программой. View «слушает» (binding) изменения значений свойств, описанных в ViewModel. Если в ViewModel меняется свойство, оно информирует своих «слушателей» об изменениях, и View запрашивает новое значение свойства. Данный уровень описан с помощью языка разметки XAML. (см. Текст программы. MainWindow.xaml).

ViewModel (Модель представления) является связующим звеном между двумя другими элементами; она содержит логику GUI и ссылки на модель. Данный уровень реализован на языке C#.(см. Текст программы.MainWindowViewModel.cs).

Структура приложения в модели MVVM представлена на Рисунке 8 .

Рисунок 8. Структура приложения в модели MVVM

Рассмотрим применение данной модели в программе. Класс MainWindowViewModel реализует интерфейс INotifyPropertyChanged [16]:

public event PropertyChangedEventHandler PropertyChanged;

private void NotifyPropertyChanged(String info)

{

if (PropertyChanged != null)

{

PropertyChanged(this, new PropertyChangedEventArgs(info));

}

}

также в нём объявлено свойство Graph, об изменении которого необходимо оповещать View:

public PocGraph Graph

{

get { return graph; }

set

{

graph = value;

NotifyPropertyChanged("Graph");

}

}

View, в свою очередь, следит за изменением свойства Graph (MainWindow.xaml):

<local:PocGraphLayout x:Name="graphLayout" Margin="10"

Graph="{Binding Path=Graph}"

LayoutAlgorithmType="{Binding Path=LayoutAlgorithmType, Mode=OneWay}"

OverlapRemovalAlgorithmType="FSA"

HighlightAlgorithmType="Simple" />

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

Рисунок 9 . Пример визуализации в программе.

В третьей главе были рассмотрены основания выбора средств реализации программы, а также особенности работы с входными файлами электронных таблиц с использованием стандарта OpenXML; принципы визуализации с помощью средств Windows Presentation Foundation и модели MVVM; для наглядности были добавлены фрагменты кода программы. Приведенная в данной главе информация необходима для ознакомления с особенностями разработки программы.



Заключение

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

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

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

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



Список используемых источников

[1] Natan A. Windows Presentation Foundation Unleashed - Indianapolis : Sams Publishing, 2006. - Т. Edition 1 : стр. 45-84.

[2]Cadle J., Paul D., Turner P. Business Analysis Techniques: 72 Essential Tools for Success - Chippenham : BISL, 2010. - стр. 146-149.

[3]ClosedXML - Easy way to OpenXML // CodePlex 2015. URL: https://closedxml.codeplex.com/ (дата обращения: 20 апреля 2016)

[4]Graph# // CodePlex 2015. дата обращения: URL: https://graphsharp.codeplex.com/15 (дата обращения: 20 апреля 2016)

[5]Henno J., Kiyoki Y., Tokuda T. Information Modelling and Knowledge Bases - Fairfax : IOS Press, 2012. - Т. 23 : стр. 214-233.

[6]Jamshidi P., Mansour S. An Automated Service Identification Method - Beheshti : Automated Software Engineering Research Group, 2012 - стр. 79-83.

[7]Michel R. V. Chaudron, Clemens Szyperski, Ralf H. Reussner Component-Based Software Engineering [Книга]. - Karlsruhe : Springer, 2008 - стр. 139-143.

[8]Mohapatra S., Singh R.P. Information Strategy Design and Practices - [б.м.] : Springer, 2012 г. - стр. 65-77.

[9]NuGet Gallery | DocumentFormat.OpenXml.2.5.0 // NuGet 2016. URL: https://www.nuget.org/packages/DocumentFormat.OpenXml/ ( дата обращения: 20 апреля 2016 г.)

[10] Perks C. Beveridge T. Guide to Enterprise IT Architecture - New York : Springer, 2003, стр. 25-29.

[11]QuickGraph, Graph Data Structures And Algorithms for .NET // CodePlex 2015. URL: https://quickgraph.codeplex.com/ (дата обращения: 21 апреля 2016).

[12]Tewarson R. Sparse Matrices [Book]. - [б.м.] : Academic Press, 1973. - Vol 1. стр. 7-8.

[13]Task // MSDN 2016. URL: https://msdn.microsoft.com/ru-ru/library/system.threading.tasks.task(v=vs.110).aspx (дата обращения: 15 апреля 2016)

[14]Tuppler C.D. Data Architecture: From Zen to Reality - Burlington : Morgan Kaufmann, 2011. - стр. 448.

[15]В.В. Ильин Моделирование бизнес-процессов - Москва : Вильямс, 2012. - стр. 176-180.

[16]Введение в WPF //MSDN 2016 г. URL: https://msdn.microsoft.com/ru-ru/library/mt149842(v=vs.110).aspx (дата обращения: 20 апреля 2016).



Приложение

Диаграмма классов

Более детализированная версия диаграммы находится в файле ClassDiagram.cd.

Размещено на Allbest.ru