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

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

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

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

Также в системе нужно создать web-сервис, методы которого позволяют получить:

-список всех пользователей;

-список агентов, подчиненных заданному агенту;

-десять лучших агентов по количеству документов.

2. Проектирование

2.1 Выбор инструментальных средств разработки системы

2.1.1 Сервер базы данных

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

Сервер баз данный MySQL имеет менее удобные средства для проектирования баз данных по сравнению с другими серверами БД.

База данных, разработанная с помощью Derby, легко переносима с одного компьютера на другой.

В СУБД PostgreSQL удобный интерфейс пользователя и для работы с ней из среды Eclipse существуют специальные модули. Поэтому в качестве сервера баз данных выберем PostgreSQL.

2.1.2 Технологии реализации системы

Технология JSP-страниц (JavaServer Pages - JSP) позволяет без труда создавать web-содержимое, у которого есть как статическая, так и динамическая компоненты. Основными характеристиками JSP-технологии являются:

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

-конструкции для получения доступа к объектам на стороне сервера.

-механизмы, определяющие расширения для JSP-языка.

JSP-страницей является документ с текстовой основой, содержащий два типа текста: статические шаблонные данные, выражаемые при помощи любого формата на текстовой основе, такого как HTML, SVG, WML, и XML, а также JSP-элементы, которые создают динамическое содержимое.

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

В технологиях Servlet и JSP введено понятие "контейнера" (container). Если вкратце, то Servlet-контейнер - это движок, отвечающий за выполнение Servlet-ов. JSP-контейнер - это движок, отвечающий за трансляцию jsp-страниц в сервлеты и передачу этих сервлетов Servlet-контейнеру. Так как сервлеты и jsp-страницы вызываются через HTTP-протокол, то Servlet-контейнер и JSP-контейнер часто сопровождает еще один компонент - web-сервер, который тоже может быть написан на Java.

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

JSTL (Java Server Pages Standard Tag Library) -- стандартная библиотека тегов JSP. Она расширяет спецификацию JSP, добавляя в библиотеку JSP теги специального назначения, предназначенные для разбора XML данных, условной обработки, создания циклов, обработки коллекций, работы с базами данных и поддержки интернационализации.

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

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

Для работы с данными в JSTL используется язык выражений (EL - Expression Language), представляющий собой упрощённое объединение JavaScript и XPath. Многие из возможностей языка выражений, получивших поддержку в стандартной библиотеке тегов, были включены в следующую спецификацию JSP, а именно JSP 2.0 или JSR-152. Но JSTL остается независимой библиотекой тегов.

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

Веб-сервисы преобразуют XML-документы (Extensible Markup Language, XML) в ИТ-системах. Веб-сервисы - это XML-приложения, осуществляющие связывание данных с программами, объектами, базами данных либо с деловыми операциями целиком. Между веб-сервисом и программой осуществляется обмен XML-документами, оформленными в виде сообщений. Стандарты веб-сервисов определяют формат таких сообщений, интерфейс, которому передается сообщение, правила привязки содержания сообщения к реализующему сервис приложению и обратно, а также механизмы публикации и поиска интерфейсов.

Для удаленного взаимодействия с веб-сервисами используется Simple Object Access Protocol (SOAP). SOAP обеспечивает взаимодействие распределенных систем, независимо от объектной модели, операционной системы или языка программирования. Данные передаются в виде особых XML документов особого формата.

Для создания веб-сервиса можно использовать плагин WTP(Web Tools Platform), который расширяет возможности Eclipse средствами для создания web-приложений.

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

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

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

2.1.3 Сервлет контейнер Tomcat

Web-сервер Tomcat включает в себя Servlet-контейнер, позволяющий выполнять сервлеты, и JSP-контейнер, который транслирует jsp-страницы в сервлеты и передает эти сервлеты Servlet-контейнеру.

Конфигурация Tomcat осуществляется с помощью файла server.xml, в котором содержится вся информация о настройке, записанная в XML-формате.

2.2 Проектирование архитектуры системы

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

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

На рисунке 2.1 представлена архитектура многослойного приложения.

Рисунок 2.1 - Многослойная архитектура корпоративного приложения

Как видно из приведенного рисунка, архитектуру приложения можно разделить на такие слои:

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

-слой сервисов (service layer) - слой служб определяющий границы приложения и множество операций, предоставляемых им для интерфейсных клиентских слоев кода;

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

-слой представления (presentation layer) - слой, охватывающий все, что имеет отношение к общению пользователя с системой.

2.2.1 Проектирование слоя бизнес-логики и бизнес-правил

На данном этапе была выполнена разработка классов доменов. Диаграммы классов доменов приведены на рисунке 2.2.

Рисунок 2.2 - Диаграммы классов доменов

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

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

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

Алгоритмы работы системы согласно бизнес-правилам, присутствующим в данной предметной области приведены на рисунках (рисунок 2.3 и рисунок 2.4).

Рисунок 2.3 - Схема алгоритма добавления рекрута агенту

Рисунок 2.4 - Алгоритм поиска всех подчиненных данного агента

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

2.2.2 Проектирование слоя доступа к данным

На данном этапе проектирования выполняется разработка DAO (data access object) классов, которые обеспечивают доступ к данным. Простые функции получения свойств объектов уже разработаны в классах домена. DAO основаны на классах домена и обеспечивают более сложные выборки данных, характерные для данной предметной области.

Диаграмма классов DAO представлена на рисунке 2.5.

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

Для единообразного доступа к данным, все классы DAO реализуют интерфейс Dao. Классы для каждой отдельной сущности в своих методах обращаются к классу StaticDao.

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

Среди всех операций доступа к данным также присутствуют базовые CRUD (create, read, update, delete) операции - создание объекта, удаление объекта, обновление объекта, получение объекта по идентификатору, и получение всех объектов.

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

2.2.3 Проектирование слоя сервисов

Диаграмма классов сервисов системы приведена на рисунке 2.6.

Рисунок 2.6 - Диаграмма классов сервисов системы

Классы сервисов - основные классы, обслуживающие web-страницы. В этих классах также реализуются правила бизнес-логики.

Сервисы основываются на классах DAO. Все необходимые операции, которые пользователь может выбирать на web-страницах, исполняются вызовами методов данных классов. В классы сервисов вынесены также базовые CRUD-операции.

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

Помимо самих интерфейсов и классов сервисов в пакете присутствуют классы-enumeration, необходимые для задания некоторых свойств объектов.

Так, в классе UserStatus существуют поля ACTIVE(0), WAIT_FOR_CONFIRAMTION(1), DECLASSIFIED(2), и DELETED(3), которые обозначают соответствующее состояние пользователя. Например, если пользователь ожидает подтверждения, он не может войти в систему, а если имеет статус рассекречен - агент сообщил о рассекречивании.

Класс Role - еще один класс-перечисление. В данном классе описываются состояния ADMIN(0), BOSS(1), LOCALAGENT(2), AGENT(3) и RECRUIT(4). В зависимости от них пользователю предоставляются соответствующие права доступа.

Значение в скобках - соответствие имени поля числу; именно это число записывается в соответствующее поле таблицы в базе данных.

2.2.4 Проектирование слоя отображения

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

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

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

После подтверждения регистрации пользователь имеет доступ к своей личной странице. Её внешний вид, а именно левая панель, меняются в зависимости от роли (и, соответственно, прав доступа) пользователя.

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

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

3.1 Разработка базы данных системы

3.1.1 Разработка схемы базы данных

Исходя из анализа, проектирования слоя бизнес логики и правил, структуру БД можно сделать следующей (рисунок 3.1)

Рисунок 3.1 - Логическая схема БД

Физическая схема БД показана на рисунке 3.2

Рисунок 3.2 - Физическая схема БД

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

- страна;

- документ;

- пользователь;

- агент.

В каждой таблице уникальный первичный ключ является суррогатным. Это дополнительное служебное поле, добавленное к уже имеющимся информационным полям таблицы, единственное предназначение которого - служить первичным ключом. Значения этого поля не образуется на основе каких-либо других данных из БД, а генерируются искусственно. Главное достоинство суррогатного ключа состоит в том, что он никогда не изменяется, поскольку не является информативным полем таблицы (не несёт никакой информации об описываемом записью объекте). Использовать суррогатный ключ имеет смысл в случае, когда возможны изменения полей, составляющих (естественный) первичный ключ (в особенности, если этот ключ - составной). В этом случае возникает проблема т.н. "каскадных изменений". При использовании же суррогатного ключа в качестве первичного, изменять его не придется. Также, при выполнении запросов, использующих суррогатные ключи, сравнение полей будет происходить быстрее, в особенности, если естественный первичный ключ представляет собой строку.

3.1.2 Обеспечение целостности данных

Ограничения целостности приведены в таблице 3.1

Таблица 3.1 - Описание таблиц БД