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

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1. АНАЛИЗ ТРЕБОВАНИЙ К ИС

1.2 Требования к интерфейсу

1.3 Требования к функционалу ИС

2. АНАЛИТИЧЕСКИЙ ОБЗОР

2.1 Анализ существующих информационных систем9

3. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ

3.1 Архитектура информационных систем

3.2 Проектирование структур данных и алгоритмов

3.3 Проектирование пользовательского интерфейса

4. РЕАЛИЗАЦИЯ

4.1 Особенности реализации

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

4.1.2 Разработка слоя взаимодействия с базой данных

4.1.3 Разработка слоя бизнес сервисов

4.1.4 Разработка слоя пользовательского интерфейса

5. ТЕСТИРОВАНИЕ

5.1 Обоснование методики тестирования

5.2 Результаты тестирования

ЗАКЛЮЧЕНИЕ

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

ПРИЛОЖЕНИЯ



ВВЕДЕНИЕ

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

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

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

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

Объектом работы является: автоматизация деятельности сервисного центра.

Цель данной работы: разработка информационной системы для автоматизации деятельности сервисного центра.

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

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

2. выяснить какие основные потоки данных существуют на предприятии;

3. установить какие процессы предприятия можно автоматизировать;

4. автоматизировать максимально возможное количество бизнес процессов;

5. улучшить качество регулирования процессов;

6. обеспечить достоверность информации о материальных компонентах, применяемых в производстве;

7. хранение информации о ходе технологического процесса и аварийных ситуациях;

8. улучшение эргономики труда операторов процесса;

9. выбрать способы и средства для разработки программного обеспечения;

10. выдвинуть требования к программному продукту;

11. разработать ПО согласно выдвинутым требованиям;

12. проверить качество программного продукта.

Методы: изучение научно - методической литературы; анализ; синтез; обобщение.



1. АНАЛИЗ ТРЕБОВАНИЙ К ИС

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

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

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

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

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

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

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

Каждый работник в сервисном центре имеет свои обязанности в зависимости от занимаемой должности.

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

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

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

Каждый работник сервисного центра может совмещать несколько должностей.

В сервисном центре было выделено несколько бизнес процессов, ниже расписаны наиболее важные.

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

Прием техники может осуществляться как в приемных пунктах, так и в мастерских.

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

У каждого заказа имеется статус, он изменяется в зависимости от операций, произведенных над ним. Количество статусов не ограничено, администратор сервисного центра вправе решать сам, какие статусы необходимы для выполнения бизнес процессов. Однако есть обязательные статусы: «Принят», «В ремонте», «На согласовании», «Готов», «Выдан».

1.2 Требования к интерфейсу

пользовательский интерфейс программный обеспечение

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

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

функциональность (соответствие задачам пользователя);

понятность и логичность;

обеспечение высокой скорости работы пользователя;

обеспечение защиты от человеческих ошибок;

быстрое обучение пользователя;

субъективное удовлетворение пользователя

в цветовой схеме интерфейса должны преобладать оранжевый и белый цвет (корпоративные цвета).

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

1.3 Требования к функционалу ИС

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

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

- доступ к базе данных через интернет браузер;

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

обеспечение безопасности хранимой в системе информации;

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

наличие справочников информации, их заполнения, изменения, удаления;

авторизация и аутентификация;

разграничение доступа к информации работникам;

возможность отслеживать статус заказа клиентом онлайн.

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



2. АНАЛИТИЧЕСКИЙ ОБЗОР

2.1 Анализ существующих информационных систем

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

РемонтОнлайн - web сервис, позволяющий вести учет заказов предприятия, имеет достаточно удобный интерфейс[1]. К недостаткам данного сервиса можно отнести: высокая стоимость использования, отсутствие возможности отслеживать перемещения заказа между подразделениями, владельцы ресурса имеют доступ к любой информации расположенной на нем. Навязчивый обслуживающий персонал. Интерфейс представлен на рисунке 2.1.

Рисунок 2.1. Интерфейс web сервиса «РемонтОнлайн»

ServiceCentr - программа предназначена для организаций занимающихся ремонтом цифровой техники. Имеет легкий в освоении, интуитивно понятный интерфейс программы. К минусам данной программы можно отнести то, что она отслеживает заказы только одного подразделения, подходит для небольших сервисных центров [2]. Практически отсутствует техническая поддержка сайта. Новые версии программы выходят достаточно редко. Интерфейс представлен на рисунке 2.2.



Рисунок 2.2 - Интерфейс программы «ServiceCentr»

Gincore - web сервис, имеет похожий функционал, однако стоимость пользования данным ресурсом достаточно велика[3] Интерфейс представлен на рисунке 2.1.3.

Рисунок 2.3 - Интерфейс web сервиса «Gincore»

1С - Один из наиболее подходящий вариантов, в плане функционала. Продуманы практически все интересующие заказчика моменты, однако высокая стоимость, заставляет отказаться от данной системы [4].

Сравним все найденные аналоги и подведем итоги в таблице 2.1



Таблица 2.1 - Сравнение аналогов по ключевым параметрам

Критерий	РемонтОнлайн	ServiceCentr	Gincore	1С:Предприятие 8 Управление сервисным центром
Доступ из веб браузера	+	-	+	-
Бесплатное распространение	-	-	-	-
Возможность отслеживать перемещения заказа между подразделениями	-	-	-	+
Прикрепление файлов к заказу	-	-	-	+
Неограниченное количество мастерских и сотрудников	-	-	+	+

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

Однако во многих системах заказчику не хватает определенного функционала. В «Gincore» и “РемонтОнлайн” вся информация о работе сервисного центра доступна владельцам ресурсов, с чем заказчик не готов мирится. Сервис “РемонтОнлайн” имеет навязчивый обслуживающий персонал постоянно докучающий звонками и письмами на электронную почту.

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



3. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ

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

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

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

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

Так как пользователь для работы с приложением будет использовать интернет браузер, то логично использовать на клиентской части связку HTML, CSS и JavaScript. HTML - стандартизированный язык разметки документов, он позволяет легко разрабатывать пользовательский интерфейс. CSS - формальный язык описания внешнего вида документа, написанного с использованием языка разметки. JavaScript - это объектно ориентированный язык программирования, часто использующийся для формирования логики клиентской части приложения. Данная связка является стандартом при разработке веб приложений.

Для разработки серверной части данной системы был выбран язык Java - типизированный объектно-ориентированный язык программирования, разработанный компанией Sun Microsystems. Данный язык был выбран по ряду причин:

кроссплатформенность обеспечивает переносимость приложений на разные платформы;

строгая типизация;

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

большое количество информации по тонкостям языка;

сильно развитое интернет сообщество.

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

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

Под данный критерий попали следующие системы управления базами данных: Firebird (FirebirdSQL), H2, MySQL, PostgreSQL. Для разработки приложения решено было использовать MySQL, так как это наиболее знакомая СУБД для разработчика.Разработку и поддержку MySQL осуществляет корпорация Oracle. MySQL является решением для малых и средних приложений. К тому же данная СУБД очень популярна. Имеет удобный инструмент для разработки mysql workbench. Он позволяет без особых усилий создать схему базы данных, написать и выполнить любые запросы к базе данных.

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

быстрая разработка пользовательского интерфейса;

наличие готовых визуальных компонент;

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

Основным недостатком данного подхода является увеличение нагрузки на сервер. В сети интернет найдены следующие технологии: Apache Wicket, Tapestry, OpenLaszlo, ZK. Все представленные Фреймворки позволяют создавать пользовательские интерфейсы для веб приложений, используя для решения большинства задач язык Java.

Apache Wicket - фреймворк с открытым исходным кодом для создания веб-приложений. Разработан Джонатаном Локе в 2004 году. С июня 2007 года является проектом Apache Software Foundation. Для использования данной технологии требуется знание HTML и JAVA, возможно использование технологии AJAX без написания кода на языке JavaScript. Файл шаблона разметки представлен в листинге 3.1.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:wicket="http://wicket.apache.org/dtds.data/wicket-xhtml1.3-strict.dtd" xml:lang="en" lang="en"> <body> <span wicket:id="message" id="message">Message goes here</span> </body> </html>

Листинг 3.1 - Файл шаблона разметки на HTML фреймворка Apache Wicket

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

<canvas height="350" width="1050" bgcolor="#FFBE7D" > <view width="500" height="250" align="center" valign="middle" bgcolor="#FFFF66"> <text align="center" valign="middle"> <font size="25">Welcome to Hello World!</font> </text> </view> </canvas>

Листинг 3.2 - Пример синтаксиса OpenLaszlo

Tapestry - фреймворк для создания веб-приложений, реализующих шаблон MVC («Модель-представление-контроллер»). Tapestry был создан Говардом Льюисом Шипом и продолжает активно развиваться. Фреймворк позволяет легко использовать технологию AJAX, валидацию данных, обеспечивает возможность локализации веб-приложений.

<t:eventlink event="updateTime" async="true">update</t:eventlink> ... <t:zone t:id="timeArea" id="timeArea"> The current time is ${currentTime} </t:zone>

Листинг 3.3 - Пример Синтаксиса Tapestry

ZK - фреймворк для разработки web приложений имеется как бесплатная, так и платная версии, позволяет облегчить разработку пользовательского интерфейса программы. Имеет XML подобный синтаксис.

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

Файлы, использующиеся для представления пользователю, имеют расширение *.zul.

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

Таблица 3.1 - Сравнение генераторов HTML страниц

Критерий	Apache Wicket	OpenLaszlo	Tapestry	ZK
Наличие множества готовых компонент	-	-	-	+
Возможность управлять содержимым страницы с помощью Java кода	+	+	+	+
Отсутствие необходимости знать HTML	-	+	+	+
Взаимодействие по шаблону MVVM	-	-	-	+
Наличие большого количества примеров использования	+	+	-	+

Среди представленных фреймворков для решения задачи взаимодействия с пользователем была выбрана технология ZK. Поэтому представим ее более подробное описание.

Zkoss преобразует файлы формата *.zul в html документ посредством внутренней логики фреймворка. Синтаксис языка отличается от html, однако поддерживает все его конструкции. Поддерживает язык JavaScript, а также ZScript. Есть поддержка CSS3 и ZCSS. Zkoss сам производит формирование запроса на сервер, а также обработку данных для отображения пользователю.

Позволяет работать по двум шаблонам проектирования MVC и MVVM. В разрабатываемом приложении используется второй способ, так как является более производительным и более прост в реализации.

На рисунке 3.1 представлен принцип работы приложения по шаблону MVVM.

Рисунок 3.1 принцип работы приложения по шаблону MVVM.

Также Zkoss поддерживает другой, пожалуй, самый популярный фреймворк в языке java - Spring. Во всех ViewModel используемых Zkoss необходимо использовать вместо аннотации @Autowired или @Inject аннотацию @WireVariable или @Wire.

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

Для разделения полномочий пользователей и обеспечения безопасности необходима авторизация. Каждый пользователь имеет уникальный логин и пароль. Каждому пользователю назначаются определенные права на доступ к данным. Данные о пользователе и ролях хранятся в базе данных. В качестве инструмента для обеспечения безопасности выбран Spring Security. Данный фреймворк предоставляет комплексные службы безопасности для приложений корпоративного ПО на базе Java EE. Особое внимание уделяется поддержке проектов, созданных с использованием Spring Framework, который является ведущим решением Java EE для разработки корпоративного программного обеспечения.

Для организации взаимодействия базы данных и приложения в языке Java существует специальная спецификация - JPA (Java Persistence API). Данная спецификация описывает систему управления сохранения Java объектов в таблицы реляционных баз данных в удобном виде. В самом языке нет предусмотренной реализации данной спецификации, однако существует множество реализаций данной спецификации от разных компаний. Данный способ сохранения Java объектов в базе данных является самым популярным, именно он и используется в данном проекте.

В качестве реализации спецификации JPA используется Hibernate -- библиотека для языка программирования Java, предназначенная для решения задач объектно-реляционного отображения (ORM). Является самым популярным фреймворком для работы с базами данных.

Для автоматизированного выполнения рутинных операций таких как компиляция, сборка, выполнение тестов и добавление библиотек к проекту необходимо использовать специализированный фреймворк сборщик. К наиболее популярным сборщикам относятся: Apache Maven, Gradle, Apache Ant. Произведем сравнение данных фреймворков, результаты сравнения представлены в таблице 3.2.

Таблица 3.2 - Сравнение средств автоматической сборки проекта

Критерий	Apache Maven	Gradle	Apache Ant
Независимость от OS	+	+	+
Управление зависимостями	+	+	-
Возможна сборка из командной строки	+	+	+
Интеграция со средами разработки	+	+	-

Так как изо всех представленных средств для сборки проекта наибольшей популярностью пользуется Apache Maven, то он и будет использоваться в данном проекте.

Web приложения, разрабатываемые на Java, работают при помощи Java Servlet API. Сервлет является интерфейсом Java, реализация которого расширяет функциональные возможности сервера. Сервлет взаимодействует с клиентами посредством принципа запрос-ответ. Общее взаимодействие клиента и сервлета выглядит следующим образом: после того как пользователь отправил запрос веб-серверу, сервер отправляет запрос контейнеру сервлетов. Контейнер сервлетов выполняет запрос и отправляет ответ веб-серверу в виде html страницы.

Для работы приложения необходим контейнер сервлетов и веб-сервер. Apache Tomcat может одновременно использоваться как контейнер сервлетов и веб-сервер. Использование Apache Tomcat является стандартом при разработке веб-приложений с использованием Java Servlet API. По сравнению с Jetty работает быстрее.

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

Среди популярных систем контроля версий можно выделить следующие: GIT, SVN (Subversion), Mercurial. Все представленные системы имеют свои преимущества и недостатки. В данном проекте используется GIT так как он, по сравнению с остальными системами контроля версий работает с изменениями, а не с файлами, является распределенной системой. Работать с GIT намного проще, чем с SVN и Mercurial, к тому же GIT отлично взаимодействует с редакторами, такими как Intellij Idea и Eclipse.

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

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

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

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

Состоят из четырех стандартных слоев: презентационный слой, бизнес, слой взаимодействия с базой данных и базы данных. В некоторых случаях бизнес-уровень и уровень взаимодействия с базой данных объединяются в единый бизнес-уровень, в частности, когда логика взаимодействия с базой данных (например, SQL или HSQL) находится в компонентах бизнес уровня. Таким образом, маленькие приложения могут иметь только три слоя, тогда как больше и более сложные бизнес-приложения могут содержать пять или более слоев.

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

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

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



Рисунок 3.2 Архитектура приложения

Серверная часть приложения разбита на слои, отвечающие за определенный вид задач. Всего можно выделить 4 три слоя: слой, отвечающий за работу пользовательского интерфейса - User Interface(UI), слой сервисов отвечающих за логику работы приложения - Business Service(BS), слой для работы с базой данных - Data Access(DA) и слой хранения данных в качестве данного слоя выступает выбранная нами СУБД MySQL.

3.2 Проектирование структур данных и алгоритмов

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

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

Для начала разработки сайта необходимо установить следующее программное обеспечение: GIT, Apache Maven, Intellij Idea, Tomcat 7.0. JDK 1.8. При запуске Intellij Idea указываем расположение JDK и Apache Maven и создаем пустой maven проект. В файле pom.xml указываем необходимые зависимости: ZK, Spring, Spring security, JPA, Hibernate.

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

В листинге 3.4 приведен пример конфигурации зависимости в файле pom.xml для фреймворка ZK.

<properties> <zk.version>8.0.3.1</zk.version> </properties> <repositories> <repository> <id>zk repository</id> <url>http://mavensync.zkoss.org/maven2</url> </repository> </repositories> <dependency> <groupId>org.zkoss.zk</groupId> <artifactId>zkplus</artifactId> <version>${zk.version}</version> </dependency> <dependency> <groupId>org.zkoss.zk</groupId> <artifactId>zk</artifactId> <version>${zk.version}</version> </dependency>

Листинг 3.4 Пример конфигурации зависимостей в maven

В Intellij Idea есть панель управления сборщиком maven в которой представлены основные команды для работы с данным инструментом. После нажатия кнопки “Reimport All Maven projects” произойдет автоматическое скачивание необходимых библиотек и удаление ненужных. По аналогии с листингом 4 прописываем все остальные зависимости.

3.3 Проектирование пользовательского интерфейса

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

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

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

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

Рисунок 3.3 - Пример макета пользовательского интерфейса



4. РЕАЛИЗАЦИЯ

4.1 Особенности реализации

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

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

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

Таблица USERS хранит информацию о пользователях системы, содержит следующие поля:

ID INT(11) - идентификационный номер;

NAME VARCHAR(45) - имя пользователя;

SECOND_NAME VARCHAR(45) - отчество;

FAMILY_NAME VARCHAR(45) - фамилия;

EMAIL VARCHAR(45) - электронная почта;

PASSWORD - пароль для доступа к системе хранится в зашифрованном виде;

PLACE_ID INT(11) - ИД места к которому привязан пользователь системы.

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

ID INT(11) - идентификационный номер;

TYPE VARCHAR(45) - тип ресурса в системе;

таблицы USERS и RIGHTS имеют связь многие ко многим.

Каждое отделение имеет определенный адрес, который потом учитывается при найме работников, местонахождении заказов, а также для других бизнес процессов. Таблица PLACE имеет четыре поля:

ID INT(11) - идентификационный номер;

ADDRESS VARCHAR(255) - полный адрес отделения сервисного центра.

Следующие два поля используются для визуального отображения отделения на карте:

LAT DOUBLE - координата широты (latitude);

LNG DOUBLE - координата долготы (longitude).

Таблица REQUEST используется для хранения информации о заказах, имеет четыре поля:

ID INT(11) - идентификационный номер;

DATE DATE - дата создания заказа;

DESCRIPTION VARCHAR(45) - описание заказа;

CLIENT_ID INT(11) - ссылка на клиента сделавшего заказ.

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

STATUS:

ID INT(11) - идентификационный номер;

STATUS VARCHAR(255) - название статуса;

Таблицы REQUEST и STATUS имеют связь многие ко многим. Связующей таблицей является таблица STATUS_HISTORY. В данной таблице хранится:

DATE DATE - дата добавления статуса к заказу;

STATUS_ID INT(11) - ссылка на статус;

REQUEST _ID INT(11) - ссылка на заказ.

В таблице DEFECT хранятся неисправности техники, имеет лишь два поля:

ID INT(11) - идентификационный номер;

NAME VARCHAR(45) - название неисправности.

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

Сведения о клиенте находятся в таблице CLIENT:

ID INT(11) - идентификационный номер;

NAME VARCHAR(45) - имя пользователя;

SECOND_NAME VARCHAR(45) - отчество;

FAMILY_NAME VARCHAR(45) - фамилия;

ADDRESS VARCHAR(45) - адрес проживания ( используется при доставке заказа на дом);

PHONE VARCHAR(45) - номер телефона для связи.

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

ID INT(11) - идентификационный номер;

DATE DATE - дата;

REQUEST _ID INT(11) - ссылка на заказ;

USER_ID INT(11) - ссылка на пользователя системы.

Описанная выше база данных может быть легко расширена (Приложение 1). Листинг создания базы данных (Приложение 2).

4.1.2 Разработка слоя взаимодействия с базой данных

Так как все данные приложения хранятся в базе данных, то необходимо настроить взаимодействие СУБД и разрабатываемой системой. Язык Java является объектно-ориентированным языком программирования, поэтому все данные в нем должны представляться в виде объектов. Фреймворк Hibernate предоставляет возможность объектно реляционного отображения данных. В базе данных на данный момент находится двенадцать сущностей. Все эти сущности необходимы для работы с пользователем, поэтому необходимо создать для каждой сущности объект который отображал бы структуру сущности в базе данных. В структуре объекта необходимо указать только те атрибуты из базы данных которые необходимы для работы приложения, таким образом, сокращается требуемый приложению объем оперативной памяти.

Для того чтобы использовать выбранную реализацию JPA фреймворк Hibernate необходимо прописать зависимость в файле pom.xml и заново импортировать все библиотеки. Maven автоматически подтянет все указанные библиотеки.

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

Над созданным классом сущности необходимо указать две аннотации @Entity и @Table в атрибутах последней необходимо указать название сущности в базе данных. Вместо аннотаций также допустимо использовать XML конфигурацию. Над каждым полем класса указывается аннотация @Column, в атрибутах которой указывается название атрибута сущности в базе данных, а также дополнительные параметры. В качестве атрибута Java класса также может быть подмножество других сущностей. Подмножества сущностей в Java классе представляют собой коллекцию данных Set. Использование данного способа хранения обусловлено тем, что при таком хранении данных отсутствует дублирование объектов. В Java классе над полем такого подмножества прописывается аннотация @OneToMany, в атрибутах данной аннотации указывается способ извлечения данных. Существует два способа EAGER и LAZY. Использование второго способа более предпочтительно, так как по сравнению с EAGER данные извлекаются из базы данных только во время вызова get метода данного атрибута, при использовании EAGER извлекаются сразу все данные из сущности соответствующей данному Java объекту. Согласно спецификации в Java классе отражающем сущность в базе данных, необходимо создать не приватный конструктор без аргументов.

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

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

На рисунке 4.1 представлена общая схема взаимодействия DataAccess слоя с базой данных с использованием связки JPA и Hibernate.

Рисунок 4.1 - Общая схема взаимодействия DataAccess слоя с базой данных

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

В качестве паттерна использования конкретного DataAccess сервиса применятся Singleton. Это позволяет использовать один экземпляр класса в работе всего приложения. Достигается этот использованием Фреймворка Spring и его возможности управления внедрения зависимостей Dependency Injection (DI). В фреймворке Spring существует несколько способов управления внедрением зависимостей: XML конфигурация, аннотации, использование специальных интерфейсов фреймворка Spring для конфигурирования зависимостей с помощью Java кода. В данном проекте используются первые два способа. В XML конфигурации указывается конкретная реализация интерфейса EntityManagerFactory и JpaTransactionManager. Разработанные нами сервисы DataAccess слоя конфигурируются только при помощи аннотаций. Аннотация @Repository показывает, что данный класс функционирует как репозиторий, что требует наличия прозрачной трансляции исключений. В независимости от используемой технологии в слое доступа данных слой сервиса будет иметь дело с общей иерархией исключений Spring (DataAccessException). Над методами классов непосредственно осуществляющих работу с базой данных стоит аннотация @Transactional перед выполнением данного метода Spring открывает транзакцию, а после выполнения метода транзакция коммитится, а при выбрасывании RuntimeException происходит откат транзакции.

4.1.3 Разработка слоя бизнес сервисов

В данном проекте имеется большая бизнес логика, для того что бы как то отделить бизнес процессы от технических сервисов системы, вся логика связанная с бизнес процессами вынесена в отдельный слой называемый Business Service(BS).

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

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

В проекте на данный момент создано 6 сервисов.ClientService отвечает за все операции, проводимые с клиентами: добавить нового клиента, найти клиента по фамилии, изменить данные клиента. Каждый сервис содержит в себе операции, проводимые с моделями. Такими операциями как создание заказа, изменение заказа, удаление.

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

Объекты в приложении имеют зависимости друг от друга. Хотя платформа Java обеспечивает множество функциональных возможностей разработки приложений, ей не хватает средств для организации базовых строительных блоков в единое целое, оставляя эту задачу архитекторам и разработчикам. Для решения данной проблемы можно использовать шаблоны проектирования, такие как Factory, Abstract Factory, Builder, Decorator и Service Locator для составления различных классов и экземпляров объектов, составляющих приложение, эти шаблоны содержат: лучшие практики с указанием имени, с описанием что делает шаблон, где его применять, проблемы, с которыми он обращается, и так далее. Шаблоны - это формализованные лучшие практики, которые можно реализовать в своем приложении. Компонент Spring Framework Inversion of Control (IoC) решает эту проблему, предоставляя формализованные средства компоновки разрозненных компонентов в полностью работающее приложение, готовое к использованию. Spring Framework кодирует формализованные шаблоны проектирования как объекты первого класса, которые можно интегрировать в свои собственные приложения.

Управление зависимостями и внедрение зависимостей - это разные вещи. Чтобы получить эти приятные функции Spring в нашем приложении необходимо собрать все необходимые библиотеки (файлы jar) и получить их на пути к классам во время выполнения и, возможно, во время компиляции. Эти зависимости не являются импортированными виртуальными компонентами, а физическими ресурсами в файловой системе. Процесс управления зависимостями включает в себя размещение этих ресурсов, их хранение и добавление их в пути к классам. Зависимости могут быть прямыми (например, мое приложение зависит от Spring во время выполнения) или косвенным (например, мое приложение зависит от commons-dbcp, который зависит от общего пула). Косвенные зависимости также известны как «транзитивные», и именно эти зависимости сложнее идентифицировать и управлять.

В каждый бизнес сервис с помощью Фреймворка Spring внедряется зависимость от сервиса, отвечающего за взаимодействие с базой данных. С помощью данной зависимости бизнес сервисы работают с данными находящимися в базе данных.

4.1.4 Разработка слоя пользовательского интерфейса

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

Благодаря Фреймворку ZK пользовательский интерфейс разрабатывается достаточно быстро.

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

Spring Security обеспечивает комплексное решение для обеспечения безопасности для корпоративного программного обеспечения на базе Java EE приложения.Особое внимание уделяется поддержке проектов, созданных с использованием Spring Framework, который является ведущим решением Java EE для разработки корпоративного программного обеспечения.

Большинство причин для привлечения Spring Security к проекту является обнаружение функций безопасности спецификации сервлетов Java EE или спецификации EJB так как не хватает глубины, необходимой для типичных сценариев корпоративных приложений. Несмотря на упоминание этих стандартов, важно признать, что они не переносимы на уровне WAR или EAR. Поэтому, если работа приложения переключается на разные серверные среды, обычно требуется большая работа по перенастройке безопасности вашего приложения в новую целевую среду. Использование Spring Security позволяет преодолеть эти проблемы, а также приносит вам десятки других полезных настраиваемых функций безопасности.

Spring Security имеет архитектуру, которая предназначена для разделения аутентификации от авторизации и имеет стратегии и точки расширения для обоих.

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

Рисунок 4.2- Меню сайта

Во вкладке заказы расположен список с новыми заказами в системе.

При нажатии на вкладку «Справочники» разворачивается список с категориями справочников.

Вкладка «Места» содержит списочное представление существующих мастерских и приемных пунктов у данного сервисного центра.