Проблема реинжиниринга баз данных в рамках разработки информационной системы для информационного портала

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

Содержание

Введение

1. Основная часть

1.1 Определение методов реинжиниринга информационных систем

1.2 Построение диаграмм UML

1.3 Построение ER диаграмм

2. Разработка

2.1 Постановка задачи

2.2 Анализ предметной области

2.3 Инструментальные средства

2.3.1 Средства работы в среде MySQL

2.4 Выбор метода и его обоснование

2.5 Обоснование выбора программного обеспечения

2.6 Реализация иерархии пользователей

3. Результат работы

Выводы

Заключение

Список используемой литературы

Введение

В данной дипломной работе рассматривается проблема реинжиниринга баз данных в рамках разработки информационной системы (далее: ИС) для информационного портала. Особенностью данной задачи является необходимость провести модернизацию имеющейся БД информационного портала в связи с переходом на новую CMS (Content Management System) систему управления контентом на сайте для расширения его функциональных возможностей. Был проведен обзор существующих методов реинжиниринга, дано подробное описание различных этапов обратной разработки ИС, так как данный способ разработки является достаточно эффективным лишь для крупных проектов, а потому не используется повсеместно.

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

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

1. Основная часть

1.1 Определение методов реинжиниринга информационных систем

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

1. Полное и подробное описание системы с целью получения представления о всех ее компонентах;

2. Построение концептуальной модели работы информационной системы;

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

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

Основная задача реинжиниринга информационных систем:

1. Подробное описание архитектуры информационной системы;

2. Четкая иерархия пользователей данной системы;

3. Выделение функционала из изначальной системы;

4. Моделирование логической схемы информационной системы;

5. Нахождение и анализ реляционной модели базы данных.

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

Начало разработки

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

Модель будущей системы

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

Автоматический метод реинжиниринга

В ряде случаев исходные коды информационной системы, ожидающей модернизации, будут вам доступны. К примеру, файл SQL скриптов базы данных. В рамках работы над данным проектом нам доступна база данных bossbd.sql, содержащая весь перечень таблиц, которые устарели и требуют модернизации. Отправной точкой в данном вопросе будет автоматический реинжиниринг - построение ER-диаграмм средствами программного обеспечения для работы с базами данных. Данный метод помогает получить начальные сведения в графическом виде, которые улучшат представления о текущем составе информационной системы и дадут возможность их последующего редактирования. Функции обратной разработки позволят внести изменения в исходные коды базы данных, представленной в нотации ER-диаграмм, а в последствии обратно преобразовать изменения в скрипт SQL.

Обработка моделей, полученных после автоматического реинжиниринга

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

Определение функциональности информационной системы

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

Назначение пользователей и ролей

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

1) Кто будет использовать данную информационную систему и какие роли они будут выполнять?

2) Состав аппаратного и программного обеспечения, который будет использоваться при работе с модернизированной системой;

3) Находится ли данная информационная система в работе постоянно, или же некоторые события в ней происходят с течением времени, а один из пользователей будет выполнять роль таймера?

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

Варианты использования информационной системы

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

Установка соответствия между пользователями и вариантами использования

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

Установление иерархии пользователей и распределение их по группам

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

1) Если вариант использования применяется лишь для одного пользователя;

2) Пользователь и/или вариант использования включаются друг в друга или расширяют друг друга.

Детализация функциональности информационной системы

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

1.2 Построение диаграмм UML

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

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

1) Диаграмма использования;

2) Диаграмма классов;

3) Диаграмма автомата;

4) Диаграмма деятельности;

5) Диаграмма последовательности;

6) Диаграмма коммуникации;

7) Диаграмма компонентов;

8) Диаграмма размещения.

Диаграмма использования

Диаграмма использования призвана показать как данная информационная система соотносится с окружающим миром. Основные типы данных на данном виде диаграммы: пользователи и варианты использования.

Для реализации модели между ними выстраиваются различные типы отношений:

1) Связь между пользователем и вариантами использования;

2) Приведение к общему ключу всех действующих лиц;

3) Упорядочивание вариантов использования;

4) Установление зависимостей различных видов вариантов использования.

Рис. 1. Пример диаграммы использования

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

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

Использует в качестве сущностей классы и интерфейсы.

Для реализации модели выделяют следующие виды отношений:

1) Отношения между различными классами и их документирование;

2) Приведение различных классов к общему виду;

3) Описание разнообразных типов данных.



Рис. 2. Пример диаграммы классов

Диаграмма автомата

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

Рис. 3. Пример диаграммы автомата

Диаграмма деятельности

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

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

1) Развилка;

2) Слияние;

3) Ветвление.

Рис. 4. Пример диаграммы деятельности

Диаграмма последовательности

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



Рис. 5. Пример диаграммы последовательности

Диаграмма коммуникации

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

Рис. 6. Пример диаграммы коммуникации

Диаграмма компонентов

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

При построении модели используются следующие отношения между ними:

1) Взаимосвязь компонентов и интерфейсов;

2) Функциональные зависимости между компонентами системы.



Рис. 7. Пример диаграммы компонентов

Диаграмма размещения

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

Рис. 8. Пример диаграммы размещения

1.3 Построение ER диаграмм

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

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

Сущность всегда должна иметь имя.

Рис. 9. Пример сущности

Сущности представлены на модели информационной системы при помощи экземпляров. Экземпляр - конкретный объект представляющий заданную сущность. Приведем пример: экземпляром сущности "Ученик" будет являться "Ученик Сидоров".

Рис. 10. Сущность с атрибутами

В рамках построения информационной системы объекты имеют различные атрибуты. Обычно их бывает один или несколько. Атрибут - свойство, присущее данной сущности. Приведем пример для нашей сущности "Ученик": "Фамилия", "Имя", "Отчество", "Класс".

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

Различают три типа связей:

1) 1-к-1. В данном виде связи экземпляр первого объекта связан с одним экземпляром второго объекта. Как правило, от таких связей следует отказаться;

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

3) n-к-n. При такой связи несколько экземпляров первого объекта связано с несколькими экземплярами второго объекта. На практике это означает, что система находится в промежуточном этапе разработки и при дальнейшем анализе данный вид связи будет заменен на 1-к-n с созданием промежуточных сущностей и переназначением связей.

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

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

1) Списка объектов;

2) Списка связанных атрибутов объектов;

3) Построения корректных взаимосвязей между различными объектами.

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

1) Концептуальные;

2) Физические.

Рис. 11. Пример концептуальной модели

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

Рис. 12. Пример физической диаграммы

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



2. Разработка

2.1 Постановка задачи

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

Формулировка требований:

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

2. Создать раздел отвечающий за работу модуля карт на основе Google Maps.

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

4. Унифицировать различные разделы базы данных, исключить дублирование контента.

5. Привести базу данных SQL к виду, пригодному для работы CMS WordPress.

2.2 Анализ предметной области

Наша работа связана с использованием CMS WordPress. Данная платформа предназначена для персонального блоггинга и разработки модульных веб-сайтов.

Требования CMS WordPress:

1) PHP 5.2.4 или выше;

2) MySQL 5.0.2 или выше.

CMS WordPress устанавливается на собственном Web-сервере. Данная CMS использует API WordPress который обеспечивает покрытие всего спектра основных задач веб-разработки. Ниже приведем ER диаграмму базы данных CMS WordPress [7]:

Рис. 13. ER-диаграмма стандартной базы данных CMS WordPress

2.3 Инструментальные средства

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

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

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

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

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

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

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

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

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

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

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

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

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

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



2.3.1 Средства работы в среде MySQL

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

MySQL Workbench

Имеет версию для Mac Os X. Распространяется бесплатно. Встроенная функция обратной разработки. Возможность построения функциональных диаграмм баз данных. Не имеет открытой лицензии.

Функциональные возможности:

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

2) Инструментарий графического редактора для создания связей таблиц. Возможность разработки таблицы связей.

3) Возможность обратной разработки при помощи модуля RE. Производит построение ER-диаграмм из скриптов SQL реализованных ранее;

4) Умный редактор, позволяющий работать с запросами SQL.

Navicat

Имеет версию для Mac Os X. Стоимость 199-379$. Не имеет встроенной функция обратной разработки. Возможность построения функциональных диаграмм баз данных. Не имеет открытой лицензии.

Функциональные возможности:

1) Визуальный редактор позволяющий конструировать запросы к базе данных;

5) Возможность резервного копирования, а так же импорта и экспорта таблиц баз данных;

6) Встроенный редактор позволяющий создавать отчеты;

7) Помощник в миграции больших проектов;

8) Имеет инструментарий продвинутого планирования разработки.

PHPMyAdmin

Имеет версию для Mac Os X. Распространяется бесплатно. Не имеет встроенной функция обратной разработки. Не имеет возможности строить функциональные диаграммы. Распространяется по открытой лицензии с доступным программным кодом.

Функциональные возможности:

1) Веб-интерфейс позволяет с легкость переносить его на любые программные платформы;

2) Позволяет управлять выделенными базами данных удаленно;

3) Возможность неограниченной интеграции в собственные разработки.

dbForge Studio for MySQL

Версия только для MS Windows. Распространяется бесплатно, есть платная расширенная версия. Не имеет встроенной функция обратной разработки. Визуальный редактор для построения функциональных диаграмм. Не имеет открытой лицензии.

Функциональные возможности:

1) Программные средства, предназначенные для осуществления центрального администрирования;

2) Инструментарий для сравнения двух разных баз данных;

3) Визуальный редактор для профилирования различных запросов к базе;

4) Инструментарий настройки пользовательских привилегий;

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

HeidiSQL

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

Функциональные возможности:

1) Позволяет выполнять подключение к серверу базы данных при помощи командной строки;

2) Инструментарий оптимизации пакетов и восстановления таблиц базы данных;

3) Сервис для форматирования и упорядочивания SQL;

4) Инструментарий для синхронизации таблиц разных баз данных.

SQL Maestro для MySQL

Версия только для MS Windows. Стоимость от 99 до 1949$. Не имеет встроенной функция обратной разработки. Нет возможности построения функциональных диаграмм. Не имеет открытой лицензии.

Функциональные возможности:

1) Конструктор для проектирования и реализации баз данных;

2) Инструментарий для сортировки и упорядочивания данных внутри базы данных;

3) Инструментарий для создания и реализации запросов к базе данных.

EMS SQL Manager

Версия только для MS Windows. Распространяется бесплатно. Существует платная версия с расширенным функционалом по цене от 95 до 245$. Не имеет встроенной функция обратной разработки. Нет возможности построения функциональных диаграмм. Не имеет открытой лицензии.

Функциональные возможности:

1) Поддержка ввода данных в кодировке UTF8;

2) Инструментарий для простого управления различными объектами MySQL;

3) Графический интерфейс для работы с текстовыми запросами и консолью;

4) Инструментарий для создания и генерации отчетов.

SQLyog

Версия для MS Windows и Linux. Стоимость от 99 до 1499$. Не имеет встроенной функция обратной разработки. Нет возможности построения функциональных диаграмм. Не имеет открытой лицензии.

Функциональные возможности:

1) Продвинутый конструктор запросов к базе данных;

2) Инструментарий синхронизации таблиц различных баз данных;

3) Возможность использования юникода.

DBTools Manager

Версия только для MS Windows. Распространяется бесплатно, предусмотрена расширенная платная версия. Не имеет встроенной функция обратной разработки. Есть инструментарий построения функциональных диаграмм. Не имеет открытой лицензии.

Функциональные возможности:

1) Удаленное управление базами данных и таблицами;

2) Инструментарий редактирования запросов SQL;

3) Мастер для создания и управления отчетами и формами;

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

MyDB Studio

Версия только для MS Windows. Распространяется бесплатно. Не имеет встроенной функция обратной разработки. Нет возможности построения функциональных диаграмм. Имеет открытую лицензию.

Функциональные возможности:

1) Возможность одновременного подключения к неограниченному числу баз данных;

2) Предусмотрен экспорт баз данных в разнообразные форматы;

3) Инструментарий для переноса, резервного копирования и создания резервных копий [8].



2.4 Выбор метода и его обоснование

Для решения поставленных задач используются следующие методы:

1) Иерархия пользователей будет определена при помощи построения UML диаграммы, для последующей обработки и создания необходимых таблиц в БД;

2) Существующая БД будет обработана методом автоматического реинжиниринга, поскольку данный метод является наиболее оптимальным при наличии доступа к исходным кодам проекта;

3) Обработка модели будет произведена на редакторе физических моделей, методом, описанным в разделе "Построение ER диаграмм". В нашем случае одной концептуальной модели будет недостаточно, поскольку мы проектируем информационную систему.

4) Преобразование физической диаграммы в исходные коды MySQL будут проведены на программном обеспечении, выбранном на основе установленных исследованием критериев.

2.5 Обоснование выбора программного обеспечения

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

К средствам моделирования применяются следующие требования:

1) Работа будет выполняться на iMac 27" late 2012, поэтому программное обеспечение должно поддерживать OS X Yosemite 10.10.3;

2) Бюджет работы ограничен, поэтому программное обеспечение должно распространяться бесплатно;

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

4) Необходимо наличие функции Reverse Engineering (реинжиниринга) для автоматической генерации физической ER диаграммы базы данных;

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

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

Таблица 1

Критерии отбора программного обеспечения

	OS X версия	Бесплатная версия	Reverse Engineering	Свободное ПО	ER диагр.
Workbench	Да	Да	Да	Нет	Да
Navicat	Да	Нет	Нет	Нет	Нет
PHPMyAdmin	Да	Да	Нет	Да	Нет
dbForge Studio	Нет	Да	Нет	Нет	Да
HeidiSQL	Нет	Да	Нет	Да	Нет
SQL Maestro	Нет	Нет	Нет	Нет	Да
EMS SQL Manager	Нет	Да	Нет	Нет	Нет
SQLyog	Нет	Да	Нет	Нет	Нет
DBTools Manager	Нет	Да	Нет	Нет	Нет
MyDB Studio	Нет	Да	Нет	Да	Нет

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



2.6 Реализация иерархии пользователей

Обновленная база данных должна иметь продвинутую структуру пользователей для использования на информационном портале под управлением новой CMS. Для построения ее модели нами будет применено UML моделирование.

Структура пользователей сайта под управлением CMS WordPress должна иметь следующую структуру:

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

2) Редактор. Редактирует записи в блоге. Создает и редактирует новые записи без ограничений предварительной модерации.

3) Автор. Создает новые статьи в блоге с возможностью их редактирования. Статьи добавляются на сайт только после предварительной модерации.

4) Участник. Может редактировать свой профиль и оставлять комментарии. Его именем могут быть подписаны записи в блоге.

5) Подписчик. Может оставлять комментарии на сайте, авторизовываться, участвовать в голосовании.

Данную структуру пользователей можно представить в виде модели:



Рис. 14. Диаграмма иерархии пользователей UML

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

Средства реинжиниринга MySQL Workbench

Программные средства MySQL Workbench позволяют построить первичную ER диаграмму из существующего SQL скрипта.

Необработанная база данных не содержит связей и имеет следующий вид:



Рис. 15. ER-диаграмма сгенерированная при помощи автоматического реинжиниринга

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

Вот перечень имеющихся таблиц и их назначение:

1) commentmeta, comments - хранят информацию о комментариях;

2) gg_folders, gg_galleries, gg_galleries_excluded, gg_galleries_resourses, gg_photos, gg_photos_pos, gg_photos_settings, gg_photos_presets, gg_settings_sets, gg_stats - таблицы надстройки Grid Gallery для управления и настроек изображений, галереи фотографий и их миниатюр. В системе CMS WordPress будет использоваться аналог, поэтому данные таблицы использоваться не будут;

3) links - используется для хранения ссылок;

4) options - таблица настроек;

5) postmeta - хранение мета-тегов записей;

6) posts - содержимое записей;

7) terms - ассоциация с категориями;

8) term_taxonomy - описывает метки ссылки и категории;

9) usermeta - пользовательские теги;

10) users - информация о пользователях.

Помимо данных таблиц требования предписывают создать дополнительную структуру базы данных для хранения данных карт на основе Google Maps, которые так же могли бы использоваться в записях нашего ресурса. Для начала отредактируем структуру нашей базы таким образом, чтобы она соответствовала требованиям CMS WordPress.

Для этого удалим лишние таблицы и составим функциональную диаграмму из необходимых элементов:

Рис. 16. Функциональная диаграмма модернизированной БД

Данную диаграмму необходимо дополнить таблицами данных модуля карт Google.

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

1) wpgmza - таблица, описывающая работу модуля карт и хранящая необходимые сервисные данные;

2) wpgmza_categories - таблица хранящая настройки категорий карт;

3) wpgmza_category_maps - хранит в себе настройки карт принадлежащих к той или иной категории;

4) wpgmza_maps - данная таблица хранит в себе настройки, маркеры, установленные координаты, прочую сервисную информацию;

5) wpgmza_polygon - хранит координаты для построения полигонов на картах;

6) wpgmza_polylines - хранит координаты для построения линий на картах.

Выглядят данные элементы следующим образом:

Рис. 17. Представление таблиц модуля в классической нотации ER диаграмм

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



Рис. 18. ER диаграмма таблиц хранящих информацию модуля карт Google

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



Рис. 19. Связь элементов модуля карт с общей функциональной диаграммой

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



3. Результат работы

После установки обновленной базы данных на сервер CMS WordPress была запущена на хостинге и подключена. Ниже следуют примеры изменений.

Обновленная иерархия пользователей

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

Рис. 20. Интерфейс добавления нового пользователя

Обновленная БД

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



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

Модуль Google Maps

Модуль Google Maps корректно работает с обновленной базой данных. На данный момент карт на портале нет, однако функционал модуля позволяет создавать их и добавлять в записи и на страницы там, где это будет необходимо. База данных хранит информацию о пользовательских маркерах, их координатах, описаниях места расположения.

Рис. 22. Интерфейс карты Google



Рис. 23. Интерфейс создания меток

Несколько слов об информационном портале Warboss.ru

Информационный портал Warboss.ru обозревает новости связанные с миром настольных игр с миниатюрами и моделированием. Портал призван давать широкую информацию по последним новостям компаний-производителей, обозревать жизнь сообщества, давать своевременную информацию о мероприятиях, проводимых в городах России и в странах СНГ. Данный портал был разработан на базе CMS WordPress в качестве наглядного пособия по модернизации структуры базы данных, выполненной в данной работе. Все материалы, использованные на данном портале принадлежат его создателям, если не указано иное.



Выводы

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

Тема обратной разработки (реинжиниринга) раскрыта в Российских изданиях недостаточно, поскольку данный подход обычно используется для крупных проектов, по этой причине были задействованы зарубежные источники в виде документации к программным средствам MySQL Workbench.

Поставленные требования в данной работе были выполнены полностью.



Заключение

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

Список используемой литературы

1. Открытые системы. Реинжиниринг баз данных. URL: [http://www.osp.ru/os/2004/04/184169/] (дата обращения 13.04.2015)

2. Портал Informicus. Реинжиниринг программных систем. URL: [http://www.informicus.ru/Default.aspx?SECTION=6&id=73&subdivisionid=10] (дата обращения 15.04.2015)

3. CitForum. Silverrun. URL: [http://citforum.ru/database/case/glava5_1_1.shtml] (дата обращения 20.04.2015)

4. Ю. Новоженов. Опыт реинжиниринга объектно-ориентированного комплекса программ с применением CASE-средства Rational Rose и SILVERRUN. URL: [http://citforum.ru/programming/prg96/97.shtml] (дата обращения 20.04.2015)

5. Д. Иванов, Ф. Новиков. Моделирование на UML. URL: [http://book.uml3.ru/] (Дата обращения 21.05.2015)

6. CitForum. Основные понятия ER-диаграмм. URL: [http://citforum.ru/database/dblearn/dblearn08.shtml] (дата обращения 21.05.2015)

7. Документация CMS WordPress. URL: [http://wordpress.org] (дата обращения 22.04.2015)

8. Портал Habrahabr. 10 лучших инструментов для разработки и администрирования MySQL. URL: [http://habrahabr.ru/post/142385/] (дата обращения 22.05.2015)

9. Портал Creately. Построение UML диаграмм. URL: [https://creately.com/] (дата обращения 22.05.2015)

10. WordPress Support Forums. URL: [https://wordpress.org/support/topic/photos-wont-upload-5] (дата обращения 22.05.2015)

11. MySQL Workbench Documentation. Reverse Engineering. URL: [http://dev.mysql.com/doc/workbench/en/wb-reverse-engineering.html] (дата обращения 20.04.2015)

12. PHPMyAdmin Documentation. URL: [http://www.phpmyadmin.net/home_page/docs.php] (дата обращения 22.05.15)

13. Gliffy User Manual. URL: [https://www.gliffy.com/user-manual/] (дата обращения 22.05.2015)

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

...