Диссертация (1148239), страница 15
Текст из файла (страница 15)
Это единственный способ для других компонент узнать обизменениях в рабочей копии.Как показано на рис. 16, интерфейс плагина инструмента версионированияVersioningPluginInterface унаследован от трех других интерфейсов. Таким образом,каждый плагин, реализующий поддержку какой-либо VCS, должно состоять из трехчастей.●Функционал обычного плагина инструмента.●Реализация интерфейса инспектора WorkingCopyInspectionInterface. Например,в случае поддержки subversion метод onFileAdded() будет вызывать командуsvn add, а onFileRemoved() — команду svn remove.●РеализацияинтерфейсаабстрактнойVCS:BriefVersioningInterface,получениерабочейкопиисодержащегосудаленногооперациисервера,синхронизация рабочей копии с сервером, откат к выбранной версии и т.п.Этот интерфейс, по сути, и есть API плагинов версионирования, используемыйдругими компонентами в рамках графического интерфейса пользователя.Для удобства выполнения внешних команд над клиентами систем контроляверсийвмодулеqrutilsбылреализованклассExternalClientPluginBase,инкапсулирующий в себе механизм общения с внешними процессами, выдаваянаружу только методы по синхронному/асинхронному запуску этих процессов.88На основе модуля версионирования был реализован механизм визуальногоотображенияизмененийвыбраннойдиаграммымеждурабочейкопиейиопределенной версией на сервере.
Сравнение осуществляется следующим образом.После выбора интересующей проектировщика версии она загружается с сервера вовременную директорию, создается новый экземпляр репозитория, в которой изагружается полученная с сервера версия проекта. После этого имеется двезагруженные в память модели, которые сравниваются поэлементно: через методырепозитория можно запросить информацию обо всех элементах, их свойствах и т.п.При этом стадия сопоставления является тривиальной, поскольку каждому элементув репозитории присвоен уникальный идентификатор, не изменяющийся напротяжении всей жизни объекта.Когда построение модели разницы завершается, отображается окно, нагляднодемонстрирующее изменения между диаграммами (см. рис.
17). Левая часть окнаотображает диаграмму, хранящуюся на сервере, правая — в рабочей копии.Элементы на диаграммах подсвечены в соответствии с их состоянием. Состояниеможет быть одним из следующих: “добавлено”, “удалено”, “изменено” или “безизменений”. На рисунке удаленные и добавленные элементы подсвечены зеленымцветом, модифицированные — оранжевым (цвета, соответствующие состояниям,могут быть изменены в диалоговом окне настроек QReal).Изменение значений свойств, не отображаемых визуально на диаграмме, можноотследить на вкладках в нижней части окна.89Рисунок 87. Окно визуального сравнения версий диаграммы5.4.5. Отладчики и интерпретаторы моделейДля поведенческих языков, описывающих систему в динамике (например,диаграммы деятельности UML 2 или язык блок-схем), очень полезными могут бытьотладчики и интерпретаторы, работающие на уровне моделей. Подобныеинструменты позволяют разработчику наглядно проследить ход работы заданногоим алгоритма и либо убедиться в его корректности, либо внести нужные изменения.Семантика таких языков обычно основывается на понятии токена исполнения иформализуется с помощью сетей Петри, причём класс поведенческих языковдостаточно широк, чтобы стоило потратить усилия на формализацию их семантики(например, упоминавшиеся выше диаграммы деятельности UML 2 и блок-схемыимеют именно такую семантику).90В QReal в данном направлении реализовано несколько инструментов.●Интерпретатормоделей, позволяющийпошагово«исполнять» модель,подсвечивая текущий блок и отображая текущие состояния переменных, еслиэто применимо для данного языка.●Отладчик сгенерированного кода с привязками к диаграммам.Описанные инструменты были реализованы «вручную» в виде плагиновинструментов QReal, однако в дальнейшем создание интерпретаторов былоавтоматизировано путем описания операционной семантики разрабатываемого языка(как описано в главе 4).Создание отладчиков моделей с привязкой к отладке исходного кода все ещёостается неавтоматизированной задачей ввиду большого числа целевых языковгенерации и существующих отладчиков/интерпретаторов для них.5.4.6.
Генераторы кодаВизуальные модели могут использоваться практически на всех этапахжизненного цикла: для фиксирования знаний при сборе и анализе требований, вкачестве наглядного материала при общении с пользователями и заказчиками, придекомпозиции задач разработчиками и т.п. Основное требование к такимдиаграммам — наглядность и понятность.
Однако, многие желают пойти дальше ииспользовать знания о предметной области и разрабатываемой системе, отраженныев моделях, для того, чтобы автоматически (или хотя бы автоматизированно)получать по ним программный или тестирующий код, скрипты сборки илиустановки, документацию и т.д. Построение подобных артефактов разработки помоделям — задача генераторов.С архитектурной точки зрения генераторы в QReal могут быть внутренние ивнешние. Внутренние генераторы реализованы в виде плагина инструментов,динамически подгружаются в QReal и могут через стандартные интерфейсывоздействовать на графический интерфейс пользователя (например, отображать91сгенерированный код в отдельной вкладке, отображать сообщения об ошибкахсредствами QReal и т.п.). Внешние генераторы реализуются и запускаются какотдельные приложения и никак не связаны с платформой QReal.
Возможностьсоздавать такие генераторы может быть полезна, если разработчик по каким-топричинам выбирает язык программирования, отличный от C++.Независимоот типагенератора получение данныхпроисходитчерезинтерфейсы логической (и, реже, графической) моделей репозитория. В случаегенератора, реализованного на отличном от C++ языке программирования,взаимодействие с библиотекой репозитория может происходить, например,посредством инструментария ZeroC ICE [2], обеспечивающего взаимодействие кодана различных языках программирования.В области модельно-ориентированной разработки с генераторами кода тесносвязан вопрос о возможности циклической разработки (round-trip engineering [55]).Основная проблема, решаемая данным подходом, — синхронизация изменений,внесенных в сгенерированный код, с исходными моделями.
Эта задача далеко нетривиальна, и разработчики практически каждого инструмента моделированиявынуждены как-то решать ее для себя [54]. Однако, как было описано в главе 1,предметно-ориентированное моделирование постулирует отказ от «ручного»изменения сгенерированного кода — проектировщик ведет работу только смоделями,покоторымавтоматическигенерируетсякод,нетребующийпоследующих изменений. При необходимости внести в получаемый исходный кодизменениянеобходимолибопоправитьисходнуюмодельипроизвестиперегенерацию кода (если это логическое изменение), либо исправить генераторкода (если требуемое изменение — это исправление ошибки), либо если в языке нехватает выразительных средств для описания требуемого изменения — поднятьвопрос о расширении языка и инструментов, поддерживающих его.Для платформы QReal существует несколько механизмов для упрощения92процесса создания генераторов кода.
Один из них основан на специализированномтекстовом языке [38, 39], позволяющем описывать логику генерации. Это позволяетускорить процесс создания генератора, однако всё еще требует от пользователясерьёзных навыков программирования. Другой способ создания генераторовподразумевает задание исполнимой семантики языка (см. главу 4). Генератор в этомслучае по сути является интерпретатором, обходящим (возможно неоднократно)диаграммы, на каждом элементе осуществляя запись исходного кода в выходнойфайл.5.4.7. Механизм рефакторингов моделейРефакторинг определяют как изменение внутренней структуры системы длятого, чтобы сделать ее проще для понимания и внесения изменений.
При этомвнешнее поведение такой системы не должно меняться. При переносе уровняабстракции с кода на визуальные модели имеет смысл перенести на уровень моделейи понятие рефакторинга. Рефакторинг на уровне моделей является довольномолодой областью знания, многие вопросы в ней остаются открытыми длядальнейших исследований. В настоящее время очень немногие инструментарииспособны осуществлять интегрированную поддержку рефакторинга моделей (см.главу 2). Кроме того, класс моделей, для которых реализована поддержкарефакторинга, весьма ограничен: чаще всего исследования ведутся применительнолишь к диаграммам классов UML.В настоящее время вопрос организации рефакторингов моделей в QReal все ещеисследуется, однако уже сейчас реализована инфраструктура и несколько примеровавтоматического преобразования моделей: групповое изменение имени элементов,инвертирование выбранных связей на диаграмме, выделение набора элементов вподпрограмму и некоторые другие. Несложно заметить, что практически все этирефакторинги применимы для произвольных языков.С точки зрения пользователя процесс применения рефакторинга выглядит93следующим образом: с помощью соответствующего пункта меню необходимооткрыть окно рефакторингов в QReal и выбрать интересующее правило (см.
рис. 18).Правило представляется в виде левой и правой части, между которыми находитсястрелка, символизирующая преобразование модели. Левая часть задает шаблонпоиска элементов в моделях, а правая часть описывает то, во что преобразуетсяэлемент (или группа элементов для более сложных правил), подходящий под шаблонлевой части.Нажатие кнопки “Найти” приводит к поиску элементов, подходящих подшаблон левой части правила. Если было найдено хотя бы одно соответствие,становится активной кнопка “Применить”, которая осуществляет выбранноепреобразование модели.Рисунок 18.
Окно применения рефакторингов в QRealС архитектурной точки зрения модуль применения рефакторингов представленотдельнымплагиноминструментовQReal.Правилаявляютсяотдельнымидиаграммами, хранящимися в репозитории. Для осуществления поиска по моделямиспользуется базовый механизм трансформации графов QReal, вынесенный в модульqrutls (данный механизм используются и другими модулями QReal, например, привыполнении правил исполнимой семантики языка).945.4.8. Механизм проверки правил ограниченийНесмотря на то, что визуальные программы в большинстве своем нагляднее ипроще для понимания, чем текстовые, модели также могут содержать в себе ошибки.Часть ошибок могут быть синтаксическими (например, из элемента “Начало”диаграмм деятельности UML должна выходить только один связь, и не должновходить ни одной), так и семантическими (поле “Возраст” элемента “Человек” недолжно быть отрицательным).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
