Проектирование программного обеспечения "Расписание занятий ЧГУ"

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

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

ВВЕДЕНИЕ

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

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

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

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

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

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

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



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

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

Цель

Целью данной работы является разработка программного обеспечения для корпоративного портала Череповецкого Государственного Университета (ЧГУ).

Исходные данные

Корпоративный портал ЧГУ работает на программном продукте Liferay. Разрабатываемое программное обеспечение должно состоять из модулей, расширяющих функционал портала. Данные для формирования расписания доступны в базе данных университета, работающей на СУБД MySQL. Для авторизации пользователей на электронных ресурсах ЧГУ используется домен Windows с настроенной Active Directory. Все студенты и преподаватели имеют логин и пароль для доступа к этим ресурсам. Разрабатываемое ПО должно позволять авторизироваться с помощью этого логина/пароля для настройки рассылки сообщений.

Назначение

Программное обеспечение предназначено для решения следующих задач:

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

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

список занятий для учебной группы на неделю;

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

список занятий у преподавателя на неделю.

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

Рассылать SMS/email уведомления.

Создание печатных форм документов.

Создание электронных документов в формате PDF.

Входная информация

Входными сообщениями являются следующие данные:

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

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

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

Выходная информация

Входными сообщениями являются следующие данные:

Выходным сообщением для задачи 1 является расписание занятий в виде web - формы;

Выходным сообщением для задачи 2 является расписание занятий в форме сообщения электронной почты или SMS сообщения;

Входными сообщением для задачи 4 являются расписание занятий в печатной форме;

Входными сообщением для задачи 5 являются сформированный документ формата PDF.

Средства реализации

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

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

Для отладки кода рекомендуется использовать среду разработки Eclipse с установленным расширением Liferay IDE.

1.2 Анализ существующих решений

Российские ВУЗы к вопросу формирования расписания применяют следующие подходы:

Использование готового решения.

Разработка собственного модуля.

Каждый подход имеет свои плюсы и минусы, рассмотренные ниже.

При использовании готового решения ВУЗ получает готовый программный продукт «из коробки». Его только остается внедрить в учебный процесс и продукт готов к работе. На рынке программного обеспечения представлено несколько продуктов.

Электронный деканат(Free Dean`s Office).

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

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

Расписание вузов (www.raspisaniye-vuzov.ru)

Является веб-сервисом, а не программным продуктом. Имеет современный функциональный и информативный дизайн. Разработаны приложения для основных мобильных платформ(Android, IOS).

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

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

Собственные решения формируются несколькими способами:

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

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

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



2. ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

2.1 Выбор технологии, среды и языка программирования

2.1.1 Выбор модели жизненного цикла

К настоящему времени наибольшее распространение получили следующие три модели ЖЦ:

каскадная модель;

каскадная модель с возвратами [3];

спиральная модель.

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

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

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

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

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

2.1.2 Выбор технологии проектирования

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

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

перечисление условий, при которых выполняется та или иная операция;

описания самих операций, где для каждой операции определены исходные данные;

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

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

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

технология должна поддерживать полный ЖЦ ПО;

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

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

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

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

При проектировании системы было решено использовать методологию быстрой разработки приложений RAD (Rapid Application Development). Известно, что методология RAD поддерживает каскадную модель ЖЦ с возвратами, поэтому выбор именно этой методологии является оправданным. Одним из основных принципов методологии RAD является использование CASE-средств.

2.1.3 Выбор подхода к программированию

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

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

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

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

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

2.1.4 Выбор языка и среды программирования

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

Расширения для портала Liferay строятся по модели MVC(модель-представление-контроллер)[2]. Для программирования контроллеров и моделей используется язык программирования Java.

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

Для программирования представлений используется технология JavaServer Pages(JSP) - технология, позволяющая создавать содержимое, которое имеет как статические, так и динамические компоненты. Для программирования статических компонентов используется язык разметки HTML и язык описания стилей CSS. Для программирования динамических компонентов - скриптовый язык JavaScript и скриплеты на языке Java. Технология JSP даёт возможность легко создавать динамическое содержимое web-страниц, предельно мощное и гибкое.

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

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

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

В качестве СУБД для работы с базой данных была выбрана MySQL - свободная реляционная система управления базами данных. Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц.

2.1.5 Выбор CASE - средств

Для автоматизации процессов проектирования целесообразно использовать CASE-средства. CASE-технология представляет собой методологию проектирования ПО, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ПО и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методологиях объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств[1].

Наиболее часто используемые CASE-средства:

BPwin;

Rational Rose;

IBM Rational Rhapsody.

Rational Rose - средство фирмы Rational Software Corporation, предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. В составе Rational Rose можно выделить 6 основных структурных компонент: репозиторий, графический интерфейс пользователя, средства просмотра проекта (browser), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для С++, обеспечивающий реинжиниринг - восстановление модели проекта по исходным текстам программ.

BPwin поддерживает методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram). Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (модель AS-IS) и идеального положения вещей - того, к чему нужно стремиться (ТО-ВЕ). Методология IDEFO предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. После каждого сеанса декомпозиции проводится сеанс экспертизы: каждая диаграмма проверяется экспертами предметной области, представителями заказчика, людьми, непосредственно участвующими в бизнес-процессе. Такая технология создания модели позволяет построить модель, адекватную предметной области на всех уровнях абстрагирования. Если в процессе моделирования нужно осветить специфические стороны технологии предприятия, BPwin позволяет переключиться на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель. Нотация DFD включает такие понятия, как внешняя ссылка и хранилище данных, что делает ее более удобной (по сравнению с IDEF0) для моделирования документооборота.

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

2.2 Разработка технических требований программного обеспечения

2.2.1 Общие сведения

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

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

2.2.2 Требования к программе

2.2.2.1 Требования к функциональным характеристикам

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

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

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

список занятий для учебной группы на неделю;

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

список занятий у преподавателя на неделю.

Предоставлять авторизацию пользователей в личном кабинете, с использованием учетных данных (логина, пароля), предоставляемых пользователям для доступа к электронным ресурсам ЧГУ;

рассылать e-mail уведомления;

создание печатных форм документов;

создание электронных документов в формате PDF.

Входные данные:

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

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

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

Выходные данные:

расписание занятий в электронном виде;

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

расписание занятий в форме SMS сообщения;

сформированный документ формата PDF;

расписание занятий в печатной форме.

2.2.2.2 Требования к надежности

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

организацией электропитания технических средств и устройств;

подключение к сети интернет;

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

использованием лицензионного программного обеспечения;

регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. «Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;

регулярным выполнением требований ГОСТ 51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов.

Так же предусмотреть:

контроль вводимой информации;

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

Обеспечить:

защиту от несанкционированного доступа к информации.

2.2.2.3 Условия эксплуатации

Климатические условия эксплуатации

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

Требования к видам обслуживания

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

Требования к численности и квалификации персонала

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

2.2.2.4 Требования к составу и параметрам технических средств

Для функционирования разрабатываемому программному продукту требуется:

сервер с предустановленной операционной системой Windows или Linux и доступом к сети Интернет;

установленная СУБД MySQL;

установленное и настроенное ПО Liferay;

настроенный домен Windows с Active Directory.

Для работы с разрабатываемым программным продуктом пользователю требуется:

персональный компьютер с установленной на него операционной системой и выходом в сеть Интернет;

интернет-браузер, поддерживающий язык гипертекстовой разметки HTML версии 4.0 и выше, таблицу стилей CSS и работу сценариев, написанных на языке JavaScript.;

Программа для чтения PDF файлов.

2.2.2.5 Требования к информационной и программной совместимости

Требования к исходным кодам и языкам программирования

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

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

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

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

База данных включает в себя таблицу «Расписание», включающая следующие поля:

Учебная группа;

День недели;

Время занятия;

Дата занятия;

Дисциплина;

Недели занятия;

Четность недель;

Должность;

Аудитория.

2.2.3 Требования к программной документации

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

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

Программная документация должна включать:

расчётно-пояснительную записку (ГОСТ 19.404-79);

схемы и/или диаграммы (ГОСТ 19.701-90);

спецификацию (ГОСТ 19.202-78);

руководство пользователя (ГОСТ 19.505-79).

Вся документация оформляется на листах формата А4, по действующим стандартам (ЕСПД). Для изображения крупных схем и диаграмм также возможно использование листов формата А3.



2.3 Разработка функциональной структуры программного обеспечения

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

2.3.1 Разработка структуры программного обеспечения

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

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

Система состоит из трех взаимосвязанных программных модулей:

модуль отображения расписания;

модуль личного кабинета;

модуль рассылки сообщений.

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

Блок личный кабинет предназначен для авторизации пользователей и настройки рассылки сообщений.

Блок рассылки сообщений отвечает за рассылку расписания автоматически в электронном виде.

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

Рисунок 2.1 - Структурная схема программного обеспечения

Детальное рассмотрение каждого модуля позволяет ее представить в виде следующих элементов:

«Ввод параметров запроса» - позволяет указывать данные для запроса.

«Отображение страницы расписания» - формирование страницы с запрошенными данными на экране.

«Формирование электронных документов» - формирование файлов с запрошенными данными.

«Отправка расписания» - отправка при изменениях, данных с изменениями.

«Авторизация пользователей» - позволяет авторизироваться пользователям с использованием личного логина и пароля.

«Отображение настроек рассылки» - показывает настройки рассылки, заданные пользователем.

«Задание настроек рассылки» - позволяет задавать или изменять настройки рассылки пользователем.

2.3.2 Разработка функциональной схемы

Функциональная схема или схема данных (ГОСТ 19.701-90) - схема взаимодействия компонентов программного обеспечения с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств. Для изображения функциональных схем используют специальные обозначения, установленные стандартом. [1]

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

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

модуль отображения расписания;

модуль личного кабинета;

модуль рассылки сообщений.

Функциональная схема программного обеспечения общего вида представлена на рисунке 2.2.

Рисунок 2.2 - Функциональная схема программного обеспечения

2.4 Анализ существующей базы данных расписания учебных занятий

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

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

Атрибуты сущности:

Учебная группа;

День недели;

Время занятия;

Дата занятия;

Дисциплина;

Недели занятия;

Четность недель;

Должность;

Аудитория.

Определения и свойства атрибутов:

1) Учебная группа - группа студентов, обучающихся в учебном заведении. Свойства объекта «учебная группа»:

Название группы.

2) День недели - параметр, определяющий неделю проведения занятий. Свойства объекта:

День недели.

3) Время - параметр, определяющий время проведения занятий. Свойства объекта «время»:

Время занятия.

4) Дата занятия - параметр, определяющий даты проведения занятий, если оно не периодично в течение семестра. Свойства объекта:

Дата.

5) Дисциплина - предмет, которому обучают студентов. Свойства объекта «дисциплина»:

Название дисциплины;

Вид занятия.

6) Недели занятия - параметр, определяющий диапазон недель проведения занятий. Свойства объекта:

Начальная неделя;

Конечная неделя.

7) Четность недели - параметр, определяющий проведения занятий по четным и нечетным неделям. Свойства объекта:

Четность недели.

8) Должность - человек, преподающий какую-либо дисциплину. Свойства объекта:

ФИО.

Учёное звание.

9) Аудитория - помещение для проведения занятий. Свойства объекта «аудитория»:

Номер аудитории.

Улица, номер дома, в котором находится данная аудитория.

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

Таблица 2.1 - Сущность Rasp.

№ п/п	Атрибут	Тип данных
1	Grp	VARCHAR
2	D_ned	VARCHAR
3	Vrem	VARCHAR
4	Data	VARCHAR
5	N_Dis	VARCHAR
6	Nach_Ned	VARCHAR
7	CH_NCH	VARCHAR
8	Dol	VARCHAR
9	Aud	VARCHAR

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

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

2.5 Проектирование базы данных пользователей

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

Сущность «пользователь» имеет следующие атрибуты:

Идентификатор;

Имя пользователя;

Полное имя.

Определения и свойства атрибутов:

1) Идентификатор - уникальный числовой идентификатор пользователя. Присваивается автоматически при добавлении пользователя. Является первичным ключом сущности. Свойства объекта:

Идентификатор.

2) Имя пользователя - параметр, определяющий имя пользователя авторизированного в системе. Свойства объекта:

Имя пользователя.

3) Полное имя - параметр, определяющий имя пользователя, используется для формирования текста сообщения. Свойства объекта

Полное имя.

Сущность «подписки» имеет следующие атрибуты:

Идентификатор;

Имя пользователя;

Полное имя.

Определения и свойства атрибутов:

1) Идентификатор - уникальный числовой идентификатор подписки на рассылку. Присваивается автоматически при добавлении подписки. Является первичным ключом сущности. Свойства объекта:

Идентификатор.

2) Идентификатор пользователя - уникальный числовой идентификатор пользователя, создавшего подписку. Свойства объекта:

Идентификатор пользователя.

3) Электронный адрес - параметр, определяющий электронный адрес, на который будут рассылаться сообщения. Свойства объекта

Электронный адрес.

4) Группа - параметр, определяющий название группы расписание, которой будет рассылаться. Свойства объекта:

Группа.

5) Ежедневно - параметр, определяющий периодичность рассылки. Свойства объекта

Ежедневно.

6) Еженедельно - параметр, определяющий периодичность рассылки. Свойства объекта

Еженедельно.

На рисунке 2.3 представлена диаграмма базы данных.

Рисунок 2.3 - База данных пользователей

В таблицах 2.2 - 2.3 представлены типы данных, используемы в базе данных.

Таблица 2.2 - Сущность user.

№ п/п	Атрибут	Тип данных
1	id	INT
2	name	VARCHAR
3	full_name	VARCHAR

Таблица 2.3 - Сущность subscribe.

№ п/п	Атрибут	Тип данных
1	id	INT
2	id_user	INT
3	email	VARCHAR
4	group	VARCHAR
5	everyday	BOOL
6	everyweek	BOOL

2.6 Функциональное моделирование структуры программного обеспечения

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

2.6.1 Построение функциональных диаграмм

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

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

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

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

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

Рисунок 2.4 -Контекстная функциональная диаграмма

На рисунке 2.5 видно, что общая функция разбивается на три основных:

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

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

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

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

Рассмотрим детализацию функции «Личный кабинет» (рисунок 2.6). Данная функция разбивается на ряд подфункций:

Авторизация. Происходит авторизация в личном кабинете. Введенные логин и пароль сверяются с логином и паролем пользователя в Active Directory.

Настройка рассылки. Пользователь указывает контактные данные для настройки рассылки. Данные сохраняются в базу данных.

Рисунок 2.6 - Декомпозиция функционального блока «Личный кабинет»

Рассмотрим детализацию функции «Отображение расписания» (рисунок 2.7). Данная функция разбивается на ряд подфункций:

Запрос расписания учебной группы. Формируется запрос по указанной дате и номеру группы.

Запрос расписания преподавателя. Формируется запрос по указанной дате и фамилии преподавателя.

Вывод информации. Отображается запрошенная информация.

Рисунок 2.7 - Декомпозиция функционального блока «Отображение расписания»

Рассмотрим детализацию функции «Модуль рассылки» (рисунок 2.8). Данная функция разбивается на ряд подфункций:

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

Формирование сообщения. Формируется сообщение для пользователя и отправляется.

Рисунок 2.8 - Декомпозиция функционального блока «Модуль рассылки»

2.6.2 Построение диаграмм потоков данных

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

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

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

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

Ниже представлена контекстная диаграмма (рисунок 2.9) для разрабатываемого программного обеспечения.

Рисунок 2.9 - Контекстная диаграмма потоков данных DFD

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

Процессы:

Авторизация в личном кабинете.

Отображение расписания.

Рассылка сообщений.

Хранилища данных:

БД Университета - Система хранения учебных занятий.

БД Active Directory - Система хранения учетных данных пользователей.

БД настроек - Система хранения данных настроек для рассылки.



Рисунок 2.10 - Декомпозиция диаграммы потоков данных А-0 DFD

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

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

2.7.1 Построение графа диалога

Граф диалога представляет собой ориентированный взвешенный граф, каждой вершине которого сопоставлена конкретная картинка на экране (кадр) или определенное состояние диалога, характеризующееся набором доступных пользователю действий. Дуги, исходящие из вершин, показывают возможные изменения состояний при выполнении пользователем указанных действий. В качестве весов дуг указывают условия переходов из состояния в состояние и операции, выполняемые во время перехода [1]. На рисунке 2.11 представлен общий граф абстрактного диалога программного обеспечения «Портал расписания Череповецкого Государственного Университета».

Рисунок 2.11 - Общий граф диалога

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

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

Рисунок 2.12 - Граф диалога «Авторизация»

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

Рисунок 2.13 - Граф диалога «Запрос расписания»

На рисунке 2.14 изображён граф диалога «Настройка рассылок пользователя». На этом этапе, после введения логина и пароля пользователю становится доступна панель администрирования, с которой можно начать работать в форме редактирования. Пользователь может совершить 3 варианта действий: просмотр, редактирование или выйти из системы (уйти со страницы). Если пользователь выберет просмотр, то следующим этапом станет, либо отключение, либо удаление рассылок, затем выход из системы или переход на другую страницу. Если пользователь зашёл в форму редактирования, то следующим этапом после редактирования данных является их сохранение, затем выход из системы или переход на другую страницу.

Рисунок 2.14 - Граф диалога «Настройка рассылок пользователя»

Граф диалога «Администрирование рассылок» (рисунок 2.15) представляет схему действий администратора. На этом этапе, после введения логина и пароля становится доступна панель администрирования, с которой можно начать работать в форме редактирования. Администратор может совершить 2 варианта действий: или редактированием или выйти из системы (уйти со страницы). Если зашёл в форму редактирования, то следующим этапом после редактирования данных является их сохранение, затем из системы или переход на другую страницу.

Рисунок 2.15 - Граф диалога «Администрирование рассылок»

2.7.2 Разработка форм ввода-вывода информации

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

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

После запуска портала появится главная страница (рисунок 2.16), где пользователь может посмотреть расписание по интересующим параметрам.

Рисунок 2.16 - Главная страница портала

При нажатии кнопки «войти» откроется окно авторизации (рисунок 2.17), где пользователь должен ввести логин и пароль.

Рисунок 2.17 - Окно авторизации портала

После авторизации пользователя появляется возможность подписаться на рассылку, заполнив данные в окне подписки (рисунок 2.18).

Рисунок 2.18 - Окно подписки на рассылку

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

Рисунок 2.19 - Окно просмотра рассылок пользователем

Пользователь также может отключить рассылку или редактировать в окне редактирования (рисунок 2.20).



Рисунок 2.20 - Окно редактирования рассылки пользователем

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

Рисунок 2.21 - Окно просмотра рассылок администратором

Администратор также может отключить рассылку или редактировать в окне редактирования (рисунок 2.22).

Рисунок 2.22 - Окно редактирования рассылки администратором



Подробное описание окон и последовательность действий по работе с ними представлено в руководстве пользователя (приложение 1) и руководстве администратора (приложение 2).

3. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

3.1 Разработка алгоритмов

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

На рисунке 3.1 представлен алгоритм работы модуля отображения расписания. Как указано в пункте 2.4 база данных расписания ненормализована и для выборки записей необходимо применить дополнительные решения, рассмотренные в пункте 3.2.3.

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

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

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

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



Рисунок 3.1 - Алгоритм работы модуля отображения расписания.



Рисунок 3.2 - Алгоритм работы модуля отображения расписания



Рисунок 3.3 - Алгоритм работы модуля отображения расписания

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

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

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

Рисунок 3.4 - Алгоритм работы модуля рассылки сообщений.

3.2 Особенности программной реализации

3.2.1 Основы разработки для портала Liferay

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

Рисунок 3.5 - Пример страницы портала.

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

Для удобства разработки структура портлета генерируется применяемой средой разработки Eclipse. На рисунке 3.6 представлена структура портлета отображения параметров запроса расписания.



Рисунок 3.6 Портлет Query-portlet

В основном родительском каталоге проекта портлета есть папка «docroot» и «build.xml» файл. Файл «build.xml» используется для сборки и развертывания портлета с помощью приложения Apache Ant. В Liferay все файлы и каталоги располагаются в директории «docroot». В «docroot» есть «WEB-INF», где содержатся все xml-файлы конфигурации портлета, каталог библиотек «lib», а также «src» - каталог для классов Java, реализующих управление портлета. Каталоги «css», «html» и «js» таблицы стилей, скрипты и web-структуру портлета, т.е. реализуют представление портлета.

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

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

Рисунок 3.7 - Схема взаимодействия IPC Events

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

У портлета - отправителя перед методом отправки указывается аннотация @ProcessAction. У портлета - получателя перед методом отправки указывается аннотация @ProcessEvent.

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

3.2.2 Доступ к базе данных

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

Для работы с БД в портале Liferay используется библиотека Hibernate, поэтому при ручной разработке необходимо, вручную написать код моделей, состояний и сервисных уровней.[5] Решение получится гибким и позволит избежать таких компромиссных решений, как формирование SQL-запросов. Как указано в пункте 2.4 база данных расписания ненормализована, поэтому преимущество гибкости запроса несущественно. Использование встроенных инструментов позволит сэкономить время на разработку.

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

Для базы данных расписания они будут следующие.

Service.xml - описывает все сущности в базе данных, доступ к которым необходимо реализовать. Текст входного XML-файла представлен на рисунке 3.8.

Рисунок 3.8 - Файл Service.xml.

Ext-spring.xml позволяет переопределить классы объектов, используемых для связи программного обеспечения и БД. Текст входного XML-файла представлен на рисунке 3.9.



Рисунок 3.9 - Файл Ext-spring.xml.

Для базы данных рассылок они будут следующие.

Текст файла «Service.xml» представлен на рисунке 3.10.

Рисунок 3.10 - Файл Service.xml.

Текст файла «Ext-spring.xml» представлен на рисунке 3.11.

Рисунок 3.11 - Файл Ext-spring.xml.

3.2.3 Библиотека для работы с датами

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

Даты занятий в записях базы данных представлены в строковом типе данных. Например, данные в поле «Nach_Ned» представлены в следующем виде - «с 31 по 37», что означает - занятия проводятся с 31 недели до 37.

Периодичность занятий представлена в строковом типе данных. Например, данные в поле «CH_NCH» представлены в следующем виде - «ежен», «чет», «нечет». Что означает - занятия еженедельные, по четным, либо нечетным дням недели.

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

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

Функция parseDate преобразует строку вида «с 31 по 37» в массив типа integer.

Функция isEntersRangeDate получая строку вида «с 31 по 37» и дату в строковом виде, позволяет определить входит ли дата в этот диапазон недель.

Переопределенная функция parseDate получая строку вида «с 31 по 37» и дату, день недели и периодичность занятий в строковом виде, позволяет определить входит ли дата в этот диапазон недель.

Функция getNumberWeek получая дату в типе Date, позволяет получить номер недели.

Функция getDateFormatDate преобразует формат даты из типа Date в строковый тип.

Функция getDateFormatString преобразует формат даты из строкового типа в тип Date.

Таблица 3.1 - Описание методов класса Util

Имя метода	Входные параметры	Выходные параметры	Выполняемые действия
parseDate	String	int[]	Преобразует текстовый диапазон недель в массив
isEntersRangeDate	String, String	boolean	Проверяет входимость недели в диапазон
isEntersRangeDate	String, String, String, String	boolean	Проверяет входимость недели в диапазон
getNumberWeek	Date	int	Получить номер недели заданной даты
getDateFormatDate	String	Date	Преобразует формат даты из Date в строковый
getDateFormatString	Date	String	Преобразует формат даты из строкового в Date

Детальный исходный код представлен в приложении .

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