Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

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

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

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

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

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

Примеры в программной инженерии [ править ]

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

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

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

  • JavaScript Class Creator [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 .