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

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

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

Введение

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

– с проверкой работоспособности системы после скачивания (pull) и слияния (merg) изменений с сервера;

– с идентификацией ошибки (в случае наличия);

– с поиском сохранённого Data Definition Language (далее - DDL) запроса в соответствующей папке;

– с выполнением запроса для нивелирования различий в структурах баз данных либо через графический интерфейс системы управления базой данных (далее - СУБД), либо непосредственно через командную строку СУБД;

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

– с ситуацией, когда один из сотрудников изменил структуру БД, но забыл добавить соответствующий DDL запрос в папку или неправильно его оформил;

– с ошибками программирования.

В отделе разработок компании в настоящее время работают 11 программистов. У каждого сотрудника есть своё рабочее место - ПК или ноутбук, на котором установлены:

– операционная система (Windows);

– локальный сервер (Apache2.4 или IIS);

– интерпретатор языка Personal Home Page (PHP) (v.5.4);

– система управления базами данных (СУБД) (MySQL 5.6);

– графическое приложение для работы с СУБД (HeidiSQL v.9.3);

– текстовый редактор (SublimeText v.3.0);

– система контроля версий Mercurial (Tortoise HG v.3.5).

Помимо этого есть общий сервер (production), работающий на Linux Debian, на котором также установлены:

– интерпретатор языка PHP (v.5.4);

– СУБД MySQL (5.6);

– система контроля версий Mercurial (Tortoise HG v.3.5).

Структура БД на сервере является эталонной.

По мере необходимости программисты добавляют (удаляют, изменяют) поля, данные, индексы, триггеры, хранимые процедуры, представления, формируя из Data Manipulation Language (далее - DML) или DDL - запросов (changesets) текстовые файлы, которые сохраняются в отдельную папку. Затем происходит фиксация проделанной работы через систему контроля версий и изменения «выкладывается» на сервер. Далее, на сервере выполняется сохранённый changeset. Таким образом, структура БД на сервере изменяется.

Остальные программисты скачивают изменения с сервера, производят слияние (merge) и формы становятся у всех идентичными (в том числе и папка с сохранёнными changeset-ами).

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

– пользователь, скачавший изменение с сервера, не посмотрел, какие файлы были изменены, т.к. каждый программист занимается своей частью работы;

– пользователь, сделавший фиксацию изменений (commit) забыл добавить sql-файл на изменение БД;

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

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

Актуальность задачи можно обосновать следующим образом:

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

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

– Сложность поддержки работоспособности системы при установке на объекты с классом секретности, на которых отсутствует доступ в интернет.

– Увеличение числа сотрудников влечёт за собой увеличение затраченного времени на поиск и устранение ошибок.

Создание системы позволит:

– снять с программистов необходимость отдельно фиксировать изменения в структуре БД;

– отслеживать изменения сделанные другими сотрудниками;

– освободит время на поиск и устранение ошибок, связанных с версионной миграцией БД;

– позволит хранить историю изменения БД в xml файлах;

– позволит мигрировать структуру рабочей БД на любую другую СУБД.

Со стороны организации ООО «БРеалИТ» (далее заказчик) к разрабатываемой АИС были предъявлены следующие требования:

– Должна иметь настройку запуска: запускаться сразу после скачиваний изменений с сервера или по решению пользователя.

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

– Должна предоставлять пользователю выбор действий (выполнить запросы сейчас или отложить выполнение).

– Для переносимости между различными СУБД, структура БД должна храниться в XML-файле.

– Файлы со структурой БД и историей её изменения должны находиться под СКВ чтобы, в случае необходимости, можно было откатиться на предыдущую ревизию.

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

– Должна иметь возможность сравнения структуры выбранной БД и файла со структурой БД.

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

– Должно быть руководство пользователя.

– Должна быть бесплатной.

– Должна быть кроссплатформенной.

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

Compalex.

Рис. 1 -- Внешний вид окна с результатом работы программы Compalex

Система Compalex (Рис. 1) сравнивает структуру двух баз данных, результат сравнения выводит пользователю через графический интерфейс. Однако данная программа предназначена исключительно для сравнения структуры БД и:

– не может сохранить результаты в файл и, соответственно, не может работать с СКВ;

– не позволяет выполнить sql запрос для сглаживания различий;

– запускается только в ручном режиме;

– необходимо каждый раз указывать название базы данных.

LIQUIBASE

Рис. 2 -- Логотип программы Liquibase

Система LIQUIBASE (Рис. 2) позволяет вести изменение БД. История изменений хранится в xml файле. Однако данная программа:

– не позволяет сравнивать структуру двух разных баз;

– работает с СКВ Git, а проект заказчика поддерживается системой контроля версий Mercurial;

– является платной;

– имеет сложный синтаксис выполнения команд (Рис. 3);

– недостаточная документация по системе.

Рис. 3 -- Пример ввода команды в программе Liquibase

Flayway.

Рис. 4 -- Логотип программы Flayway

Система Flayway (Рис. 4). Из особенностей можно отметить, что данная программа может вести журнал изменений базы данных, работает через интерфейс командной строки, имеет множество дополнительных функций. Из минусов:

– не позволяет сравнивать две базы данных;

– сложная установка;

– документация и интерфейс не поддерживает русский язык;

– исходные коды не открыты.

Rails

Рис. 5 - Логотип программы Rails

Система Rails (Рис. 5) позволяет сравнивать две базы данных, история изменений хранится в отдельном файле, работает через интерфейс командной строки, быстро выполняется скрипт, позволяет абстрагироваться от конкретной СУБД. Однако, имеет ряд особенностей, из-за которых не может использоваться в качестве решения поставленной задачи:

– написана на языке программирования Ruby, а в ООО «БРеалИТ» (компания - заказчик) нет штатной должности по данному направлению и поддержка системы «своими силами» не представляется возможной;

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

Dbdeploy.

Рис. 6 - Логотип программы Dbdeploy

Dbdeploy (Рис. 6) хранит всю историю изменений в отдельных xml файлах, имеет открытый исходный код. Из минусов:

– не работает через командную строку;

– нет возможности сравнить две различные базы данных;

– не показывает тот sql запрос, который необходимо выполнить для нивелирования различий между БД.

MySQL Workbanch.

Рис. 7 - Логотип программы MySQL Workbanch

MySQL Workbanch (Рис. 7) является программой для управления базами данных MySQL и MSSQL и может использоваться в качестве графического интерфейса. Позволяет сохранять изменения базы данных, не запуская дополнительного ПО, имеет отличную документацию и техническую поддержку, но имеет ряд недостатков, не позволяющих использовать данное решение в конкретной задаче:

– не хранит структуры БД в xml документе;

– не работает через командную строку;

– компания - заказчик использует другое ПО для управления базой данных;

– инструмент миграции выполнен в качестве библиотеки к MySQL Workbanch.

MySQL Migration with PHP.

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

– создавать ALTER (CREATE, DROP) скрипты в читабельном виде;

– хранить структуру базы данных в xml файле;

– работать под контролем СКВ.

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

1. Выбор средств разработки

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

– Язык программирования PHP 5.4;

– Модернизированный и усовершенствованный вариант командной оболочки для Unix систем - Bash;

– Пакетные файлы (batch file);

– Расширение SimpleXML в PHP;

– СУБД MySQL 5.6;

– Библиотека MySQLi в PHP для расширения функциональности при работе с MySQL;

– Система контроля версий Mercurial HG;

– Программа для работы и управления базой данных HeidiSQL;

– Инструмент слияния и сравнения для Windows - WinMerge.

Язык PHP.

PHP (англ. PHP: Hypertext Preprocessor «PHP: гипертекста препроцессор»; изначально Personal Home Page Tools -- «Инструменты для создания персональных web-страниц») -- скриптовый язык программирования общего назначения, повсеместно применяемый для разработки и поддержки web-приложений. В настоящее время поддерживается практически каждым хостинг-провайдером и является одним из лидеров среди языков программирования, используемых для создания динамических web-сайтов.

При написании данного дипломного проекта я использовал язык PHP, потому как он является одним из самых распространённых языков, используемых в web-разработке, по нему есть огромное количество документации, доступной, в том числе на русском языке, создано большое количество различных библиотек. Кроме того, согласно штатному расписанию компании заказчика, 7 из 11 сотрудников владеют данным языком программирования, что особенно важно для поддержки и дальнейшего развития разработанной АИС.

К недостаткам PHP можно отнести производительность. В среднем при обращении к скрипту PHP использует приблизительно 2 Мб оперативной памяти, т.е. при одновременном обращении к серверу 1800 запросов одновременно сервер может «упасть». Однако такая ситуация в принципе невозможна, т.к. разрабатываемая АИС будет запускаться на локальных серверах сотрудников и на сервере компании, а число пользователей АИС равно числу программистов ООО «БРеалИТ».

База данных MySQL

MySQL - свободная реляционная система управления базами данных. MySQL является наилучшим решением для малых и средних проектов, использующих СУБД. Поддерживает большое количество типов таблиц, в том числе MyISAM, с поддержкой полнотекстового поиска, InnoDB, с поддержкой транзакций на уровне отдельных записей, типа Merge, позволяющей разбить большую таблицу на несколько небольших, за счёт чего увеличивается скорость работы, типа Federated, позволяет «связать» серверы MySQL таким образом, что получилась одна логическая база данных.

Для получения данных в MySQL используется язык запросов SQL. Версия базы данных 5.6 использует модификацию стандарта SQL - 2003.

Достоинства MySQL:

– Компактная.

– Если продукт не продаётся - бесплатная.

– Имеет application programming interface (API), по средствам которого может очень быстро взаимодействовать с приложением.

– Имеет встроенный сервер.

Недостатки:

– Надёжность таблицы типа MyISAM. При достижении размера в 10 Гб может «упасть»;

– Таблицы InnoDB поддерживают до 1 ТБ, однако они гораздо медленнее MyISAM;

– MyISAM таблицы поддерживают полнотекстовый поиск, но не поддерживают транзакции, а таблицы InnoDB поддерживают транзакции, но не поддерживают полнотекстовый поиск.

Интерфейс командной строки.

Интерфейс командной строки (англ. Command line interface, CLI) -- разновидность текстового интерфейса между человеком и компьютером, в котором инструкции компьютеру даются путём ввода с клавиатуры текстовых строк (команд). Также распространено название консоль.

Достоинства командной строки:

– Естественное расширение интерфейса командной строки -- пакетный интерфейс. Означает, что в обычный текстовый файл, в определённом формате записывается последовательность команд, после чего этот файл можно выполнить в программе. Получится такой же эффект, как если бы эти команды были по очереди введены в командную строку. Например, shell - скрипты в Unix - системах, .bat - файлы в Windows.

– Значительно меньший расход памяти в сравнении с системой меню.

– Можно работать на выделенном сервере, т.е на операционных системах, не имеющих графического интерфейса.

– Есть возможность просмотра сообщений об ошибках работы программы или сообщений программы, путём пролистывания консоли.

– Для просмотра ранее введённых команд и их повторного выполнения можно пользоваться кнопками «^» и «v».

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

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

Недостатки командной строки:

– Данный вид интерфейса нельзя назвать «дружелюбным» для пользователей.

– Необходимо запоминать сокращения и учить команды.

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

XML.

XML (англ. eXtensible Markup Language - расширяемый язык разметки). Средство для описания документа. К достоинствам данной разметки можно отнести то, что:

– Позволяет стандартизировать внешний вид хранения данных визуально наиболее понятных для человека;

– Поддерживает Юникод;

– Возможность описать имена и структуру полей;

– Рекомендован Консорциумом Всемирной паутины (W3C);

– Абсолютно свободен в части требований по расположению атрибутов в элементах;

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

– Поддержка на низком программном уровне.

Из недостатков можно выделить следующие:

– Избыточный синтаксис;

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

– Нет поддержки типов данных.

Система управления версиями Mercurial.

Mercurial (c англ. -- «ртутный, подвижный»), помимо этого названия известен как Hg -- кроссплатформенная распределённая система управления версиями, была разработана в 2005 году для работы с проектами, имеющими большие репозитории кода. В основном Hg является программой работающей через консоль, но для облегчения использования можно использовать графический интерфейс TortoiseHg (Рис. 8).

Рис. 8 -- Внешний вид диалогового окна программы TortoiseHg

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

Программа для работы и управления базой данных HeidiSQL.

HeidiSQL является бесплатной графической (Рис. 9) оболочкой для управления базами данных MSSQL и MySQL. Позволяет создавать, редактировать, удалять таблицы, триггеры, процедуры, представления. Поддерживает подключение к нескольким серверам одновременно (Рис. 10) позволяет экспортировать выбранные в таблице строки в различные форматы: CSV, XML, SQL, HTML и массивы PHP. В данной дипломной работе HeidiSQL применялась для удобства тестирования и проверки корректности работы разрабатываемой АИС.

Рис. 9 -- Внешний вид графической оболочки HeidiSQL

Рис. 10 -- Пример подключения HeidiSQL к нескольким серверам одновременно

Инструмент слияния и сравнения для Windows - WinMerge.

WinMerge является инструментом, предназначенным для сравнения файлов в ОС Windows. Имеет прекрасный графический интерфейс (Рис. 11) и обладает широкими возможностями при сравнении файлов:

ѕ имеет визуальную подсветку при наличии различий в файлах;

ѕ обнаруживает перемещённые строки;

ѕ позволяет создавать фалы с патчами в различных форматах;

ѕ имеет готовое HTML -- руководство.

Программа WinMerge, также как и HeidiSQL использовалась при тестировании разрабатываемой АИС.

Рис. 11 -- Пример работы программы WinMerge 2.0.14

2. Использованные библиотеки и сторонние модули

SimpleXML.

В PHP версии 5.0 и выше появилось расширение для работы с xml структурой. Библитека SimpleXML содержит большое количество методов для работы с xml документами.

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

Очевидны и плюсы при работе с данным модулем:

– большое количество наличие уже готовых к использованию методов;

– простота использования;

– лёгкость чтения полученных данных;

– быстрота обработки;

– возможность работать с данными в виде объектов.

MySQLi.

Расширение MySQL для PHP является устаревшим и, в качестве альтернативы, было выбрано расширение MySQLi по следующим причинам:

– поддерживает объектно-ориентированный интерфейс;

– существует поддержка подготавливаемых запросов;

– поддерживает выполнение мультизапросов;

– поддерживает транзакции;

– введены улучшенные возможности отладки;

– данное расширение рекомендуется для использования самими разработчиками языка PHP [13_Список_использованной_литературы]

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

3. Использованные языковые парадигмы

Использование парадигмы ООП.

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

Обозначение переменных.

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

– лёгкость запоминания идентификатора -- мнемоническое значение;

– по возможности роль переменной должна читаться из названия -- смысловое значение;

– похожим переменным рекомендуется давать похожие идентификаторы -- преемственность;

– появление, внедрение и редактирование переменной не должно занимать большого количества времени;

– внедряемый идентификатор не должен быть слишком громоздким.

Таблица 1. Пример используемых префиксов венгерской нотации

Приставка	Тип переменной	Пример использования
s	строковый (string)	$sTab -- название вкладки
i	числовой (int)	$iTab -- порядковый номер вкладки
a	массив (array)	$aTab -- информация о вкладке, хранящаяся в массиве. Например, его свойства.
r	жесткая ссылка (&)	$arTabCurrent -- символьная ссылка на массив, содержащий информацию о вкладке.
aa	массив, содержащий в своих элементах другой массив (array of array)	$aaTabFields -- массив массивов, содержащих информацию о полях, находящихся во вкладке.

4. Разработка АИС

Алгоритм работы.

В результате работы АИС генерируются три xml документа - два со структурой сравниваемых баз данных и один с результатами сравнения. В зависимости от переданных параметров система АИС может зафиксировать текущее состояния БД, показать, что изменилось с момента последней фиксации, сгенерировать запрос для унификации БД и выполнить его. Так же формируется история изменений структуры БД в виде отдельных changeset-файлов, хранящихся также в репозитории СКВ.

Для создания xml файла со структурой БД необходимо иметь доступ к чтению служебной базы данных MySQL information_schema. Название базы и файл, в который будет записана структура, передаются в качестве параметров при вызове qdb create.

Алгоритм работы АИС можно разделить на несколько частей:

ѕ при внесении изменений в текущий проект;

ѕ при скачивании изменений с сервера и объединении проекта.

Внутреннее устройство АИС.

АИС состоит из нескольких частей:

а) Команды запуска:

– qdb.bat;

– qdb.sh;

– start.php.

б) Используемые команды:

– qdb init;

– qdb create;

– qdb status;

– qdb run;

– qdb commit;

– qdb update.

в) Используемые классы:

– qcreatedatabase;

– qdatabase;

– qchangeset;

– qshow;

– qbuild.

г) Файлы и папки со структурой БД и историей её изменений:

– database.xml;

– databaseOld.xml;

– databaseLastRevision.xml;

– папка changesets;

– done_changesets.txt;

– файлы истории изменений вида changeset.date.username.time.xml

Команды qdb.bat и qdb.sh выполняют одинаковую функцию -- получают параметры, передаваемые пользователем, и перенаправляют их в файл start.php. Разница в написании этих двух файлов заключается в том, что «qdb.bat» запускается в ОС Windows, а «qdb.sh» -- в Unix системах. Т.к. при установке АИС в переменную окружения “PATH” добавляется путь к папке с дистрибутивом «qdb», то при работе с АИС указывать расширение файлов необязательно.

Файл start.php обрабатывает получаемые параметры и, в случае корректного вызова команды, передаёт управление в соответствующий файл. В случае, когда вызов команды производится с ошибкой (Рис. 12), пользователю предлагается ознакомиться с правилом вызова команд (Табл. 2).

Рис. 12 -- Пример вывода сообщений пользователю

Таблица 2. Возможные ключи для вызова qdb команд при работе с АИС

init	Используется для инициализации проекта.
create	Создаёт исходный вариант структуры БД.
status	Показывает текущее различие между xml документом со структурой БД и физической структурой БД.
run	Если есть различия, то генерирует DDL запрос к БД и выполняет его.
commit	Фиксирует проделанные изменения и добавляет файлы под контроль СКВ.
update	При скачивании изменений с сервера автоматически определяет разницу между структурами БД сервера и ПК разработчика.

Класс qcraetedatabase используется для создания xml структуры базы данных. Он содержит массив со значениями по умолчанию для всех типов полей MySQL. Подключение к базе данных и выборка данных производится с помощью класса «mysqli». Xml файл формируется с помощью расширения SimpleXML.

Класс qdatabase предназначен для преобразования xml файла со структурой БД в объект, получения массива объектов значений по умолчанию для различных типов полей, получения типа колонки по её названию, получения используемых ключей и индексов.

Класс qchangeset предназначен для получения и записи результатов сравнения двух файлов xml со структурой БД итоговый xml файл.

Класс qshow преобразует xml файл с изменениями в объект и предоставляет пользователю результат сравнения в удобочитаемом виде.

Класс qbuild, также как и класс qshow, преобразует xml файл с изменениями в объект, но результат подготавливает в виде уже сформированного sql запроса, который необходимо выполнить для устранения различий в структуре БД.

qdb init - используется для инициализации проекта. При выполнении данной команды, в директории запуска создаётся метка - папка «.qdb». В этой папке будут храниться файлы с данными (Рис. 13):

– database.xml - содержит структуру используемой базы данных в xml формате. Предполагается что добавление (изменение, удаление) таблиц, полей, индексов будет проводиться не через программу HeidiSQL, а напрямую в данном файле;

– databaseOld.xml - также содержит структуру используемой базы данных в xml формате и служит для получения различий между текущей версией БД и структурой БД до выполнения предыдущих DDL запросов;

– databaseLastRevision.xml - аналогично двум вышеуказанным файлам содержит структуру БД в xml формате и, так же как и databaseOld.xml, служит для получения различий, но в отличие от databseOld.xml файл databaseLastRevision.xml содержит структуру БД, хранящуюся с предыдущей фиксации;

– changeset4qdb_build.xml - содержит изменения, сделанные с предыдущей фиксации или с предыдущего выполнения запросов

– папка changesets - в данной папке содержатся sql файлы истории изменений, которые автоматически формируются при фиксации работы;

– done_changesets.txt - список выполненных DDL запросов на текущем компьютере из папки changesets.

Рис. 13 -- Пример работы команды qdb init

qdb create необходим при подготовке к работе АИС. Создаст файл database.xml, databaseOld.xml и databaseLastRevision.xml со структурой БД (Рис. 14). Данную команду можно также использовать в случае необходимости создания xml файла с другой базой данных. В этом случае необходимо запустить qdb create с соответствующими ключами (Табл. 3).

Рис. 14 -- Пример работы команды qdb create

Таблица 3. Возможные ключи при вызове команды qdb create

Ключ	Значение по умолчанию	Описание	Пример
-db	asupb2	Название базы данных, структуру которой необходимо сделать.	qdb create -db db_name.
-f	database.xml	Название файла, в который будет записана структура.	qdb create -f file_name.xml
-h	localhost	Название хоста для подключения к БД.	qdb create -h ssh://user@asupb:22/
-u	asupb	Имя пользователя для подключения к БД.	qdb create -u user_name
-p	`'	Пароль пользователя для подключения к БД.	qdb create -p *****

Qdb status показывает текущие различия (Рис. 15) и формирует файл changeset4qdb-build.xml (Рис. 16). Qdb status также может запускаться с различными ключами (Табл. 4).



Рис. 15 -- Пример работы команды qdb status

Рис. 16 -- Содержание файла changeset4qdb_build.xml после выполнения команды qdb status

Таблица 4. Возможные ключи при вызове команды qdb status

Ключ	Значение по умолчанию	Описание	Пример
-f1	database.xml	Название файла со структурой БД которую меняем.	qdb status -f1 first_file.xml
-f2	databaseOld.xml	Название файла со структурой БД с которой сравниваем.	qdb status -f2 second_file.xml
-f3	databaseLastRevision.xml	Название файла со структурой БД с которой сравниваем при вызове qdb status с ключом «-a».	qdb status -f3 third_file.xml
-a	bool false	Используется при сравнении файла с текущей структурой БД, и файла, сделанного при последней фиксации.	qdb status -a

Qdb run формирует из файла changeset4qdb-build.xml DDL запрос и в зависимости от переданных ключей (Табл. 5) либо показывает в читабельном виде пользователю (Рис. 17), либо выполняет его в СУБД (Рис. 18).

Рис. 17 -- Пример работы команды qdb run с ключом «show»

Рис. 18 -- Пример работы команды qdb run без ключей

Таблица 5. Возможные ключи при вызове команды qdb run

Ключ	Значение по умолчанию	Описание	Пример
-show	bool false	Формирует sql запрос для выполнения в БД и выводит пользователю на экран.	qdb run -show
-f	database.xml	Название файла, в который будет записана структура.	qdb run -f file_name.xml
-h	localhost	Название хоста для подключения к БД.	qdb run -h ssh://user@asupb:22/
-u	asupb	Имя пользователя для подключения к БД.	qdb run -u user_name
-p	`'	Пароль пользователя для подключения к БД.	qdb run -p *****

Qdb commit вызывает команду qdb status с ключом «-а» (Табл. 4), если изменения в структуре есть, то вызывается команда qdb run (Табл. 5) . Далее фиксируются изменения о проделанной работе (Рис. 19): создаётся xml файл, название которого генерируется автоматически в формате «changeset.YYYY-mm-dd.username.hh-mm-ss.xml», в папке «changesets» (Рис. 20). При формировании файла, вызвав qdb commit с ключом «-m» (Табл. 6), можно ввести сообщение. Данный файл помечается как «выполнен» путём добавления названия в файл done_changesets.txt. В завершении, изменённый файл database.xml и созданный файл changeset добавляются под контроль СКВ с помощью команд Mercurial (Рис. 21).

Рис. 19 -- Пример работы программы qdb commit

Рис. 20 -- Пример содержимого сгенерированного changeset - файла



Рис. 21 -- Пример добавления файла со структурой БД и сохранённым changeset - файлом под контроль СКВ

Таблица 6. Возможные ключи при вызове команды qdb commit

Ключ	Значение по умолчанию	Описание	Пример
-m	bool false	Позволяет ввести примечание к формируемому changeset файлу	qdb commit -m “Вводимое сообщение”
-h	localhost	Название хоста для подключения к БД.	qdb commit -h ssh://user@asupb:22/
-u	asupb	Имя пользователя для подключения к БД.	qdb commit -u user_name
-p	`'	Пароль пользователя для подключения к БД.	qdb commit -p *****

Qdb update автоматически запускается после скачивания изменений с сервера, сравнивает названия файлов в папке changesets и названия уже выполненных, в файле done_changesets.txt. Если находятся различия, то запускается команда qdb run с ключом «-f `название файла'» (Табл. 5). Запуск qdb update также возможен с различными ключами (Табл. 7).

Таблица 7. Возможные ключи при вызове команды qdb update

Ключ	Значение по умолчанию	Описание	Пример
-h	localhost	Название хоста для подключения к БД.	qdb commit -h ssh://user@asupb:22/
-u	asupb	Имя пользователя для подключения к БД.	qdb commit -u user_name
-p	`'	Пароль пользователя для подключения к БД.	qdb commit -p *****

Мероприятия по улучшению разрабатываемого ПО.

В качестве мероприятий по улучшению разработанной АИС можно указать следующие:

ѕ разработать шаблон по созданию CREATE кода структуры БД для СУБД MSSQL, PostgreSQL и ORACLE;

ѕ расширить функционал АИС возможностью хранения информации в xml файлах;

ѕ для улучшения внешнего вида при установке использовать установщик.

5. Экономическая выгода от внедрения

Для того чтобы оценить экономическую выгоду от внедрения АИС необходимо вычислить трудозатраты компании направленные непосредственно на реализацию проекта. При расчёте себестоимости часа разработки необходимо было учитывать следующие составляющие:

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

ѕ налог на добавленную стоимость. Учитывается исходя из ставки 14% -- льготная категория налогоплательщиков -- разработчики ПО;

ѕ затраты по сопровождению конечного продукта разработки -- поиск и устранение ошибок, версионная поддержка продукта, внесение изменений и дополнений -- составляют 30% от общей ёмкости;

ѕ хозяйственные, дополнительные, административные расходы составляют 20%.

Состав работ при разработке, внедрении и поддержке ПО:

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

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

ѕ непосредственная разработка программного продукта;

ѕ нагрузочное тестирование при приёмке разработанного продукта;

ѕ внедрение разработанного ПО;

ѕ сопровождение и поддержка на всём периоде гарантийного обслуживания и последующей технической поддержки.

Расходы, связанные с оплатой труда сотрудников:

ѕ заработная плата сотрудника согласно штатного расписания предприятия;

ѕ премии, выплаченные сотрудникам по результатам работы;

ѕ социальны выплаты -- пенсионный фонд и фонд социального страхования) -- 14%;

ѕ медицинская страховка -- 1% от заработной платы;

ѕ компенсация питания сотрудников -- 2% от заработной платы.

При расчёте затрат на оплату труда разработчиков, берётся количество рабочих дней в году, согласно производственного календаря, вычитается 20 рабочих дней ежегодного оплачиваемого отпуска очередного и делится на 12. В итоге получим количество дней в месяце, когда сотрудники занимаются своими прямыми обязанностями, а именно 18,9 дней в месяц.

При расчёте производственных часов, направленных непосредственно на разработку ПО, следует учитывать время на сопровождение разрабатываемого ПО -- 30%. Соответственно, получается 2,4 часа в день, тратится на сопровождение и 5,6 часа в день на написание кода.

При расчёте расходов на оплату труда сотрудников по категориям возьмём:

ѕ среднюю заработную плату разработчиков в ООО «БРеалИТ» 100 000 рублей;

ѕ заработная плата сотрудников, занимающих тестированием, 50% от заработной платы разработчика;

ѕ заработная плата специалистов по внедрению приравнивается к з/п разработчика;

ѕ средний ежемесячный заработок проектировщиков составляет 75% з/п разработчика.

Сведём полученные данные в таблицу.

Таблица 8. Расчёт затрат по оплате часа труда сотрудника

	Разработчики	Тестировщики	Внедрение	Проектировщики
З/п сотрудника, рублей/мес.	100 000	50 000	100 000	75 000
Питание, руб./мес.	2 000	1 000	2 000	1 500
Мед. страховка, руб./мес.	1 000	500	1 000	750
Социальные налоги	14%	14%	14%	14%
Социальные налоги по сотруднику, руб./мес.	14 000	7 000	14 000	10 500
Премии, 15 % от заработной платы, руб./мес.	15 000	7 500	15 000	11 250
Рабочие дни в году, дней	247	247	247	247
Ежегодный отпуск, дней в году	20	20	20	20
Количество часов по сопровождению кода, часов/день	2,4	2,4
Рабочих дней в месяц	18,9	18,9	18,9	18,9
Количество часов, затраченных на разработку, часов/день	5,6	5,6
Затраты по уплате труда в пересчёте за час разработки, руб.	1 265,98	633
Затраты по уплате труда в пересчёте за час внедрения и тестирования, руб.			892,86	669,64

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

сервер версионный скриптовый веб

Таблица 9. Расчёт стоимости одного часа разработки

Оплата сотрудников	Часов всех работ к часу разработки	Средняя з/п, руб.	Затраты в час	Рассчитанные затраты в час
Проектирование	35%	75 000	669,64	234,37
Разработка	100%	100 000	1 265,98	1 265,98
Тестирование	50%	50 000	633,00	316,50
Внедрение	5%	100 000	892,86	44,63
Описательная часть (Документация)	5%	50 000	633,00	31,65
Итого оплата сотрудникам за один час разработки, руб./час	1893,13
Сопутствующие и хозяйственные расходы, руб./час	378,60
Общая себестоимость часа разработки, руб./час	2271,73

Рассчитав стоимость одного часа разработки, мы можем вычислить стоимость одной минуты -- 37,86 рублей. После внедрения разработанной АИС, с разработчиков была снята обязанность по поиску и устранению ошибок. Плюс ко всему, благодаря АИС, файлы с историей изменений структуры БД (changeset файлы) стали генерироваться автоматически. Учитывая то, что каждый сотрудник, ежедневно скачивает изменения с сервера и закачивает на сервер результаты проделанной работы, и что каждый второй разработчик в день делает, как минимум, по одному alter (create, drop) запросу к БД, мы можем рассчитать сэкономленную сумму в день -- 678,82 рубля. В месяц сумма составит 13 576 рублей, а в год 162 912 рублей.

Заключение

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

Реализованный программный продукт позволяет:

ѕ автоматически создавать файлы с историей изменения структуры БД;

ѕ абстрагироваться от конкретной СУБД, сохраняя структуру БД в формате xml;

ѕ работать под управлением СКВ;

ѕ просматривать как текущие изменения в структуре БД, так и различия, сделанные с последней фиксации;

ѕ в автоматическом режиме проверять наличие различий после скачивания изменений с сервера и, в случае необходимости, выполнять sql запросы для нивелирований различий в структуре БД;

ѕ снять с разработчиков задачу по поиску и устранению ошибок, связанных с различием в структуре БД.

Указанные выше возможности повышают производительность работы сотрудников, снижают вероятность возникновения ошибок при внесении изменений в структуру БД.

5 мая 2016 года, после ряда тестов на производительность и корректность работы, разработанная АИС, была внедрена в работу компании заказчика.

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