Программа контроля МЧС рыбаков, дрейфующих на льдине

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

РЕФЕРАТ

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

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

Целью работы являлась разработка инфраструктуры для программной системы «Программа контроля МЧС рыбаков, дрейфующих на льдинах».

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

Данная программная система разработана на основе технологий реляционного отображения данных, Servlet, JSP, XML, JavaMail. Так как сервлеты и jsp-страницы вызываются через HTTP-протокол, то Servlet-контейнер и JSP-контейнер часто сопровождает еще один компонент - web-сервер.

В качестве веб-сервера был использован Tomcat 7.0. Приложение было разработано с использованием комплекта JDK версии 1.6.0.22.

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

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

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

БАЗА ДАННЫХ, JAVA, ОБЪЕКТНО-РЕЛЯЦИОННОЕ ОТОБРАЖЕНИЕ (ORM), JSP, DAO, DOMAIN, WEB-СЕРВИС

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

1. АНАЛИЗ РЕШАЕМОЙ ЗАДАЧИ

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

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

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

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

Структура МЧС:

- Центральный аппарат МЧС Украины;

- Правительственные органы государственного управления в составе центрального аппарата, содержащихся на отдельных штатных росписях;

- Территориальные органы управления МЧС Украины и подчиненные подразделения;

- Подразделения непосредственного подчинения аппарата МЧС;

- Предприятия, организации и учреждения;

- Учебные заведения и научно-исследовательские учреждения;

- Специализированные и невоенизированные формирования.

Администратор МЧС получает сигнал о чрезвычайном происшествии, и отправляет информацию командиру подразделения. Корабль отправляется к месту происшествия и эвакуирует пострадавших. Каждый месяц составляется отчет о проделанной работе и составляется рейтинг «Топ 10 кораблей», подразделениям которых будет начислена премия, размер которой устанавливается командиром территориального округа.

Выделено четыре группы пользователей:

1. Администратор;

2. Командир подразделения;

3. Командир территориального округа;

4. Очевидец;

Администратор - сотрудник МЧС, котoрый принимает информацию о чрезвычайном проишествии, количестве пострадавших, месте проишествия, и отправляет эту информацию командиру подразделения, добавляет новую информацию о кораблях, удаляет старые заявки и данные пострадавших.

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

Очевидец - человек, который стал свидетелем происшествия и который оставляет заявку о происшествии.

1.2 Цели и задачи системы

Программная система «Программа контроля МЧС рыбаков, дрейфующих на льдинах» автоматизирует работу МЧС по контролю рыбаков, дрейфующих на льдинах.

Основные цели системы:

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

- автоматический расчет ТОП10 кораблей;

- отправка сообщений на почтовый ящик при регистрации очевидца;

1.3 Назначение системы

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

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

Рисунок 1.1 - Диаграмма вариантов использования программной системы пользователя «Администратор»

Рисунок 1.2 - Диаграмма вариантов использования программной системы пользователя «Очевидец»



Рисунок 1.3 - Диаграмма вариантов использования программной системы пользователя «Командир подразделения»

Рисунок 1.4 - Диаграмма вариантов использования программной системы пользователя «Командир территориального округа»

1.4 Требования к системе

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

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

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

2. ПРОЕКТИРОВАНИЕ ПРОГРАММНОЙ СИСТЕМЫ «ПРОГРАММА КОНТРОЛЯ МЧС РЫБАКОВ, ДРЕЙФУЮЩИХ НА ЛЬДИНАХ»

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

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

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

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

При проектировании системы управления базами данных рассмотрим следующие серверы баз данных: Oracle, MySQL, PostgreSQL и Derby.

СУБД Oracle используется в основном для баз управлениями базами данных со сложной структурой и большими размерами. К тому же, СУБД этого типа не являются свободно распостраняемыми.

MySQL - это СУБД, работа с данными в которой осуществляется при помощи SQL запросов. Основными преимуществами этого типа БД является скорость и простота в использовании. При помощи MySQL можно производить операции над данными, которые с текстовыми файлами трудно реализуемы. Данный тип баз данных широко используется в порталах, досках объявлений, электронных магазинах. В MySQL доступ к базе данных осуществляется через скрипты или с помощью программы phpMyAdmin. Недостатком в MySQL является сложность задания ограничений в базе данных.

PostgreSQL - это бесплатный и вместе с тем достаточно быстрый и мощный SQL сервер. Многие современные дистрибутивы Linux включают в себя PostgreSQL. Запущенный сервер PostgreSQL может управлять множеством баз данных. Обычно, для каждого проекта или каждого пользователя используется отдельная база данных.

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

Программа, выпущенная в рамках открытого проекта Apache Derby project, представляет собой систему баз данных с открытым исходным кодом, которая разработана на основе технологии, предоставленной организацией Apache Software Foundation корпорации IBM.

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

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

В курсовой работе будем использовать базу данных PostgreSQL, поскольку это бесплатный, кроссплатформенный и вместе с тем достаточно быстрый и мощный SQL сервер.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При выборе сервлет-контейнера были рассмотрены следующие контейнеры: Tomcat и Jetty.

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

По умолчанию, когда запускается Tomcat с помощью команды startup.bat или startup.sh, используется server.xml, который расположен в каталоге <TOMCAT_HOME>/conf/.

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

Jetty - свободный контейнер-сервлетов, написанный полностью на Java. Может использоваться как http-сервер или в паре с специализированным http-сервером. Jetty начиная с версии 7 поддерживает спецификацию Servlet 2.5 API.

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

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

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

Описывая систему в терминах архитектурных слоев, удобно воспринимать составляющие ее подсистемы в виде «слоеного пирога». Слой более высокого уровня пользуется службами, предоставляемыми нижележащим слоем, но тот не «осведомлен» о наличии соседнего верхнего слоя. Более того, обычно каждый промежуточный слой «скрывает» нижний слой от верхнего: например, слой 4 пользуется услугами слоя 3, который обращается к слою 2, но слой 4 не знает о существовании слоя 2. (Не в каждой архитектуре слои настолько «непроницаемы», но в большинстве случаев дело обстоит именно так). На рисунке 2.1 представлена архитектура многослойного приложения.

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

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

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

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

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

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

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

Расчленение системы на слои предоставляет целый ряд преимуществ:

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

- можно выбирать альтернативную реализацию базовых слоев;

- зависимость между слоями можно свести к минимуму;

- каждый слой является удачным кандидатом на стандартизацию;

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

Схема расслоения обладает и определенными недостатками:

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

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

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

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

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

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

Диаграмма классов домена изображена на рисунке 2.2:



Рисунок 2.2 - Диаграмма классов домена предметной области

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

Слой доступа к данным (Data Access Object) предназначен для обеспечения доступа к данным по определенным критериям. Он состоит из интерфейсов доступа к данным и их реализации. Диаграмма интерфейсов классов доступа к данным представлена на рисунке 2.3:

Рисунок 2.3 - Диаграмма интерфейсов классов доступа к данным

Среди всех операций доступа к данным можно отчетливо выделить базовые CRUD (create, read, update, delete) операции - создание объекта, удаление объекта, обновление объекта, получение объекта по идентификатору, и получение всех объектов. Вынесение таких операций в отдельный суперкласс позволит избежать дублирования кода. Такие базовые операции были вынесены в отдельный базовый интерфейс IGenericDao<T>, который используя Java Generics позволяет указать класс объектов, с которыми будет проходить работа.

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

На рисунке 2.4 показана диаграмма классов реализации интерфейсов доступа к данным:

Рисунок 2.4 - Диаграмма классов реализации интерфейсов доступа к данным

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

Интерфейс пользователя в приложении зависит от его роли. Главная страница гостя изображена на рисунке 2.7. На ней размещены кнопки для регистрации и входа в систему, а также ссылки на главную страницу, и на ТОП10 кораблей.

программный автоматизация серверный клиентский

3. РАЗРАБОТКА ПРОГРАММНОЙ СИСТЕМЫ «ПРОГРАММА КОНТРОЛЯ МЧС РЫБАКОВ, ДРЕЙФУЮЩИХ НА ЛЬДИНАХ»

На данном этапе приведены шаги проектирования серверной и клиентской части ИКС, сделанные на основании проведенного анализа.

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

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

3.1.1 Выбор модели данных

Модель данных - средство для определения логического представления физических данных, относящихся к некоторой ПО.

Модель данных определяется тремя компонентами:

- допустимая организация данных ( структуры данных );

- операции;

- ограничения целостности.

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

Иерархическая модель данных была первой моделью, которую стали поддерживать СУБД.

Наиболее известные СУБД, поддерживающие иерархическую модель данных - IMS, СУБД фирмы IBM. В СССР аналог IMS - ОКА.

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

Рисунок 3.1 - Структура иерархической модели данных

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

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

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

В иерархической модели легко представляются связи 1:1 и 1:М. Однако связь M:N вызывает сложности.

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



Рисунок 3.2 - Структура сетевой модели данных

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

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

В сетевой модели можно представить все виды взаимосвязи 1:1, 1:M и M:N.

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

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

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

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

В реляционной модели данные состоят в некоторых отношениях (таблицах).

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



Рисунок 3.3 - Организация данных в реляционной модели данных

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

В реляционной модели зависимости вида 1:1 и 1:М реализуется с помощью распространения ключа, а в представление М:N необходимо дополнительное отношение.

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

3.1.2 Разработка логической структуры базы данных

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

Рисунок 3.4 - Концептуальная модель предметной области

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

Рисунок 3.5 - Схема БД «Программа контроля МЧС рыбаков, дрейфующих на льдинах»

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

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

3.1.3 Объектно-реляционное отображение

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

3.2 Разработка модулей системы

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

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

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

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

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

Он включает в себя 8 классов, а именно:

1) Eyewitness.java - класс, который описывает пользователя, который стал свидетелем происшествия. В нём содержатся такая информация: ФИО, адрес, телефон, адрес электронной почты, логин и пароль. Он содержит методы получения и записи полей.

2) Administrator.java - класс, который описывает администратора. В нём содержатся такая информация: ФИО, звание, адрес, телефон, логин и пароль. Он содержит методы получения и записи полей.

3) ComanderGroup.java - класс, который описывает командира подразделения. В нём содержатся такая информация: ФИО, звание, адрес, телефон, логин и пароль. Он содержит методы получения и записи полей.

4) CoanderTerritory.java - класс, который описывает командира территориального округа. В нём содержатся такая информация: ФИО, звание, адрес, телефон, логин и пароль. Он содержит методы получения и записи полей.

5) Ship.java - класс, который описывает корабль. В нём содержатся такая информация: название, командир и количество екипажа. Он содержит методы получения и записи полей.

6) Postradavshie.java - класс, который описывает пострадавшего. В нём содержатся такая информация: ФИО, возраст, адрес и телефон. Он содержит методы получения и записи полей.

7) Zajavka.java - класс, который описывает заявку. В нём содержатся такая информация: дата, время и местопроишествия. Он содержит методы получения и записи полей.

8) DomainSuperClass.java - базовый класс, в котором содержится единое поле id. В нем описаны методы получения и записи поля, а также методы сравнения объектов, сериализации и десериализации.

3.2.2 Разработка модулей слоя доступа к данным

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

Доступ к интерфейсам доступа к данным можно получить с помощью фабрики DAO.

В данном модуле содержатся следующие интерфейсы:

1) IEyewitness.java - интерфейс, который содержит описания методов, для работы со списком очевидцев.

2) IAdministratorClub.java - интерфейс, который содержит описания методов, для работы со списком администраторов.

3) IComanderGroup.java - интерфейс, который содержит описания методов, для работы со списком командиров подразделений.

4) IComanderTerritory.java - интерфейс, который содержит описания методов, для работы со списком командиров территориальных округов.

5) IPostradavshie.java - интерфейс, который содержит описания методов, для работы со списком пострадавших.

6) IShip.java - это абстрактный класс, который содержит описания методов для работы со списком кораблей.

7) IZajavka.java - это абстрактный класс, который содержит описания методов для работы со списком заявок.

8) DAOFactory.java - интерфейс, который содержит описания стандартных методов со списками объектов. В нём описаны следующие методы:

– T findById(Integer id) - метод, который описывает поиск объекта типа Т по указанному ид;

– Collection<T> findAll() - метод, который описывает получения всего списка объектов типа Т;

– T save(T entity) - метод, который помещает в список объект типа Т;

– void delete(T entity) - метод, который удаляет из списка объектов типа Т;

– public Long getAllCount() - метод, который возращает количество объектов в списке.

– void delete(Integer entityId) - метод, который удаляет объект по указанному entityId.

3.2.3 Разработка модулей слоя отображения

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

XML (англ. eXtensible Markup Language - расширяемый язык разметки, фактически представляющий собой свод общих синтаксических правил. XML - текстовый формат, предназначенный для хранения структурированных данных (взамен существующих файлов баз данных), для обмена информацией между программами, а также для создания на его основе более специализированных языков разметки (например, XHTML). XML является упрощённым подмножеством языка SGML.

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

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

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

Пакеты javax.servlet и javax.servlet.http обеспечивают интерфейсы и классы для создания сервлетов.

ORM (англ. Object-relational mapping, русск. Объектно-реляционное отображение) - запись объектов программы в реляционную базу данных, отображение объекта и его представления в виде набора таблиц.

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

SOAP (от англ. Simple Object Access Protocol - простой протокол доступа к объектам) - протокол обмена структурированными сообщениями в распределённой вычислительной среде. Первоначально SOAP предназначался в основном для реализации удалённого вызова процедур (RPC). Сейчас протокол используется для обмена произвольными сообщениями в формате XML, а не только для вызова процедур. Официальная спецификация последней версии 1.2 протокола никак не расшифровывает название SOAP. SOAP является расширением протокола XML-RPC.

SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS и др. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые должны быть определены отдельно. Чаще всего SOAP используется поверх HTTP.

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

ВЫВОДЫ

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

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

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

Разработанная программная система автоматизирует работу МЧС по контролю Рибаков дрейфуючих на льдинах.

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

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

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

При реализации программной системы были использованы технологий реляционного отображения данных, Servlet, JSP, XML, JavaMail, SOAP.

Размещено на Allbest.ru