Войти
Инжиниринг туда и обратно (RTE ) - это функция разработки программного обеспечения tools, который синхронизирует два или более связанных программных артефакта, таких как исходный код, модели, файлы конфигурации и даже документация. Потребность в проектировании с двусторонним обращением возникает, когда одна и та же информация присутствует в нескольких артефактах, и поэтому может возникнуть несогласованность, если не все артефакты последовательно обновляются для отражения данного изменения. Например, некоторая часть информации была добавлена / изменена только в одном артефакте, и в результате она стала отсутствовать / несовместима с другими артефактами.
Инжиниринг туда и обратно тесно связан с традиционными дисциплинами программной инженерии : прямой инжиниринг (создание программного обеспечения из спецификаций), обратный инжиниринг (создание спецификаций из существующего ПО), и реинжиниринг (понимание существующего программного обеспечения и его модификация). Инжиниринг туда и обратно часто ошибочно определяется как просто поддержка как прямого, так и обратного проектирования. Фактически, ключевой характеристикой двустороннего проектирования, которая отличает его от прямого и обратного проектирования, является способность синхронизировать существующие артефакты, которые развивались одновременно, путем постепенного обновления каждого артефакта для отражения изменений, внесенных в другие артефакты. Более того, прямое проектирование можно рассматривать как особый экземпляр RTE, в котором присутствует только спецификация, а обратное проектирование можно рассматривать как особый экземпляр RTE, в котором присутствует только программное обеспечение. Многие действия по реинжинирингу также можно понимать как RTE, когда программное обеспечение обновляется для отражения изменений, внесенных в ранее разработанную спецификацию.
Еще одна характеристика технологии двустороннего обмена - автоматическое обновление артефактов в ответ на автоматически обнаруженные несоответствия. В этом смысле он отличается от прямого и обратного проектирования, который может быть как ручным (традиционно), так и автоматическим (посредством автоматической генерации или анализа артефактов). Автоматическое обновление может быть мгновенным или по запросу. В мгновенном RTE все связанные артефакты немедленно обновляются после каждого изменения одного из них. В RTE по требованию авторы артефактов могут одновременно развивать артефакты (даже в распределенной среде) и в какой-то момент выбрать выполнение сопоставления для выявления несоответствий и выбрать распространение некоторых из них и урегулирование потенциальных конфликтов.
Инжиниринг туда и обратно поддерживает итеративный процесс разработки. После того, как вы синхронизировали свою модель с исправленным кодом, вы по-прежнему можете выбрать лучший способ работы - внести дальнейшие изменения в код или внести изменения в свою модель. Вы можете синхронизировать в любом направлении в любое время и можете повторять цикл столько раз, сколько необходимо.
Возможно, наиболее распространенной формой проектирования в оба конца является синхронизация между моделями UML (Unified Modeling Language ) и соответствующим исходным кодом. Многие коммерческие инструменты и исследовательские прототипы поддерживают эту форму RTE; в книге 2007 года перечислены Rational Rose, Micro Focus Together, BlueJ и среди тех, кто способен, при этом Fujaba, как утверждается, способна также идентифицировать шаблоны проектирования. Обычно диаграммы классов UML в той или иной степени поддерживаются; однако некоторые концепции UML, такие как ассоциации и включение, не имеют прямого представления на многих языках программирования, что ограничивает удобство использования созданного кода и точность анализа кода (например, в коде трудно распознать включение). В книге 2005 года по Visual Studio отмечается, например, что общая проблема инструментов RTE заключается в том, что реверсированная модель не такая же, как исходная, если только инструменты не сопровождаются трудоемкими аннотациями. Поведенческие части UML создают еще больше проблем для RTE.
Более управляемая форма двустороннего проектирования реализуется в контексте инфраструктуры интерфейсов прикладного программирования (API), посредством чего синхронизируется модель, описывающая использование API инфраструктуры приложением. с кодом этого приложения. В этом параметре API предписывает все правильные способы использования платформы в приложениях, что позволяет точно и полностью обнаруживать использование API в коде, а также создавать полезный код, реализующий правильное использование API. Двумя известными реализациями RTE в этой категории являются языки моделирования для конкретной среды и Spring Roo.
Конструирование туда и обратно критически важно для поддержания согласованности между несколькими моделями и между моделями и кодом в <17.>Группа управления объектами (OMG) Архитектура, управляемая моделями. OMG предложила стандарт QVT (запрос / просмотр / преобразование) для обработки преобразований модели, необходимых для MDA. На сегодняшний день создано несколько реализаций стандарта. (Необходимо представить практический опыт работы с MDA применительно к RTE).
Для разработки программного обеспечения на основе Unified Modeling Language (UML) требуются три основных компонента:
Пример базового двустороннего проектирования доступен в виде веб-инструмента с открытым исходным кодом:
