ПОКАЗАТЕЛИ КАЧЕСТВА ВКР

Студент РПИС-31 А.И. Ханыкин

Руководитель ВКР доцент к.т.н. М.А. Стефанов

Введение

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

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

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

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

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

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

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

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

· сформулировать требования к программному обеспечению;

· выбрать инструменты разработки путём анализа альтернативных вариантов;

· определить структуру приложения;

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

· провести комплексное и модульное тестирование;

· устранить выявленные на этапе тестирования ошибки, привести ПО к рабочему состоянию для последующей эксплуатации.

Методологической основой данной работы являются труды следующих авторов: Э. Гонсалвес, который описывал в своей книге разработку по стандарту Java Enterprise Edition; К. Уоллс в книге “Spring в действии” рассказывает о фреймворке Spring и приводит примеры работы с ним.

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

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

В Заключении приводятся основные результаты и выводы по работе.

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

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

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

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

К функциям, которые должны быть реализованы в рассматриваемой задаче, относятся:

· удалённое управление компьютерами;

· управление процессами установки программного обеспечения;

· хранение и манипулирование информацией в базе данных обо всех объектах системы.

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

· управлять объектами системы могут только авторизованные пользователи.

· только пользователи, имеющие статус администратора, могут управлять другими пользователями.

· компьютеры могут объединяться в группы.

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

приложение разработка база данные

2. Определение требований к разрабатываемому продукту

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

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

Функциональные требования к разрабатываемому приложению описываются следующими возможностями:

· создание и удаление компьютеров;

· создание и удаление групп компьютеров;

· создание и удаление программ;

· создание и удаление пользователей (от имени администратора);

· создание и удаление задач по расписанию;

· установка программ на компьютер;

· установка программ на группу компьютеров;

· авторизация пользователей по логину и паролю.

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

· легкость в эксплуатации;

· возможность обслуживания.

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

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

Все требования должны поддаваться проверке. Наиболее распространенной и общепринятой методикой проверки является тестирование [3]. Так как иногда такая проверка бывает невозможна, необходимо использовать другой метод (например, анализ, осмотр или обзор дизайна и т.п.). Подробнее о тестах будет сказано в главе 9 данной работы.

3. Разработка структуры приложения

Проектирование программного обеспечения надо начинать с разработки структуры. Этот процесс также носит название структурирования, или декомпозиции [1].

Структура приложения построена на известном паттерне MVC. MVC (Model-View-Controller, "Модель-Представление-Контроллер", "Модель-Вид-Контроллер") - схема разделения данных приложения, пользовательского интерфейса и управляющей логики на три отдельных компонента: модель, представление и контроллер -- таким образом, что модификация каждого компонента может осуществляться независимо. Схема паттерна MVC представлена на рис. 3.1 Каждый из компонентов отвечает за определенные функции ПО, таким образом достигается логическое «разделение обязанностей» между частями программы. Модель (Model) предоставляет данные и реагирует на команды контроллера, изменяя свое состояние. Представление (View) отвечает за отображение данных модели пользователю, реагируя на изменения модели. Контроллер (Controller) интерпретирует действия пользователя, оповещая модель о необходимости изменений [4].

Рис. 3.1 - Схема паттерна MVC

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

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

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

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

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

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

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

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

Рис. 3.2 - Схема структуры разрабатываемого приложения

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

4. Выбор инструментов разработки

Для реализации данного приложения следует выбрать язык программирования. Так как это клиент-серверное приложение, для сервера следует определить хранилище данных. В качестве языка программирования был выбран язык Java в связи с большим опытом использования, а также благодаря преимуществу созданных на нём приложений, связанному с возможностью их переноса на разные платформы. Возможность запуска на разных системах достигается особенностью Java - её программы не зависят от платформы ни на уровне исходного кода, ни на двоичном уровне, что особенно важно для программ, выполняющих свою работу на удалённом сервере в World Wide Web.

Серверная часть приложения будет реализована с применением технологии JavaEE (Java Enterprise Edition). Для использования JavaEE требуется определиться с сервером приложений, под которым в случае с JavaEE подразумевается комплекс программ, реализующих концепцию этой технологии и позволяющих запускать в себе приложения, построенные на ней. Сервер приложений представляет собой расширенную виртуальную машину, управляющую соединениями с базой данных с одной стороны и соединениями с веб-клиентом - с другой [5]. Были выдвинуты следующие критерии выбора:

· бесплатность - это основной критерий отбора, так как у проекта отсутствует какая-либо финансовая поддержка;

· наличие документации - что бы правильно настроить и начать использовать сервер приложений требуется наличие информации в свободном доступе;

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

· поддержка стандарта JavaEE 7.

В результате был выбран сервер приложений WildFly. WildFly - это JavaEE сервер приложений с открытым исходным кодом, разработанный компанией JBoss [6].

Также встал вопрос о выборе СУБД. Основными критериями при выборе конкретной СУБД были следующие:

· поддержка языка программирования Java;

· поддержка стандарта PL/SQL.

В результате была выбрана свободная объектно-реляционная система управления базами данных PostgreSQL, как продукт, отвечающий всем вышеуказанным требованиям и имеющий ряд особенных преимуществ [7]:

· поддержка сложных структур;

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

· расширенная ёмкость данных;

· бережное отношение к целостности данных.

Java - это объектно-ориентированный язык программирования с большим набором всевозможных библиотек и фреймворков. Для упрощения написания приложения был использован Spring Framework со всеми его отдельными модулями[8]:

· Spring Data - облегчает доступ к базам данных через интеграцию с ORM и JDBC;

· Spring MVC - модуль, позволяющий с наименьшими затратами поддержать архитектуру Модель-Представление-Контроллер для web-приложений.;

· Spring Security - инструмент, предоставляющий функционал, который позволяет настраивать процессы аутентификации и авторизации;

· Spring JMS - упрощенный функционал для работы с Java Messaging Service;

· Spring Boot - модуль, позволяющий легко создавать приложения без написания дополнительной xml конфигурации.

Spring Boot имеет в своем составе так называемый контейнер сервлетов. Контейнер сервлетов -- программа, представляющая собой сервер, который занимается системной поддержкой сервлетов и обеспечивает их жизненный цикл в соответствии с правилами, определёнными в спецификациях [8]. Может работать как полноценный самостоятельный web-сервер, быть поставщиком страниц для другого web-сервера или интегрироваться в JavaEE сервер приложений. Обеспечивает обмен данными между сервлетом и клиентами, берёт на себя выполнение таких функций, как создание программной среды для функционирующего сервлета, идентификацию и авторизацию клиентов, организацию сессии для каждого из них. Сервлет является интерфейсом Java, реализация которого расширяет функциональные возможности сервера. Сервлет взаимодействует с клиентами посредством принципа запрос-ответ. Наличие этого контейнера позволяет Spring Boot работать по принципу “просто запусти”. Этот путь нам не подходит, так как настройку подключения к базе данных и конфигурацию соединения с Java Messaging Service хотелось бы производить на сервере приложений. Однако Spring Boot позволяет создавать разворачиваемые приложения, которые в свою очередь работают в рамках сервера приложения.

Клиентское приложение должно олицетворять компьютер в системе. Общение между клиентом и сервером будет происходить посредством Java Messaging Service. Так как для сервера уже есть модуль, который осуществляет работы с JMS, для минимизации временных затрат разумнее повторно использовать уже имеющиеся разработанные компоненты. В связи с этим клиентское приложение также использует Spring Framework. Запуск и конфигурация приложения осуществляется при помощи технологии Spring Boot. Желательно чтобы клиентское приложение несло какую-либо информацию для пользователя компьютера, следовательно, у приложения должен быть графический интерфейс. Для языка Java существуют несколько технологий для разработки графических интерфейсов [9]:

· AWT - первая технология разработки графических интерфейсов для Java. Основной минус данной технологии в том, что не гарантируется идентичная работа на разных платформах;

· Swing - технология, разработанная вслед за AWT. Полностью разработана на языке Java, благодаря чему одинаково работает на разных платформах, однако данная библиотека не отличается быстродействием;

· SWT - технология, разработанная компанией IBM, в качестве замены Swing c целью решить проблему с производительностью, но была нарушена кроссплатформенность из-за того, что для различных платформ приходилось ставить различные библиотеки;

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

5. Разработка структуры базы данных

Для создания данного приложения требуется спроектировать структуру данных, которая будет отвечать всем требованиям приложения. В качестве СУБД используется PostgreSQL. Все сущности снабжены первичным ключом и хранят ссылку на пользователя, который создал экземпляр сущности. В качестве основных сущностей базы данных выступают “Компьютер” (Computer) и “Программа” (Program).

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

Рис. 5.1 - Структура сущности “Программа”

· id - число, выступающее в качестве уникального идентификатора программы;

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

· description - некоторый текст, описывающий программу, задается пользователем при создании;

· path - строка, являющаяся путем до архива с программой внутри системы, которая определяется после этапа загрузки инсталлятора на сервер и его помещения в архив;

· createBy - идентификатор пользователя, который создал программу в системе, определяется системой в момент создания объекта.

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

Рис. 5.2 - Структура сущности “Компьютер”

· id - число, выступающее в качестве уникального идентификатора компьютера;

· name - строка, представляющая собой имя компьютера, данное поле задается пользователем при создании;

· description - некоторый текст, описывающий компьютер, задается пользователем при создании;

· online - логическая переменная. Если она равна true, значит, компьютер находится в сети, если false, значит, - не в сети. Будет выставляться задачей по расписанию в процессе опроса парка компьютеров;

· revision_date - дата и время последнего ответа компьютера на сообщение о проверке его статуса, отправляемого задачей по расписанию;

· uuid - уникальный идентификатор компьютера, предназначенный для определения физической машины в системе, генерируется в момент создания объекта и выступает в качестве адреса компьютера;

· group_id - идентификатор группы, в которой состоит компьютер;

· createby - идентификатор пользователя, создавшего компьютер в системе. Определяется системой в момент создания объекта.

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

Рис. 5.3 - Структура связывающей таблицы для программ и компьютеров

· id - число, являющееся уникальным идентификатором связи компьютера и программы;

· last_update - дата и время последнего обновления статуса связи, обновляется при попытке установки программы на компьютер;

· status - строка, определяющая текущий статус программы. Возможны следующие статусы: “Не установлено”, “Установлено”, “В опасности” и “Ошибка”, сам статус обновляется в процессе установки программы. Статус “Ошибка” выставляется при возникновении какой-либо ошибки в процессе установки программы. Статус “В опасности” выставляется при превышении временного лимита для установки программы;

· computer - идентификатор компьютера, участвующего в связи;

· program - идентификатор программы, участвующей в связи.

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

Рис. 5.4 - Структура сущности “Группа”

· id - число, являющееся уникальным идентификатором;

· name - строка, определяющая имя группы, данное поле задается пользователем при создании;

· description - текст, описывающий группу, задается пользователем при создании;

· createby - идентификатор пользователя, создавшего группу.

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

Рис. 5.5 - Структура сущности “Пользователь”

· id - число, являющееся уникальным идентификатором пользователя;

· username - идентификатор учетной записи пользователя, данное поле задается пользователем при создании;

· firstname - имя пользователя, задается пользователем при создании;

· lastname - фамилия пользователя, задается пользователем при создании;

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

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

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

Рис. 5.6 - Структура сущности “Задача”

· id - уникальный идентификатор задачи в системе;

· name - имя задачи, данное поле задается пользователем при создании;

· actionname - название операции, которую исполняет задача по расписанию, данное поле задается пользователем при создании, значения предлагаются системой на основе зарегистрированных типов задач;

· pattern - расписание, по которому исполняются задачи, вид значения характеризуется типом задачи и может принимать число миллисекунд или строку, написанную по определённым правилам и представляющую собой расписание;

· status - текущий статус задачи в системе, может принимать значения “Стартована” и “Приостановлена”;

· type - тип расписания, по которому исполняется задача. Может принимать следующие значения: “Rate” - задача исполняется с фиксированной периодичностью, вне зависимости от того, завершилось предыдущее выполнение или нет; “Delay” - задача исполняется через фиксированный промежуток времени после предыдущего выполнения; “Cron” - задача исполняется по специально сформированному расписанию, которое может не иметь фиксированного промежутка между разными случаями выполнения задачи.

В результате были определены и сформированы связи между описанными выше сущностями. Между компьютером и группой компьютеров определена связь многие к одному. Компьютер и программа связаны через вспомогательную таблицу. Связь между компьютером или программой и этой таблицей один ко многим. Таблица пользователей связана с таблицами групп, компьютеров и программ ассоциацией один ко многим. Общая концептуальная схема предметной области приложения - диаграмма «сущность-связь» (ERD) - представлена на рис 5.7:

Рис. 5.7 - Структурная схема базы данных

На основе данной ER диаграммы были созданы Java классы, которые представляют собой сущности базы данных, а экземпляр каждого класса отражает содержимое кортежа соответствующей сущности БД. При помощи созданных классов будет происходить управление сущностями в базе - создание, удаление, редактирование, - а также описана логика их взаимодействия. Такой подход позволяет минимизировать количество SQL-запросов в программе для взаимодействия с используемым хранилищем данных, а также обеспечить независимость разработанного приложения от конкретной СУБД, благодаря использованию только Java-объектов.

6. Разработка серверной части приложения

В основе приложения лежит клиент-серверная архитектура. Часть сервера реализована при помощи сервера приложений WildFly. WildFly - это JavaEE сервер приложений с открытым исходным кодом [6]. Сервер приложений представляет собой подобие виртуальной машины для запуска приложений. Само приложение написано на языке Java с применением фреймворка Spring. Spring Framework - это универсальный фреймворк с открытым исходным кодом для приложений, написанных на языке Java [10]. Серверная часть состоит из сервера приложений и базы данных. На сервер приложений ложиться основная обязанность по контролю за базой данных и web стороной клиента.

6.1 Разработка модулей

6.1.1 Разработка модуля для работы с базой данных

Контроль за базой данных реализован при помощи технологии Spring Data, в которой отображение объектов Java на таблицы базы данных происходит при помощи ORM. ORM (англ. Object-Relational Mapping, рус. объектно-реляционное отображение) - технология программирования, которая связывает базу данных с концепциями объектно-ориентированного программирования, при котором происходит сопоставление объектов с сущностями базы данных [5]. В рамках этого модуля реализованы следующие классы сущностей: Computer, ComputerGroup, ComputersProgramsAssociation и Program.

Так как приложение использует модуль Spring Security, требуется определить место хранения информации о пользователе. Существует множество способов хранения подобной информации (например, LDAP), но самым простым в реализации способом является хранение всей информации в базе данных. В связи с этим потребуется дополнительная сущность User. Также в системе присутствуют задачи, выполняемые по определенному расписанию, и, чтобы при перезапуске сервера приложений не приходилось заново настраивать эти задачи, будем хранить всю нужную для восстановления информацию в базе данных. В итоге у нас появится сущность Task. Сами сущности и связи между ними представлены на диаграмме классов показанной на рис. 6.1:

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

Для управления сущностями создаются специальные репозитории. Репозиторий - это интерфейс, расширяющий интерфейс JpaRepository, реализуемый модулем Spring Data в процессе инициализации приложения [6, 10]. Методы этих классов представляют простые операции над объектами сущностей, такие как: сохранение, удаление и поиски по различным параметрам. Чтобы модуль Spring Data смог реализовать методы, описанные в интерфейсе, суть методов должна отражаться в их названии. Конкретные правила именования методов описаны в спецификации Spring Data [8]. В интерфейсе JpaRepository уже присутствуют методы для сохранения сущностей, удаления сущностей, поиск сущностей по уникальному идентификатору и т.д. В приложении представлены следующие репозитории со следующими методами:

1. ComputerRepository - управляет сущностью Computer;

1.1. findAllByComputerGroup - возвращает коллекцию компьютеров, принадлежащих определенной группе;

1.2. findOneByName - возвращает компьютер по его имени;

1.3. findOneByUuid - возвращает компьютер по uuid;

1.4. deleteByName - удаляет компьютер по имени.

2. ComputerGroupRepository - управляет сущностью ComputerGroup;

2.1. findOneByName - возвращает группу по её имени;

2.2. deleteByName - удаляет группу по её имени.

3. ComputersProgramsAssociationRepository - управляет сущностью ComputersProgramsAssociation;

3.1. findAllByComputer - поиск всех ассоциаций для конкретного компьютера;

3.2. findAllByProgram - поиск всех ассоциаций для конкретной программы;

3.3. findAllByStatus - поиск ассоциаций по статусу инсталляции программы.

4. ProgramRepository - управляет сущностью Program;

4.1. findOneByName - поиск программы по имени.

5. UserRepository - управляет сущностью User;

5.1. findOneByUsername - возвращает пользователя по его имени;

5.2. deleteByUsername - удаляет пользователя по его имени.

6. TaskRepository - управляет сущность Task;

6.1. findAllByType - возвращает задачи по типу расписания;

6.2. findAllByStatus - возвращает задачи по статусу;

6.3. findByName - возвращает задачу по имени;

6.4. deleteByName - удаляет задачу по имени.

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

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

6.1.2 Разработка web интерфейса приложения

На сервере также присутствует web клиент, основанный на технологии Spring MVC. В качестве разметки страниц используется расширение JSP - JSTL. JSTL - является альтернативой такому виду встроенной в JSP логики, как скриплеты, то есть прямые вставки Java кода [5]. Использование стандартизованного множества тегов предпочтительнее, поскольку получаемый код легче поддерживать и проще отделять бизнес-логику от логики отображения. За бизнес-логику в приложении отвечают классы контроллеров, написанные при помощи технологии Spring MVC. Эти классы помечены специальной аннотацией, а методы этого класса реагируют на запросы пользователей и предоставляют ответ в формате, пригодном для работы с JSTL. Каждый контроллер позволяет манипулировать пользователю различными сущностями. В качестве классов контроллеров выступают:

· ComputerController - позволяет пользователю получать, создавать и удалять экземпляры сущности Computer;

· GroupController - позволяет пользователю получать, создавать и удалять экземпляры сущности ComputerGroup;

· ProgramController - позволяет пользователю получать, создавать и удалять экземпляры сущности Program, а также инициировать установку программ;

· UserController - позволяет пользователю получать, создавать и удалять экземпляры сущности User. Доступ к функциям, предоставляемым данным контроллером, существует только у пользователей с правами администратора;

· SchedullerController - позволяет пользователю контролировать задачи, выполняющиеся в системе;

· LoginController - данный контроллер отвечает за процесс аутентификации пользователя при возникновении в этом процессе ошибок.

Каждый метод контроллера реагирует на определенный HTTP запрос, который прописан в аннотации над методом. Spring MVC самостоятельно превращает все данные, приходящие со стороны web клиента, в объекты Java, что в разы упрощает написание серверной части приложения [10]. Сам пользовательский интерфейс представлен на рис. 6.2:

Рис. 6.2 - Пользовательский web интерфейс приложения

Вся информация в пользовательском интерфейсе представлена в виде таблиц. Навигация по иерархии объектов происходит по нажатию на имя объекта. Например, для того чтобы посмотреть на компьютеры, принадлежащие конкретной группе, требуется нажать на название этой группы. Функциональные возможности интерфейса представляют кнопки, находящиеся над таблицами. Основные кнопки предназначены для того, чтобы добавлять и удалять объекты. Для программ предусмотрена кнопка для инициализации установки программ. Программы можно устанавливать, как на один компьютер, так и на всю группу сразу. Для этого на странице группы и компьютера присутствует таблица, отображающая программы, установленные на всю группу или на конкретный компьютер. Все таблицы снабжены формами поиска и возможностью для сортировки по определенному столбцу без перезагрузки страницы. Данный функционал реализован при помощи библиотеки jQuery. jQuery -- библиотека JavaScript, фокусирующаяся на взаимодействии JavaScript и HTML. Библиотека jQuery помогает легко получать доступ к любому элементу DOM, обращаться к атрибутам и содержимому элементов DOM, манипулировать ими. Также библиотека jQuery предоставляет удобный API для работы с AJAX. Все кнопки, принадлежащие таблицам, также реализованы при помощи данной библиотеки. При нажатии на кнопку появляется специально окно, которое требует от пользователя согласия на отправку запроса или ввод каких-либо данных. В качестве примера приведем форму создания компьютера показанную на рис. 6.3:

Рис. 6.3 - Форма создания экземпляра сущности “Компьютер”

Данная форма заполняется пользователем, после чего происходит отправка средствами jQuery при помощи технологии AJAX. AJAX (от англ. Asynchronous JavaScript and XML -- «асинхронный JavaScript и XML») -- подход к построению интерактивных пользовательских интерфейсов веб-приложений, заключающийся в «фоновом» обмене данными браузера с веб-сервером [9]. В результате при обновлении данных веб-страница не перезагружается полностью, и веб-приложения становятся быстрее и удобнее. АJAX отправляет форму на сервер, где её обрабатывает контроллер, создавая новый объект в системе. Далее происходит перестроение страницы с новыми данными.

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

Вся работа с web-клиентом контролируется технологией Spring Security. В рамках приложения эта технология используется для предоставления пользователям доступа к клиенту и контроля прав пользователей. В качестве пользователя выступает сущность User. Хранение и доступ к ней описаны в модуле, связанном с работой с базой данных. Spring Security применяется на всех уровнях приложения и не только ограничивает функционал, который может использовать конкретный пользователь, но и влияет на представление информации в виде, доступном определенной группе пользователей. Благодаря этому модулю доступ к системе может получить только авторизованный пользователь.

6.1.3 Разработка модуля задач по расписанию

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

· CRON - данный вид расписания можно считать самым сложным в плане настройки, но благодаря ему можно создавать задачи, которые выполняются не через фиксированный промежуток времени. Данный тип расписания пришел из Unix систем. Ему можно дать следующее определение. СRON -- демон-планировщик заданий в Unix-подобных операционных системах, использующийся для периодического выполнения заданий в определённое время;

· RATE - задачи с таким типом расписания выполняются с определенной частотой, то есть выполнение задачи может начаться еще до окончания предыдущего;

· DELAY - выполнение задач по данному расписанию схоже с расписанием типа RATE, но следующее выполнение задачи начинает считаться после того, как закончилось предыдущее исполнение задачи.

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

Рис. 6.4 - Пользовательский web интерфейс для управления задачами

6.1.4 Разработка модуля клиент-серверного взаимодействия

Клиент-серверное общение реализовано на основе технологии JMS. JMS (Java Messaging Service) - это вид промежуточного ПО для обмена сообщения, позволяющего Java приложениям создавать, отправлять и принимать сообщения [9]. Данный функционал реализован в виде отдельного модуля, который используется как на сервере, так и на клиенте. Клиент и сервер обмениваются специальными xml сообщениями, которые имеют представление в виде Java объектов. У каждого сообщения есть указатель на компьютер (uuid определенного компьютера), которому адресовано сообщение, в случае отправки сервером, или от кого приходит сообщение, в случае отправки со стороны клиента. Если у сообщения, отправляемого сервером, не указан адрес, то оно рассылается на всех. Клиент-серверное общение основано на двух моделях работы с сообщениями. От клиента к серверу общение происходит по модели точка-точка, а от сервера клиенту по модели издатель-подписчик [11]. Для работы этих модели были созданы два пункта назначения сообщений на сервере: Topic и Queue. Для клиента и сервера существует различная конфигурация слушателей. Процесс приема и передачи сообщений можно представить в виде схемы показанной на рис. 6.5:

Рис. 6.5- Схема передачи сообщений между клиентом и сервером

Все приложение разбито на отдельные модули. Модули сосредоточивают внутри себя определенный функционал, такой как: функционал доступа к базе данных, планировщик задач, функционал для общения клиента и сервера и пользовательский web интерфейс. Все эти модули объединяются в одно рабочее приложение при помощи технологии Spring Boot. В свою очередь приложение, инициализируемое через Spring Boot, разворачивается на сервере приложений WildFly.

6.2 Разработка функций серверной части приложения

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

Рис. 6.6 - Схема создания экземпляра сущности

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

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

Рис. 6.7 - Схема создания программы

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

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

Рис. 6.8 - Схема процесса установки программы

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

Для отслеживания доступа к системе служит процесс авторизации, контролируемый модулем Spring Security. Процесс авторизации представлен на рис. 6.9:

Рис. 6.9 - Схема процесса авторизации

В процессе авторизации используется CurrentUserDetailsService, который принимает имя пользователя и возвращает объект пользователя или ошибку. В зависимости от того, что выдал сервис, модуль Spring Security предоставляет доступ к системе [8].

7. Разработка клиентской части приложения

На каждом компьютере установлено специальное приложение, которое несет в себе основной функционал по установке программ, получению сообщений от сервера и составления ответа на них. Клиентское приложение написано при помощи JavaFX и Spring Boot. JavaFX -- платформа на основе Java для создания приложений с насыщенным графическим интерфейсом. Может использоваться как для создания настольных приложений, запускаемых непосредственно из-под операционных систем, так и для интернет-приложений, работающих в браузерах, и для приложений на мобильных устройствах. JavaFX призвана заменить использовавшуюся ранее библиотеку Swing [8]. Основа интерфейса приложения состоит из файлов самого интерфейса и классов контроллера. Интерфейс представлен на рис. 7.1.

Рис. 7.1 - Интерфейс клиентского приложения, устанавливаемого на конкретный компьютер

Интерфейс состоит из двух элементов:

1. Основное окно, в котором отображается текущий адрес компьютера и устанавливаемые и установленные программы;

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

Основной функционал клиентского приложения заключается в получении от сервера программ и их установке. Команды на установку программ получаются с помощью технологии JMS. От сервера к клиентам идет широковещательная рассылка. Каждый клиент получает сообщение от сервера и после фильтрует его в зависимости от адреса, указанного в сообщении. Также сообщение содержит идентификатор программы, которую следует установить. Клиент скачивает заархивированную программу с сервера, после чего распаковывает и по конфигурационному файлу производит установку. Для каждого этапа создан отдельный функциональный бин [11]:

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

· Unziper - принимает путь до архива с программой, после чего начинает распаковывать архив в специальную временную директорию и передает путь до неё бину ProgramInstaller;

· ProgramInstaller - данный бин берет на себя основной функционал по установке приложений. У каждой программы создается конфигурационный файл (config.xml), который берется за основу для создания процесса. В нем указывается имя исполняемого файла и ключи, требующиеся для тихой установки.

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

Рис. 7.2 - Процесс установки программы

Само приложение может не отображаться для пользователей, а будет находиться в области уведомлений. Область уведомлений - элемент панели инструментов среды рабочего стола («панель задач» в Windows), используемый для нужд длительно запущенных, но при этом не постоянно используемых программ. Имеет неофициальное название “системный трей”.

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

8. Тестирование разработанного продукта

Обязательной частью разработки любого программного обеспечения является подтверждение качества его работы. Для этого предусмотрена процедура тестирования. Тестирование преследует две основные цели [3]: