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

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

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

Цель

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

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

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

Назначение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Расписание вузов (www.raspisaniye-vuzov.ru <#"897384.files/image001.gif">

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

День недели;

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

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

Дисциплина;

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

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

Должность;

Аудитория.

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

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

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

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

День недели.

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

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

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

Дата.

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

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

Вид занятия.

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

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

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

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

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

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

ФИО.

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

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

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

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

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

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

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

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

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

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

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

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

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

Полное имя.

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

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

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

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

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

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

Полное имя.

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

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

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

Полное имя.

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

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

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

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

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

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

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

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

Группа.

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

Ежедневно.

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

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

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

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

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

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

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

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

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

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

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

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

Функциональная диаграмма для разрабатываемого программного обеспечения описана в нотации 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 - Декомпозиция функционального блока «Модуль рассылки»

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

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

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

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

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

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

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

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

Процессы:

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

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

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

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

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

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

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

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

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

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

.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 - Граф диалога «Администрирование рассылок»

.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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.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. В следующих главах рассмотрим реализацию доступа к данным и их обработку.

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

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

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

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

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

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

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

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

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

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

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

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

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

Для отправки сообщений можно использовать API JavaMail, но на самом деле Liferay уже предоставляет служебный класс MailEngine для отправки электронной почты. На рисунке 3.12 представлен реализуемый класс отправки сообщений.

Рисунок 3.12 - Файл SenderEmail.java

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

После создания портлета, в файле liferay-portlet.xml инициализируем планировщик:

<scheduler-entry>

<scheduler-event-listener-class>com.liferay.calendar.messaging.CheckRaspMessageListener</scheduler-event-listener-class>

<trigger>

<simple>

<property-key>calendar.notification.check.interval</property-key>

<time-unit>day</time-unit>

</simple>

</trigger>

</scheduler-entry>

В файле portlet.properties указываем периодичность :.notification.check.interval=1

Тогда метод doReceive () в CheckRaspMessageListener (как показано ниже) будет выполняться ежедневно:class CheckRaspMessageListener extends BaseMessageListener {

protected void doReceive(Message message) throws Exception {

CalendarRaspLocalServiceUtil.checkCalendarRasp();

}

}

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

.3 Тестирование

.3.1 Выбор метода тестирования

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

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

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

Для тестирования применялся метод ручного контроля. Ручной контроль используется на ранних стадиях разработки системы, так как он обеспечивает обнаружение 30 - 70 % ошибок. В качестве исходных данных для такого контроля выступают техническое задание, спецификации, структурные и функциональные схемы, схемы отдельных компонентов, а для более поздних этапов - алгоритмы и тексты программ, а также тестовые наборы. Из методов ручного контроля был выбран метод проверки за столом. Этот метод не требует наличия группы специалистов. Проверка исходного текста выполняется одним человеком, который читает текст программы, проверяет его на наличие возможных ошибок по списку часто встречающихся ошибок[6].

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

.3.2 Анализ результатов тестирования

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

На тесте «Проверка соединения» была обнаружена ошибка. В конфигурационном файле настройки подключения к БД была неверно указана кодировка WIN-1251. Для исправления ошибки в конфигурационном файле была указана UTF-8 кодировка.

На тесте «Неправильный адрес» возникла ошибка при попытке во время настройки рассылки указать некорректный формат электронного адреса. Форма приняла адрес для обработке. Для исправления ошибки в поле адреса была добавлена маска вида «имя@домен.расширение».

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

Таблица 3.2 - Результаты тестирования

. РАЗРАБОТКА ДОКУМЕНТАЦИИ

.1 Разработка инструкции для пользователя

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

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

Руководящим стандартом для создания документа «Руководство пользователя» могут, является ГОСТ 19.505-79 «Руководство оператора. Требования к содержанию и оформлению». Ниже приведена структура документа согласно стандарту.

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

Назначение программного обеспечения;

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

Подготовка программного обеспечения к работе;

Описание операций;

Аварийные ситуации.

Назначение программного обеспечения

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

Условия применения программного обеспечения

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

Требования к аппаратному обеспечению;

Квалификация пользователя.

Подготовка программного обеспечения к работе

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

Описание операций

Это основной раздел «Руководства пользователя», которое содержит пошаговую инструкцию для выполнения того или иного действия пользователем.

Аварийные ситуации

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

На основе вышеизложенной информации было сформировано «Руководство пользователя» для разработанного программного обеспечения. Посмотреть его возможно в приложении 1.

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

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

Несмотря на то, что не существует отдельного ГОСТа на создание «Руководство администратора», его структура и оформление регламентируется РД 50-34.698-90, где описаны общие требования к содержанию документации.

«Руководство администратора» обычно имеет следующую структуру:

Назначение программного обеспечения;

Принципы функционирования программного обеспечения;

Обязанности и задачи администратора;

Обслуживание программного обеспечения;

Проблемы в работе программного обеспечения и способы их решения.

Назначение программного обеспечения

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

Принципы функционирования программного обеспечения

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

Обязанности и задачи администратора

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

Обслуживание программного обеспечения

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

настройка и параметризация

справочно-нормативные данные

управления учетными записями

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

ввод и вывод информации

Проблемы в работе программного обеспечения и способы их решения

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

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

На основе вышеизложенной информации было сформировано «Руководство администратора» для разработанного программного обеспечения. Посмотреть его возможно в приложении 2.

5. ОРГАНИЗАЦИОННО-ЭКОНОМИЧЕСКАЯ ЧАСТЬ

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

.1 Расчет совокупной стоимости владения

Совокупная стоимость владения (Total Cost of Ownership - TCO) является одним из основных инструментов в экономическом анализе информационных технологий. Первооткрывателем этого термина стала компания GartnerGroup, а после фирма Interpose, которая стала использовать метод как модель анализа финансовой стороны использования информационных технологий [7].

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

Единовременные затраты осуществляются на этапе построения ИС. К единовременным затратам по методике Gartner Group относят:

стоимость разработки и внедрения проекта;

привлечение внешних консультантов;

первоначальные закупки основного ПО;

первоначальные закупки дополнительного ПО;

первоначальные закупки аппаратного обеспечения [8].

Текущие затраты осуществляются на этапе функционирования. К текущим относят:

стоимость обновления и модернизации системы;

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

затраты, вызванные активностью пользователей ИС [8].

ТСО = N + n * T,

где N - единовременные затраты на ИС;- текущие затраты;- количество лет экплуатации.

Затраты приведены в таблице 5.1.

Таблица 5.1. Таблица затрат.

Проведем расчет затрат:

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

,

где Спп - стоимость программного продукта, руб.;

Зтр - затраты на оплату труда, руб.;

Зм.вр - затраты на использование машинного времени, руб.;

Зн.и - затраты на носители информации, руб.;

Зрем - затраты на текущий и профилактический ремонт вычислительной техники, руб.;

Зпр - прочие эксплуатационные расходы, руб.

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

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

, - с окладом

, - почасовая,

где - общая зарплата работника за час;

 - отчисления с зарплаты, %;

 - время написания программы.

Время написания программы  совпадает со временем работы компьютера.

Заработная плата программиста за час определяется по формуле:

,

где - ставка программиста;

 - фонд рабочего времени в месяц.

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

Заработная плата дополнительная определяется по формуле:

,

где - заработная плата программиста;

 - норма отчислений на дополнительную зарплату (10%).

Тогда дополнительная заработная плата программиста за час равна:

Зарплата общая вычисляется по формуле:

.

Общая зарплата программиста за час равна:

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

,

где - отчисления на соцстрах;

 - отчисления в фонд медицинского страхования;

 - отчисления в пенсионный фонд.

В 2016 году работодатель уплачивает страховые взносы в размере 30 % от зарплаты работника:

Пенсионный фонд (ПФР) - 22 %

Фонд медицинского страхования (ФФОМС) - 5,1 %

Фонд социального страхования (ФСС) - 2,9 %

Тогда отчисления с заработной платы программиста:

Исходя из того что оплата труда с окладом и время написания программы составляет 3 месяца (т.е. ч), тогда затраты на оплату труда программиста равны:

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

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

Общая зарплата руководителя за час равна:

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

Затраты на оплату труда руководителя равны:

Итого затраты на оплату труда составят:

Все данные по заработной плате сведем в таблице 5.2.

Таблица 5.2 - Данные по заработной плате

Затраты на использование машинного времени вычисляются по
формуле:

,

где - затраты на использование машинного времени, руб;

 - стоимость одного часа машинного времени, руб/ч;

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

Стоимость одного часа машинного времени рассчитывается по формуле:

,

где  - стоимость одного часа машинного времени, руб./ч;

 - покупная цена компьютера, руб.;

 - срок службы компьютера, год;

 - количество рабочих дней в году;

 - время работы компьютера в течение суток, ч;

 - стоимость одного кВт*ч электроэнергии, руб.;

 - мощность вычислительной системы, кВт.

Учитывая, что покупная цена компьютера - 15000 руб., срок службы компьютера - 5 лет, количество рабочих дней в году - 247, время работы компьютера в течение суток - 8 ч., стоимость одного кВт*ч электроэнергии - 3,50 руб., а мощность вычислительной системы - 0,1 кВт, получаем стоимость одного часа машинного времени:

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

,

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

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

- время работы компьютера в течение суток, ч.

Учитывая, что время работы компьютера в течение суток равно 8 ч., а количество дней разработки программного продукта - 63, то получаем следующий результат:

Тогда затраты на использование машинного времени равны:

Затраты на носители информации принимаются в размере 2% от цены вычислительной техники и составляют:

Затраты на текущий и профилактический ремонт принимаются в размере 4% от цены вычислительной техники и составляют:

Прочие эксплуатационные расходы включают в себя затраты на освещение, отопление, охрану, уборку и текущий ремонт помещений. Они принимаются в размере 10 % от стоимости помещения (или его аренды), где происходит разработка программного продукта. Учитывая, что стоимость аренды помещения - 5000 руб. в месяц, а срок разработки программного продукта - 3 месяца, то данный вид расходов составляет:

Зпр = 5 000 * 3 * 0,1 = 1 500 (руб)

Таким образом, стоимость программного продукта равна:

Спп = 140123,6 + 942,48 + 300 + 600 + 1 500 = 143466,08 (руб).

Затраты на программное обеспечение включают следующие:

Затраты на ПО Liferay - 0 руб. (Свободная лицензия).

Затраты на ПО Java - 0 руб. (Свободная лицензия).

Затраты на ПО MySQL - 0 руб. (Свободная лицензия).

Затраты на ПО Windows Server 2008 - 42 000 руб.

Затраты на аппаратное обеспечение:

Сервер LX100.4-004LF - 55 600 руб. [9].

Таким образом, единовременные затраты составят 241 066,08 руб. и имеют следующий вид.

Рисунок 5.1 - Единовременные затраты

Затраты на подключение к сети Enternet.

В ЧГУ подключен оптический канал связи «Ростелеком». Абонентская плата за канал с пропускной скоростью 10 Мбит/сек составляет 5750 руб. в месяц. За год расходы составят 69 000 руб.

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

- количество месяцев в году;

,21 - поправочный коэффициент.

В данном случае эксплуатационные расходы составляют:

.

Затраты на использование машинного времени вычисляются по формуле:

,

Стоимость одного часа машинного времени рассчитывается по формуле:

,

Учитывая, что покупная цена сервера - 55600 руб., срок службы сервера - 10 лет, количество рабочих дней в году - 365, время работы компьютера в течение суток - 24 ч., стоимость одного кВт*ч электроэнергии - 3,50 руб., а мощность вычислительной системы - 0,1 кВт, получаем стоимость одного часа машинного времени:

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

,

Учитывая, что время работы сервера в течение суток равно 24 ч., а количество дней - 365, то получаем следующий результат:

Тогда затраты на использование машинного времени равны:

Затраты на носители информации принимаются в размере 2% от цены вычислительной техники и составляют:

Затраты на текущий и профилактический ремонт принимаются в размере 4% от цены вычислительной техники и составляют:

Прочие эксплуатационные расходы включают в себя затраты на освещение, отопление, охрану, уборку и текущий ремонт помещений. Они принимаются в размере 10 % от стоимости помещения (или его аренды), где происходит разработка программного продукта. Учитывая, что стоимость аренды помещения - 5000 руб. в месяц, а срок - 12 месяцев, то данный вид расходов составляет:

Зпр = 5 000 * 12 * 0,1 = 6000 (руб)

Таким образом, текущие затраты в год составят 449 920,8 руб. и структура расходов следующая:

Рисунок 5.2 - Текущие затраты

Совокупная стоимость владения на 3 года составит:

ТСО = N + n * T = 241 066,08 + 3 * 449 920,8 = 1 590 828,48 руб.

Для удобства чтения все данные затрат представлены в виде таблицы.

Таблица 5.3 - Таблица затрат.

Рисунок 5.3 - Совокупная стоимость владения

5.2 Разработка графика проектирования и внедрения системы

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

Инженерный метод оценки трудоемкости проекта PERT (Program / Project Evaluation and Review Technique) был разработан в 1958 году в ходе проекта по созданию баллистических ракет морского базирования «Поларис».

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

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

Продолжительность каждой работы Dj определяется по формуле:

где nj - численность исполнителей, чел.

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

 ;

 ;

 ;

 ;

 ;

 ;

Таблица 5.4 - Оценка трудоемкости отдельных видов работ.

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

Таблица 5.5 - Сводная таблица для планирования работ.

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

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

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

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

Рисунок 5.6 - Ленточный график разработки программного обеспечения.

.3 Разработка инструкции по установке и настройке продукта

.3.1 Общие сведения о программе

Назначение и функциональные возможности программы

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

В программе реализованы возможности:

Просмотр расписания:

для учебной группы на день;

для учебной группы на неделю;

для преподавателя на день;

для преподавателя на неделю.

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

Рассылать расписания ежедневно или еженедельно;

Печать расписания;

Сохранение расписания в формате PDF.

.3.2 Системные требования

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

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

операционная система Windows или Linux;

СУБД MySQL;

корпоративный портал Liferay;

домен Windows с Active Directory.

К техническому обеспечению предъявляются следующие минимальные требования:

процессор уровня Intel Core 2 Quad;

оперативная память 16 Гб;

доступ в сеть Интернет, рекомендуемая скорость соединения - 1 Мбит/сек и выше.

.3.3 Установка программы

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

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

Развертывание структуры портала

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

Перейти к панели управления

Перейти к сообществу вы хотите экспортировать

Нажмите действия -> Управление страницами

Перейдите на страницу Экспорт / Импорт

Выберите файл для импорта

Нажмите кнопку "Импорт"

Подключение базы данных

Для подключения базы данных расписания необходимо в файле portal-setup-wizard.properties указать следующие параметры:

jdbc.test.driverClassName=com.mysql.jdbc.Driver.test.url=jdbc:mysql://localhost/rasp?useUnicode=true&characterEncoding=UTF-8&useFastDateParsing=false.test.username=root.test.password=pass2adm

Подключение Active Directory

. На вкладке «общие» - в поле «как пользователи будут аутентифицироваться?» выбрать «По экранному имени».

. Добавление сервера LDAP.

Соединение:Provider URL =«ldap://имя сервера:389»

Base DN = «dc=vkgu,dc=ru»

Доверитель=имя пользователя в ldap с правами подключения

Верительные данные= пароль соответственно

Пользователи:

Фильтр поиска при аутентификации = (&objectCategory=Person) (sAMAccountName=@screen_name@)

Фильтр поиска импорта=(objectClass=inetOrgPerson)=sAMAccountName

Экранное имя=sAMAccountName

Адрес email =mail

Пароль=userPassword (тут нужно учесть, что Active Directory по умолчанию не использует это поле, поэтому пользователи будут импортироваться в liferay, но не смогут войти, так как пароль не импортируется. Можно заполнить это поле самописным скриптом )

Имя=givenName

Отчество=middleName

Фамилия=sn

Полное имя=cn

Должность=title

Группа=memberOf

Группы:

Фильтр поиска импорта =(objectClass=groupOfNames)

Имя группы=cn

Описание=description

Пользователь=member

Поставить флажок «импорт включен» - пользователи будут импортироваться при первом входе в портал. Если поставить флажок «Включен импорт при запуске» - ВСЕ пользователи будут импортироваться разом при старте сервера Tomcat, это может занять много времени.

Настройка доменного имени

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

Определите местоположение файла hosts и открыть его. В среде Windows файл находится по адресу C:/Windows/System32/drivers/etc

Добавьте следующую строку в конце файла hosts и сохраните его: 127.0.0.1 www.name.com

Обратите внимание на то, что должен использоваться реальный IP-адрес сервера портала и реальный домен. Поэтому, портал с реальным доменным именем в этом поле будет доступен в Интернете.

.3.4 Запуск программы

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

Запустить командную строку командой cmd;

Ввести команду cd %liferay_directory%/tomcat/bin

Запустить портал командой catalin.bat.

.3.5 Настройка программы

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

.1 Анализ вредных и опасных факторов на рабочем месте оператора

.1.1 Анализ вредных факторов на рабочем месте оператора

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

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

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

Основными методами защиты от электромагнитных полей являются:

использование защитного экрана;

расстояние от экрана 60-80 см;

ограничение времени работы за компьютером.

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

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

яркость экрана монитора - не менее 100 кд/м2 ;

освещенность поверхности экрана - не более 300 лк;

яркость бликов на экране - не более 40 кд/м2;

размер светящейся точки - не более 0,4 мм для монохромного дисплея и не более 0,56 - для цветного;

контраст изображения знака - не менее 0,8.

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

К системе освещения рабочего места предъявляются следующие требования:

соответствие уровня освещенности характеру выполняемой работы;

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

отсутствие резких теней, прямой и отраженной блеклости;

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

площадь оконных проемов - не менее 25% площади пола;

комбинированная система освещения с использованием люминесцентных ламп.

Одним из вредных факторов является шумовое загрязнение. Основными источниками шума при работе с ЭВМ является как сама машина, так и совокупность ее технических средств, таких как плоттер, принтер и др. Нормируемыми параметрами шума на рабочих местах являются уровни среднеквадратичных звуковых давлений (дБ) и уровни звука (дБА), измеряемые по шкале "А" шумомера, поскольку они наиболее близки к физиологическому восприятию человеком. Программист выполняет работу, требующую концентрации внимания. Шум при выполнении такой работы не должен превышать 55 дБА[11].

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

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

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

.1.2 Анализ опасных факторов на рабочем месте оператора

Опасный производственный фактор - производственный фактор, воздействие которого на человека может привести к травме.

Основной опасный фактор производства - повышенное значение напряжения в электрической цепи, замыкание которой может произойти через тело человека;

Для снижения воздействия опасных производственных факторов на оператора выполняются следующие действия[10].

Во-первых, при включении компьютера оператор должен соблюдать следующую последовательность:

включить блок питания;

включить периферийные устройства (принтер, монитор, сканер);

включит системный блок (процессор).

Во-вторых, во время работы не следует:

касаться задней панели системного блока (процессора) при включенном питании;

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

производить отключение питания во время выполнения активной задачи;

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

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

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

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

По назначению вентиляция бывает общеобменной и местной.

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

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

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

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

В помещениях данного предприятия предусмотрена смешанная система.

.2 Разработка инструкции по охране труда

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

Перед разработкой инструкций необходимо провести:

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

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

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

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

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

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

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

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

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

Инструкция по охране труда должна содержать разделы:

Введение (наличие раздела носит рекомендательный характер).

Общие требования охраны труда.

Требования охраны труда перед началом работы.

Требования охраны труда во время работы.

Требования охраны труда в аварийных ситуациях.

Требования охраны труда по окончании работы.

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

.3 Решения по обеспечению устойчивости функционирования программного обеспечения во внештатных ситуациях

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

сбой в работе программного обеспечения («зависание» компьютера, медленная скорость работы программы, ошибки в работе программы и т. п.);

отключение электричества;

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

выход из строя сервера;

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

обнаружен вирус;

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

взлом системы (web-сервера, файл-сервера и др.) или несанкционированный доступ;

попытка несанкционированного доступа (обнаружены попытки подбора пароля, доступ постороннего лица в помещение и т. п.);

компрометация ключей (утеря носителя ключевой информации (Rutoken, E-token и т. п.), несанкционированный доступ постороннего лица в место физического хранения носителя информации, к устройству хранения информации, визуальный осмотр носителя информации посторонним лицом или подозрение, что данные факты имели место, взлом учётной записи пользователя);

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

физическое повреждение ЛВС или ПЭВМ (не включается ПК, при попытке включения отображается синий или черный экраны, повреждены провода и т. п.);

стихийное бедствие;

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

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

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

Сбой программного обеспечения:

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

Регулярно проводить антивирусный контроль.

Регулярно проводить профилактические работы на ЭВМ (проверка диска и др.).

Отключение электричества:

Использовать источники бесперебойного питания на ответственных (а лучше - на всех) технологических участках;

Разработать инструкцию по аварийному переходу на резервный источник питания (если такой имеется в наличии) или аварийному завершению работы и сохранению данных;

Желательно иметь в наличии резервный источник электроэнергии (дизель-генератор и др.);

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

Сбой ЛВС:

Обеспечение бесперебойной работы ЛВС путем применения надежных сетевых технологий;

Резервирование каналов связи .

Выход из строя сервера:

Применять надежные программно-технические средства;

Продуманную политику администрирования;

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

Потеря данных:

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

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

Обеспечить комплексную защиту информации в организации.

Для обеспечения антивирусной защиты:

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

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

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

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

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

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

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

Предотвращение утечки информации (дырка в системе защиты):

Применять обновления ПО по устранению программных «дыр» в системе защиты по мере их появления (обнаружения);

Построить комплексную систему защиты информации в организации;

Регулярно проводить анализ журналов попыток НСД и совершенствование системы защиты информации.

Физическое повреждение ЛВС или ПЭВМ:

Физическая защита компонентов сети (серверов, маршрутизаторов и др.);

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

Стихийное бедствие:

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

Разрушение данных при механических и электронных сбоях и отказах в работе компьютеров:

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

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

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

обеспечить сохранность хранимых копий информации на магнитном носителе.

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

ЗАКЛЮЧЕНИЕ

В ходе проделанной работы было проведено проектирование программного обеспечения «Расписание занятий ЧГУ».

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

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

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

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

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

проведено тестирование системы;

проведено технико-экономическое обоснование разработки и внедрения проекта;

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

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

СПИСОК ИСТОЧНИКОВ

1. Иванова Г.С. Технология программирования: Учебник для вузов. - Москва: Изд-во МГТУ им. Н.Э. Баумана, 2002. - 320 с.

. Rich Sezov, Jr. Liferay in action / Rich Sezov, Jr. NY: Manning Publications Co. 2012 - 368 p.

3. Вендров А. М. "Проектирование программного обеспечения экономических информационных систем", изд. Финансы и статистика, 2002.- 192 с.

. Вендров, А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. - М.: Финансы и статистика, 1998. - 193с.

5. Jonas X. Yuan. Liferay Portal Systems Development / Jonas X. Yuan. Birmingham: Packt Publishing Ltd, 2012. - 546 p.

. Котляров В.П. Основы тестирования программного обеспечения: учебное пособие. М.: Интернет-университет информационных технологий, 2006. - 285с.

. Мухин Ю.Ю., Коссова Е.В. Подходы к оценке полной (совокупной) стоимости владения (ТСО) для медицинских информационных систем. Экономические критерии и их влияние на оптимизацию информационной структуры медицинской организации.// Информационно-измерительные и управляющие системы. 2010. Т. 8. No 12.

. Основы модели совокупной стоимости владения. Особенности расчета совокупной стоимости владения в условиях России [Электронный ресурс] // сайт - Режим доступа: #"897384.files/image115.jpg">

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

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

Рисунок П1.2 - Вкладка «Расписание для студентов»

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

Рисунок П1.3 - Вкладка «Расписание для преподавателей»

Пользователь имеет возможность распечатать расписание, либо сохранить в формате PDF.

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

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

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

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

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

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

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

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

Аварийные ситуации

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

. Проверить доступ в Интернет

. Перезапустить браузер.

. Перезапустить компьютер.

ПРИЛОЖЕНИЕ 2

Руководство администратора

. Назначение программного обеспечения

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

В программе реализованы возможности:

Просмотр расписания:

для учебной группы на день;

для учебной группы на неделю;

для преподавателя на день;

для преподавателя на неделю.

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

Рассылать расписания ежедневно или еженедельно;

Печать расписания;

Сохранение расписания в формате PDF.

. Принципы функционирования программного обеспечения

Данное программное обеспечение функционирует на основе корпоративного портала LIferay.

Портал расписания состоит из трех модулей:

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

личный кабинет;

модуль рассылки расписания.

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

Для авторизации пользователей используется сервер LDAP университета с регистрационными данными пользователей.

. Системные требования

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

операционная система Windows или Linux;

СУБД MySQL;

корпоративный портал Liferay;

домен Windows с Active Directory.

К техническому обеспечению предъявляются следующие минимальные требования:

процессор уровня Intel Core 2 Quad;

оперативная память 16 Гб;

доступ в сеть Интернет, рекомендуемая скорость соединения - 1 Мбит/сек и выше.

. Обслуживание программного обеспечения

.1 Установка

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

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

Развертывание структуры портала

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

Перейти к панели управления

Перейти к сообществу вы хотите экспортировать

Нажмите действия -> Управление страницами

Перейдите на страницу Экспорт / Импорт

Выберите файл для импорта

Нажмите кнопку "Импорт"

Подключение базы данных

Для подключения базы данных расписания необходимо в файле portal-setup-wizard.properties указать следующие параметры:

jdbc.test.driverClassName=com.mysql.jdbc.Driver.test.url=jdbc:mysql://localhost/rasp?useUnicode=true&characterEncoding=UTF-8&useFastDateParsing=false.test.username=root.test.password=pass2adm

Подключение Active Directory

. На вкладке «общие» - в поле «как пользователи будут аутентифицироваться?» выбрать «По экранному имени».

. Добавление сервера LDAP.

Соединение:Provider URL =«ldap://имя сервера:389»

Base DN = «dc=vkgu,dc=ru»

Доверитель=имя пользователя в ldap с правами подключения

Верительные данные= пароль соответственно

Пользователи:

Фильтр поиска при аутентификации = (&objectCategory=Person) (sAMAccountName=@screen_name@)

Фильтр поиска импорта=(objectClass=inetOrgPerson)=sAMAccountName

Экранное имя=sAMAccountName

Адрес email =mail

Пароль=userPassword (тут нужно учесть, что Active Directory по умолчанию не использует это поле, поэтому пользователи будут импортироваться в liferay, но не смогут войти, так как пароль не импортируется. Можно заполнить это поле самописным скриптом )

Имя=givenName

Отчество=middleName

Фамилия=sn

Полное имя=cn

Должность=title

Группа=memberOf

Группы:

Фильтр поиска импорта =(objectClass=groupOfNames)

Имя группы=cn

Описание=description

Пользователь=member

Поставить флажок «импорт включен» - пользователи будут импортироваться при первом входе в портал. Если поставить флажок «Включен импорт при запуске» - ВСЕ пользователи будут импортироваться разом при старте сервера Tomcat, это может занять много времени.

Настройка доменного имени

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

Определите местоположение файла hosts и открыть его. В среде Windows файл находится по адресу C:/Windows/System32/drivers/etc

Добавьте следующую строку в конце файла hosts и сохраните его: 127.0.0.1 www.name.com

Обратите внимание на то, что должен использоваться реальный IP-адрес сервера портала и реальный домен. Поэтому, портал с реальным доменным именем в этом поле будет доступен в Интернете.

.2 Запуск программы

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

Запустить командную строку командой cmd;

Ввести команду cd %liferay_directory%/tomcat/bin

Запустить портал командой catalin.bat.

.3 Управление рассылками

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

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

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

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

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

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

. Проблемы в работе программного обеспечения и способы их решения

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

. Проверить доступ в Интернет

. Перезапустить портал Liferay.

. Перезапустить сервер.

ПРИЛОЖЕНИЕ 3

ИНСТРУКЦИЯ

по охране труда для пользователей

персональных электронно-вычислительных машин

(ПЭВМ)

. ОБЩИЕ ТРЕБОВАНИЯ БЕЗОПАСНОСТИ

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

.2.К работе с ПК допускаются работники, не имеющие медицинских противопоказаний, прошедшие инструктаж по вопросам охраны труда. Лица, работающие с ПЭВМ более 50% рабочего времени (профессионально связанные с эксплуатацией ПЭВМ), должны проходить обязательные предварительные при поступлении на работу и периодические медицинские осмотры в установленном порядке. Указанный порядок определен приложением № 1 к приказу Министерства здравоохранения и социального развития Российской Федерации от 16 августа 2004 г. № 83.

.3Гигиенические требования к организации работы ПЭВМ изложены в СанПиН 2.2.2/2.4.1340-03. При работе с ПК на работников могут оказывать неблагоприятное воздействие следующие опасные и вредные производственные факторы:

•повышенный уровень электромагнитных излучений;

•повышенный уровень ионизирующих излучений;

•повышенный уровень статического электричества;

•повышенная или пониженная ионизация воздуха;

•повышенная яркость света;

•статические перегрузки костно-мышечного аппарата и локальные динамические перегрузки мышц кистей рук;

•перенапряжение зрительного анализатора;

•умственное перенапряжение;

•монотонность труда.

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

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

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

Клавиатура располагается на поверхности стола таким образом, чтобы пространство перед клавиатурой было достаточным для опоры рук работника (на расстоянии не менее чем 300 мм от края, обращенного к работнику).

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

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

Для снижения яркости в поле зрения при естественном освещении применяются регулируемые жалюзи, плотные шторы.

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

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

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

.7При работе с ПК обеспечивается доступ работников к первичным средствам пожаротушения, аптечкам первой медицинской помощи.

.8При работе с ПК работники обязаны:

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

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

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

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

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

.9Не допускается:

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

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

•использовать для подключения ПК розетки, удлинители, не оснащенные заземляющим контактом (шиной).

. ТРЕБОВАНИЯ БЕЗОПАСНОСТИ ПЕРЕД НАЧАЛОМ РАБОТЫ

.1Перед началом работы с ПК работник обязан:

.1.1Проветрить рабочее помещение;

.1.2Проверить:

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

•отсутствие видимых повреждений оборудования;

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

•исправность мебели.

.1.3Отрегулировать:

•положение стола, стула (кресла), подставки для ног, клавиатуры, экрана монитора;

•освещенность на рабочем месте. При необходимости включить местное освещение.

.1.4Протереть поверхность экрана монитора, защитного фильтра (при его наличии) сухой мягкой тканевой салфеткой;

.1.5Убедиться в отсутствии отражений на экране монитора, встречного светового потока;

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

.2Запрещается приступать к работе при:

•выраженном дрожании изображения на мониторе;

•обнаружении неисправности оборудования;

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

. ТРЕБОВАНИЯ БЕЗОПАСНОСТИ ПРИ ВЫПОЛНЕНИИ РАБОТЫ

.1Во время работы с ПК работник обязан:

•соблюдать требования охраны труда, установленные настоящей Инструкцией;

•содержать в порядке и чистоте свое рабочее место;

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

•соблюдать оптимальное расстояние от экрана монитора до глаз.

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

.3 Время регламентированных перерывов в течение рабочего дня (смены)

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

При 8-часовой рабочей смене и работе с ПК регламентированные перерывы устанавливаются:

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

для II категории работ через 2 часа от начала рабочей смены и через 1,5 - 2 часа после обеденного перерыва продолжительностью 15 минут каждый или продолжительностью 10 минут через каждый час работы;

для III категории работ через 1,5 - 2 часа от начала рабочей смены и через 1,5 - 2 часа после обеденного перерыва продолжительностью 20 минут каждый или продолжительностью 15 минут через каждый час работы.

При 12-часовой рабочей смене и работе с ПК регламентированные перерывы устанавливаются в первые 8 часов работы аналогично перерывам при 8 - часовой рабочей смене, а в течение последних 4 часов работы, независимо от категории и вида работ, каждый час продолжительностью 15 минут.

.3При работе с ПК в ночную смену (с 22.00 до 6.00) суммарная продолжительность регламентированных перерывов увеличивается на 60 минут.

.4Продолжительность непрерывной работы с ПК без регламентированного перерыва не должна превышать 2 часов.

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

.6 При работе с ПК не разрешается:

•при включенном питании прикасаться к панелям с разъемами оборудования, разъемам питающих и соединительных кабелей, экрану монитора;

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

•допускать попадание влаги на поверхность оборудования;

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

•производить самостоятельно вскрытие и ремонт оборудования;

•вытирать пыль на включенном оборудовании;

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

. ТРЕБОВАНИЯ БЕЗОПАСНОСТИ В АВАРИЙНЫХ СИТУАЦИЯХ

.1В аварийных (экстремальных) ситуациях необходимо:

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

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

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

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

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

.3При несчастном случае на производстве необходимо:

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

•сообщить о происшествии руководителю.

. ТРЕБОВАНИЯ БЕЗОПАСНОСТИ ПО ОКОНЧАНИИ РАБОТЫ

.1По окончании работы работник обязан:

•корректно закрыть все активные задачи;

•выключить питание системного блока;

•выключить питание всех периферийных устройств;

•отключить блок бесперебойного питания;

•отключить стабилизатор напряжения (если он используется);

•отключить питающий кабель от сети;

•осмотреть и привести в порядок рабочее место;

•о неисправностях оборудования и других замечаниях по работе с ПК сообщить непосредственному руководителю или лицам, осуществляющим техническое обслуживание оборудования;

•при необходимости вымыть с мылом руки.

ПРИЛОЖЕНИЕ 4

Текст программного обеспечения

com.test;

import java.io.IOException;java.util.List;javax.portlet.ActionRequest;javax.portlet.ActionResponse;javax.portlet.PortletException;javax.portlet.ProcessAction;javax.portlet.RenderRequest;javax.portlet.RenderResponse;javax.xml.namespace.QName;com.liferay.portal.kernel.bean.PortletBeanLocatorUtil;com.liferay.portal.kernel.dao.orm.DynamicQuery;com.liferay.portal.kernel.dao.orm.DynamicQueryFactoryUtil;com.liferay.portal.kernel.dao.orm.OrderFactoryUtil;com.liferay.portal.kernel.dao.orm.Projection;com.liferay.portal.kernel.dao.orm.ProjectionFactoryUtil;com.liferay.portal.kernel.exception.SystemException;com.liferay.portal.kernel.util.ParamUtil;com.liferay.sample.model.rasp;com.liferay.sample.service.ClpSerializer;com.liferay.sample.service.raspLocalServiceUtil;com.liferay.util.bridges.mvc.MVCPortlet;class QueryPortlet extends MVCPortlet {

@Overridevoid doView(RenderRequest renderRequest,renderResponse) throws IOException, PortletException {classLoader = (ClassLoader) PortletBeanLocatorUtil.locate(ClpSerializer.getServletContextName(), "portletClassLoader");

// Выбор из БД для списка групп

DynamicQuery grpQuery = DynamicQueryFactoryUtil.forClass(rasp.class, classLoader);grpQuery.setProjection(ProjectionFactoryUtil.distinct(ProjectionFactoryUtil.property("Grp")));.addOrder(OrderFactoryUtil.asc("Grp"));<Object> grpList = null;{= raspLocalServiceUtil.dynamicQuery(grpQuery);

} catch (SystemException e) {.printStackTrace();

}.setAttribute("grps", grpList);

// Выбор из БД для списка преподавателей

DynamicQuery dolQuery = DynamicQueryFactoryUtil.forClass(rasp.class, classLoader);.setProjection(ProjectionFactoryUtil.distinct(ProjectionFactoryUtil.property("Dol")));.addOrder(OrderFactoryUtil.asc("Dol"));

Рисунок П1.1 Файл QueryPortlet.java<Object> dolList = null;{= raspLocalServiceUtil.dynamicQuery(dolQuery);

} catch (SystemException e) {.printStackTrace();

}.setAttribute("dols", dolList);

// Выбор из БД для списка аудиторийaudQuery = DynamicQueryFactoryUtil.forClass(rasp.class, classLoader);audQuery.setProjection(ProjectionFactoryUtil.distinct(ProjectionFactoryUtil.property("Aud")));.addOrder(OrderFactoryUtil.asc("Aud"));<Object> audList = null;{= raspLocalServiceUtil.dynamicQuery(audQuery);

} catch (SystemException e) {.printStackTrace();

}.setAttribute("auds", audList);.doView(renderRequest, renderResponse);

}

@Overridevoid render(RenderRequest arg0, RenderResponse arg1)PortletException, IOException {

// TODO Auto-generated method stub.render(arg0, arg1);

}

@ProcessAction(name="processEvent")void process(ActionRequest request, ActionResponse response) {grpName = ParamUtil.getString(request, "selectGrp", "");grpDate = ParamUtil.getString(request, "calendar", "");grpQueryParams = grpName + '-' + grpDate;qName = new QName("http://www.chsu.ru", "grpName");.setEvent(qName, grpQueryParams);

}

@ProcessAction(name="processEventGrp")void sendParamGrp(ActionRequest request, ActionResponse response) {grpName = ParamUtil.getString(request, "selectGrp", "");grpDate = ParamUtil.getString(request, "dateGrp", "");grpQueryParams = grpName + ';' + grpDate;qName = new QName("http://www.chsu.ru", "grpParam");.setEvent(qName, grpQueryParams);

}

@ProcessAction(name="processEventDol")void sendParamDol(ActionRequest request, ActionResponse response) {dolName = ParamUtil.getString(request, "selectDol", "");dolDate = ParamUtil.getString(request, "dateDol", "");dolQueryParams = dolName + ';' + dolDate;qName = new QName("http://www.chsu.ru", "dolParam");.setEvent(qName, dolQueryParams);

}}

Рисунок П1.2 Файл QueryPortlet.java.