Файл: Российской федерации федеральное государственное автономное образовательное учреждение высшего образования.pdf

165
В рамках магистерского исследования на подготовительном этапе, пе- ред проектированием методической системы развития гибких навыков, были определены целевые гибкие компетенции, которые необходимо фор- мировать в курсе информатики. Помимо уже приведенного перечня ком- муникативных и личностных УУД, особое внимание также было уделено формированию навыков командной работы (потому что многие проекты в сфере информационных технологий реализуются только как командные), навыков рефлексии в ее различных видах (физической, эмоциональной, интеллектуальной, функциональной рефлексии), критического и креатив- ного мышления, а также навыкам формирования собственной информаци- онно-образовательной среды и ее наполнения контентом. Выделенные гибкие компетенции и составили целевой компонент методической систе- мы, содержательным компонентом выступили темы школьного курса ин- форматики, представленные в УМК Информатика, 6 класс (авторы
Л. Л. Босова и А. Ю. Босова), дополненные тематиками, связанными с кон- струированием, робототехникой, инструментальными средствами при- кладного назначения. основными организационными формами выступали уроки (согласно классификации занятий по преобладающему виду дея- тельности), внеурочная работа, интегрированные занятия (интеграция с предметом «Технология»).
Приведем примеры наиболее ярких технологий и методов, которые были включены в методическую систему развития гибких навыков. Для развития компетенции «работа в команде» были применены технологии и методы горизонтального обучения, включающие технологию проектного обучения, методы сотрудничества, технология наставничества (понимае- мая как оказание помощи со стороны более опытного «педагога» менее опытному в процессе усвоения последним определенных компетенций) [2].
Наставничество строилось по логике организации работы в командах про- граммистов с применением терминологии, подчеркивающей особенности работы в данной сфере: для обозначения уровня сформированности компе- тенций применялись обозначения, характерные в IT-сфере – Джуниор
(Junior), Миддл (Middle) и Синьор (Senior), иногда вводилась высшая сту- пень - Лид или ТимЛид (Team Leader). Джуниор, как самый неопытный, при реализации определенных видов практической работы, нестандартных заданий, требующих более системного взгляда на предмет, курируется бо- лее опытным Миддлом, а Мидл, в свою очередь, получает помощь от
Синьора, но при этом Синьоры могут помогать и новичкам (Джуниорам), если Мидл не справляется. Критичным для этого процесса является рост компетенций Джуниоров и Миддлов в рамках определенных задач (приме- нения инструментальных средств).
Для развития креативного мышления как умения нешаблонно мыс- лить и находить неожиданные решения проблемы применялись техноло-

166 гии ТРИЗ-педагогики, а особенно НФТМ ТРИЗ (технологии непрерывного формирования творческого мышления и развития творческих способно- стей, обучающихся с активным использованием теории решения изобрета- тельских задач).
Литература
1. Авзалова Э. С. Формирование soft skills у обучающихся в урочной и внеурочной деятельности по информатике [Электронный ресурс] URL: https://uchbash.com/articles/nachalnaya-shkola/2022-01-20/formirovanie- soft-skills-u-obuchayuschihsya-v-urochnoy-i-vneurochnoy-deyatelnosti-po- informatike-2661917 (Дата обращения: 14.03.2022).
2. Дудина Е. А. Наставничество как особый вид педагогической деятель- ности: сущностные характеристики и структура // Вестник Новосибир- ского государственного педагогического университета. – 2017. – Т. 7. –
№ 5. – С. 25–36.
3. Раицкая Л. К., Тихонова Е. В. Soft skills в представлении преподавателей и студентов российских университетов в контексте мирового опыта //
Вестник Российского университета дружбы народов. Серия: Психология и педагогика. – 2018. – Т. 15.– № 3. – С. 350–363.

167

168

факт собственно изменения некоторого элемента базы данных: кто, ко- гда, откуда (с какого компьютера или из какой программы) изменял данные

состояние элемента базы данных после данного изменения

что конкретно было изменено (какие атрибуты менялись, для каждого измененного атрибута - старое значение до изменения и новое значение после изменения).
База данных постоянно меняется (добавляются/удаляются таблицы, меняется состав и типы столбцов в таблицах).
Документы базы данных, история которых ведется в журнале измене- ний, могут иметь простую структуру (то есть соответствующая информа- ция хранится в одной таблице), но могут иметь и очень сложную структуру
(данные из таких документов хранятся в нескольких таблицах, связанных по некоторому ключу или быть в отношении один ко многим).
Базовая потребность для пользователей состоит в том, чтобы увидеть историю изменений любого документа. При этом, выбрав некоторое из- менение, можно будет посмотреть либо состояние документа после данно- го изменения, либо какие атрибуты были модифицированы в данном изме- нении.
Есть еще одна очень важная потребность при анализе журнала изме- нений. Это возможность задавать сложные запросы, используя при этом базу данных изменений. Для этого желательно использовать высокоуров- невый декларативный язык запросов, который будет похож на языки за- просов SQL или XQUERY.
Важно при создании программных модулей для журнала изменений учитывать следующее:

желательно иметь единые универсальные модули, позволяющие вести журнал изменений. При этом такие универсальные модули должны быть инвариантны структуре документов и не меняться при каждом из- менении в структуре данного документа

база данных (журнал) изменений является очень быстрорастущей. Ее объем растет на несколько порядков быстрее объема рабочей базы дан- ных. Поэтому необходим специальный аппарат для контроля объема журнала изменений. Важно уметь архивировать "старые" изменения, но при необходимости восстанавливать и анализировать эти «старые» из- менения.
Одной из важнейших проблем, которую надо было решить при проек- тировании структуры журнала изменений, было решение о структуре соот- ветствующих данных. Поскольку база данных реализована на классиче- ской реляционной СУБД, для хранения различных содержательных ком- понентов базы данных использовалось множество таблиц с принципиально

169 разной структурой. Чтобы хранить историю изменений этих компонентов, если следовать традиционному подходу, необходимо было иметь анало- гичное множество таблиц с такой же структурой. Еще одним фактором, влияющим на структуру журнала изменений, было частая модификация структуры таблиц, что неизбежно в ходе сопровождения практически лю- бой реальной базы данных.
Решение данного вопроса состояло в том, чтобы использовать привыч- ную реляционную таблицу, в которой присутствуют два поля с типом XML.
Одно такое поле необходимо для информации о состоянии документа после данного изменения, а второе XML поле для информации о том, ка- кие именно атрибуты были модифицированы. С одной стороны, хотелось сохранить мощь и быстродействие реляционной модели данных, а с другой стороны необходим был единый универсальный формат для хранения до- кументов различной структуры. Именно в XML поле можно записывать данные сложной структуры, поскольку, по сути, это представление атрибу- тированного дерева.
Тип XML не похож на другие существующие допустимые типы. Из-за невозможности обращения к пользовательским тегам и атрибутам ввиду того, что они не определены заранее, необходимо использовать средства и функции обработки, созданные специально для работы с XML. Наиболее популярные среди таких средств – XQuery и XSLT, языки запросов, со- зданные для преобразования XML-документов [3].
Существует множество различных модулей, решающих задачу DIFF
XML [4]. Однако, как правило, эти модули решают задачу сравнения двух
XML файлов в слишком общем виде. Специфика задачи сравнения XML для журнала изменений не позволяет в чистом виде использовать эти су- ществующие модули.
Поэтому был разработан свой специализированный модуль сравнения
XML объектов, заточенный именно под специфику использования при ре- ализации журнала изменений.
Интересной особенностью реализации модулей журнала изменений является использование метаданных для подключения новых видов доку- ментов к журнализации. Таблица с метаданными хранит метаинформацию об используемых таблицах для всех видов документов, а также о типах от- ношений между этими таблицами. Такая информация содержит имена таб- лиц, первичные ключи для каждой таблицы и названия внешних ссылок для связей между таблицами.
На основе этих метаданных для каждого вида документов в базе фор- мируется SELECT запрос, преобразующий табличное представление доку- мента в эквивалентное XML представление. Этот SELECT запрос форми- руется по единому универсальному алгоритму, что позволяет динамически подключать и модифицировать данный запрос путем внесения нужных из-

170 менений и добавлений в таблицу с метаданными. Таким образом, для под- ключения нового вида документов к журнализации достаточно просто до- бавить новую строку в таблицу с метаданными. Это позволяет также заме- нить использование громоздкого оператора выбора в коде хранимой про- цедуры вызовом динамически сформированного запроса, на основе ин- формации из соответствующей строки таблицы метаданных.
Одним из ключевых моментов реализации журнала изменений явля- ется механизм показа состояний документов и собственно измененных ат- рибутов. Для реализации этого механизма можно использовать разные техники. Хорошие результаты можно получить, применяя технологию
XSLT трансформаций.
Заключение
Чтобы решать все вопросы, связанные с тем, кто ответственный за вводимую в базу информацию, необходимо вести журнал изменений базы данных. Организация такого журнала является нетривиальной задачей, учитывая, что состав и структура таблиц базы данных претерпевает неиз- бежные модификации.
Для эффективного решения этих проблем удобно совместить реляци- онную и иерархическую модель организации данных. Использование со- временных XML технологий в рамках многопользовательского сервера ба- зы данных позволяет эффективно решить эту задачу.
Литература
1. Айзикович С. М., Волков С. С., Васильев А. С, Литвиненко А. Н. Анали- тическое решение контактной задачи о внедрении параболического штампа в неоднородную полосу, лежащую на однородной полуплоско- сти // XI Всероссийский съезд по фундаментальным проблемам теорети- ческой и прикладной механики, г. Казань, 20–24 августа 2015 г. – Изд-во
Казанского ун-та, 2015. – С. 93–95. ISBN 978-5-00019492-8.
2. Kudish I. I., Volkov S. S., Vasiliev A. S. and Aizikovich S. M. 2018 Lubri- cated point heavily loaded contacts of functionally graded materials. Part 1.
Dry contacts Math. Mech. Solids 23(7) 1061–1080.
3. XQuery and SQL Server. - URL: https://docs.microsoft.com/ru-ru/sql/xquery
(date of treatment 04/01/2020).
4. https: //github.com/Shoobx/xmldiff Shoobx / xmldiff: A library and command line utility for diffing xml (access date 04/01/2020).

171
ИДЕНТИФИКАЦИЯ ВИХРЕВЫХ ПЯТЕН
С ИСПОЛЬЗОВАНИЕМ МОДЕЛЕЙ ТОЧЕЧНЫХ
И РАСПРЕДЕЛЕННЫХ ВИХРЕЙ
Лысенко Ф. П., Говорухин В. Н.
ФГАОУ ВО «Южный федеральный университет»,
Институт математики, механики и компьютерных наук
им. И. И. Воровича,
г. Ростов-на-Дону
E-mail: Alen.kor@bk.ru
Постановка задачи
Пусть, имеется плоское вихревое течение жидкости или газа и извест- ны вектора скоростей в наборе из точек в фиксированный момент вре- мени:
(
(
)) где
– координаты точек; а
– соответствующие им компонен- ты вектора скорости.
Необходимо определить их интенсивности и координаты центров для вихревых пятен, формирующих данное течение.
Для описания вихревой конфигурации будем использовать модели вихревых конфигураций с известным выражением для векторного поля те- чения, зависящие от параметров: модель точечных вихрей и модели рас- пределенных вихрей.
Модельная система точечных вихрей
Простейшей вихревой моделью является точечный вихрь. Модель за- дается тремя параметрами: координаты центра вихря на плоскости, его интенсивность. Система из точечных вихрей в каждый момент времени определяет на плоскости поле скорости, которое задается функци- ей тока:
∑
[
]
Компоненты скорости в точке выражаются через функцию тока:
∑