Научная статья на тему 'РАЗРАБОТКА МОДУЛЬНОЙ АРХИТЕКТУРЫ СИСТЕМЫ УПРАВЛЕНИЯ ПРОЕКТАМИ'

РАЗРАБОТКА МОДУЛЬНОЙ АРХИТЕКТУРЫ СИСТЕМЫ УПРАВЛЕНИЯ ПРОЕКТАМИ Текст научной статьи по специальности «Компьютерные и информационные науки»

CC BY
136
11
i Надоели баннеры? Вы всегда можете отключить рекламу.
Ключевые слова
СИСТЕМА УПРАВЛЕНИЯ ПРОЕКТАМИ И ЗАДАЧАМИ / МОДЕЛЬ ДАННЫХ / МЕТРИКА / OSGI-СЕРВИС / OSGI-ПЛАГИН

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Иванов Н.В.

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

i Надоели баннеры? Вы всегда можете отключить рекламу.
iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

DEVELOPMENT OF THE MODULAR ARCHITECTURE OF THE PROJECT MANAGEMENT SYSTEM

The article examines the implementation of the modular architecture of the project management system.

Текст научной работы на тему «РАЗРАБОТКА МОДУЛЬНОЙ АРХИТЕКТУРЫ СИСТЕМЫ УПРАВЛЕНИЯ ПРОЕКТАМИ»

Абрамова // Alma mater (Вестник высшей школы). - 2012. - № 9. - C. 109-110.

3. Бесшабашнов С. Создание сайта: от идеи до реализации [электронный ресурс] / С. Бесшабашнов, А. Денисов // CMSmagazine аналитический портал рынка веб-разработки. URL: http://www.cmsmagazine.ru/library/items/management/stages_of_site_developme nt/ - (Дата обращения: 24.06.2017)

4. Короткова Н.Н. Разработка и программная реализация алгоритма моделирования взаимодействия на рынке производителей программного обеспечения / Короткова, Н.Н. // Качество. Инновации. Образование. - 2016. - №12. - с. 39-42

5. Мустафина Д.А. Модель конкурентоспособности будущего инженера-программиста / Д.А. Мустафина, Г.А. Рахманкулова, Короткова, Н.Н. // Современные наукоемкие технологии- 2010. - №8. - с. 16-20.

6. ГОСТ Р 54869— 2011. Проектный менеджмент. Требования к управлению проектом. - введен 2012-09-01. - М.: Стандартинформ, 2012. -12 с.

7. Татьяна В. План работ для веб-проекта [электронный ресурс] / Татьяна В. // Библиотека интернет индустрии. URL: http://www.i2r.ru/static/512/out 13972.shtml (Дата обращения: 24.06.2017)

8. Завадин В.А. Проектирование веб-системы электронного документооборота с интеграцией облачного хранилища [Электронный ресурс] / В.А. Завадин, О.Ф. Абрамова, Д.Н. Лясин // Форум молодых учёных : электрон. науч. журнал. - 2017. - № 5 (9). - 18 с. - Режим доступа : http://forum-nauka.ru/domains_data/files/9/Zavadin.pdf.

УДК 004.415.23

Иванов Н.В. бакалавр

направление 09.03.02 «Информационные системы и технологии» Национальный исследовательский ядерный университет «МИФИ»

Россия, г. Москва РАЗРАБОТКА МОДУЛЬНОЙ АРХИТЕКТУРЫ СИСТЕМЫ

УПРАВЛЕНИЯ ПРОЕКТАМИ Аннотация: в статье рассматривается реализация модульной архитектуры системы управления проектами.

Ключевые слова: система управления проектами и задачами, модель данных, метрика, REST, OSGi, OSGI-плагин, OSGI-сервис.

Ivanov N. V. Bachelor's degree 09.03.02 Information systems and technologies National Research Nuclear University "MEPhl"

Russia, Moscow

DEVELOPMENT OF THE MODULAR ARCHITECTURE OF THE PROJECT MANAGEMENT SYSTEM

Annotation: the article examines the implementation of the modular architecture of the project management system.

Keywords: project and task management system, data model, metric, REST, OSGi, OSGI-plugin, OSGI-service

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

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

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

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

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

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

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

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

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

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

- Bundle-Name - название плагина

- Bundle-Version - версия плагина

- Bundle-SymbolicName - идентификатор плагина

- Export-package - список экспортируемых пакетов

- Import-package - список импортируемых пакетов.

Компонент OSGi может декларировать некоторый API в виде

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

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

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

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

2) Система внутреннего управления плагинами;

3) API для разработки плагинов

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

1) Модель данных плагинов

2) Сервисы для управления плагинами

3) REST API для управления плагинами со стороны пользователя

Модель данных плагина состоит из двух типов сущностей, плагина и

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

Сущность plugin содержит следующую информацию по загруженном плагине:

- Описание

- Имя корневого пакета (соответствует SymbolicName OSGi-плагина)

- Путь к jar-архиву плагина

- Время создания

- Наименование (соответствует Bundle-Name)

- Версия (соответствует Bundle-Version)

Загруженный плагин связан с плагином следующими связями:

- Связь через таблицу plugin_entries

- Связь через таблицу plugin_properties

Plugin_entries отвечает за хранение признака включен/выключен для пары плагин-проект. Plugin_properties хранит свойства плагина для каждого проекта.

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

активировать/деактивировать плагин для конкретного плагина, изменить свойство плагина в рамках конкретного плагина.

API для разработки плагинов представляет собой java-библиотеку, внутри которой содержатся интерфейсы, используемые в плагинах. Основным интерфейсом в API является метрика. Семантически метрика является аналогом бинов в 1оС-контейнере с более узкой направленностью. С точки зрения OSGi метрика - это интерфейс потребителя API -программы, использующей данный API в логике своей работы. В данном

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

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

Для доступа к данным основной системы присутствует ограниченный набор интерфейсов, которые предоставляют доступ к следующим видам объектов:

- Проект

- Участник проекта

- Задача

- Категория

- Статус

- Тип задачи

- Приоритет

Таким образом API предоставляет возможности для работы с данными системы и для использования связей между плагинами.

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

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

метрику или плагин не удалось, ошибка логируется, после чего, система завершает свою работу. Если система плагинов не работает, то основная система выдаст код ошибки 501 с сообщением, что система плагинов не запущена, при попытке использования REST API для управления плагинами. Если метрика была обнаружена, то её объект подставляется в поле. После разрешения всех зависимостей метрика проверяется, является ли она периодичной, если да, то создается задача с вызовом метода метрики для периодичных вызовов по расписанию, указанном в метрике.

Система внутреннего управления плагинами реализует интерфейсы для управления данными основной системы. Для связи системы плагинов с основной системой используется REST API.

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

На рисунке 1 показана общая схема работы разработанной системы плагинов:

Рисунок 1. Общая архитектура системы плагинов

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

различные архитектурные приемы, в том числе и представление системы в виде набора микросервисов в сочетании технологий Kubernetes и Apache Karaf.

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

Использованные источники:

1. Мирошниченко Е.А. Технологии программирования . - Томск : Изд-во Томского политехнического университета, 2008. - 2-е изд., испр. и доп..

2. Брукс Ф. Мифический человеко-месяц или как создаются программные системы. - Санкт-Петербург : Символ-Плюс, 1999.

3. OSGi Alliance Архитектура OSGi [Электронный ресурс] // Веб-сайт спецификации OSGi. - OSGi Alliance https://www.osgi.org/ developer/architecture/ (дата обращения 3.05.2017)

4. Hans Dockter Adam Murdoch Документация Gradle [Электронный ресурс] // Официальный сайт Gradle. - Hans Dockter, Adam Murdoch https://docs.gradle.org/3.5/userguide/userguide.html (дата обращения 2.05.2017).

5. Phillip Webb Dave Syer, Josh Long, Stéphane Nicoll, Rob Winch, Andy Wilkinson, Marcel Overdijk, Christian Dupuis, Sébastien Deleuze, Michael Simons Spring Boot Reference Guide [Электронный ресурс] // Spring Boot Reference Guide http://docs.spring.io/spring-boot/docs/2.0.0.M1/reference/ htmlsingle/ (дата обращения 2.05.2017).

УДК 004.415.23

Иванов Н.В. бакалавр

направление 09.03.02 «Информационные системы и технологии» Национальный исследовательский ядерный университет «МИФИ»

Россия, г. Москва АНАЛИЗ СИСТЕМ УПРАВЛЕНИЯ ПРОЕКТАМИ

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

Ключевые слова: веб-приложение, сервер приложений, Java-приложение, система управления проектами и задачами, модель данных, REST.

Ivanov N. V. Bachelor's degree 09.03.02 Information systems and technologies National Research Nuclear University "MEPhl"

Russia, Moscow ANALYSIS OF PROJECT MANAGEMENT SYSTEMS Annotation: the article analyzes the existing project management systems

i Надоели баннеры? Вы всегда можете отключить рекламу.