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

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

В настоящее время существует большое количество порталов, разработанных с целью информирования общества о предстоящих или прошедших научных мероприятиях. В данной работе предлагается один из вариантов проектирования интернет-портала для обеспечения проведения научных мероприятий. Для реализации подобных проектов следует использовать серверные технологии, реляционные базы данных[1], методологии проектирования (DFD/IDEF0)[2], а также алгоритмы хеширования (SHA, MD5 и др.) для обеспечения безопасности.

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

Рисунок 1 – Главная диаграмма потоков данных

На рисунке 2 предлагается вариант декомпозиции главной диаграммы.

Рисунок 2 – Декомпозиция главной диаграммы потоков данных

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

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

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

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

Следующим этапом проектирования является создание модели будущей базы данных (рисунок 3).

Рисунок 3 – Схема базы данных портала

База данных представлена следующими таблицами: «event», «user», «flag», «user_event», «organizer», «user_organizer» и «content».

Таблица «event» предназначена для хранения данных о научном мероприятии (название, текст, дата начала и окончания мероприятия и т.д.).

В таблице «user» хранятся личные данные зарегистрированных пользователей (логин, ФИО, телефон, пароль и др.). Стоит отметить, что пароль хранится не в своем первоначальном виде, а в виде хеш-кода для обеспечения безопасности. Преобразование пароля в хеш-код происходит при помощи алгоритмов шифрования. Можно использовать ряд алгоритмов SHA, MD5 и др.

Таблица «flags» связана с «user» типом связи один-к-одному и хранит в себе данные о роли пользователя (пользователь, рецензент или администратор).

Таблица «user_event» обеспечивает связь таблиц «user» и «event» соотношением многие-ко-многим и содержит данные о заявке пользователя на участие.

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

Таблица «content» не связана с другими таблицами. Данная таблица содержит данные об остальном контенте портала (статьях и новостях).

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

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