Диссертация (1090660), страница 25
Текст из файла (страница 25)
Окончательноеудаление объекта может произойти по прошествии определенного времени. Это сделано для того, чтобы избежать случайного удаления данных вследствие небольшихизменений или опечаток в коде BML. Когда используется имя, задействованное ранее, и существует удаленный объект (таблица или поле), связанный с этим именем,то объект восстанавливается.При изменении типа блока изменяется и тип в базе данных.
При этом тип приводится согласно используемой СУБД. Изначально программный комплекс BlockSetиспользует MySQL, но существуют и технологические заделы под другие системы.В файле настроек синхронизатора существует опция, задающая его поведение приизменении типа, называемая “type_cast” и имеющая следующие значения: On (типприводится всегда, предупреждение не выводится), Warning (тип приводится, но еслив результате приведения происходит потеря данных, в файл журнала пишется предупреждение об этом), Off (приведение типа выключено, в журнал пишется предупреждение о несанкционированном изменении типа).4.4.7Разработка алгоритма синхронизации отношений таблиц снаборамиСинтаксис BML позволяет задать отношения между наборами.
Наборы взаимосвязаны атрибутом “relation”, устанавливающим, какой тип связи они имеют. Еслиу экземпляра родительского набора может быть множество экземпляров дочернего,то родительский набор имеет значение “parent” (например, у одной категории форумаможет быть множество тем). При обратной ситуации устанавливается атрибут “child”.Атрибут задает главенствующий набор: основной (родительский) или вложенный (дочерний). Если наборы состоят в равных правах, когда у них обоих может быть мно-145жество экземпляров друг друга, то устанавливается значение “multi” (множественнаясвязь [36]).
На рис. 4.8 представлен вызов внешнего процесса проверки спецификиобъекта. Более подробно этот процесс представлен на рис. 4.12. На нем схематичнообозначен алгоритм работы со спецификой набора и блока: перестроение ключей иприведение типа соответственно.Каждая таблица, сопоставляемая с набором, имеет первичный ключ (идентификатор), название которого генерируется по следующему шаблону: набор_id, где «набор» – имя набора. Вторичный ключ генерируется таким же образом, но в качествеимени набора указывается тот, с которым родитель состоит в отношениях.
Для наборов, между которыми установлена множественная связь, необходимо создать связующую таблицу с именем вида: “набор1_набор2$multi”, где «набор1», «набор2» –имена связанных между собой наборов, при этом в начале находится тот, чье имярасположено первым по алфавиту.Существует нетривиальная задача для синхронизатора в случае, когда разработчикпожелает изменить отношение между наборами, что привлечет к перестроению полей и связующей таблицы (при ее наличии). Из этого следует, что может возникнутьпотенциальная потеря части связей при изменении их типа.Анализ проблемы минимизации потерь предлагается начать с рассмотрения вариантов изменения связей. Всего их получается шесть:1. multi ⇒ parent;2.
multi ⇒ child;3. parent ⇒ multi;4. child ⇒ multi;5. parent ⇒ child;6. child ⇒ parent.Разработчик может поменять эти связи, а потом еще раз. Если смена типов связейпроисходит впервые, т.е. отсутствуют необходимые вторичные ключи или связующиетаблицы, то эти компоненты создаются автоматически. В то же время старые ключиили связующие таблицы не удаляются из базы данных до тех пор, пока не истечет их время жизни, устанавливаемое в конфигурационном файле. Это сделано дляпредотвращения случайного изменения связей разработчиком в коде BML.
Разработчик может без ущерба для данных вернуться к старому типу связей.146Варианты 1, 2 подразумевают отказ от связующей таблицы, так как связь междутаблицами меняется с «многие ко многим» на «один ко многим». После преобразования связующая таблица не используется, но сохраняется, как было сказано выше.У вариантов 5, 6 связующей таблицы нет изначально. Во всех четырех случаях, если существует вторичный ключ у ведомой таблицы (при устанавливаемом значении“parent” это таблица дочернего набора, при “child” — родительского), это означает, чтопреобразование не первично и что атрибут “parent” или “child” при соответствующихпреобразованиях уже использовался. Точно так же для вариантов 3 и 4 существованиесвязующей таблицы свидетельствует о повторной установке соответствующей связи.После первичной смены отношения набора возникает закономерный вопрос переноса ключей.
Для случаев 3 и 4 перенос ключей осуществляется безболезненно.По сути, это всего лишь расширение возможностей набора. После создания связующей таблицы в нее переносятся один к одному все ключи из главного набора. Этопреобразование самое безопасное. Остальные случаи подразумевают потерю частиключей.
В общем виде запросы, переносящие ключи, представлены в листинге 1. Выбор присоединения справа или слева зависит от того, какая из двух таблиц наборовмодифицируется.Режим переноса ключей регулируется опцией “relation_cast” в конфигурационномфайле. Опция имеет следующие атрибуты: new (по умолчанию, ключи переносятсялишь в том случае, если новая связь устанавливается впервые), rewrite (ключи переносятся всегда, даже если существовали связующие таблицы и вторичные ключи, онибудут перезаписаны, не рекомендуется), none (ключи не переносятся, при этом ужесуществующие связи остаются нетронутыми).4.5Разработка интерфейсов визуального редакторапостроения структур декларативного языка BMLВажной составляющей методики BlockSet является визуальный редактор, позволяющий наглядно отобразить структуру языка BML и позволяющий охарактеризоватьданный язык, как визуальный.
Декларативная предметно-специфичная природа языкаBML является хорошей почвой для его визуализации, что улучшает его восприятие.Визуальный редактор является неотъемлемой частью конструктора и позволяет генерировать исходный код BML с минимальным использованием клавиатурного ввода.147Данный редактор позволяет автоматизировать создание нового проекта, редактирование свойств его локаций, наборов и блоков [111].4.5.1Разработка мастера создания нового проектаПроект в визуальном редакторе может создаваться как с нуля, так и с помощьюмастера. Создание проекта с помощью мастера позволяет на первом шаге выбратьнеобходимые готовые рецепты (рис. 4.13) и отдельный функционал от них. К примеру,пользователю не обязательно задействовывать весь функционал форума. С помощьюмастера он может выбрать те элементы, которые нужны ему в рамках решения своейзадачи. К примеру, пользователь может взять только блоки и наборы, отвечающие засоздание тем и ответов к ним, сняв соответствующие флаги.4.5.2Разработка интерфейса редактора набораРежим редактора набора отличается в зависимости от контекста.
Так, если наборредактируется в контексте локации, пользователю будет предложено ввести базовыйадрес, а с помощью выпадающего списка пользователь может выбрать те блоки, которые задействованы в данной локации. В контексте модели пользователь и вовсе можетудалить ненужные блоки, при этом для локаций, в которых они задействованы, будуттакже более недоступны.
Кроме всего прочего, в свойствах набора могут быть заданы собственные параметры и их свойства. На рисунке 4.14 показано редактированиенабора в контексте локации.4.5.3Разработка интерфейса редактора блокаРедактирование блока также отображается в зависимости от контекста. В контексте локации серым цветом подсвечиваются свойства, унаследованные от модели. Приэтом свойства, характерные только для модели не подлежат редактированию, но отображаются в виде статического текста. Как известно из раздела 2.5, блоки имеют различные свойства в зависимости от типа.
Визуальный редактор это обстоятельствотакже учитывает, причём в зависимости от характера свойства, предлагает различныйвид элемента ввода.1484.5.4Разработка интерфейса редактора локации и моделиРедактирование локации и модели является совмещённым функционалом, поскольку имеет один общий фактор: добавление и удаление блоков. Разница в том, что вконтексте модели блоки и наборы могут быть физически удалены из проекта, а в контексте локации – только в рамках данной локации. У локации присутствует свойстворедактирования базового адреса. Причём динамические его компоненты могут бытьвставлены путём нажатия на соответствующую кнопку рядом с блоком.4.5.5Разработка интерфейса редактора прав доступаОтдельного внимания заслуживают права доступа [85]. Поскольку механизм взаимодействия прав доступа в BlockSet достаточно витиеватый за счёт их универсализации, его визуализация значительно облегчает понимание.
На рисунке 4.17 показанодействие прав доступа из рецепта «Форум» (приложение B.3). Каждый блок, отвечающий за права доступа подсвечен своим цветом. При этом иконка пользователя справаотражает группу, которая подсвечена своим цветом блока прав доступа. Расположение групп также не случайно. В случае, если две одинаковые группы пересекаются вразных блоках прав доступа, будет применена та, что расположена справа. При этомокончательные права доступа будут определены по группе с наивысшим приоритетом,в которой состоит пользователь.4.6Выводы по главе 4В работе произведен сравнительный анализ языков программирования с учетомследующих требований: высокая производительность, низкие накладные расходы навыполнение разработанных программ, кроссплатформенность, открытость.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
