Система поддержки принятия решений при формировании документов организации учебного процесса

Размещено на http://www.allbest.ru/

Содержание

• Введение
• 1. Аналитический обзор
• 1.1 Анализ предметной области
• 1.2 Анализ аналогов
• 1.3 Выводы к первой главы
• 2.1 Программная инженерия
• 2.2 Руководство к своду знаний по программной инженерии - SWEBOK
• 2.3 Составление ОПОП
• 2.4 XML-конструкции
• 2.5 Синтаксический анализ данных
• 2.6 Выводы по второй главе.
• 3. Реализация
• 3.1 Выбор инструментария
• 3.2 Разработка базы данных
• 3.3 Разработка приложения
• 3.4 Работа алгоритмов
• 3.5 Отчеты
• 3.6 Выводы к 3 главе
• 4. Тестирование
• Заключение
• Список используемых источников
• Приложение А
• Приложение Б
• Приложение В
• Приложение Г
• Приложение Д
• Приложение Е

Введение

Быстрые изменение и совершенствование технологий опережает документирование стандартов, которые содержат в себе различные требования к профессиям специалистов. Происходит разрыв связи между требованиями работодателей и знаниями, которые обеспечивает система образования. Тем самым работодатели получают специалистов, не обладающих необходимым набором и уровнем знаний. Именно поэтому, образовательные стандарты, учебные планы и учебные программы подвергаются частым корректировкам. Эти корректировки способны обеспечить необходимый путь развития специалиста. Диссертационное исследование посвящено изучению и разработке системы для формирования документов организации учебного процесса кафедры. Рассмотрены проблемы автоматизации процесса работы с текстовыми наборами данных нормативных документов Федеральных государственных образовательных стандартов (далее ФГОС) и Профессиональных стандартов (далее ПС). Актуальность темы диссертационного исследования обусловлена важностью создания автоматизированных систем для формирования документов организации учебного процесса кафедры. Планирование учебного процесса в вузе требует создания программного продукта, который бы позволял автоматизировать разработку Основных профессиональных образовательных программ (далее ОПОП) и Рабочих программ дисциплин (далее РПД) на базе часто меняющихся ФГОС и ПС. Целью настоящей работы является разработка системы для поддержки деятельности пользователя по подготовке исходной информации и её последующего применения в ОПОП и РПД путём автоматизированного получения информации из нормативных документов ФГОС и ПС, а также по созданию взаимосвязей между основными понятиями документов и их представления пользователю, в том числе в виде XML документов.

Поставленная цель предполагает решение приведенных ниже задач:

· Проведение анализа над нормативными документами.

· Анализ методических рекомендаций по разработке основных профессиональных образовательных программ с учетом профессиональных стандартов.

· Разработка структуры базы данных.

· Разработка механизмов синтаксического поиска информации из документов.

· Составление классификатора

· Разработка механизмов поиска информации в системе.

· Разработка словаря предметной области.

· Разработка механизмов для проверки степени формализации текста ФГОС и его соответствия словарю предметной области.

· Получение выходной информации в удобном виде.

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

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

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

Положения, которые выносятся на защиту:

· Структурирование документов управления учебным процессом при помощи xml-конструкций;

· Способ автоматизированной обработки и поиска по тексту;

· Способ формирования результирующего документа;

· Способ анализа степени формализации нормативных документов;

· Архитектура программного продукта, разработанные и примененные алгоритмы.

1. Аналитический обзор

1.1 Анализ предметной области

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

· ФГОС.

· ПС.

· Основные профессиональные образовательные программы (далее ОПОП).

· Примерные основные общеобразовательные программы (далее ПООП).

· Рабочие программы дисциплин (далее РПД).

ФГОС - необходимый набор требований к образованию, к профессии, специальности и направленности подготовки [1]. ФГОС утверждается федеральным органом исполнительной власти. Цель ФГОС - обеспечение единства образовательного пространства Российской Федерации. Стандарт содержит 3 вида требований:

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

2 Требования к реализации основных образовательных программ. В данных требованиях приводятся кадровые финансовые материально-технические условия, в которых реализуются основные образовательные программы.

3 Требования, в которых прописаны необходимые результаты освоения образовательных программ.

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

Работодатели применяют ПС в следующих случаях:

· формирование кадровой политики;

· управление персоналом;

· при организации дополнительного обучения работников;

· при разработке должностных инструкций;

· тарификации работ; присвоение разрядов работникам;

· установление систем оплаты труда.

Образовательные организации применяют ПС:

· при разработке профессиональных образовательных программ;

· при разработке ФГОС.

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

РПД - это базовый документ, необходимый для подготовки специалиста. У каждой дисциплины существует своя рабочая программа.

По иерархии, ПООП находится между ФГОС и ОПОП. В ПООП содержится возможный вариант ОПОП. ПООП содержит в себе такие важные компоненты как:

· Список профилей подготовки.

· Список направлений подготовки выпускника.

· Список требований к результатам освоения основной образовательной программы.

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

В настоящее время в высшем образовании выделяют следующие компетенции:

· Общекультурные компетенции.

· Универсальные компетенции.

· Общепрофессиональные компетенции.

· Профессиональные компетенции.

· Профессионально-специализированные компетенции

Формирование компетенций не может, происходит без участия работодателей [3].

При рассмотрении требований, которые представляет работодатель к специалистам, возникает следующие проблемы, которые в первую очередь связаны с существующими документами. Первая проблема - это понятийно-терминологические расхождения в терминах и компонентах, которые содержаться в документах сферы труда и сферы образования, а именно ФГОС и ПС. Это происходит из-за того, что документы разрабатывают разные ведомства [4]. Таким образом, появляются термины и компоненты, которые имеют одно и тоже происхождение и несут в себе одинаковую смысловую нагрузку, но записаны они по-разному. Поэтому сотруднику иногда сложно выявить эту закономерность. Приведем закономерности, которые были выявлены из документов ФГОС и ПС. В ПС существуют такое понятие, как «вид трудовой деятельности». В документе ФГОС существует очень близкие понятия. Это «основной вид профессиональной деятельности». Так же в документе ПС есть такие понятия как «трудовая функция» и «обобщенная трудовая функция». В свою очередь в ФГОС противопоставляются такие понятия как «профессиональная компетенция» и «профессиональная задача».

1.2 Анализ аналогов

Представленные на ИТ-рынке программы и системы позволяют выполнять различные функции по расчёту и балансированию нагрузки учебных программ и дисциплин. Разрабатываемая система даст возможность объединить множество документов в единый комплекс, который будет рассматриваться как одно целое. Данное действие позволит избежать ошибок несоответствия понятий этих документов. Разрабатываемая система должна помогать пользователю принимать решения при понятийно-терминологических расхождениях сферы труда и сферы образования, автоматизировано получать и сопоставлять информацию из документов, изменять основные документы управления учебным процессом на кафедре. При анализе аналогов не было выявлено продуктов, которые бы имели в своем распоряжении возможности по сопоставлению понятий и терминов из документов ФГОС и ПС. Было принято решение взять технологический функционал и сделать все возможное для облегчения работы пользователя.

Рассмотрим более подробно некоторые системы, и какой функционал они предлагают, также отметим интересующий нас функционал [4].

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

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

· Загрузка в систему данных из файлов, со сканера. Выгрузка данных из БД, в файлы XML и другие форматы.

· Создание и редактирование учебных планов

· Формирование на основе учебного плана учебных графиков.

· Применениея «FastReport» для создания отчетов.

Рассмотрим систему «Галактика: управление вузом». Система так же носит модульный характер, как и система «GS-Ведомости». Из всех существующих в данной системе модулей нас интересует модуль «Учебный процесс». Модуль позволяет осуществлять:

1. работу с современными стандартами;

2. формировать учебные планы в соответствии с образовательными стандартами;

3. выполнять расчет нагрузки;

4. создавать расписание занятий.

Выделим для себя второй пункт возможностей данной системы, так как в системе так же присутствует необходимость работы с ФГОС.

Рассмотрим более подробно продукт «Планы ВПО». Ниже представлен рисунок 1.1, на котором приведен интерфейс формы.

Рис. 1.1 Создание, хранение и обработка учебных планов специальностей

В «Планы ВПО» имеется механизм, который способен производить проверку правильности составления учебного плана. Если учебный план расходится по параметрам или отдельным компонентам с государственным стандартом специальности, то перед пользователем появляется ошибка. Система так же способна предотвратить расхождение учебного плана с государственным стандартом специальности. Система имеет в своем распоряжении механизмы, которые позволяют автоматизировать разработку РПД. Данный комплекс позволяет:

· формирование учебных планов в соответствии государственным стандартам;

· создание отчетов;

· проверка соответствия между рабочим учебным планом и нормативными документами;

· проверку соответствий по смежным специальностям;

· загрузка и выгрузка документов XML формата;

· перенос данных;

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

· классификаторы.

· проекции.

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

Рис. 1.2 Классификатор

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



Рис. 1.3 Схема формирования связей между классификаторами в проекции

1.3 Выводы к первой главе

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

1. Документы ОПОП, ПООП, РПД, ФГОС и ПС взаимосвязаны. Основой для формирования документов ОПОП, ПООП, РПД является сопоставимые понятия из документов ФГОС И ПС, которые имеют одинаковую смысловую нагрузку и которые необходимо сопоставлять с помощью разрабатываемой системы.

2. Существует необходимость в проверке степени формализации текста ФГОС и его соответствия словарю предметной области, при адаптации образовательных программ к требованиям рынка.

3. Каждому документу ФГОС может соответствовать несколько документов ПС. Таким образом, для составления соответствий необходим механизм, который бы упрощал получение информации из документов.

4. Благодаря проведенному анализу над аналогами, в нашей системе будем учитывать следующее:

a) Для хранения всей полученной информации и созданных связей, необходима база данных.

b) Необходима реализация классификаторов и проекций.

c) Для создания отчетов применим мощный инструмент «FastReport».

d) Необходима реализация экспорта и импорта данных с использованием открытого XML формата;

e) Реализация модульности. Реализация программы будет идти постепенно, отдельными блоками.

2.1 Программная инженерия

Как известно, каждая профессия содержит в себе определенный набор знаний [5]. Если имеется возможность данный набор знаний структурировать, то он становится базой для следующих компонентов:

· создания учебных программ;

· разработки в области работ по повышению их квалификации;

· разработки работ для аккредитации академических программ;

· разработки профессиональной сертификации.

Формализация знаний произошла и в программной инженерии (software engineering) [7], где был создан собственный свод знаний. Программная инженерия - систематический подход к разработке, сопровождению и исследованию программных продуктов. Названия профессии программных инженеров несколько отличаются в разных странах: в Великобритании программные инженеры становятся «сертифицированными инженерами» [8], а в Канаде «профессиональными инженерами» или «магистрами информационных систем» [9].

В программной инженерии предлагается сертификация знаний по следующим областям:

1. Безопасность.

2. Оптимизация.

3. Архитектура программного обеспечения.

Многие компании создают и проводят собственные экзамены для сертификации специалистов в данной области [10]. В данном случае, сертификации ориентированы на конкретные технологии. Эти программы сертификации разработаны с учётом необходимых знаний и опыта в той или иной технологии. Многие университеты мира имеют программы обучения программной инженерии. Сюда входят:

· очные программы;

· интернет-курсы;

· программы для специалистов;

· программы для учёных в этой области;

· программы для сертификатов (например в США) [11].

В российских вузах есть отдельное направление подготовки 09.03.04 «программная инженерия». Многие компании финансируют программы стажировок для будущих специалистов. Эти практики полезны для студентов тем, что они способны показать практические задачи, с которыми программные инженеры сталкиваются каждый день. Но, по мнению экспертного сообщества, существует нехватка квалифицированного персонала [6]. Особенно это заметно ощущается в Европе и Австралии. Даже не смотря на мировой спад в экономике, зарплаты специалистов программной инженерии остаются высокими. Подобный экономический спад может послужить причиной более тщательного поиска высококвалифицированных работников работодателями.

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

2.2 Руководство к своду знаний по программной инженерии - SWEBOK

Без знаний в области программной инженерии не стать программным инженером-специалистом. В феврале 2004 года ieee computer society завершило работу над созданием SWEBOK. Данное руководство было опубликовано как стандарт iso/iec 19759:2004. Данный стандарт описывает знания и навыки, которые должен получить дипломированный инженер за срок его обучения продолжительностью в четыре года. Среди обязательных знаний и навыков инженера:

1. начальное профессиональное образование;

2. регистрация пригодности к практической деятельности;

3. повышение квалификации специалистов;

4. поддержка со стороны профессионального сообщества;

5. следование коду этики профессии.

Разработка SWEBOK позволяет выполнить первые три компонента. SWEBOK содержит в себе, что должен знать и какими навыками владеть специалист по программной инженерии.

SWEBOK рассчитана на следующих пользователей:

· государственные организации и компании, для определения требований к образовательным программам и требований к профессии;

· чиновники, для профессионального лицензирования специалистов;

· сообщества и учебные организации, для сертификации программ вузов;

· студенты, которые связали свою профессиональную деятельность с программной инженерией;

· преподаватели, которые отвечают за создание учебных планов и курсов.

SWEBOK предлагает руководство к своду знаний, в котором приводятся понятия, знания и определения по программной инженерии Цели SWEBOK:

· Единое представление.

· Определение границы.

· Содержание.

· Единый свод знаний и предоставление к нему доступа.

· Разработки учебных планов и материалов.

· Лицензирование.

· Сертификации.

Приведем пример один из элементов структуры документа SWEBOK в таблице 1.1.

Таблица 1

Структура SWEBOK

1. Software Requirements Fundamentals	1. основы программного обеспечения
1.1. Definition of a Software Requirement	1.1. определение требований к программному обеспечению
1.2. Product and Process Requirements	1.2. требования к продукту и процессам
1.3. Functional and Nonfunctional Requirements	1.3. функциональные и нефункциональные требования
1.4. Emergent Properties	1.4. новые свойства
1.5. Quantifiable Requirements	1.5. количественные требования
1.6. System Requirements and Software Requirements	1.6. требования к системе и требования к программному обеспечению
2. Requirements Process	2. процесс требований
2.1. Process Models	2.1. модели процессов
2.2. Process Actors	2.2. процессоры
2.3. Process Support and Management	2.3. поддержка процессов и управление ими
2.4. Process Quality and Improvement	2.4. качество и улучшение качества процесса
3. Requirements Elicitation	3. требование к требованиям
3.1. Requirements Sources	3.1. источники требований
3.2. Elicitation Techniques	3.2. методы эскизации
4. Requirements Analysis	4. анализ требований
4.1. Requirements Classification	4.1. классификация требований
4.2. Conceptual Modeling	4.2. концептуальное моделирование
4.3. Architectural Design and Requirements Allocation	4.3. распределение архитектурного дизайна и требований
4.4. Requirements Negotiation	4.4. требования согласования
4.5. Formal Analysis	4.5. формальный анализ
5. Requirements Specification	5. спецификация требований
5.1. System Definition Document	5.1. документ определения системы
5.2. System Requirements Specification	5.2. спецификация системных требований
5.3. Software Requirements Specification	5.3. спецификация требований к программному обеспечению
6. Requirements Validation	6. проверка требований
6.1. Requirements Reviews	6.1. требования проверки
6.2. Prototyping	6.2. макетирование
6.3. Model Validation	6.3. проверка модели
6.4. Acceptance Tests	6.4.приемочные испытания
7. Practical Considerations	7. практические соображения
7.1. Iterative Nature of the Requirements Process	7.1. итеративная природа процесса требований
7.2. Change Management	7.2. управление изменениями
7.3. Requirements Attributes	7.3. атрибуты требований
7.4. Requirements Tracing	7.4. отслеживание требований
7.5. Measuring Requirements	7.5. требования к измерению
8. Software Requirements Tools	8. инструменты программного обеспечения

В документе SWEBOK описывается все то, что относится и должно быть рассмотрено и учтено в предметной области программной инженерии. На основе SWEBOK. Мы можем создать нечто похожее, а именно собственный словарь синонимов предметной области, с помощью которого мы будем проверять наличие необходимых компонентов в содержании ФГОС. На основе ФГОС необходимо проанализировать понятия и термины, которые обязаны быть в данном документе и которые должны быть отражены в ПС. Благодаря структурированию и упорядочиванию терминов понятий работу можно рассматривать как составную часть онтологической модели и как усеченный вариант структурирования предметной области программной инженерии. При поиске аналогов не было найдено автоматизированных средств для подобного структурирования.

2.3 Составление ОПОП

В разрабатываемой автоматизированной системе будет идти работа над документами ФГОС и ПС, так как они являются основным источником информации для формирования ОПОП, ПООП и РПД.

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

· проанализировать перечень трудовых функций, отобранных для разработки конкретной образовательной программы;

· выбрать наиболее значимые трудовые функции;

· при необходимости на основе выбранных трудовых функций составить обобщенный перечень задач профессиональной деятельности выпускника образовательной программы высшего образования и сопоставить его с ФГОС.

Вышеперечисленные операции можно изобразить в виде таблицы (таблица 1.2).

Таблица 1.2

Сопоставление профессиональных задач ФГОС и трудовых функций ПС

Требования ФГОС ВО	Требования ПС
Профессиональные задачи	Обобщенные трудовые функции (ОТФ), трудовые функции (ТФ)

Для системы также необходимо формирование перечня компетенций, вносимых в ОПОП дополнительно к компетенциям ФГОС. При использовании ПС для формирования расширенного перечня профессиональных компетенций образовательной программы необходимо:

· проанализировать описание трудовых функций, которые содержит профессиональный стандарт;

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

· отобрать наиболее значимые для конкретного проекта образовательной программы трудовые функции;

· проанализировать сформулированные в ПС квалификационные требования к выбранным трудовым функциям;

· составить на основе отобранных единиц профессионального стандарта и квалификационных требований к ним перечень профессиональных компетенций.

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

Так же оформим эти действия в виде таблицы (таблица 1.3).

Таблица 1.3

Сопоставление профессиональных компетенций ФГОС и трудовых функций ПС

Требования ФГОС ВО	Требования ПС
Профессиональные компетенции по каждому ВД	Трудовые функции по каждой ОТФ и квалификационные требования к ним, сформулированные в ПС

Таким образом, из документа ФГОС необходимо выделить следующие пункты 4.4 и 5.2.

В пункте 4.4 приводятся профессиональные задачи соответствующие определенному направлению подготовки. На рисунке 2.1 приведен пример пункта 4.4 для направления подготовки 010400 Прикладная математика и информатика

Рис. 2.1 Пункт 4.4

В пункте 5.2 приводятся профессиональные компетенции (ПК), которыми выпускник должен обладать. На рисунке 2.2 приведен пример текста из пункта 5.2.



Рис. 2.2 Пункт 5.2

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

1. Название пункта

2. Вид деятельности

3. Список компетенций и задач

Проанализируем, что необходимо учитывать из документа ПС. В качестве примера приведен профессиональный стандарт для программиста (Рисунок 2.3).



Рис. 2.3 ПС «Программист»

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

На рисунке 2.4 приведены перечень компонентов, которые входят в каждую трудовую функцию.

Рис. 2.4 Компоненты

Таким образом, мы имеем следующий необходимый набор данных из этого документа:

· Название документа

· Обобщенные трудовые функции

· Трудовые функции

· Трудовые действия

· Необходимые умения

· Необходимые знания

Так как в каждую специальность входит некоторое количество профессий, то и каждому ФГОС необходимо учитывать некоторое количество ПС. Чтобы разграничивать данные и знать, какому ПС они принадлежат, можно учитывать название или код документа, так как эти значения уникальны. На рисунке 2.5 приведена титульная страница ПС «Программист».

Рис. 2.5 Титульная страница ПС Программист

Таким образом, мы выделили основные компоненты из документов ФГОС и ПС, которые необходимо учитывать для автоматизации методики при составлении основных профессиональных образовательных программ высшего образования с учетом профессиональных стандартов.

Как показал анализ ФГОС и ПС, содержание документов постоянно и практически не меняется, что облегчает работу над автоматическим получением информации из документов. Для автоматизации методики необходимо так же учитывать следующее:

· Получать информацию из документов

· Сохранять информацию, полученную из документов

· Представлять в удобном виде информацию для работы с ней

· Выводить отчеты по проделанной работе.

2.4 XML-конструкции

Самое удобное и распространенное ныне средство структурирования информации - язык XML. XML означает Extensible Markup Language - расширяемый язык разметки текста. Документы XML используются во многих приложениях и во всех аналогах, которые были представлены выше.

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

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

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

Для работы с XML-информацией часто используют XML-схемы.

XML-схема - это промышленный стандарт описания XML-документов. Используется XML- схемы для создания структуры будущего документа XML. Сначала создается схема, потом создается документ под эту схему.

2.5 Синтаксический анализ данных

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

· Получение доступа к коду ресурса;

· Сбор информации

· Чтение, извлечение и обработка данных, получение и преобразование информации

· Генерация результатов представление извлеченных данных в удобоваримом виде - файлы.txt,.sql,.xml,.html и других форматах.

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

Приложения для парсинга обычно пишут на C++, Delphi, Perl, Ruby, Python, PHP.

2.6 Выводы по второй главе.

Можно сделать следующие выводы:

· Необходимо работать с файлами профессиональных стандартов и федеральных государственных образовательных стандартов;

· Необходимо структурировать необходимую для построения ОПОП и РПД информацию, полученную из файлов ПС и ФГОС, продумать XML-конструкции для входных и выходных документов;

· Необходимо структурировать информацию о кафедрах, специальностях и профессиях и представлять в удобном для человека виде (справочники);

· Необходимо формировать хранилище данных;

· Необходимо формировать и вести словарь основных понятий стандартов ФГОС, для уточнения и подтверждения полноты содержания данного документа;

· Необходимо составление классификатора

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

3. Реализация

3.1 Выбор инструментария

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

Среда разработки программного обеспечения C++ Builder. C++ Builder - средство быстрой разработки приложений, позволяющее создавать приложения на языке C++, используя при этом среду разработки и библиотеку компонентов Delphi. Компоненты C++ Builder располагаются на палитре компонентов, выполненной в виде многостраничного блокнота. Важная особенность C++ Builder состоит в том, что он позволяет создавать собственные компоненты и настраивать палитру компонентов, а также создавать различные версии палитры компонентов для разных проектов.

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

Генератор отчетов FastReport. FastReport - программный продукт, который предоставляет сторонним разработчикам возможность использовать свои компоненты в привычных для них средах разработки например C++ Builder. Разработчик получает возможность использовать связь с различными СУБД.

Библиотека EhLib включает в себя компоненты и классы для Builder C++. Предназначена для расширения функциональности клиентской части приложений, работающей с БД: вывод, печать и занесения данных конечным пользователем.

SQL Manager for SQL Server для работы с SQL Server

В конечном итоге получили программу, которая соответствует всем заявленным требованиям. Разработка происходила в два этапа:

1. Создание системы с базой данных;

2. Создание парсера;

3. Объединение двух систем;

3.2 Разработка базы данных

Создание базы данных происходило в 3 этапа:

1. Концептуальная модель;

2. Логическая модель;

3. Физическая модель.

Цель построения концептуальной модели для предметной области - это разработка высокоуровневой модели предметной области в виде совокупности взаимосвязанных сущностей, атрибутов и связей. В приложении Г приведены концептуальные модели.

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



Рис. 3.1 Взаимодействие компонентов БД

Представленная модель ЛМ БД соответствует всем требованиям и находится в третьей нормальной форме.

Для проектирования физической структуры базы данных необходимо выбрать формат хранения информации в базе данных и представить все отношения в виде набора файлов базы данных. В СУБД будут использованы следующие типы данных, представленные на рисунке 3.2.

Рис. 3.2 Типы данных

Ниже приведены таблицы из базы данных, для описания физической структуры БД (рисунки 3.3 - 3.14).

Рис. 3.3 Кафедры

Рис. 3.4 ОТФ

Рис. 3.5 ПК

Рис. 3.6 Связь между ПК и ТФ

Рис. 3.7 Виды профессиональной деятельности

Рис. 3.8 Профессии



Рис. 3.9 ПЗ

Рис. 3.10 Связь между ПК и ТФ

Рис. 3.11 Специальности

Рис. 3.12 Трудовые функции

Рис. 3.13 сведения о ТФ

Рис. 3.14 Уточнения ТФ

3.3 Разработка приложения

Рассмотрим, что изменилось на второй фазе разработки. Напомним что на первой фазе для разработки технологии ведения автоматизированного учета была создана система по вводу нормативно-справочной информации. Были созданы простые и сложные справочники. К простым справочникам относятся названия кафедр, направлений подготовки, видов профессиональной деятельности. К сложным справочникам относятся справочник федеральных государственных образовательных стандартов и справочник профессиональных стандартов. Чтобы облегчить работу с такими структурами предоставления данных, необходима разработка и реализация механизмов получения информации из текстов ФГОС и ПС и ее структуризация в виде XML для хранения, передачи и редактирования. Предлагается реализация трех способов:

1. С использованием системного буфера обмена

2. Ручной ввод.

3. Парсинг информации.

На первом этапе разработки были выполнены первые два пункта.

Структура главной формы приведена на рисунке 3.15.



Рис. 3.15 Главная форма

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

Главное меню состоит из двух пунктов: «Справочники» и «Справка»

Меню «Справочники» формы представлено на рисунке 3.16.

Рис. 3.16 Справочники

Справочника ФГОС, выглядит следующим образом и представлен на рисунке 3.17.

Рис. 3.17 Справочник ФГОС

Для заполнения справочника ФГОС необходимо сделать следующее:

· Выбрать необходимую кафедру;

· Выбрать необходимую специальность;

· Выбрать необходимый вид профессиональной деятельности;

С помощью справочника ФГОС мы можем выполнять следующие операции:

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

2. Добавление профессиональных задач и профессиональных компетенций, использую системный буфер обмена, о нем пойдет речь далее

3. Изменение профессиональных задач и профессиональных компетенций.

4. Удаление профессиональных задач и профессиональных компетенций.

И в данном справочнике было добавлено две новые возможности:

5. Загрузить данные из заранее подготовленного XML-документа с помощью отдельно разработанной программы - парсер при нажатии на кнопку «Загрузить из XML-файла».

6. Загрузить данные непосредственно из документа ФГОС формата.doc или.docx.

На рисунке 3.18 представлен механизм работы второго пункта возможностей

Рис. 3.18 Получение информации с помощью системного буфера

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

Справочник «Профессиональные стандарты» представлен на рисунке 3.19.



Рис. 3.19 Форма справочника профессиональных стандартов

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



Рис. 3.20 Дополнительной форма

Справочника «кафедра» представлен на рисунке 3.21.

Рис. 3.21 Структура справочника «Кафедра»

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

Вторым заполняется справочник «Специальности», который представлен на рисунке 3.22.

Рис. 3.22 Структура справочника «Специальности»

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

Третьим справочником, заполняется справочник «профессиональная деятельность», который представлен на рисунке 3.23.



Рис. 3.23 Структура справочника «профессиональная деятельность»

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

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

На рисунке 3.24 представлена главная форма, после заполнения всех справочников и создания взаимосвязей между компонентами.



Рис. 3.24 Главная форма после создания взаимосвязей

3.4 Работа алгоритмов

Рассмотрим более подробно, как работает системные компоненты нашего приложения. На рисунке 3.25 представлен скриншот реализованного парсера, а именно пример парсинга документа ПС «Программист».

Рисунок 3.25 Скриншот приложения парсера

Как видно из рисунка, имеются входные данные, которые могут быть в формате.doc и.docx и выходные данные в формате XML. В приложении приведен код для получения информации из документов ПС и ФГОС.

Рассмотрим алгоритм работы парсера для документа ПС. Так как структура документов ПС одинакова, то и алгоритм получения информации из документов один и тот же. Для получения информации из документа ПС необходимо:

1. взять таблицу номер 4

a) для каждой строки таблицы 4:

b) если значение в первом столбце изменилось, то создать новый узел для GeneralWorkFunction и запомнить этот узел в vector;

2. из текущей строки считать данные о функции и коде и записать в текущий узел GeneralWorkFunction;

3. Если текущая таблица не последняя, то перейти к следующей таблицы перейти к шагу 8;

4. Взять текст в ячейке (2, 2) ;

5. если среди сохраненных в vector узлов есть узел, у которого значение совпадает с текстом, полученным на шаге 4, то перейти к шагу 6, иначе к шагу 3;

6. из текущей таблицы добавить "детали" в узел, найденный на шаге 5;

7. перейти к шагу 3;

8. закончить процедуру.

Надо заметить, что в общей таблице (№4) код содержит английский текст, а далее в таблицах русский. Визуально коды “А/1.3” и “A/1.3” ничем не отличаются, но первые буквы написаны на разных языках. Поэтому при сравнении строк получается неравенство.

Полученный xml-документ, после проведенного синтаксического анализа над документом ПС «Программист», представлен в приложении Е.

При проведении синтаксического анализа над документом ФГОС идет перебор всех абзацев. Если встретили абзац, содержащий нужный текст, то создаем узел и добавляем информацию. Причем после для строки с символом ":" создается подузел, а строки с символом ";" добавляются как подузлы для узла с символом":" в конце. Добавление заканчивается, когда встречается в конце символ ".". Полученный xml-документ, после проведенного синтаксического анализа над документом ФГОС, представлен в приложении Е.

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

Рассмотрим работу новых возможностей, которые были введены на втором этапе разработки. Допустим, что была получена информация из ФГОС и ПС и были сформулированы XML-документы с помощью отдельного приложения - парсера. Первым делом надо разобраться с чтением файлов XML и записью полученных результатов в базу. Функции чтения и записи информации из XML-документа находятся в исходном файле «datamodule» и называется «openXML». На рисунке 3.26 изображен файл «datamodule», на котором располагается «openXML».



Рисунок 3.26 datamodule

«openXML» - это объект, который позволяет вызывать окно выбора файлов. На рисунке приведен 3.27 участок кода, где вызывается окно выбора файлов.

Рисунок 3.27 вызов файла XML

Если пользователь выбрал определенный файл, начинается чтение из этого файла. На рисунке 3.28 представлена функция «parseDocument», которая предназначена для разграничения ФГОС и для ПС.



Рисунок 3.28 функция parseDocument

В данном фрагменте кода передаются соответствующие параметры, чтобы разграничить в какой документ надо будет записывать, в ФГОС или ПС.

В приложении А приведен фрагмент кода, где начинается чтение файла для ФГОС, а именно «parseFGOS».

В builder C++ существует объект для работы с xml-файлами. Он называется «TXMLDocument». Для доступа к возможностям XML компанией Borland разработан компонент VCL «TXMLDocument», который позволяет разработчику использовать в своих приложениях преимущества документов XML. Компонент «TXMLDocument» представляет собой оболочку к внешнему анализатору объектной модели документа. Этот компонент не вошел ни в Builder 6 Professional, ни в Delphi б Professional в качестве "зарегистрированного" VCL-компонента. По сути, все, что нужно для работы - зарегистрировать компонент «TXMLDocument» и обеспечить редактор его свойств.

Порядок действий следующий:

· Создание объекта.

· Выбор кодировки.

· Чтение, исходя из структуры готовых файлов, то есть мы уже знаем, какие файлы мы получаем от парсера ФГОС или ПС.

· Открытие файла.

В приложении Е приведен XML-документ, полученный после парсинга ФГОС.

В xml документе можно выделить объект «root». Root - это корень структуры. В коде он читается следующим образом, рисунок 3.29.

Рисунок 3.31 чтение root

У корня root имеются потомки. У самих потомков так же имеются потомки. В xml-документе можно выделить тег «ProfessionalStandard», которой идет ниже тега «root», и представляет собой потомка данного тега. Читается данный потомок следующим образом (рисунок 3.32)

Рисунок 3.32 чтение тега «ProfessionalStandard»

Чтобы добраться до какого-то конкретного текста, необходимо пройти все теги по порядку. Так же можно выделить тег «Activities». Этот тег является потомком тега «ProfessionalStandard».У данного тега есть несколько своих потомков, а именно activity_i, где i - индекс. По тегам необходимо пройти с помощью цикла. На рисунке 3.33 выделен участок кода, где представлен данный цикл.

Рисунок 3.33 цикл для «activity_i»

Обратим внимание на рисунок 3.34, где приводится вектор «detailsV». В этот вектор входят пункты по текущему виду деятельности.

Рисунок 3.35 «detailsV»

В первый вид деятельности будут входит все элементы с detail_i, а именно в вектор «detailsV».

На рисунке 3.36 приведен участок кода, куда помещается тег activity_1.

Рисунок 3.36 Помещение «тега activity_1»

Чтобы узнать имя, у потомка берется текст с помощью «GetText()». Пример данного действия приведен на рисунке 3.37.

Рисунок 3.37 «GetText()»

С помощью GetText() получается название вида деятельности.

На рисунке 3.38 показан пример, как считывается определенный вид деятельности.

Рисунок 3.38 считывание вид обязанности

Наименование текущего вида профессиональной деятельности записывается в переменную «professionalActivityTypeName», для нее в вектор заносятся требования. Зная id специальности, для которой загружается данные, пишется в базу полученная информация по текущему виду профессиональной деятельности и вызывается функция «writeFGOSToDatabase» (рисунок 3.39).

Рисунок 3.39 вызов «writeFGOSToDatabase»

В нее передается наименование вида профессиональной деятельности, вектор требований и id специальности. Id специальности известен, т.к. первоначально в программе в справочнике ФГОС выбирается специальность из выпадающего списка, перед чтением xml-файла.

Следующий шаг - переход к функции «writeFGOSToDatabase». Код представлен в приложении А. Можно заметить, что в данную функцию также передается булевское значение «profTasks». Это необходимо для разграничения профессиональных задач и профессиональных компетенций. Для них вызывается одна функция. Так же создается объект «TADOQuery». Далее идет проверка, есть ли такой вид профессиональной деятельности в базе или нет. Если есть, то получаем его id из базы. Если нет, тогда записываем в базу с возвратом свежеполученного id. Надо заметить, что id формируется автоматически - автоинкрементом. Если базе такой вид не найден («if (query->Eof)»). Далее следует оборот в sql server, который возвращает id записи «OUTPUT Inserted.id». После «inserted» можно написать любое поле этой таблицы и вернется его значение. В «profTypeId» помещается id вида профессиональной деятельности. Рассмотрим следующий код:

«AnsiString tableName = profTasks?"PZ":"PK";»

В данном месте можно узнать, с какой таблицей идет работа - с профессиональными задачами или компетенциями. Если параметр «profTasks» истина - значит профессиональными задачами. Дальше обратим внимание на следующий код:

· query->SQL->Text = "select * from "+tableName+

· " where name = "+QuotedStr(details[i])+

· " and proftype_id = "+IntToStr(profTypeId)+

· " and speciality_id = "+IntToStr(speciality_id);

В данном участке идет проверка, есть ли такое требование или нет. Если есть, алгоритм работает дальше. Если нет, записываем в базу данных.

На рисунке 3.40 показан участок кода, где будет выведена ошибка, если возникнет какое-то исключение.

Рисунок 3.40 Вывод ошибки

Дальше происходит возврат назад и проделывается те же самые операции с «activity_i». И так со всеми требованиями по всем видам профессиональной деятельности. Если возникает ошибка - выход.

Дальше переходим к компетенциям и находим тег «Competency» и проделывается такие же операции.

Следующий документ - профессиональные стандарты. Так же передается булевское значение, для того, чтобы понять, что это не ФГОС и id профессии (рисунок 3.41).