Круговая инженерия ( RTE ) в контексте архитектуры на основе моделей — это функциональная возможность инструментов разработки программного обеспечения , которая синхронизирует два или более связанных программных артефакта, таких как исходный код, модели , файлы конфигурации, документация и т. д. между собой. [1] Необходимость в круговой инженерии возникает, когда одна и та же информация присутствует в нескольких артефактах и когда может возникнуть несоответствие в случае обновления некоторых артефактов. Например, некоторая часть информации была добавлена/изменена только в одном артефакте (исходном коде) и, как следствие, она стала отсутствовать/несогласованной с другими артефактами (в моделях).
Круговая инженерия тесно связана с традиционными дисциплинами программной инженерии : прямой инженерией (создание программного обеспечения на основе спецификаций), обратной инженерией (создание спецификаций на основе существующего программного обеспечения) и реинжинирингом (понимание существующего программного обеспечения и его изменение). Круговая инженерия часто ошибочно определяется как просто поддержка как прямой, так и обратной инженерии. Фактически, ключевой характеристикой круговой инженерии, которая отличает ее от прямой и обратной инженерии, является возможность синхронизировать существующие артефакты, которые развивались одновременно , путем постепенного обновления каждого артефакта для отражения изменений, внесенных в другие артефакты. Кроме того, прямую инженерию можно рассматривать как особый случай RTE, в котором присутствует только спецификация, а обратную инженерию можно рассматривать как особый случай RTE, в котором присутствует только программное обеспечение. Многие виды реинжиниринга также можно понимать как RTE, когда программное обеспечение обновляется для отражения изменений, внесенных в ранее реверсивно спроектированную спецификацию.
В различных книгах описываются два типа RTE: [2] : 459
Другой характеристикой круговой разработки является автоматическое обновление артефактов в ответ на автоматически обнаруженные несоответствия. В этом смысле она отличается от прямой и обратной разработки, которые могут быть как ручными (традиционно), так и автоматическими (через автоматическую генерацию или анализ артефактов). Автоматическое обновление может быть как мгновенным , так и по требованию . В мгновенной RTE все связанные артефакты немедленно обновляются после каждого изменения, внесенного в один из них. В RTE по требованию авторы артефактов могут одновременно обновлять артефакты (даже в распределенной среде) и в какой-то момент выбирать выполнение сопоставления для выявления несоответствий и выбирать распространение некоторых из них и урегулирование потенциальных конфликтов.
Круговая инженерия может включать итеративный процесс разработки. После синхронизации модели с измененным кодом вы по-прежнему можете выбрать наилучший способ работы — вносить дальнейшие изменения в код или вносить изменения в модель. Вы можете синхронизироваться в любом направлении в любое время и можете повторять цикл столько раз, сколько необходимо.
Многие коммерческие инструменты и исследовательские прототипы поддерживают эту форму RTE; в книге 2007 года перечислены Rational Rose , Micro Focus Together , ESS-Model, BlueJ и Fujaba среди тех, кто способен на это, причем Fujaba, как утверждается, также способна определять шаблоны проектирования . [3]
В книге 2005 года по Visual Studio , например, отмечается, что распространенной проблемой инструментов RTE является то, что обратная модель не совпадает с исходной, если только инструменты не помогают, оставляя трудоемкие аннотации в исходном коде. [4] Поведенческие части UML создают еще больше проблем для RTE.
Обычно диаграммы классов UML поддерживаются в некоторой степени; однако некоторые концепции UML, такие как ассоциации и включение, не имеют прямого представления во многих языках программирования, что ограничивает удобство использования созданного кода и точность анализа кода/обратной разработки (например, включение трудно распознать в коде).
Более гибкая форма круговой инженерии реализуется в контексте интерфейсов прикладного программирования (API) фреймворка, в которых модель, описывающая использование API фреймворка приложением, синхронизируется с кодом этого приложения. В этой настройке API предписывает все правильные способы использования фреймворка в приложениях, что позволяет точно и полностью обнаруживать использование API в коде, а также создавать полезный код, реализующий правильное использование API. Две выдающиеся реализации RTE в этой категории — это языки моделирования, специфичные для фреймворка , и Spring Roo (Java).
Круговая инженерия имеет решающее значение для поддержания согласованности между несколькими моделями, а также между моделями и кодом в архитектуре на основе моделей Object Management Group (OMG) . OMG предложила стандарт QVT (запрос/представление/преобразование) для обработки преобразований моделей, необходимых для MDA. На сегодняшний день [ когда? ] было создано несколько реализаций стандарта. (Необходимо представить практический опыт работы с MDA в отношении RTE).
Генерация кода (прямая разработка) из моделей означает, что пользователь абстрактно моделирует решения, которые подразумеваются некоторыми данными модели, а затем автоматизированный инструмент выводит из моделей части или весь исходный код для программной системы. В некоторых инструментах пользователь может предоставить скелет исходного кода программы в форме шаблона исходного кода, где предопределенные токены затем заменяются частями исходного кода программы в процессе генерации кода.
Спецификация диаграмм UML (если она используется для MDA) критиковалась за отсутствие детализации, необходимой для того, чтобы содержать ту же информацию, которая содержится в исходном коде программы. Некоторые разработчики даже утверждают, что «Код — это дизайн». [5] [6]
Существует серьезный риск того, что сгенерированный код будет быстро отличаться от модели или что реверсивная модель потеряет свое отражение в коде или возникнет сочетание этих двух проблем в результате циклических усилий по реинжинирингу. [7]
Что касается поведенческой/динамической части UML для таких функций, как диаграмма состояний, то в языках программирования нет эквивалентов. Их перевод во время генерации кода приведет к тому, что общее выражение программирования (например, if,switch,enum) будет либо отсутствовать, либо будет неверно истолковано. Если его отредактировать и импортировать обратно, это может привести к другой или неполной модели. [8] [9] То же самое касается фрагментов кода, используемых на этапе генерации кода для реализации шаблона и пользовательской логики: смешанные, они не могут быть легко реверсированы обратно. [8] [9]
Также наблюдается общая нехватка передовых инструментов для моделирования, сопоставимых с инструментами современных IDE (для тестирования, отладки, навигации и т. д.) для языков программирования общего назначения и предметно-ориентированных языков . [9]
Пожалуй, наиболее распространенной формой круговой разработки является синхронизация между моделями UML ( унифицированный язык моделирования ) и соответствующим исходным кодом, а также диаграммами «сущность-связь» в моделировании данных и моделировании баз данных .
Круговая инженерия на основе унифицированного языка моделирования (UML) требует трех основных инструментов для разработки программного обеспечения: [ необходима ссылка ]