Диссертация (1145120), страница 25
Текст из файла (страница 25)
Достичь нужного нам решения можно двумя способами. Во-первых, можно не записывать в edit-скрпит те изменения, которыесоответствуют изменениям узлов из исходной версии в серверную. Вовторых, можно запустить алгоритм повторно, используя в качестве исходнойсерверную версию, а в качестве локальной — целевую версию. В результатебудет построено целевое дерево, а в edit-скрипт будут включены операции,которые переводят серверную версию в целевую. Но поскольку средстваComapping легко позволяют в момент добавления операций в edit-скриптопределять, изменениями в какой из версий оно вызвано (локальной или серверной), то был выбран первый вариант.Остановимся теперь на реализации предложенного алгоритма.
Сначала открытая версия Java-реализации 3DM-алгоритма [424] была переписана на141языке Haxe, поскольку именно на этом языке написаны клиентская и серверная части продукта Comapping. Далее, мы внесли изменения в реализацию всоответствии со сделанными нами изменениями в алгоритме 3DM и выполнили интеграцию с Comapping.
С работой нашего механизма слияния и-картможно ознакомиться, запустив Comapping.В момент отключения Интернет-соединения текущее состояние и-картысохраняется на компьютере пользователя в виде базовой и локальной версий.Первая остаётся неизменной, вторая модифицируется пользователем локально, без связи с Интернетом. При следующем запуске Comapping (без Интернет-соединения Commaping нельзя запустить) пользователь может просмотреть изменения и-карты, сделанные им в режиме отсутствия Интернетсоединения следующим образом: во-первых, при нажатии в стартовом диалоге Comapping кнопки «Open Autosave» откроется список и-карт, когда-либосохранённых локально, среди которых просто нужно найти нужную и открыть её; во-вторых, при попытке открыть серверную версию карты пользователь будет оповещён о том, что на его компьютере имеется сохранённаялокальная версия, и ему будет предложено просмотреть её — см.
рис. 3.9, сообщение «Confirm».Рис. 3.9. Приглашение открыть версию карты после слиянияПри открытии сохранённой локально версии пользователю будет сразу жепредложено слить эту версию с той, которая находится на сервере. Пользователь может отказаться от слияния, и тогда он может продолжить работу над142локальной версией и-карты в только в режиме read-only. Если же он соглашается, то запускается алгоритм слияния, описанный выше.
После окончанияего работы в браузере пользователя открывается целевая версия, на которойотображается информация о случивших конфликтах. Все дальнейшие изменения и-карты, которые будет выполнять пользователь, сохраняются на сервере, то есть работа над картой происходит в обычном режиме.абвгРис. 3.10. Пример разрешения конфликта update/update: а — показ описанияконфликта; б — выбор опции перехода к offline-содержимому узла; в —выбор опции разрешения конфликта; г — итог работы с конфликтомНа и-карте целевой версии, полученной после слияния, появляется кнопка«Hide Conflicts», с помощью которой можно разрешить все оставшиеся конфликты без их анализа.
Рассмотрим подробнее типы конфликтов и возможные варианты их разрешения пользователем.Конфликт update/update по умолчанию разрешается в пользу сервернойверсии и-карты. Однако пользователю предоставляется возможность заменить содержимое этого же узла из локальной версии. На рис. 3.8, а показанпример конфликта update/update: показано, что у узла «Name patterns» есть143конфликт — описание этого конфликта появляется при наведении курсороммышки на знак конфликта.
На рис. 3.10, б показано, что во всплывающем меню конфликтного узла есть возможность выбрать просмотр его сервернойили локальной версии. На рис. 3.10, в показана локальная версия данного узла (видно, что у узла изменилось имя). В том же всплывающем меню естьвозможность зафиксировать текущий вариант как окончательный (пункт«Mark as resolved»).
В данном случае разрешение конфликта было выполненов пользу локальной версии, как показано на рис. 3.10, г — знака конфликтарядом с узлом уже нет.Работа с конфликтом update/delete показана на рис. 3.11, а с конфликтомmove/move — на рис. 3.12.абвРис. 3.11. Пример разрешения конфликта update/delete: а — показ описанияконфликта; б — выбор опции сохранения конфликтного поддерева; в — итогработы с конфликтом144абвгРис. 3.12. Пример разрешения конфликта move/move: а — показ описанияконфликта; б — выбор опции перемещения поддерева к альтернативному родителю; в — выбор опции разрешения конфликта; г — итог работы с конфликтомВ табл.
3.2 приведены данные об использовании Comapping и реализованного алгоритма слияния для трёх индустриальных проектов, в которых былприменён предлагаемый подход. Измерялись следующие показатели: количество узлов и-карты, максимальная глубина дерева, общий объем текста в икарте (количество слов), а также количество участников процесса групповойработы и количество выполнений процедуры слияния (после обрыва и восстановления соединения).145Табл.
3.2. Статистика использования и-карт и алгоритма слияния в проектахПроекты/показателиКол-во узловМакс. глубинаОбъемтекстаКол-во участниковКол-во выполненийслиянияПроект 1439113903412Проект 2119532835Проект 3206781128Из данных, приведённых в табл. 3.2, очевидно, что объём разработанныхи-карт оказался значительным.
Для сравнения, реальный документ с техническим заданием к системе на 6 человеко-лет, имеющийся у автора работы,составил 7900 слов (46 страниц), а и-карта является всего лишь заготовкойдокумента. В и-карте первого проекта оказалось много текста, находящегосяв узлах: разработчики старались подробно описывать каждое требование. Воставшихся двух проектах текста в узлах было значительно меньше, и-картыбыли, скорее, каркасом собираемых знаний и материалом для обсуждений поSkype. В первом и третьем проекте алгоритм слияния выполнялся чаще, поскольку менеджер проекта часто бывал в командировках, в том числе, у заказчика проекта; именно у менеджера происходили обрывы Интернетсоединения во время работы, и он выполнял процедуру слияния и-карт. Продолжение работы над и-картами в режиме отсутствия Интернет-соединенияпроисходило после общения с заказчиком, поскольку требовалось формализовать полученную информацию.
В это же время команда активно изучалавозможности реализации проекта и также работала над и-картой. Необходимость параллельной работы следовала из сжатых сроков для данного видаработ. В целом, несмотря на то, что предложенный алгоритм слияния запускался относительно нечасто, его наличие, по мнению разработчиков анализируемых проектов, обеспечивало надёжность процесса и собираемых данных.Наличие фактора надёжности часто является одним из решающих при выборе тех или иных инструментов разработки программного обеспечения.1463.3 Метод контроля качества предметно-ориентированных спецификацийПредлагаемый метод ориентирован на проекты, в которых создаются и интенсивно изменяются большие предметно-ориентированные модели, приэтом разработкой и сопровождением таких моделей занимается значительный коллектив аналитиков и разработчиков (от 5 до 30 человек).
Также важно, что у моделей имеется большой жизненный цикл — до10–20 и более лет.Мы рассматриваем случай, когда к таким моделям предъявляют повышенныетребования по корректности, то есть модели являются одним из центральныхартефактов разработки и используются для генерации конечного кода или вдругих формальных процедурах. Такие ситуации встречаются при разработкесемейств программных продуктов, когда модели повторно используемых активов могут существовать и модифицироваться в течение всего жизненногоцикла линейки, при этом по ним генерируется конечный код (на наличие повышенных требований к корректности моделей при их использовании в генерации кода указывалось, например, в [145]). Большие модели с повышенными требованиями к корректности часто создаются в рамках разработки ИТархитектуры крупных компаний, являются объёмными, сопровождаются иизменяются большим количеством архитекторов; при этом требования к корректности имеют здесь дополнительный источник — строгие регламентымоделирования.
Следует отметить, чтодалеко не все проекты, использую-щие модельно-ориентированный подход, удовлетворяют этим требованиям.Например, модели анализа часто имеют облегчённые требования по корректности, хотя и при их разработке задача поиска ошибок является актуальной[197]. Также следует отметить, что эскизное моделирование [148] не требуетдополнительных усилий для обеспечения корректности моделей. Таким образом, с одной стороны, высоки требования к корректности моделей в описанной выше ситуации, с другой стороны, в этих моделях делаются многочисленные ошибки.
Для решения этой проблемы целесообразно предприни147мать специальные усилия с тем, чтобы ошибки в таких моделях не накапливать — цена исправления ошибки увеличивается по мере увеличения её возраста.Ещё одним обстоятельством, затрудняющим поддержку корректностибольших моделей, являются трудности автоматизации этого процесса. Дажеесли применяется стандартный язык моделирования — UML, BPMN и пр., —и, соответственно, стандартные средства моделирования, то при использовании кодогенерационного подхода появляется большое количество дополнительных правил, соглашений и пр., налагаемых на модели, но не выраженныхсредствами языка визуального моделирования, или выраженных в виде примечаний, свойств и неструктурированного текста.
Соответственно, все этидополнительные ограничения не контролируются средой разработки — тоесть средствами моделирования, — и, следовательно, могут не соблюдатьсяразработчиками и приводить к ошибкам, которые обнаруживаются на следующих за моделированием этапах разработки43. При использовании предметно-ориентированного подхода на основе таких DSM-платформ как MetaEdit+[346], Microsoft Modeling SDK[213] или GMF [398], которые генерируют целевой графический редактор по метамодели, с помощью метамодели неудобно задавать все особенности языка моделирования: даже для небольших языков моделирования точная метамодель зачастую оказывается неоправданнобольшой. Поэтому общепринятой практикой является создание избыточныхметамоделей и наложение на них различных локальных ограничений с помощью декларативного языка OCL [362] — например, многочисленные OCLограничения к разным метамоделям подробно рассмотрены в работе [205].Соответственно, особенности языка, не отражённые в метамодели, не могут43Здесь можно провести некоторые параллели со средствами поддержки языков программирования — компиляцией и выявлением при этом различных ошибок, подсветкой синтаксиса и пр.
возможностями, предоставляемыми обычными средствами разработки. И когда, например, в программе используется несколькоязыков, то возникает задача обеспечения всех этих языков соответствующими средствами. При этом такиесредства стараются обеспечить даже в случае динамически формируемых фрагментов — см. исследования[20], [264].
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
