WikiDer > Техника туда и обратно

Round-trip engineering

Техника туда и обратно (RTE) - это функциональность инструменты разработки программного обеспечения который синхронизирует два или более связанных программных артефакта, например, исходный код, модели, файлы конфигурации и даже документацию.[1] Потребность в проектировании туда и обратно возникает, когда одна и та же информация присутствует в нескольких артефактах, и поэтому может возникнуть несогласованность, если не все артефакты согласованно обновляются для отражения данного изменения. Например, некоторая часть информации была добавлена ​​/ изменена только в одном артефакте, и в результате она стала отсутствовать / несовместима с другими артефактами.

Техника туда и обратно тесно связана с традиционными программная инженерия дисциплины: перспективный инжиниринг (создание программного обеспечения по спецификациям), обратный инжиниринг (создание спецификаций из существующего программного обеспечения), и реинжиниринг (понимание существующего программного обеспечения и его модификация). Инжиниринг туда и обратно часто ошибочно определяют как просто поддержку как прямого, так и обратного проектирования. Фактически, ключевая характеристика двустороннего проектирования, которая отличает его от прямого и обратного проектирования, - это способность синхронизировать существующий артефакты, которые эволюционировали одновременно от постепенно обновление каждого артефакта для отражения изменений, внесенных в другие артефакты. Более того, прямое проектирование можно рассматривать как особый экземпляр RTE, в котором присутствует только спецификация, а обратное проектирование можно рассматривать как особый экземпляр RTE, в котором присутствует только программное обеспечение. Многие действия по реинжинирингу также можно понимать как RTE, когда программное обеспечение обновляется для отражения изменений, внесенных в ранее разработанную спецификацию.

Еще одна характеристика техники с двусторонним обходом: автоматический обновление артефактов в ответ на автоматически обнаруженные несоответствия. В этом смысле он отличается от прямого и обратного инжиниринга, который может быть как ручным (традиционно), так и автоматическим (посредством автоматической генерации или анализа артефактов). Автоматическое обновление может быть либо мгновенный или на лету. В мгновенном RTE все связанные артефакты немедленно обновляются после каждого изменения, внесенного в один из них. В RTE по требованию авторы артефактов могут одновременно развивать артефакты (даже в распределенной среде) и в какой-то момент выбрать выполнение сопоставления для выявления несоответствий и выбрать распространение некоторых из них и урегулирование потенциальных конфликтов.

Инжиниринг туда и обратно поддерживает итеративный процесс разработки. После того, как вы синхронизировали свою модель с исправленным кодом, вы по-прежнему можете выбрать лучший способ работы - внести дальнейшие изменения в код или внести изменения в свою модель. Вы можете синхронизировать в любом направлении в любое время и можете повторять цикл столько раз, сколько необходимо.

Примеры проектирования в оба конца

Возможно, наиболее распространенной формой двустороннего проектирования является синхронизация между UML (Единый язык моделирования) модели и соответствующий исходный код. Многие коммерческие инструменты и исследовательские прототипы поддерживают эту форму RTE; списки книг 2007 года Рациональная роза, Micro Focus вместе, ESS-Модель, BlueJ, и Фуджаба среди тех, кто способен, причем Фуджаба, как говорят, может также идентифицировать шаблоны проектирования.[2] Обычно диаграммы классов UML в той или иной степени поддерживаются; однако некоторые концепции UML, такие как ассоциации и сдерживание не имеют прямого представления на многих языках программирования, что ограничивает удобство использования созданного кода и точность анализа кода (например, в коде трудно распознать локализацию). Книга 2005 года о Visual Studio отмечает, например, что общая проблема в инструментах RTE заключается в том, что реверсированная модель не такая же, как исходная, если только инструментам не помогают трудоемкие аннотации.[3] Поведенческие части UML создают еще больше проблем для RTE.

В контексте фреймворка реализована более удобная форма двустороннего проектирования. интерфейсы прикладного программирования (API), посредством чего модель, описывающая использование API фреймворка приложением, синхронизируется с кодом этого приложения. В этой настройке API предписывает все правильные способы использования платформы в приложениях, что позволяет точно и полностью определять использование API в коде, а также создавать полезный код, реализующий правильное использование API. Две известные реализации RTE в этой категории: языки моделирования для конкретных платформ и Spring Roo.

Инжиниринг в оба конца имеет решающее значение для поддержания согласованности между несколькими моделями, а также между моделями и кодом в Группа управления объектами(OMG) Модельно-управляемая архитектура. OMG предложила QVT (запрос / просмотр / преобразование) стандарт для обработки преобразований модели, необходимых для MDA. На сегодняшний день создано несколько реализаций стандарта. (Необходимо представить практический опыт использования MDA применительно к RTE).

Примеры в программной инженерии

Инжиниринг туда и обратно на основе Единый язык моделирования (UML) требует трех основных компонентов для разработки программного обеспечения:[нужна цитата]

  • Редактор исходного кода;
  • Редактор UML для атрибутов и методов;
  • Визуализация структуры UML.

Пример базовой двусторонней разработки доступен в виде веб-инструмента с открытым исходным кодом:[нужна цитата]

  • Создатель классов JavaScript[4] позволяет интегрировать двустороннюю инженерию для классов JavaScript. UML Диаграммы создаются с помощью библиотеки диаграмм JointJS.[5] Редактирование исходного кода Javascript осуществляется с помощью редактора ACE.[6]

использованная литература

  1. ^ Нежный, Энн (2012). Разговор и сообщество: социальная сеть для документации (2-е изд.). XML Press. ISBN 978-1937434106.
  2. ^ Стефан Диль (2007). Визуализация программного обеспечения: визуализация структуры, поведения и эволюции программного обеспечения. Springer Science & Business Media. п. 63. ISBN 978-3-540-46505-8.
  3. ^ Андрей Филев; Тони Лотон; Кевин Макниш; Бен Шёлльманн; Джон Слейтер; Чаур Г. Ву (2005). Профессиональный UML с использованием Visual Studio .Net. Джон Вили и сыновья. п. 181. ISBN 978-0-7645-5875-7.
  4. ^ Создатель классов JavaScript, GitHub.
  5. ^ JointJS, GitHub.
  6. ^ ACE.