Библиотека электронных ресурсов "Скиф" в образовательном процессе ДГТУ

Развитие информационных технологий повлекло создание новой формы образования, называемого электронным обучением (e-learning), то есть обучением с использованием информационно-коммуникационных технологий. Основой электронного образования являются электронные образовательные ресурсы [1].

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

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

В настоящее время перспективным является интерактивное взаимодействие со студентом посредством информационных коммуникационных сетей, из которых массово выделяется среда интернет-пользователей [2].

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

Структурная модель электронной библиотеки ДГТУ

В Донском государственном техническом университете на портале электронного обучения «СКИФ» создан раздел «Библиотека электронных ресурсов ДГТУ». В настоящее время в ней содержится более 5700 тысяч электронных образовательных ресурсов (ЭОР). Данный раздел предназначен для удалённого представления учебно-методических материалов для обеспечения образовательного процесса студентов по всем специальностям и направлениям [3].

На рис. 1 представлена модель системы электронного обучения ДГТУ на базе портала электронного обучения СКИФ.

Рис. 1. Модель системы электронного обучения ДГТУ

Электронная библиотека (ЭБ) портала «СКИФ» представляет собой web-приложение, включающее в себя следующие основные страницы: «Дерево» факультетов, раздел «Кафедры», страница поиска по различным направлениям и т.д. Как было отмечено выше, одним из основных функционалов, реализуемых в ЭБ, является предоставление свободного доступа к электронным ресурсам для всех категорий пользователей с любой географической точки [5].

Общая схема бизнес-процессов ЭБ представлена на рис. 2.

Рис. 2. Общая схема бизнес-процессов ЭБ

В Управлении цифровых образовательных технологий Донского государственного технического университета (УЦОТ ДГТУ) размещение электронных образовательных ресурсов (ЭОР) в библиотеке «СКИФ» осуществляется после регистрации заявок, поступающих от авторов-разработчиков в информационноаналитическую систему (ИАС).

В ходе изучения текущего процесса размещения были выделены требования к ИАС, основные этапы разработки приложения для полной автоматизации процесса создания и использования ЭОР.

Основным объектом для работы приложения является электронная библиотека портала «СКИФ» ДГТУ. Организационная схема объекта, на котором планируется создание ИАС изображена на рис. 3.

Рис. 3. Организационная схема объекта автоматизации

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

• 1.    Ответственное лицо за регистрацию ЭОР;

• 2.    Автор разработки.

Выбрав сущности, составим информационные потоки и составим DFD-диаграмму.

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

Основными компонентами диаграмм потоков данных являются: внешние сущности, системы/подсистемы, процессы, накопители данных, потоки данных.

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

Подсистема – это составная часть ИАС. Процесс – процесс преобразования входных данных в выходные. Физически процесс может быть реализован различными способами.

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

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

DFD-диаграмма изображена на рис. 4.

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

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

Ответственное лицо га регистрацию OOP

Электронный журнал

Рис. 4. Контекстная диаграмма верхнего уровня иерархии для проектируемой ИАС

Рис. 5. DFD-диаграмма нулевого уровня иерархии

Реализация форума ИАС «Электронная библиотека»

Для разработки форума поддержки авторов ЭОР необходимо организовать Web-приложение на основе технологии взаимодействия СУБД и браузера. В качестве Web-сервера выступает Apache. Apache является кроссплатформенным ПО, поддерживающим операционные системы Linux, BSD, Mac OS, Microsoft Windows, Novell Net Ware, Be OS. В качестве основного инструментального средства разработки нами выбран фреймворк Rails [6]. Rails – это современный фреймворк для web-разработки, написанный на языке программирования Ruby [7].

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

Используемая нами Model-view-controller (MVC, «Модель-представление-поведение», «Модель-представление-контроллер») — схема использования нескольких шаблонов проектирования, с помощью которых модель данных приложения, пользовательский интерфейс и взаимодействие с пользователем разделены на три отдельных компонента.

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

• 1.    Модель – предоставляет знания: данные и методы работы с этими данными, реагирует на запросы, изменяя своё состояние. Не содержит информации, как эти знания можно визуализировать.

• 2.    Представление – отвечает за отображение информации (визуализация). Часто в качестве представления выступает форма (окно) с графическими элементами.

• 3.    Контроллер – обеспечивает связь между пользователем и системой: контролирует ввод данных пользователем и использует модель и представление для реализации необходимой реакции.

В общем случае MVC подразумевает следование нескольким правилам:

• 1.    Вся бизнес-логика приложения должна быть реализована с помощью моделей.

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

• 3.    Контроллеры выступают лишь связующим звеном и не более того.

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

Для визуального оформления представлений воспользуемся интерфейсным фрейморком Bootstrap версии 3.3.4.

При разработке аналитической системы определим следующие контроллеры:

• 1.    cohort_members – основной контроллер системы;

• 2.    skif – контроллер для подсистемы сбора данных;

• 3.    mdl_user_enrolments – контроллер для подсистемы распределения прав доступа;

• 4.    table_name – контроллер для подсистемы ввода данных;

• 5.    coh_mem – контроллер для подсистемы формирования отчётности.

Схема связей между таблицами модуля «Форум» изображена на рис. 6.

Рис. 6. Структурно-функциональная схема модели модуля «Форум»

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

• 1.    cohort.cohort_members – реализует объект показатель. Функции добавления и получения списка показателей.

• 2.    UserEnrolments – реализует бизнес-логику работы с показателями. Обладает функциями создания, поиска, редактирования и представления данных в требуемом формате.

• 3.    CohortMember – реализует добавление, редактирование, подтверждение и поиск ЭОР.

• 4.    mdl_cohort – модель построение отчетов. Каждая функция формирует выходные данные, являющиеся отчетом по определенным параметрам. Для расширения типов предоставляемых отчетов необходимо добавлять методы к этой модели.

Представления содержат в себе шаблоны отображения информации, используемой в каждой из подсистем. Хотя они и подчиняются общим правилам построения, но их набор для каждой подсистемы уникален. Но, несмотря на этот факт, есть несколько шаблонов представления, используемых в каждой подсистеме. Такие шаблоны содержат меню для навигации между подсистемами и должны присутствовать в каждом представлении. К универсальным представлениям относится «/www/skif_imports/skif_import_accred.log». Исключение может быть только в случае ограничения прав доступа, прописанные в этом файле.

Для разработки представлений использовались языки разметки html и xml.

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

• 1.    contextid – для просмотра всех материалов по одному показателю.

• 2.    UserEnrolments.new – для добавления нового материала.

• 3.    cohortid – для просмотра одного материала.

• 4.    modifierid –для редактирования ранее добавленного материала.

• 5.    component – содержит в себе повторяющуюся в остальных представлениях информацию.

Анализ и оценка разработки

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

Формирование электронной библиографической записи на портале «СКИФ» свидетельствует о том, что электронный образовательный ресурс, разработанный автором, появился в соответствующем разделе электронной библиотеки.

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

На рис. 7 изображена главная страница форума пользователей электронной библиотеки портала «СКИФ».

Рис. 7. Главная страница форума

Для удобства обработки информации требовалось распределение по группам. Группы формировались, исходя из данных, предоставляемых сотрудниками Управления цифровых образовательных технологий. На главной странице форума, присутствует возможность обратной связи пользователей с сотрудниками электронной библиотеки портала «СКИФ» в диалоговой форме. Для пояснения некоторых этапов регистрации электронных образовательных ресурсов были созданы специальные разделы [8].

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

Заключение

Апробация разработанной системы проводилась на основе системы электронной библиотеки портала «СКИФ» Управления цифровых образовательных технологий ДГТУ. В ходе тестирования системы выявлена устойчивая работа приложения и возникла необходимость доработать приложение для дистанционной регистрации заявок и размещения электронных ресурсов в библиотеке «СКИФ». Данная доработка особенно актуальна для ДГТУ, как опорного вуза, имеющего разветвленную сеть филиалов и колледжей.