Круглосуточный инжиниринг

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

Обзор [ править ]

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

Типы [ править ]

В различных книгах описываются два типа RTE: ^[2]^: 459

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

Автоматическая синхронизация [ править ]

Еще одной особенностью комплексного проектирования является автоматическое обновление артефактов в ответ на автоматически обнаруженные несоответствия. В этом смысле он отличается от прямого и обратного проектирования, которое может быть как ручным (традиционно), так и автоматическим (посредством автоматического создания или анализа артефактов). Автоматическое обновление может быть мгновенным или по требованию . При мгновенном 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) требует трех основных инструментов для разработки программного обеспечения: ^{[ нужна цитата ]}

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

Ссылки [ править ]

^ Нежный, Энн (2012). Разговор и сообщество: Социальная сеть для документации (2-е изд.). XML Пресс. ISBN 978-1937434106 .
^ Собх, Тарек М. (2008). Достижения в области компьютерных и информационных наук и техники . Международная конференция по системам, вычислительным наукам и программной инженерии. Нью-Йорк?: Спрингер. ISBN 978-1-4020-8741-7 .
^ Стефан Диль (2007). Визуализация программного обеспечения: визуализация структуры, поведения и эволюции программного обеспечения . Springer Science & Business Media. п. 63. ИСБН 978-3-540-46505-8 .
^ Андрей Филев; Тони Лотон; Кевин Макниш; Бен Шёлльманн; Джон Слейтер; Чаур Г. Ву (2005). Профессиональный UML с использованием Visual Studio .Net . Джон Уайли и сыновья. п. 181. ИСБН 978-0-7645-5875-7 .
^ http://www.developerdotstar.com/mag/articles/reeves_design_main.html Джека В. Ривза
^ Ривз, Джек В. (1992). «Что такое программная инженерия» . www.bleading-edge.com . Журнал С++ . Проверено 25 июля 2023 г.
^ "Помощь -" . www.modeliosoft.com . Проверено 25 июля 2023 г.
^ Перейти обратно: ^а ^б Сигл, Дэниел. «Почему двустороннее проектирование не работает | LieberLieber Modeling Expert» . Проверено 25 июля 2023 г.
^ Перейти обратно: ^а ^б ^с «8 причин, почему подходы, основанные на моделях, терпят неудачу» . ИнфоQ . Проверено 29 июля 2023 г.

[1] Нежный, Энн (2012). Разговор и сообщество: Социальная сеть для документации (2-е изд.). XML Пресс. ISBN 978-1937434106 .

[2] Собх, Тарек М. (2008). Достижения в области компьютерных и информационных наук и техники . Международная конференция по системам, вычислительным наукам и программной инженерии. Нью-Йорк?: Спрингер. ISBN 978-1-4020-8741-7 .

[Diehl2007-3] Стефан Диль (2007). Визуализация программного обеспечения: визуализация структуры, поведения и эволюции программного обеспечения . Springer Science & Business Media. п. 63. ИСБН 978-3-540-46505-8 .

[FilevLoton2005-4] Андрей Филев; Тони Лотон; Кевин Макниш; Бен Шёлльманн; Джон Слейтер; Чаур Г. Ву (2005). Профессиональный UML с использованием Visual Studio .Net . Джон Уайли и сыновья. п. 181. ИСБН 978-0-7645-5875-7 .

[5] ttp://www.developerdotstar.com/mag/articles/reeves_design_main.html Джека В. Ривза

[6] Ривз, Джек В. (1992). «Что такое программная инженерия» . www.bleading-edge.com . Журнал С++ . Проверено 25 июля 2023 г.

[7] "Помощь -" . www.modeliosoft.com . Проверено 25 июля 2023 г.

[:0-8] Перейти обратно: ^а ^б Сигл, Дэниел. «Почему двустороннее проектирование не работает | LieberLieber Modeling Expert» . Проверено 25 июля 2023 г.

[:1-9] Перейти обратно: ^а ^б ^с «8 причин, почему подходы, основанные на моделях, терпят неудачу» . ИнфоQ . Проверено 29 июля 2023 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]