Разработка систем GPS-мониторинга

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

Федеральное агентство связи

Федеральное государственное бюджетное образовательное учреждение

высшего образования

«Поволжский государственный университет телекоммуникаций и информатики»

Факультет Информационных систем и технологий

Направление Программная инженерия

Кафедра Информационных систем и технологий

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

Разработка систем GPS-мониторинга

Разработал

В.А. Тарасова

Самара 2017



Введение

В последнее десятилетие в России интенсивно ведутся исследования и разработки по геоинформатике. Основным инструментом для решения стоящих перед ней задач являются геоинформационные системы (ГИС). Эти системы предназначены для работы с большими объемами пространственных данных и решают задачи сбора, хранения, визуализации и анализа таких данных. Сегодня ГИС широко применяются в различных областях человеческой деятельности.

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

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

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

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

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

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

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

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

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

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

Предмет исследования: применение программного обеспечения в этой отрасли.

Основными источниками для написания работы послужили книги по разработке на Java Б. Эккеля, К. Хорстмана, Г. Шилдта, статьи по работе с навигационными системами.

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

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

Вторая глава раскрывает обзор средств и методов для решения поставленной задачи.

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

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



1. Геоинформационные системы

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

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

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



1.1 Использование ГИС в мире

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

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

На электронной карте города может быть представлена следующая информация:

Инфраструктура территории, административное деление, органы управления.

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

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

Объекты связи и коммуникации, состояние коммуникационной сети, планирование ремонта и развития сети.

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

Геоинфраструктура торговли, общественного питания и др.

Промышленные объекты и их влияние на экологию.

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

Формирование отчетов о состоянии подчиненной территории, как по территориальным признакам, так и по стандартным запросам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Формирование отчетов о состоянии управляемой сети, как по территориальным признакам, так и по стандартным запросам.

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

1.2 Системы навигации GPS и ГЛОНАСС

GPS (Global Positioning System -- глобальная система определения координат) -- спутниковая поисковая система, составленная из совокупности 24 спутников, помещенных на орбиту американским Министерством обороны и наземных станций слежения, объединенных в общую сеть. Глобальная система определения координат (GPS) была первоначально предназначена для военных целей, но в 80-х годах XX века, правительство сделало систему доступной для гражданского использования. Глобальная система определения координат работает в любых метеорологических условиях, в любой точке мира, 24 часа в день. Никаких ограничений на использование системы определения координат не существует.

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

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

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

Более новые модели приемников (навигаторов) GPS с системой WAAS (Wide Area Augmentation System) способны улучшить точность определения координат до 2-3 метров. Эта расположенная в космосе система передает информацию, обеспечивающую непрерывность спутниковых сигналов, а также данные корректировок, определяемые наземными станциями. Правительства США, Канады и других государств установили дифференциальные GPS-станции (DGPS), предназначенные для передачи корректирующих сигналов. Эти станции работают в прибрежных районах, а также в бассейнах судоходных рек. Пользование системой DGPS является бесплатным. Сигналы, передаваемые станциями DGPS, не только корректируют ошибки при расчете местоположения, но также компенсируют ухудшение точности GPS, вызванное использованием программы SA (Selective Availability), проводимой Департаментом Обороны США. Для использования DGPS требуется дополнительное оборудование.

24 орбитальных спутника земли, которые составляют сеть GPS, находятся на высоте 12 000 миль. Они постоянно двигаются, делая две полных орбиты за менее чем 24 часа. Эти спутники имеют скорость примерно 7 000 миль в час.

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

Вот некоторые факты о спутниках GPS, также называемые NAVSTAR (официальное американское название Министерства обороны):

Первый спутник GPS был запущен в 1978 году.

Полная совокупность из 24 спутников была достигнута в 1994 году.

Средний срок службы одного спутника приблизительно 10 лет.

Спутник GPS весит приблизительно 2 000 фунтов и имеет размер 17 футов, включая солнечные панели.

Мощность передатчика -- 50 ватт.

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

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

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

Ошибки часов приемника -- встроенные часы приемника не столь же точны как бортовые атомные часы спутника GPS. Поэтому, это может иметь очень небольшие ошибки синхронизации.

Орбитальные ошибки -- Также известны как эфемероидные ошибки, -- погрешности местоположения спутника.

Количество спутников -- Чем больше спутников может видеть приемник, тем лучше точность. Модули глобальной системы обычно не будут работать в закрытом помещении, под водой или землей.

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

Намеренное снижение производительности спутникового сигнала -- Основным источником было наличие, так называемого, режима "ограниченного доступа". В этом режиме в сигналы спутников Министерством обороны США априорно вводилась погрешность, позволяющая определять местоположение с точностью 30-100 м. С 1 мая 2000 года режим "ограниченного доступа" был отключен.

ГЛОбальная НАвигационная Спутниковая Система (ГЛОНАСС) - российская спутниковая система навигации, предназначена для оперативного навигационно-временного обеспечения неограниченного числа пользователей наземного, морского, воздушного и космического базирования. ГЛОНАСС - единственная система в мире, которая предоставляет доступ к гражданскому сигналу глобального позиционирования в двух частотных диапазонах L1 и L2 потребителям по всему миру на безвозмездной основе.

Основой системы ГЛОНАСС являются 24 космических аппарата, которые движутся в трёх орбитальных плоскостях по 8 аппаратов в каждой плоскости, наклоненных к экватору под углом 64,8°, с высотой орбит 19100 км и периодом обращения 11 ч 15 мин 44 с. Выбранная структура орбитальной группировки обеспечивает движение всех КА по единой трассе на поверхности Земли с ее повторяемостью через 8 суток. Такие характеристики обеспечивают высокую устойчивость орбитальной группировки системы ГЛОНАСС, что практически позволяет обходиться без коррекции орбит космических аппаратов в течение всего срока их активного существования.

В настоящее время развитием проекта ГЛОНАСС занимается Государственная корпорация «РОСКОСМОС» и министерства и ведомства России: Минобороны, МВД, Ростехнадзор, Минтранс, Росреестр, Минпромторг, Росстандарт, Росавиация, Росморречфлот, ФАНО.

1.3 Постановка задачи

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

ѕ Спроектировать архитектуру приложения;

ѕ Выбрать инструменты и методы реализации на языке Java;

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

ѕ Приложение не должно обладать другими избыточными функциями;

ѕ Приложение должно быть легко масштабируемо и дополняемо;

ѕ Код должен быть снабжен документацией и комментариями;

ѕ Архитектура приложения должна быть понятной, логичной и обоснованной;

ѕ Приложение должно быть кроссплатформенным;

ѕ Реализовать веб-интерфейс приложения

ѕ Реализовать приложение в формате трехзвенной архитектуры

ѕ Работу клиента и сервера производить через специальный протокол

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

ѕ Хранение объектов в БД

ѕ Загрузка объектов из БД при запуске приложения

ѕ Графический интерфейс на Swing

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

ѕ Иные возможности на усмотрение разработчика;

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



2. Веб-приложения на Java

Веб-приложение Java создает интерактивные веб-страницы, содержащие различные типы языков разметки (HTML, XML и т.д.), а также динамическое содержимое. Это содержимое обычно формируется веб-компонентами, например, страницами JavaServer (JSP), сервлетами и компонентами JavaBean, которые позволяют изменять данные и осуществлять их временное хранение, взаимодействовать с базами данных и веб-службами, а также отображать содержимое в ответ на запросы клиентов.

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

Java EE (Enterprise Edition) представляет собой широко используемую платформу, содержащую набор взаимосвязанных технологий, которые существенно сокращают стоимость и сложность разработки, развертывания многоуровневых серверных приложений, а также управления ими. Платформа Java EE основана на платформе Java SE и предоставляет набор интерфейсов API (интерфейсов разработки приложений) для разработки и запуска портируемых, надежных, масштабируемых и безопасных серверных приложений.

Java EE в числе прочих содержит следующие компоненты:

Enterprise JavaBeans (EJB): управляемая серверная архитектура компонентов, используемая для инкапсуляции бизнес-логики приложения. Технология EJB позволяет осуществлять быструю и упрощенную разработку распределенных, транзакционных, безопасных и переносимых приложений, основанных на технологии Java.

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

2.1 Разработка структуры корпоративных приложений

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

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

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

Рис. 2.1 - Обобщенная структура корпоративного приложения

Другими словами, каждое web-приложение отправляет http запросы на web-сервер для получения полезных данных. Программа под управлением web-сервера использует ту или иную модель для хранения данных. В современном мире чаще всего используются базы данных, SQL или NoSQL.

Формально каждое web-приложение можно разбить на 3 взаимно независимые части.

ѕ Модуль, который исполняется WEB-браузером. Это приложение может быть написано на любом языке, который поддерживает браузер. Чаще всего используется язык JavaScript, как наиболее поддерживаемый и имеющий большую библиотечную поддержку. Это очень важно, так как позволяет существенно экономить бюджеты проектов.

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

ѕ База данных. В этой области так же существует достаточно широкий выбор. Есть промышленные базы данных, такие как Oracle, DB2, PostgreSQL. Есть легкие базы данных, такие как MySQL. База данных выбирается основываясь на целях и области решаемых задач.

Возможные эталонные модели проектирования web-приложений.

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

Рис. 2.2 - Модель проектирования веб-приложения

ѕ Модуль, который работает под управлением браузера.

ѕ Модуль, который работает под управлением web-сервера.

ѕ База данных.

Эти структурные единицы порождают два вида связей.

ѕ Связь между браузером и серверной частью.

ѕ Связь между серверной частью и базой данных.

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

Браузер -- это прикладное программное обеспечение для просмотра web страниц.

HTML - это стандартный язык разметки документов. Большинство современных web-браузеров способны интерпретировать язык HTML.

Web сервер -- это программное обеспечение, которое способно принимать HTTP запросы от клиентов, обрабатывать их и отправлять ответ в соответствии со стандартом протокола.

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

Минимизация зависимостей

Для минимизации зависимостей между «Браузером» и Web-сервером необходимо, чтобы язык разметки HTML был задействован только в браузере, а Web-сервер предоставлял интерфейс для получения необходимых данных для страницы.

Для решения этой задачи необходимо:

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

ѕ Определить API серверной части.

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

ѕ Написать документ, в котором будет изложен протокол.

Диаграмма может быть преобразована в следующий вид:

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

Далее «Браузер» преобразуется в UML диаграммы состояний. На этих диаграммах будет отражено, в каком случае вызывается тот или иной метод.

Данная модель достижима двумя путями

ѕ Программа, выполняемая «Браузером» написана на JavaScript и общается с Web-Сервером через AJAX, получая ответы в соответствие с определенным протоколом.

ѕ «Браузер» интерпретирует только HTML код, а преобразования происходят посредством XSLT преобразований на стороне Web-Сервера.

В каждом из этих случаев достигается разделение программной части Web-Сервера и «Браузера». Т.е используя данную модель возможно вносить изменения в структурную единицу для «Браузера» и не вызывать косвенных изменений в серверной части. Это очень важно, так как ведет к уменьшению затрат на обработку запросов на изменения. Это происходит в силу того, что изменения в одной структурной единицы не выходят за ее рамки.

Взаимодействие базы данных и web-сервера возможно организовать на основании двух принципиально разных сценариях:

ѕ Бизнес логика находится в базе данных.

ѕ Бизнес логика находится в коде web-сервера.

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

ѕ Выборка данных -- решается через представления.

ѕ Модификация данных -- решается через хранимые процедуры.

Программа для web-сервера является драйвером для доступа к бизнес-логике. Т.е она просто связывает Браузер с бизнес логикой, которая реализована в базе данных.

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

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

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

ѕ Модуль для «Браузера».

ѕ Модуль для Web-Сервера.

ѕ Модуль для Базы данных.

ѕ Протокол обмена между модулем «Браузера» и Web-Сервером.

ѕ Интерфейс взаимодействия между модулем «Браузера» и Web-Сервером.

ѕ Интерфейс взаимодействия между Web-Сервером и Базой данных.

2.2 Серверы приложений

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

Сервер приложений -- это сервисная программа, которая обеспечивает доступ клиентов к прикладным программам, выполняющимся на сервере. Сервер приложений обычно выделяется как среднее звено (рис. 2.4) в трехуровневой клиент-серверной архитектуре (3-tier):

Рис. 2.4 - Модель "сервер приложений".

Первый уровень, интерфейсный, как правило, графический (GUI).

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

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

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

Бизнес-логика может быть реализована на стороне сервера как целиком (удаленный код), так и частично (распределенный код). В первом случае к серверу могут обращаться терминалы и «тонкие» клиенты и такое взаимодействие соответствует модели «сервер терминалов». «Толстые» и rich-клиенты могут получать компоненты серверного приложения и выполнять их на своей стороне (например, javascript, апплеты, flash).

Мобильный софт:

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

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

ѕ для поддержки новых устройств нужно адаптировать только фронт-энд, не затрагивая прикладную логику;

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

Клиенты могут взаимодействовать с приложениями через API сервера (Java-клиент <--> контейнер сервлетов <--> сервлет). Большую гибкость и универсальность представляет взаимодействие через сторонние сервисы, в первую очередь -- через веб-сервер.

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

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

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

ѕ Предоставляет модель контейнера для приложений.

ѕ Предоставляет сервисные услуги для программ.

ѕ Обеспечивает управление приложениями и/или представляет средства их разработки.

ѕ Соответствует индустриальным спецификациям и стандартам.

ѕ Обслуживание веб-страниц, ввиду реальной востребованности технологий на основе WWW.

По приведенным признакам в рассматриваемую категорию попадают, например, традиционные терминал-серверные системы, технология CGI, контейнеры Java-сервлетов и др.

Серверы терминалов представляют среду для удаленного выполнения программ, в качестве которой выступает сама операционная система. Доступ к ним осуществляется по протоколам удаленного управления (telnet, ssh, RDP, VNC и т. п.) из клиентского ПО (эмулятор терминала, средства управления удаленным рабочим столом и т.п.). Управление запущенной программой выполняется через эмулируемый на клиенте пользовательский интерфейс (текстовый или графический) операционной системы. На серверной стороне взаимодействие программ с ОС реализуется через системные вызовы. Управление также осуществляется средствами операционной системы. Разработка может вестись на любом языке, доступном в конкретной ОС.

Общий шлюзовый интерфейс (CGI) -- технология доступа к приложениям через веб-сервер. Отличия от сервера терминалов здесь в том, что пользовательский интерфейс предоставляется в виде веб-страниц. Запросы веб-клиентов, обращенные к программам, размещенным в выделенном каталоге (как правило cgi или cgi-bin) перенаправляются на их вход через стандартный поток ввода (stdin). Результаты выполнения в виде гипертекста приложение возвращает веб-серверу через stdout.

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

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

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

Примером реализации контейнера сервлетов является Apache TomCat, который используется в таких серверах приложений как Apache Geronimo, JBoss, GlassFish, IBM WebSphere Application Server (WAS).

Другие решения:

Компания Microsoft представляет собственные решения для поддержки бизнес-логики и сервисной инфрастуктуры на основе ОС Windows Server и технологии.NET Framework. Основным средством разработки является язык C#.

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

Для сценариев на языке PHP, широко используемом для создания веб-сайтов, компания Zend Technologies (разработчик самого языка PHP) создала сервер приложений Zend Server.

Преимущества:

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

Централизованное управление: Изменения в конфигурации прикладных программ, такие как, например, смена сервера баз данных, выполняются централизованно.

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

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

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

Недостатки

Централизация: Системы, построенные на основе сервера приложений, имеют один основной недостаток, присущий всем централизованным решениям -- «падение» сервера приведет к недоступности программ для всех клиентов. К тому же эффекту приведут и неполадки в сетевом подключении.

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



3. Проектирование и разработка решения

3.1 Средства и инструменты разработки ПО

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

Так, непосредственно для создания кода было решено выбрать среду Intellig IDEA. IDEA -- интегрированная среда разработки программного обеспечения на многих языках программирования, в частности Java, JavaScript, Python, разработанная компанией JetBrains. Первая версия IntelliJ IDEA появилась в январе 2001 года и быстро приобрела популярность, как первая Java IDE с широким набором интегрированных инструментов для рефакторинга, которые позволяли программистам быстро реорганизовывать исходные тексты программ. Дизайн среды ориентирован на продуктивность работы программистов, позволяя им сконцентрироваться на разработке функциональности, в то время как IntelliJ IDEA берёт на себя выполнение рутинных операций.

Рис. 3.1 - Скриншот рабочего окна Intellig IDEA



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

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

Комментарии документации применяют для документирования классов, интерфейсов, полей (переменных), конструкторов и методов.

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

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

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

Преимущества UML:

ѕ UML объектно-ориентирован;

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

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

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

UML получил широкое распространение и динамично развивается.

3.2 Система сборки Maven

Maven - это инструмент для сборки Java проекта: компиляции, создания jar, создания дистрибутива программы, генерации документации. Простые проекты можно собрать в командной строке. Если собирать большие проекты с командной строки, то команда для сборки будет очень длинной, поэтому её иногда записывают в bat/sh скрипт. Но такие скрипты зависят от платформы. Для того чтобы избавиться от этой зависимостии и упростить написание скрипта используют инструменты для сборки проекта.

Основные преимущества Maven:

ѕ Независимость от OS. Сборка проекта происходит в любой операционной системе. Файл проекта один и тот же.

ѕ Управление зависимостями. Редко какие проекты пишутся без использования сторонних библиотек(зависимостей). Эти сторонние библиотеки зачастую тоже в свою очередь используют библиотеки разных версий. Maven позволяет управлять такими сложными зависимостями. Что позволяет разрешать конфликты версий и в случае необходимости легко переходить на новые версии библиотек.

ѕ Возможна сборка из командной строки. Такое часто необходимо для автоматической сборки проекта на сервере (Continuous Integration).

ѕ Хорошая интеграция со средами разработки. Основные среды разработки на java легко открывают проекты, которые собираются c помощью maven. При этом зачастую проект настраивать не нужно - он сразу готов к дальнейшей разработке.

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

ѕ Декларативное описание проекта.

pom.xml - это основной файл, который описывает проект. Вообще могут быть дополнительные файлы, но они играют второстепенную роль.

Состав файла pom.xml:

1. Корневой элемент и заголовок.

<project xmlns="http://maven.apache.org/POM/4.0.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/POM/4.0.0

http://maven.apache.org/xsd/maven-4.0.0.xsd">

<modelVersion>4.0.0</modelVersion>

</project>

Корневой элемент <project>, схема, которая облегчает редактирование и проверку, и версия POM. Внутри тэга project содержится основная и обязательная информация о проекте:

<!-- The Basics -->

<groupId>...</groupId>

<artifactId>...</artifactId>

<version>...</version>



В Maven каждый проект идентифицируется парой groupId artifactId. Во избежание конфликта имён, groupId - наименование организации или подразделения и обычно действуют такие же правила, как и при именовании пакетов в Java - записывают доменное имя организации или сайта проекта. artifactId - название проекта. Внутри тэга version, как можно догадаться хранится версия проекта. Тройкой groupId, artifactId, version (далее - GAV) можно однозначно идентифицировать jar файл приложения или библиотеки. Если состояние кода для проекта не зафиксировано, то в конце к имени версии добавляется "-SNAPSHOT" что обозначает, что версия в разработке и результирующий jar файл может меняться. <packaging>...</packaging> определяет какого типа файл будет создаваться как результат сборки. Возможные варианты pom, jar, war, ear

Давайте лучше рассмотрим на примере проекта powermock-core groupId - org.powermock, artifactId - powermock-core, version - 1.4.6

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

<name>Trackcar</name> название проекта для человека

<description>GPSMonitor</description> Описание проекта

<url>localhost </url> сайт проекта.

Зависимости - следующая очень важная часть pom.xml - тут хранится список всех библиотек (зависимостей) которые используюся в проекте. Каждая библиотека идентифицируется также как и сам проект - тройкой groupId, artifactId, version (GAV). Объявление зависимостей заключено в тэг <dependencies>...</dependencies>.

<dependencies>

<dependency>

<groupId>junit</groupId>

<artifactId>junit</artifactId>

<version>4.4</version>

<scope>test</scope>

</dependency>

<dependency>

<groupId>org.powermock</groupId>

<artifactId>powermock-reflect</artifactId>

<version>${version}</version>

</dependency>

<dependency>

<groupId>org.javassist</groupId>

<artifactId>javassist</artifactId>

<version>3.13.0-GA</version>

<scope>compile</scope>

</dependency>

</dependencies>

Как можно заметить, кроме GAV при описании зависимости может присутствовать тэг <scope>. Scope задаёт, для чего библиотека используется. В данном примере говорится, что библиотека с GAV junit:junit:4.4 нужна только для выполнения тестов. Тэг <build> необязательный, т. к. существуют значения по умолчанию. Этот раздел содержит информацию по самой сборке: где находятся исходные файлы, где ресурсы, какие плагины используются. Например:

<build>

<outputDirectory>target2</outputDirectory>

<finalName>ROOT</finalName>

<sourceDirectory>src/java</sourceDirectory>

<resources>

<resource>

<directory>${basedir}/src/java</directory>

<includes>

<include>**/*.properties</include>

</includes>

</resource>

</resources>

<plugins>

<plugin>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-pmd-plugin</artifactId>

<version>2.4</version>

</plugin>

</plugins>

</build>

Рассмотрим пример более подробно.

<sourceDirectory> определяет, откуда maven будет брать файлы исходного кода. По умолчанию это src/main/java, но вы можете определить, где это удобно. Директория может быть только одна (без использования специальных плагинов)

<resources> и вложенные в неё тэги <resource> определяют, одну или несколько директорий, где хранятся файлы ресурсов. Ресурсы в отличие от файлов исходного кода при сборке просто копируются. Директория по умолчанию src/main/resources

<outputDirectory> определяет, в какую директорию компилятор будет сохранять результаты компиляции - *.class файлы. Значение по умолчанию - target/classes

<finalName> - имя результирующего jar (war, ear) файла с соответствующим типу расширением, который создаётся на фазе package. Значение по умолчанию -- artifactId-version.

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

ѕ Основные фазы сборки проекта:

ѕ Compile Компилирование проекта

ѕ Test Тестирование с помощью JUnit тестов

ѕ Package Создание.jar файла или war, ear в зависимости от типа проекта

ѕ integration-test Запуск интеграционных тестов

ѕ install Копирование.jar (war, ear) в локальный репозиторий

ѕ deploy публикация файла в удалённый репозиторий

К примеру, нам нужно создать jar проекта. Чтобы его создать нужно задать команду: mvn package.

Но перед созданием jar-файла будут выполняться все предыдущие фазы compile и test, а фазы integration-test, install, deploy не выполнятся. Если набрать mvn deploy, то выполнятся все приведённые выше фазы.

Особняком стоят фазы clean и site. Они не выполняются, если специально не указаны в строке запуска.

Clean - удаление всех созданных в процессе сборки артефактов:.class,.jar и др. файлов. В простейшем случае результат -- просто удаление каталога target Site - предназначена для создания документации (javadoc+сайт описания проекта) Т. к. команда mvn понимает, когда ему передают несколько фаз то для сборки проекта создания документации "с нуля" выполняют: mvn clean package site

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



3.3 Библиотека JUnit для тестирования классов

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

1) Для С++ была реализована CPPUnit;

2) JavaScript может использоваться совместно с JSUnit;

3) Для C# разработчики создали NUnit;

4) Perl скрипты можно тестировать с помощью Test:Unit;

5) PHP код могут тестировать с помощью PHPUnit модуля;

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

Метод assertFalse проверяет, является ли результат выражения в скобках неверным. При запуске теста последний пройдет успешно, т.к. результат - не равный. В классе "org.junit.Assert" предусмотрены и другие методы:

ѕ assertEquals(int1, int2) или утверждение эквивалентности. Проверяет на равенство двух значений любого примитивного типа;

ѕ assertFalse, assertTrue(condition) или булевые утверждения. Вместо “condition” необходимо вставить проверяемое условие;

ѕ assertNull, assertNotNull(obj) относятся к Null утверждениям и проверяет содержимое объектной переменной на Null значение;

ѕ assertSame(obj1, obj2) утверждение позволяет сравнивать объектные переменные.

Для каждого из assert-ов вы можете добавить первым параметром строку, которая выведется, если тест провалится: assertEquals (“Test is failed”, int1, int2).

Если какой-либо тест по какой-либо серьезной причине нужно отключить, nакже, если поместить аннотацию на класс, то все тесты в этом классе будут отключены. Помимо этого есть также аннотация @Test(timeout = 1000). По истечении указанного в скобках времени, если тест не пройден, он считается неудачным. Время указывается в миллисекундах.

...