Автоматизация контроля формата Текст научной статьи по специальности «Компьютерные и информационные науки»

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

5. Администрирование:

• Разграничение прав доступа к системе. Предусмотрено четыре типа пользователей: 1) ученые секретари; 2) преподаватели; 3) студенты; 4) администраторы. Преподаватели имеют право просматривать учебные материалы по всем дисциплинам, а редактировать только файлы собственных дисциплин. Ученые секретари, как лица ответственные за процесс обучения в целом, могут просматривать и редактировать файлы любых учебных материалов и дисциплин. Студенты имеют право просматривать дисциплины своих учебных планов. Администраторы же отвечают за разграничение прав доступа.

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

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

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

Литература

1. Кузнецов Л.А., Капнин А.В., Тищенко А.Д., Фарафонов А.С. Проект Автоматизированной обучающей системы кафедры АСУ // Сборник тезисов докладов научной конференции студентов и аспирантов Липецкого государственного технического университет. Липецк: ЛГТУ, 2009. С. 58-59.

2. Карпова И.П. Исследование и разработка подсистемы контроля знаний в распределенных автоматизированных обучающих системах: дис. ... канд. техн. наук / Московский государственный институт электроники и математики; науч. рук. Е.А. Саксонов. М., 2002. 204 с.

3. Агеев В.Н. Электронные учебники и автоматизированные обучающие системы. М.: 2001. 79 с.

Автоматизация контроля формата

Кузнецов Леонид Александрович (kuznetsov@stu.lipetsk.ru), Тищенко Андрей Дмитриевич (dantis@lipetsk.ru)

ГОУВПО «Липецкий государственный технический университет», г. Липецк

Аннотация

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

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

от пользователей). Для обеспечения автоматизации обработки этой информации необходимо, чтобы данные документы соответствовали набору определенных требований (например, писать тип ошибки в сообщении, указывать отдел, куда направлено требование, в конце указывать ФИО пользователя и проч.). Обеспечение соблюдения этих требований на уровне пользовательского интерфейса [3] (когда пользователь априори может ввести данные только в правильном формате [6]) не всегда возможно. В статье описывается подход, использованный для проверки представляемых лекционных данных для автоматизированной обучающей системы преподавателями кафедры. Основные принципы этого подхода могут быть легко адаптированы и применены для ряда задач проверки представляемых материалов.

Необходимость модуля проверки лекционного материала. В ходе работы над автоматизированной системой поддержки образовательной программы обучения (АСПОП), при разработке функции представления информации [1], возникли сложности с лекционным материалом, предоставляемым преподавателями.

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

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

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

Подход к разработке модуля проверки (МП). Необходимость проверки материала появляется на нескольких этапах работы автоматизированных систем. В основном таких этапов два:

• Формирование материала (пользователь должен иметь возможность проверять составленные им документы и вносить по мере надобности исправления).

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

В случае автоматизированной обучающей системы эти этапы можно представить следующим образом:

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

• При заполнении на вход модуля заполнения базы данных должны поступать только те лекции, которые СТРОГО удовлетворяют разработанным требованиям.

Опишем взаимодействие между пользователем и МП более формально с помощью диаграммы вариантов использования (рис. 1). Диаграмма вариантов использования представляет собой множество сценариев, объединенных общей целью [2, с. 55], и позволяет четко определить цель создания подсистемы.

Проверяет лекции

Преподаватель

Предоставляет лекцию для АОС

Предоставлении лекции для АОС

Рис. 1. Диаграмма вариантов использования модуля проверки для АОС

Необходимо учитывать специфику АСПОП, реализуемую в виде web-приложения. В случае разрабатываемой АСПОП данный модуль удобней реализовать в виде двух отдельных приложений.

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

2. Для представления лекций для АСПОП - удобней web-приложение, которое, в случае успешной проверки лекции, сохраняет ее на сервере для дальнейшей обработки.

Представим в общем виде поведение взаимодействия МП проверки с другими подсистемами АСПОП.

МП обменивается данными:

- с преподавателем - получает от него лекции и выдает сообщения об ошибках

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

Представим это более формально в виде диаграммы взаимодействия [2, с. 81], с учетом выделенных вариантов использования.

Рис. 2. Диаграмма взаимодействия с модулем проверки

В общем случае реализация модуля проверки должна работать с одним набором правил, чтобы не было расхождений в результатах для всех возможных вариантов использования (в нашем случае их два, согласно диаграмме вариантов использования (рис. 1): проверка лекций преподавателем и представление лекций для АСПОП). Проверка лекций, несмотря на два выделенных варианта, должна реализовывать один набор правил, чтобы не получилась ситуация, при которой лекция, прошедшая проверку на локальном приложении, не пройдет проверку системы предоставления лекции. Интерфейс общения с модулем проверки и его поведение сильно различаются для двух представленных методов взаимодействия (это видно из диаграммы взаимодействия (рис. 2)).

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

Можно выделить две основных части МП:

1. -Ядро МП - набор классов, обеспечивающих проверку материала и формирующий набор ошибок и предупреждений.

2. Интерфейс проверяющего модуля - набор классов, представляющий интерфейс для общения с пользователем и определяющий дальнейшее поведение модуля проверки для каждого варианта использования.

Схематично это можно представить следующим образом:

Материал для проверки

Рис. 3. Части модуля проверки

Исходя из перечисленных выше свойств МП, для АСПОП можно выделить два интерфейса (п = 2) (рис. 1, 2 - два варианта использования), каждый из которых требует отдельного приложения.

1. Локальное приложение [4] для проверки лекционного материала «на лету».

2. Web-приложение [1, 5], включающее в себя возможность загрузки лекций на сервер.

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

Ядро двух интерфейсов МП будет одинаковым для обоих вариантов использования.

Ядро проверяющего модуля. Ядро проверяющего модуля должно реализовывать проверку соответствия предоставленного пользователем материала и представлять результат этой проверки в виде некоторого элемента (класса, массива классов, файла, записи в БД), который могут использовать другие элементы системы для работы. В случае АСПОП это списки классов ошибок и предупреждений, генерируемые модулем проверки.

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

• Реализация проверяющей логики (осуществление проверки по заданным правилам).

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

Эти элементы должны быть едины для всех частей проверяющей системы.

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

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

Литература

1. Кузнецов Л.А, Капнин А.В., Тищенко А.Д., Фарафонов А.С. Проект автоматизированной обучающей системы кафедры АСУ // Управление большими системами»: сборник трудов V Всероссийской школы-семинара молодых ученых. Липецк, ЛГТУ, 2008. Т. 2. 326 с.

2. ФаулерМ., Скот К. UML. Основы: пер. с англ. СПб.: Символ-Плюс, 2002. 192 с.

3.Макконнелл С. Совершенный код. Мастер-класс: пер. с англ. М.: Изд-во «Русская Редакция»; СПб.: Питер, 2007. 896 стр.

4. ЛаборВ.В. Си Шарп: Создание приложений для Windows. Минск: Харвест, 2003. 384 с.

5. Рейли Д. Создание приложений Microsoft ASP.NET: пер. с англ. М.: Изд-во «Русская Редакция», 2002. 480 с.

6. Норенков И.П., Уваров М.Ю. Информационно-образовательные среды на базе онтологического подхода // Интернет-порталы: содержание и технологии: сборник научных статей / редкол.: А.Н. Тихонов (пред.) и др.; ФГУ ГНИИ ИТТ «Ин-формика». М.: Просвещение, 2005. Вып. 3. С. 367-378.

Организация самостоятельной работы студентов

ПО ИНФОРМАТИКЕ С ИСПОЛЬЗОВАНИЕМ ИНТЕРНЕТ-ТРЕНАЖЕРА

Ледак Людмила Петровна (lpledak@rambler.ru), Бояркина Лариса Александровна (bolar@yandex.ru)

ООО НИИ мониторинга качества образования, г. Йошкар-Ола, ГОУВПО «Марийский государственный технический университет», г. Йошкар-Ола

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

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

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

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

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