Рис. 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).
Рисунок 3.41 Передача булевских значений
В приложении А приведен код работы с ПС. В данном коде аналогично идет работа по тегам, т.е проход по ним. Первым делом получается наименование ОТФ конструкцией:
_di_IXMLNode gwFunction = body->ChildNodes >Nodes[WideString("name")];.
Дальше происходит переход к тегу ТФ и тоже помещается ее наименование в переменную «WorkFunction». У ТФ есть потомок «requares» - там перечислены все требования. В приложении Ж приведен пример xml-документа ПС.
Чтобы учесть все требования необходимо пройтись по всем потомкам «requares» циклом. Каждый потомок отвечает за определенный вид требования: умения, навыки и пр. В разработанной базе данных разновидности требований у нас являются константами, ведь кроме этих 4 видов больше других требований не существует. В документе они всегда идут в одном порядке. Поэтому за вид требований отвечает индекс цикла: for(int k = 0; k < req->ChildNodes->Count; ++k), который мы передаем в функцию записи в БД:
· if (!writePSToDatabase(GeneralWorkFunction,
· WorkFunction,
· requares,
· prof_id,
· k+1))
· return false;
· }
В вектор «requares» пишутся пункты по текущему виду требований. После считывания данного участка осуществляется переход в функцию записи в базу. Тут аналогично ФГОС, сначала идет проверка, есть ли такой пункт (ОТФ, ТФ, требования) в базе. Если есть - выделяем id, если нет - пишется и возвращается новое id. Далее происходит возврат назад и переход к следующему виду требований и так дальше до конца для всех ОТФ и потомков.
Таким образом, первый цикл - проход по всем ОТФ. В нем содержится другой цикл, которой проходит по всем ТФ этой ОТФ. А в нем - цикл по требованиям этой ТФ.
Рассмотрим составление отчета XML. Для наглядности создадим отчет. Отчет приведен в приложении Ж. В роли корня у нас выступает тег «Компетенции». Так же выводится специальность. Дальше можно заметить следующую иерархию:
1. вид профессиональной деятельности;
2. компетенция;
3. ОТФ;
4. ТФ;
5. требования.
Если компетенция привязана к ОТФ - тогда в отчет выводится только ОТФ, без списка ТФ. Надо заметить, что для отчета использовалась процедура «PK_TF_Report» - которая используется в похожем отчете в FastReport. Данная процедура приведена в приложении Б. Но были внесены несколько изменений. В переменную типа «table» были добавлены следующие поля:
1. prof_type nvarchar(200),
2. profession nvarchar(200)
Это нужно для того, чтобы можно было вставить в отчет вид деятельности и профессию. Это никак не повлияло на работу отчетов FastReport. В процедуру передается параметр «@proftype_id», который используется для FastReport. Если мы передаем 0, значит, нам нужен отчет по всем видам деятельности, а не только по одному. В случае текстового отчета нам нужны все виды по выбранной специальности. Ниже представлен участок кода с этим условием.
· declare @proftype_char nvarchar(10);