Personalized engineering documentation templates in instructional design: ontological aspects and situation-based implementation

Full Text

Введение

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

Применение шаблонов — заранее подготовленных заготовок КД, ориентированных на конкретный тип проекта и/или на студентов — распространённая практика в учебном процессе, особенно когда КД выполняются в электронном виде. Идея персонализированных шаблонов предусматривает индивидуальную наст­ройку заготовок КД с учётом персональных данных студента, варианта выданного ему задания, а также проектных решений в ранее созданных КД (рисунок 1). Использование персонализированных шаблонов призвано освободить студента от ручного внесения в КД тех данных, которые можно извлечь из информационной базы процесса УП. 

1. Степень разработанности темы

В областях, обеспечивающих информационную поддержку процессов проектирования, функции автоматизированной генерации документации (в т.ч. КД), разработка и применение шаблонов нашли широкое применение [1–5]. Активно используются онтологические модели соответствующих предметных областей [6–11].

Персонализация понимается как адаптация продуктов или услуг под конкретных людей или под группы людей для повышения качества обслуживания, удовлетворённости клиентов, эффективности бизнес-процессов. Персонализация рассматривается как ключевой элемент современного процесса предоставления услуг в различных сферах, в т.ч. с учётом онтологических аспектов [12–23].

Персонализация в образовании подразумевает, что учащимся предоставляется возможность планировать образовательную траекторию, ставить или выбирать значимые учебные цели, управлять временем и темпом обучения, выбирать те или иные задания, способы их решения и проверки, работать индивидуально и в группе и т.д. [24–30].  Указанные параметры опре­деляются учащимся или педагогом с учётом индивидуальных особенностей обучающегося. Большую роль при этом играют онтологические аспекты [29, 30]. Персонализацию КД не следует путать с персонализацией идентификационных документов, подразумевающей защиту документов, удостоверяющих личность [31]. В [32] рассмотрено построение персонализированных документов на основе языка текстовой разметки XML. В [33] эта задача решена для КД в форматах текстового процессора Word. В [34] аналогичная задача решается для графических документов Visio. С ними связана задача извлечения данных из КД [35]. Работы [36, 37] выполнены в рамках развития ситуационно-ориентированного подхода к интеграции гетерогенных данных в веб-приложениях. В основе этого подхода лежит понятие виртуальных мультидокументов, отображаемых на реальные внешние источники данных. В данном случае задаётся отображение на шаблоны-заготовки текстовых и графических КД в виде документов Word и Visio, а также на источники данных персонализации в виде XML-файлов, таблиц базы данных (БД), веб-сервисов и/или документов в открытых офисных форматах. В шаблонах-заготовках предварительно размечаются места размещения данных персонализации. Далее шаблоны в формате XML загружаются в объекты обработки данных в ситуационно-ориентированной среде, заполняются данными персонализации и выгружаются в виде персонализированных шаблонов.

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

 

Рисунок 1 – Идея персонализации КД в ходе УП

 

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

2. Классы объектов УП

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

Для построения концептуальной схемы выбрана расширенная модель сущность–связь. Для этой модели известны различные нотации, здесь используется смешанная нотация, которая названа «уфимской».

2.1 Классы и категории, связанные с УП

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

На рисунке 2 представлены классы и отношения объектов, непосредственно характеризующих учебный проект как тип. Прямоугольник соответствует классу объектов. Символ связи  задаёт отношение между классами типа «родитель–ребёнок». Треугольник в символе связи задаёт направление от родителя к ребёнку, светлый фон означает, что каждому экземпляру родительского класса может соответствовать ноль, один или несколько экземпляров дочернего класса. Кружок в символе связи определяет обязательность в направлении от ребёнка к родителю: тёмный кружок означает, что каждому экземпляру дочернего класса должен соответствовать один экземпляр родительского класса, а светлый, — что допустимы «сироты» — экземпляры дочернего класса, не имеющие соответствующего экземпляра родительского класса. Квадрат в символе связи указывает идентификацию через связь: тёмный означает, что экземпляры класса-ребёнка идентифицируются в контексте экземпляра родителя, светлый — что экземпляры класса-ребёнка идентифицируются независимо от экземпляра родителя. С учётом этой семантики на рисунке 2 заданы следующие классы.

 

Рисунок 2 – Классы и отношения учебного проекта

 

«Проект» объединяет экземпляры, соответствующие типам проектов, которые выполняются студентами в процессе УП в соответствии с учебными планами.

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

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

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

2.2 Шаблон КД

Шаблон КД — это документ, предназначенный для использования в процессе УП в качестве заготовки для разрабатываемого КД. В УП используются шаблоны различных категорий (рисунок 3).

 

Рисунок 3 – Категории шаблона КД

 

Прямоугольник задаёт класс объектов (понятие), в данном случае - это класс «шаблон КД». Экземплярами этого класса являются конкретные шаблоны. Именованный символ «кружок с чертой» (заимствованный из стандарта IDEF1x) обозначает связь категоризации, задающую отношение типа «класс–подкласс» («суперкласс–категория», «обобщение–детализация» и т.п.). Имена категорий подчёркнуты. Двойная черта в символе категоризации означает полную категоризацию (каждый экземпляр суперкласса относится к одной, и только одной из дочерних категорий), а одинарная — неполную (возможны экземпляры суперкласса, не относящиеся ни к одной из дочерних категорий).

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

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

Типы и экземпляры макета. Шаблон-макет можно рассматривать как:

• макет — это понятие отражает тип шаблона-макета, предназначенного для определённого типа КД и готового к персонализации (на базе макета одного типа может быть сгенерировано множество персонализированных макетов);
• персонализированный макет — это экземпляр макета некоторого типа, заполненный конкретными данными персонализации и предназначенный для выдачи студенту для создания КД в рамках задания УП;
• готовый КД — это КД, разработанный исполнителем на основе персонализированного макета и прошедший установленную процедуру проверки и утверждения.

2.3 Настраиваемые компоненты макета

Способ персонализации «настраиваемый макет» означает, что шаблон КД представляет собой документ, сконструированный таким образом, что в дальнейшем его можно наполнить определёнными персональными данными. Для этого макет содержит набор настраиваемых компонентов макета (НКМ) — контейнер для персональных данных. В одном макете может быть размещено несколько НКМ, каждый экземпляр НКМ соответствует одному родительскому макету. Понятию НКМ соответствуют три класса сущностей:

• компонент — тип НКМ, предназначенного для определённого типа КД и готового к персонализации (на базе макета одного типа может быть сгенерировано множество персонализированных макетов);
• компонент в макете — это экземпляр НКМ некоторого типа, размещённый в макете некоторого типа, но не наполненный содержанием;
• компонент в персонализированном макете — это экземпляр НКМ, наполненный содержанием в некотором экземпляре персонализированного макета. 

На рисунке 4 представлены диаграммы категорий для двух классов НКМ. Экземпляры класса «компонент» подразделяются по признаку атомарности, которая задаёт категоризацию НКМ в зависимости от внутренней структуры, существенной для персонализации: НКМ может быть простым либо составным. Составной НКМ содержит вложенные (дочерние) НКМ, совокупностью которых можно манипулировать как единым целым. Простой НКМ подразделяется на три категории: по виду содержания, по поставщику и по формату.

 

Рисунок 4 – Категории класса «компонент»

 

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

Поставщик определяет категории содержания, указывая принадлежность персональных данных. По поставщику простой НКМ независимо от содержания и источника может иметь следующие категории: «участник», «проект», «событие». НКМ-участник отражает персональные данные лиц или организаций, принимающих участие в проекте: исполнителя, консультанта, контролёра и т.п. НКМ-проект отражает данные проекта: проектные требования, проектные решения и т.п. НКМ-событие отражает существенные моменты процесса проектирования: начало, завершение, контрольные моменты для стадии, этапа, действия и т.п.

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

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

 Класс «компонент в макете» (рисунок 5). Экземпляры этого класса подразделяются по признакам обязательности и кратности.

 

Рисунок 5 – Категории «компонент в макете»

 

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

Кратность задаёт категоризацию НКМ по признаку атомарности/структурности.

2.4 Запросы

Понятие «запрос» определяет источник содержания для заполнения НКМ при персонализации. Каждому простому НКМ соответствует один запрос, в то время как один конкретный запрос может поставлять содержание в несколько НКМ. Понятию запроса соответствуют два класса сущностей:

• запрос — как тип, специфицирующий извлечение содержания для определённого типа НКМ (сам запрос не может быть выполнен, т.к. требует задания определённых параметров при использовании в конкретном персонализированном макете);
• исполняемый запрос (ИЗ) — запрос как воплощение некоторого типа запроса, т.е. это - экземпляр запроса некоторого типа, в котором заданы все требуемые параметры и который может быть выполнен для получения конкретных персональных данных.

На рисунке 6 представлены категории запроса в зависимости от источника.

 

Рисунок 6 – Категории класса «запрос»

 

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

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

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

Документ — запрос на выборку определённых данных из некоторого документа в репозитории КД: путь доступа к определённому типу документа в репозитории, а также путь доступа к определённым данным внутри документа. Для конкретизации запроса необходимо идентифицировать конкретное исполнение проекта.

3. Концептуальная схема УП

На основе рассмотренных классов (см. рисунки 3–6) построена концептуальная схема для УП на основе персонализированных шаблонов-макетов (рисунок 7). На схеме отражены только те из рассмотренных категорий, которые участвуют в отношениях классов.

Схема содержит рассмотренные классы: П — проект; Э — этап проекта; ВП — вариант проекта; ВЭ — вариант этапа; М — макет; ПМ — персонализированный макет; ГД — готовый КД; К — компонент; КМ — компонент в макете; З — запрос; ИЗ — исполняемый запрос. На схеме также представлены классы:

Д (документ) задаёт типы КД, разработка которых предусмотрена в ходе УП;

ДЭ (документ на этапе) указывает, какие документы Д должны быть разработаны на тех или иных этапах проекта Э;

И (исполнение проекта) задаёт конкретные экземпляры УП, когда некоторый вариант ВП проекта П выполняется студентом;

ИЭ (исполнение этапа) задаёт экземпляры, соответствующие выполнению некоторого этапа проекта Э, для которого назначен вариант этапа ВЭ в проекте И.

3.1 Ограничения отношений

Концептуальная схема содержит ряд ограничений на отношения классов.

Отношения «многие-ко-многим». Классы ДЭ, ИЭ, КМ содержат экземпляры, соответствующие парам экземпляров своих родителей. Так, экземпляр ДЭ соответствует паре «экземпляр документа — экземпляр этапа проекта»; экземпляр ИЭ соответствует паре «экземпляр варианта этапа — экземпляр исполнения проекта»; экземпляр КМ соответствует паре «экземпляр компонента — экземпляр макета». Экземпляры этих классов идентифицируются через связи от своих родителей (являются «полными иждивенцами» — скруглённые прямоугольники). Эти классы задают связи типа многие-ко-многим между своими родителями: например, одному экземпляру макета М может соответствовать ноль, один или несколько экземпляров компонента К; одному экземпляру компонента К может соответствовать ноль, один или несколько экземпляров макета М.

«Бездетность» в отношениях «родитель–ребёнок». Большинство связей родитель–ребёнок допускает возможность экземпляров родителей, для которых отсутствуют экземпляры детей (белый фон треугольника в символе связи). Исключение составляют связи П → Э и П → ВП (серый фон треугольника в символе связи). Связь П → Э означает, что у каждого проекта П есть по крайней мере один этап Э. Аналогично связь П → ВП означает, что у каждого проекта П есть по крайней мере один вариант ВП. Следует отметить, что для схожей по смыслу связи Э → ВЭ это ограничение отсутствует.

«Сиротство» в отношениях «родитель–ребёнок». Связи этого типа не допускают сирот за исключением рекурсивной связи К ® К. Данная связь имеет иерархическую структуру составных компонентов К, указывая для компонента его компонент-родитель. Сироты здесь необходимы для исключения бесконечной рекурсии.

Условное отношение «родитель–ребёнок». Связь ПМ ® ГД имеет ограничение на количество возможных детей — у одного родителя допускается не более одного ребёнка. Это ограничение отражает тот факт, что конкретный экземпляр ПМ ещё не доведён до уровня готового КД.

Ограничение общего предка. Ограничение этого вида задано на схеме с помощью связей в виде символа связи с тёмным концевым кружком, где кружок указывает на класс-предок для исходного класса. На схеме представлено два таких ограничения: ПМ —● П и ИЭ —● П. Ограничение общего предка требует, чтобы для каждого экземпляра исходного класса соответствующие экземпляры класса-предка совпадали для всех путей, ведущих из исходного класса в класс-предок.

На схеме показаны два пути из класса ПМ в класс П в направлении предка: ПМ → М → ДЭ → Э → П; ПМ → И → ВП → П. Для каждого из путей каждому экземпляру ПМ соответствует один и только один экземпляр П (переходы от ребёнка к родителю при отсутствии сирот). Согласно схеме движение по разным путям не всегда приведёт к одному и тому же предку. Однако в данном случае необходимо, чтобы каждому экземпляру ПМ всегда, независимо от пути, соответствовал один и тот же экземпляр проекта П. Это обеспечивается благодаря ограничению общего предка.

На схеме показаны два пути из класса ИЭ в класс П: ИЭ → ВЭ → Э → П; ИЭ → И → ВП → П. Каждому экземпляру ИЭ соответствует один и только один экземпляр П, и не гарантируется, что движение по разным путям всегда приведёт к одному и тому же предку.  В данном случае необходимо, чтобы каждому экземпляру варианта исполнения ВИ всегда, независимо от пути, соответствовал один и тот же экземпляр проекта П. Ограничение общего предка гарантирует выполнение этого требования.

3.2 Виртуальные отношения

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

 

Рисунок 7 – Концептуальная схема УП на основе персонализированных шаблонов

 

Пусть на момент персонализации компонента:

из_t — экземпляр исполняемого запроса: из_t Î ИЗ;

и_t     — экземпляр исполнения проекта, и_t Î И; 

пм_t — экземпляр персонализируемого макета, пм_t Î ПМ;  

км_t — экземпляр компонента в макете, соответствующий экземпляру простого компонента: км_t Î КМ, cat (км_t^К | 'атомарность') = 'простой', где выражение типа x^Y обозначает операцию получения родителя экземпляра x в классе Y;  

з    — экземпляр запроса, являющийся предком экземпляра км_t: з Î З, з = км_t^К^З.

Тогда экземпляр связи:

ПМ → ИЗ соответствует паре экземпляров (пм_t, из_t);

КМ → ИЗ соответствует паре экземпляров (км_t, из_t);

З → ИЗ соответствует паре экземпляров (з, из_t);

И → ИЗ соответствует паре экземпляров (и_t, из_t).

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

• для категорий «БД» и «документ» общих параметров достаточно для выполнения запроса;
• для категории «вариант проекта» требуется соответствующий экземпляр вп, вп Î ВП, который определяется как родитель экземпляра и_t: вп = и_t^ВП;
• для категории «вариант этапа» требуется соответствующий экземпляр варианта вэ, вэ Î ВЭ, который определяется следующим образом. Для экземпляра макета м отыскивается экземпляр этапа проекта э, э Î Э, как э = м_t^ДЭ^Э. Далее отыскивается экземпляр вэ, для которого э является предком (э = вэ^ВЭ^Э), а и_t — родителем (и_t = вэ^ИЭ). Это можно задать предикатом: вэ: вэ Î ВЭ, вэ^Э = м_t^ДЭ^Э, $ из: из Î ИЗ, из^Э = и_t^ДЭ^Э, где $ — квантор существования. При этом ограничения идентификации и общего предка, заданные на схеме для класса ИЗ, гарантируют, что возможно не более одного экземпляра вэ, удовлетворяющего этому условию.

4. Информационная система поддержки УП

На основе концептуальной схемы разработана информационной системы (ИС) поддержки УП на базе персонализированных шаблонов КД.

4.1 Ситуационно-ориентированная парадигма

ИС поддержки УП основана на ситуацион­но-ориентированной парадигме [36, 37]. Архитектура ситуационно-ориентированной среды показана на рисунке 8.

 

Рисунок 8 – Архитектура ситуационно-ориентированной среды

 

Обработка данных в рамках этой парадигмы основана на интерпретации иерархической ситуационной модели HSM (Hierarchical Situation Model), представляющей собой совокупность иерархически упорядоченных субмоделей. Каждая субмодель содержит набор элементов-состояний, с которыми ассоциированы элементы:

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

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

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

• персональные данные зарегистрированных студентов из БД MySQL, а также из веб-сервисов ИС университета;
• модели вариантов заданий в виде документов в формате XML;
• персональные задания, сведения о выполнении этапов проекта, замечаниях руководителя в виде документов в формате XML;
• шаблоны-макеты КД, персонализированные шаблоны, готовые КД в виде графических и текстовых документов в форматах Visio (VDX — открытый формат в виде файлов XML, VSDX — открытый формат в виде ZIP-архива файлов XML) и Word (WSDX — открытый формат текстовых документов в виде ZIP-архива файлов XML).

Персонализация шаблона-макета выполняется путём преобразования XML-данных, загруженных в объект обработки, через отображение виртуального документа. Преобразование данных выполняется через программный интерфейс DOM (Document Object Model — объектная модель документа) или по технологии XSLT (eXtensible Stylesheet Language Transformations — язык преобразования XML-документов).

4.2 Подготовка персонализируемого шаблона графического КД

Шаблон-макет КД должен быть предварительно подготовлен так, чтобы программа персонализации могла локализовать в нём все НКМ и наполнить их соответствующим содержанием. Желательно, чтобы процесс подготовки шаблона разработчик мог выполнять в визуальной среде графического редактора, не погружаясь во внутреннюю структуру документа. Разработчик задаёт дизайн КД, используя выразительные возможности графического редактора, а ИС при персонализации наполняет содержанием НКМ из КД.

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

Экземплификант — это текстовая метка в макете, которая должна быть заменена конкретным значением при параметрической персонализации. Во многих случаях НКМ, соответствующие УГО, содержат текстовые фрагменты: имена, пояснения, числовые характеристики и т.п., которые подлежат персонализации. Если в макете такому текстовому фрагменту задать уникальное значение, то при персонализации ИС может отыскать в документе это значение и заменить его персональными данными. При этом не требуется учитывать внутреннюю структуру фигуры, соответствующей НКМ. Например, в XML-документе во всех текстовых узлах, содержащих строку «ФИО-исполнителя», эта строка заменяется, например, на строку «Иванов И. И.».

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

Якорь — это специальная фигура, которое указывает в макете КД место для размещения определённого содержания при персонализации. Якорь имеет уникальное имя или свойство, по которым ИС может найти его в шаблоне и заменить соответствующей фигурой НКМ. Такой способ используется при структурной персонализации в тех случаях, когда заранее неизвестно, какого типа УГО и сколько экземпляров потребуется внести в КД.

4.3 Модели доступа к элементам графических КД

Для персонализации требуется внесение данных в определённые места шаблона-макета, а для получения вносимых данных - извлечение данных из внутренней структуры КД. Решение подобной задачи зависит от формата КД, для чего требуются соответствующие модели доступа. В рассматриваемом случае используются КД, основанные на языке XML. Модели доступа к элементам графических КД ориентированы на используемые форматы векторной графики VDX и VSDX (рисунок 9).

 

Рисунок 9 – Модели доступа к элементам графических документов в форматах VDX (а) и VSDX (b)

 

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

Векторная графика в формате VDX (рисунок 9а) представляет собой файл с текстом, размеченным посредством языка XML. ИС в этом случае загружает и обрабатывает документ целиком. Образцы собраны внутри XML-элемента Masters, а воплощения образцов Shape - на страницах документа Pages/Page внутри XML-элементов Shapes.

В формате VSDX (рисунок 9b) графический документ — это файл ZIP-архива, содержащий папки с XML-файлами, задающими отдельные части графического документа. Сведения о фигурах собраны в папке visio, внутри которой в папке masters размещён файл с образцами masters.xml, а в папке pages — файлы имеющихся в документе страниц (page1.xml, page2.xml и т.д.) с описанием размещённых на них фигур Shape. ИС в этом случае должна извлечь из ZIP-архива нужные файлы и обрабатывать их по отдельности.

Особенность рассматриваемых графических форматов состоит в том, что фигура, отображаемая на листе документа, представляется внутри документа в виде образца (Master), задающего общие свойства некоторого класса фигур, и в виде фигуры (Shape), являющейся воплощением образца и задающей его свойства. Фигуры могут содержать другие вложенные фигуры (рекурсивная необязательная связь от XML-элемента Shape к родительскому XML-элементу Shapes) и надписи, значения которых необходимо задавать при персонализации. Надпись фигуры обычно определяется текстовым содержимым XML-элемента Text, вложенного в XML-элемент Shape.

Представленные модели доступа используются для задания путей (с помощью XPath-выражений) к нужным местам внутри персонализируемых шаблонов КД при использовании технологий DOM или XSLT.

4.4 Пример

Рассмотренный подход к использованию персонализированных шаблонов в УП осуществлён в автоматизированной ИС поддержки курсового проектирования (АИС ПКП) по учебной дисциплине «Базы данных» на кафедре автоматизированных систем управления Уфимского университета науки и технологий. Система представляет собой веб-приложения (http://hsm.ugatu.su/artem/dbproj), функционирующее в ситуационно-ориентированной среде под управлением интерпретатора иерархических ситуационных моделей на платформе LAMP (Linux + Apache + MySQL + PHP).

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

• регистрироваться и вводить свои персональные данные;
• получать сгенерированное системой ТЗ;
• поэтапно получать персонализированные системой шаблоны КД;
• загружать на сервер КД, подготовленные на основе полученных шаблонов;
• знакомиться с отчётом сканера нормоконтроля о выявленных ошибках;
• получать замечания от преподавателя по результатам технического контроля;
• получать ссылки на методические материалы по теме проекта.

Возможности, предоставляемые преподавателю:

• назначать студенту вариант задания;
• получать на проверку подготовленные КД;
• запускать сканер плагиат-контроля для выявления плагиата в КД;
• знакомиться в репозитории с похожими КД;
• знакомиться с отчётом сканера нормоконтроля о выявленных ошибках;
• вводить замечания по результатам технического контроля загруженных КД;
• принимать загруженный КД и допускать студента к следующему этапу;
• получать аналитические отчёты о ходе УП.

Особенности работы АИС при персонализации:

• генерация персонализированных текстовых документов в формате Word: ТЗ, разделов пояснительной записки, текста программы, аналитических отчётов;
• генерация персонализированных шаблонов графических КД в формате Visio (учебный проект включает до 12 этапов, на 8 из них предусмотрена разработка графических моделей БД);
• внедрение в фигуры персонализированного шаблона цифровых водяных знаков, идентифицирующих исполнителя для выявления плагиата в графических КД.

На рисунке 10 приведён фрагмент КД, выполненного на основе персонализированного шаблона. На фрагменте представлена основная надпись КД и часть таблицы переименований.

 

Рисунок 10 – Фрагмент КД, подготовленного на основе персонализированного шаблона

 

Поля основной надписи относятся к категории простых (атомарность), к категории текстовых (содержание), к категории текстового содержимого XML-элемента (формат). Заполнение этих полей в ходе персонализации выполняется методом экземплификантов, поскольку их легко пометить в исходном макете уникальными строками символов. Поля основной надписи относятся к категории ситуационно-независимых, для их заполнения не требуется учитывать результаты предшествующих этапов УП. Поля двух левых столбцов таблицы переименований являются ситуационно-зависимыми. Таблица переименований составляется с целью обеспечения межэтапной прослеживаемости изменений имён объектов в ходе проектирования. Эти столбцы содержат имена сущностей и их атрибутов, использовавшихся на предыдущем этапе проектирования, а правые столбцы — соответствующие им изменённые имена данного этапа. Для заполнения левых столбцов ИС сканирует фигуры в КД предыдущего этапа, извлекает имена и заносит их в таблицу переименований. Поля таблицы переименований заполняются в ходе персонализации методом именованных графических фигур (в данном случае — заранее размещённых в макете текстовых полей, имена которых содержат числовой индекс, используемый ИС для локализации объекта).

Заключение

В статье представлены результаты исследования онтологических аспектов применения персонализированных шаблонов в УП. В основе предлагаемого подхода к созданию персонализируемых шаблонов лежит введённое понятие НКМ КД, для которых задаются запросы к источникам персонализированного содержания. На основе концептуальной схемы разработана ИС поддержки УП на базе персонализированных шаблонов КД. Применение персонализированных шаблонов снижает трудоёмкость рутинных операций оформления КД. Полученные результаты применяются в учебном процессе в автоматизированной ИС поддержки курсового проектирования.

 

Редакция сочла уместным привести титульный экран разработанной ИС по дисциплине «Базы данных» для студентов Уфимского университета науки и технологии

About the authors

Valeriy V. Mironov

Ufa University of Science and Technologies

Email: mironov@list.ru
ORCID iD: 0000-0002-0550-4676
Scopus Author ID: 57192962687
ResearcherId: AAB-9377-2022

Professor of the Department of Automated Control Systems at the Ufa University of Science and Technology, Dr. Tech. Sci. 

Russian Federation, Ufa

Artem S. Gusarenko

Ufa University of Science and Technologies

Email: gusarenko@ugatu.su
ORCID iD: 0000-0003-4132-6106
Scopus Author ID: 57192955402
ResearcherId: A-9304-2014

Associate Professor, Department of Automated Control Systems, Cand. Tech. Sciences 

Russian Federation, Ufa

Gayaz A. Tuguzbaev

Ufa Law Institute of the Ministry of Internal Affairs of Russia

Author for correspondence.
Email: hayaz1@mail.ru
ORCID iD: 0000-0003-2036-6416
ResearcherId: GRR-9497-2022

postgraduate student

Russian Federation, Ufa

References

Supplementary files