В настоящее время школьные электронные журналы получили большое распространение. Появившись впервые в 2001 г. как проект компании «РООС» (г. Самара) «Сетевая школа» или «Net школа», к настоящему моменту технология электронных журналов вошла в эпоху зрелости. Разработки электронных журналов активно проводились в России вплоть до 2010 г., когда стало ясно, что имеется достаточно разработок (более десятка), покрывающих практически все потребности школьного учебного процесса.
С 2009 г. правительство начало поддерживать идею массового внедрения школьных электронных журналов в образовательный процесс. Были выпущены соответствующие распоряжения, законы, письма и планы правительства [1] [2] [3] [4]. Окончательным закреплением использования школьных электронных журналов было введение Единых требований для систем ведения журналов успеваемости учащихся в электронном виде в общеобразовательных учреждениях Российской Федерации [5]. Данные требования вынудили разработчиков изменять свои школьные электронные журналы под эти требования. Все распоряжения и введенные требования подразумевают использование школьных электронных журналов в общеобразовательных школах, лицеях и гимназиях. С учетом введенных требований устанавливаются ограничения на виды формируемых документов.
Однако практически все существующие электронные журналы предполагают, что школа в течение года имеет постоянный или мало изменяющийся контингент учащихся, состав классов и перечень преподаваемых предметов. Эта модель не учитывает особенности учебного процесса в школах круглогодичных детских лагерей, типичным представителем которых является школа МДЦ «Артек». В этой школе состав учеников, перечень классов и учебных предметов изменяется каждую смену (длительность смены 21 день). На учебный процесс накладываются специфические особенности детского лагеря (нахождение детей в той или иной дружине, изучаемый родной и иностранный языки в школе дома, степень продвижения по учебной программе дома и т. п.). Учителям приходится заполнять ряд специфических документов. Одним из наиболее трудоёмких заполняемых документов является «Ведомость учебных достижений учащегося», которую классному руководителю необходимо заполнить на каждого учащегося в конце каждой смены.
Система электронного журнала является подходящей основой для автоматизации процесса заполнения подобных документов. Сформулируем и обоснуем требования к электронному журналу, который мог бы быть использован для решения задачи формирования нестандартных документов.
Прежде всего, должна быть обеспечена возможность описания шаблонов формируемых документов без необходимости обращения к разработчикам.
Вторым требованием будем считать необходимость реализации журнала на базе свободного программного обеспечения.
Третьим важным требованием является необходимость реализации в виде клиент-серверной архитектуры с пользовательским Web-интерфейсом.
Эти требования объясняется тем, что таких школ, круглогодично работающих лагерей, существует немного и они территориально удалены друг от друга. Как следствие, единых требований к документам типа «Ведомость учебных достижений» не существует и вряд ли они появятся. Следовательно, каждая такая школа уже имеет формы таких документов, созданные на своё усмотрение и отработанные годами. Заказ реализации таких форм разработчикам электронного журнала экономически нецелесообразен, поскольку специфичен для конкретной школы. Реализация же возможности формирования документов по шаблонам, созданным самими пользователями журнала (учителями), позволяет использовать эту технологию любому потребителю (любой школе).
Второе требование исходит из того, что любое проприетарное решение делает потребителя зависимым от «капризов» разработчика приложения. В связи с неизбежным быстрым старением современного парка вычислительной техники периодически возникает необходимость адаптации программного обеспечения под новые вычислительные платформы, что в случае с проприетарным ПО требует покупки очередной его версии. Такие организации как школы, как правило, не имеют достаточных средств для этого. Применение свободного ПО в качестве основы разработки электронного журнала снимают эту проблему.
Третье требование предполагает реализацию базы данных и программы электронного журнала в виде Web-решения, что позволило бы использовать его в гетерогенной локальной сети школы, упростило бы управление базой данных и программой журнала, и потенциально позволило бы родителям, находящимся далеко от своих детей, следить за их успеваемостью через сеть Интернет.
Проанализировав возможности существующих электронных журналов, авторы пришли к выводу, что на данный момент не существует ни одного электронного журнала, удовлетворяющего всем поставленным требованиям. В связи с чем было принято решение о необходимости разработки метода формирования произвольных документов по шаблонам, заданным пользователем, на основе информации из базы данных и его реализации в виде программы электронного журнала, в которой была бы введена эта возможность. В качестве основы были взяты специфические особенности учебного процесса школы МДЦ «Артек».
Рассмотрев возможные способы задания шаблонов, авторы пришли к выводу, что наиболее удобным для пользователей (учителей школы) будет метод с использованием стандартного офисного текстового редактора. И поскольку одним из критериев решения задачи является использование свободного ПО, выбор пал на текстовый редактор пакета LibreOffice, который имеется в реализациях и для Windows, и для Linux. Важным преимуществом такого подхода является то, что стандартным форматом сохранения документов этого офисного пакета является хорошо документированный и открытый формат odt, который представляет собой обычный архив zip, содержащий файлы формата xml, поддержка работы с которыми имеется во многих современных языках программирования.
В качестве серверной платформы авторы избрали связку Linux, Apache [6], PostgreSQL [7], PHP [8], что автоматически удовлетворяет требованиям и по открытости ПО, и по клиент-серверной технологии с Web-интерфейсом.
Разработка метода формирования документов по шаблонам информации из базы данных предполагает необходимость задания в шаблоне полей, значения которых должны быть выбраны из базы данных, скомпонованы в соответствии с логикой их размещения в БД и размещены в заданных местах шаблона. При этом количество информации, задаваемой пользователем в шаблоне, должно быть минимизировано. Например, если в итоговом документе должна быть сформирована таблица с оценками по различным предметам, то пользователю должно быть достаточно задать только шапку одну строку таблицы, в которой указать признаки выбираемых полей. Полная таблица должна быть сформирована программой электронного журнала автоматически, причём её размер (количество строк) должны определяться на основании информации, извлечённой из БД (в данном случае это перечень предметов, изучавшихся учащимся).
Перед тем как были выделены типы заполняемых полей и присвоены им обозначения, было определено, как информация будет извлекаться из базы данных. Во-первых, некоторую информацию из базы данных пользователь должен сам выбирать из предлагаемого ему списка (например, фамилию ученика, для которого формируется «Ведомость»). Список информации для выбора пользователем будет выводиться в интерфейс на первом этапе формирования документа — на этапе разбора шаблона, — при условии, что в самом шаблоне это будет как-то указано. На основе информации, выбранной пользователем из списка, из БД будет автоматически извлекаться остальная информация в зависимости от типов полей, заданных в шаблоне. Информация, выбираемая на первом этапе, будет главной, а само заполняемое поле, которое будет задавать выборку этой информации, назовём «главное ключевое поле». Авторы приняли решение, что начинаться это поле будет с пары символов \ % (обратный слеш и процент). Рекомендуемое количество таких полей от одного до пяти.
Другая информация будет извлекаться из БД автоматически и подставляться вместо полей, находящихся в таблице. Такая информация будет двух видов.
Первый вид: единичная информация, которая подставляется вместо поля (например, название изучаемого предмета).
Второй вид: накопленная информация, которая подставляется вместо поля (например, оценки по предмету).
Условиями, по которым определяется, какая информация будет извлекаться для первого вида, является главная информация; для второго вида — главная информация и информация первого вида. Поле для извлечения информации первого вида будем называть «главное табличное ключевое управляющее поле». В данной работе описание поля начинается с пары символов \s(обратный слеш и латинская s). Поле для извлечения информации второго вида будем называть «табличное накопительное управляющее поле». В данной работе описание поля начинается с пары символов \# (обратный слеш и октоторп). Сами поля задаются следующим образом:
(пара символов)имя_таблицы.имя_поля
где: «пара символов» — описана выше; «имя_таблицы» — имя таблицы в БД, из которой должна производиться выборка; «имя_поля» — имя поля в таблице «имя_таблицы», которое должно быть выбрано.
Например:
- \ %имя_таблицы.имя_поля — главное ключевое поле, информация из которого будет предложена пользователю для выбора, на основании которого будет определяться, какие данные будут извлекаться для управляющих полей в таблице;
- \sимя_таблицы.имя_поля — главное табличное ключевое управляющее поле, информация в котором определит количество строк в сформированной таблице;
- \#имя_таблицы.имя_поля — табличное накопительное управляющее поле для извлечения из БД набора данных одного типа в соответствии со значениями предыдущих двух полей.
Завершающим шагом является разработка алгоритмов формирования запросов к БД на основании заданных в шаблонах полей и заполнения документов по полям шаблона и результатам запросов к БД.
Все алгоритмы имеют похожие действия: ищут управляющие поля, определяют типы управляющих полей, формируют запросы к базе данных, извлекают информацию из базы данных, заменяют управляющие поля.
Основное различие возникает на этапе формирования запросов. В зависимости от приоритетности, сначала используется алгоритм для главных управляющих полей (с предоставлением пользователю права выбора). Потом по результатам выбора пользователя применяется алгоритм для главных табличных ключевых управляющих полей и по результатам обоих запросов (в случае наличия накапливаемых полей) используется третий алгоритм, отвечающий за формирование запросов для накапливаемых полей в таблице.
Как ранее упоминалось в статье, поля для таблиц необходимо минимизировать. Для этого используется по одному виду полей в строке. Для каждого поля формируется свой собственный запрос, независимо от типа управляющих полей. Таблица будет заполняться до тех пор, пока будет извлекаться информация из базы данных.
Для более наглядного действия алгоритмов приведем в качестве примера формирование списка пройденного материала классом. Типам управляющих полей зададим более короткие обозначения. главное ключевое поле, поле с символами \ %, обозначим как поле типа А, главное табличное ключевое управляющее поле, поле с символами \s, обозначим как поле типа Б. Накопительное управляющее поле, поле с символами \#, обозначим как поле типа В.
Будем использовать БД с таблицами class (содержит список классов), subject (содержит список изучаемых предметов) и content (содержит список изученных тем). Для нашей цели достаточно знать, что собственно названия классов записаны в поле class таблицы class, собственно названия предметов — в поле subject таблицы subject, собственно изученные темы в поле content таблицы content. Таблицы связаны между собой обычным для таких случаев способом — с помощью специально выделенных полей с числовыми идентификаторами.
Шаблон будет состоять из одной страницы. Содержимое страницы представлено далее:
Список пройденного материала по предметам у \ %class.class –го класса
|
№ |
Предмет |
Материалы |
|
\+ |
\ssubject.subject |
\#content.content |
Примечание:поле вида \+ введено авторами для автоматической нумерации строк в заполненной таблице.
Сначала программе на вход подается шаблон пройденного материала класса.odt. Средствами PHP происходит разархивация шаблона, который представляет собой архив, и поиск по архиву файла content.xml с последующим извлечением. После того как будет получен файл content.xml, его содержимое считывается в оперативную память. Далее с помощью регулярных выражений в считанном документе ищутся управляющие поля типа А. В нашем примере это одно поле \ %class.class. Данное поле отвечает за выбор класса пользователем.
Далее происходит формирование запроса к базе данных и предоставление пользователю выбора необходимой информации (в данном случае класса). Процесс формирования запроса для поля типа А представлен на рисунке 1.
Рис. 1. Алгоритм формирования запросов для поля типа А
После того, как будет произведен запрос к базе данных и будет получен результат, полученный результат выводится на экран в браузер в выпадающем списке. Выбрав нужную информацию, пользователь переводит программу к дальнейшему формированию документа. Выбранная информация будет сохранена в специальную переменную.
На следующем этапе формирования документа будет производиться заполнение таблицы. Программа выделит нужную строку в таблице путем поиска в каждой строке части управляющих полей либо \s либо \#. Выделив строку, с помощью регулярных выражений ищем поля типа Б и типа В. В нашем случае это по одному полю типа Б и типа В, \ssubject.subject и \#content.content, первое поле отвечает за названия предметов, а второе за список пройденного материала по каждому предмету. Далее идет подготовка к формированию запросов к базе данных и формирование запросов, это представлено на рисунке 2.
Рис. 2. Подготовка и формирование запросов
Рис. 2. Подготовка и формирование запросов, продолжение
Рис. 2. Подготовка и формирование запросов, продолжение
Из блок-схемы алгоритма составления запросов для управляющих полей находящихся в таблице, рисунок 2, видим, что все действия разделяются на четыре этапа.
На первом этапе, происходит извлечение из базы данных информации для полей типа А и разбор полей типа Б и В на отдельные части, а именно на имена таблиц и имена полей в таблицах.
На втором этапе, анализируются поля таблиц между собой, выявляются, чем они являются друг к другу, первичным или внешним ключом [9], или отсутствуют связи между собой.
На третьем этапе формируется запрос к базе данных для поля типа Б, в цикле для каждой новой строки формируются новые запросы к базе данных для полей типа В. Заполнение строки извлеченной информацией и накапливание всех заполненных копий строки.
На заключительном четвертом этапе подменяем в файле content.xml строку, содержащую ключевые поля, на поля, полученные на третьем этапе. Так же в нем подменяем поля типа А на ранее извлеченную для них информацию. Заключением формирования документов является помещение файла content.xml в архив, являющимся копией шаблона, но с именем необходимого документа.
Разрабатываемая система формирования документов позволит специфическим школам формировать свои собственные ведомости учебных достижений и другие прилагающиеся документы, снизит нагрузку преподавателей. А использование свободного программного обеспечения при разработке и эксплуатации вносит существенную экономию средств.
Литература:
1. Распоряжение Правительства РФ от 17.12.2009 № 1993-р. “Об утверждении сводного перечня первоочередных государственных и муниципальных услуг, предоставляемых в электронном виде” / Опубликовано на информационно-правовом портале ГАРАНТ.ру. Режим доступа: www.garant.ru/products/ipo/prime/doc/12071809/
2. Распоряжение Правительства РФ от 27.02.2010 № 246-р. “О реализации национальной образовательной инициативы “Наша новая школа”” / Опубликовано на информационно-правовом портале BestPravo. — Режим доступа: www.bestpravo.ru/rossijskoje/so-dokumenty/u0k.htm
3. Федеральный закон от 27.07.2010. № 210-ФЗ “Об организации предоставления государственных и муниципальных услуг” / Опубликовано на сайте Федеральное архивное агентство. — Режим доступа: archives.ru/documents/fz210.shtml
4. Плана действий Министерства образования и науки РФ от 22.10.2012. “По снижению излишнего документооборота в школах” / Опубликовано на сайте Минобрнауки. — Режим доступа: минобрнауки.рф/с/новости/2637
5. Письмо Минобрнауки России от 15.02.2012. № АП-147/07 “О методических рекомендациях по внедрению систем ведения журналов успеваемости в электронном виде” / Опубликовано на отраслевой информационно-справочной системе АЮДАРИНФО. — Режим доступа: www.audar-info.ru/docs/documents/detail.php?artId=479387
6. Скотт Хокинс. Администрирование веб-сервера Apache и руководство по электронной коммерции. / М.: Вильямс, 2001. — 336 с.
7. Online — справочник [Электронный ресурс] / Режим доступа: http://postgresql.ru.net
8. Online — справочник [Электронный ресурс] / Режим доступа: php.ru
9. Дейт К. Дж. Введение в системы баз данных 8-е изд. / М.: «Вильямс», 2006. // 1328 с.
