К. А. ЛЕМЕСЕВ, А. И. НЕСВИЖСКИЙ
Научный руководитель – Е. А. ПЕТУХОВА
Московский инженерно-физический институт (государственный университет)
ПРИНЦИПЫ ПОСТРОЕНИЯ ПОРТАЛА ВУЗА
1. В тексте обсуждаются такие вопросы, как построение порталов узкой направленности, имеющиеся решения организации порталов, проблемы этих решений, и предлагаются пути построения порталов на основе имеющихся решений.
Используемые в настоящее время системы организации информации web-серверов (контента), порталы, CMS (Content Management System) и их разновидности, в основном имеют ряд недостатков. Этот класс систем обеспечивает лишь общие функции (самые типичные из них – лента новостей, каталог ссылок, доска объявлений и т. д.). Причем, как правило, реализации этих функций носят обособленный характер, что в последнее время решается интеграцией одной функции в другую. Очевидно, что подобная система имеет множество слабых мест в целостности, во внутренних механизмах (взаимодействие разных областей контента между собой), в структурированности, в поддержке и совершенствовании. Проблема целостности – одна из ключевых, интеграция предоставляемых функций – лишь способ сгладить данную проблему. Неразвитость внутренних механизмов напрямую вытекает из предыдущей проблемы – взаимосвязи обычно слабы и мало функциональны. Проблемы структурированности возникают при изменении функциональности продукта. Учитывая все проблемы данного подхода, сложность поддержки и модернизации можно оценить как высокую. К тому же, при использовании продукта данной модели в специальных целях, модернизация неизбежна.
Решение поставленной задачи можно построить на одном из существующих инструментов, принимая во внимание все его особенности. Предлагается, используя существующий портал (eMPortal, на базе InterSystems Cache’), оставить только основные его функции, как то авторизация и аутентификация. Затем ввести некоторую математическую модель, которая будет описывать основные процессы, информацией о которых необходимо управлять. Далее в портал внедряются приложения, которые обеспечивают работу построенной математической модели. Исходя из специфики поставленной задачи, модель реализует информационные процессы вуза.
Математическая модель представляет собой две иерархические структуры, связанные на различных уровнях либо напрямую, либо при помощи промежуточных классов. Первая структура представляет собой модель вуза, как некоторой организации и вида её деятельности, и состоит из 6 уровней, между которыми установлено отношение «один-много»: «институт», «факультеты», «кафедры», «специальности», «сотрудники», «предметы». Вторая структура описывает учебный процесс, и состоит из 4 уровней, ключевыми из которых являются «группы» и «студенты». Два других уровня представляют соответственно текущий год и набор семестров, существующих в данный момент. Каждый объект класса «группы» связан с соответствующим ему объектом класса «кафедры». К тому же, для обозначения того, что конкретный преподаватель является научным руководителем какого-то студента, можно определить связь между классами «студенты» и «преподаватели». Однако ключевыми являются классы, организующие связь между структурами, так как именно на их основе строится расписание, ведомости и журналы преподавателя. Здесь также можно выделить некоторую иерархию, правда, уже не такую строгую. Основным является класс «элементы расписания», содержащим объекты, в которых записаны день, неделя, аудитория (их список храниться отдельно) и время, а также установлены ссылки на предмет и группу. Помимо этого каждый объект «элементов расписания» может быть связан с несколькими элементами класса «временное расписание», представляющими собой возможные однодневные изменения, и объектами класса «заметки». Все это позволяет конечному пользователю увидеть расписание конкретной группы, содержащие, помимо стандартной информации о предметах, часах занятий и преподавателях и информацию о различных изменениях, которые отображаются в соответствии с текущей датой.
Кроме того, модель подразумевает наличие еще 2-х классов: «элементы контроля» и «оценки». Первый отображает различные зачеты, контрольные работы и экзамены, и, соответственно, связан с определенной группой, предметом и преподавателями, содержит информацию о времени и месте проведения, а также о типе контроля. Класс «оценки» необходим для хранения результатов работы студентов, на предметах, и, помимо самого результат, хранит дату выставления оценки. Оценки могут быть связаны не только с уровнем «элементы контроля», что дает возможность отобразить ведомость для каждой группы, но и с «элементами расписания». Таким образом, преподаватель, при желании, может вести электронный аналог своего журнала.
Подобное решение, с одной стороны, позволит эффективно решить поставленную задачу (управление контентом в аспекте вуза), с другой – аккуратно обойти большинство недостатков.
