Диссертация (Платформа для создания специализированных визуальных сред разработки программного обеспечения), страница 5

Получаемая на этом уровне модель содержит всю техническуюинформацию, необходимую для генерации кода и других целевых артефактовразработки.Также MDA выделяет модель платформы, содержащую в себе набортехническихописанийпредоставляемыхеюсоставляющихприложениям.частейМодельплатформыплатформыисервисов,используетсяприпреобразовании модели PIM в модель PSM.Ввиду общности методологии все модели в MDA рекомендуется создавать спомощью унифицированного языка моделирования UML.Процесс преобразования моделей и роли, осуществляющие изменения моделейна каждом этапе, отражены на рис.

1.MDA определяет целый ряд способов преобразования моделей, правилапреобразования моделей рекомендуется задавать с помощью языка, описанногостандартом QVT (Query/View/Transformation) [136]. Преобразования могут бытьпараметризованы, что позволит подстраивать их под нужды конкретных проектов.Создано большое количество средств разработки, поддерживающих MDA1, вкоторых процесс преобразования моделей максимально автоматизирован.1Например, Enterprise Architect, Rhapsody, Rational Software Architect, UModel и другие24Рисунок 1.

Преобразование моделей в MDA2Рассмотренный подход к разработке ПО несомненно имеет свои преимущества:минимизацияресурсовпопереносуприложениянадругуюплатформу,потенциальная независимость моделей от средств разработки, автоматизация ичеткая структуризация процесса разработки. Однако, существенным, на наш взгляд,недостатком предлагаемого подхода является то, что каждый переход от одноймодели к другой (и переход от моделей к коду) может сопровождатьсянеобходимостью внесения “ручных” изменений в модели или получаемый исходныйкод.

Для разработчика системы это означает следующее:●Итеративный подход к разработке возможен только в случае, еслииспользуемыеинструментальныесредстваподдерживаютмеханизмциклической разработки ПО (round-trip engineering), при котором возможенвозврат к предыдущему этапу разработки, и перегенерация моделей или кода сучетом «ручных» изменений, сделанных на предыдущей итерации.●Даже если 90% кода или промежуточных моделей получается автоматическипосредством используемогоинструментария, длятого,чтобывнестиоставшиеся 10% изменений, требуется разбираться со сгенерированными2Рисунок взят из работы [80]25артефактами, что в случае большого проекта может быть крайне сложнойзадачей.1.5.

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

Однако практика показала, что создание графическихспецификаций при разработке ПО не является принципиально более простым илибыстрым процессом, чем программирование на текстовых языках — на низкомуровне проектировщик также оперирует абстрактными понятиями типа циклов,операторов, условных переходов. Разумеется, использование визуальных моделейдает свои преимущества по сравнению с текстом — большая наглядность,возможность построения иерархии моделей и быстрое переключение междууровнями абстракции системы (при соответствующей поддержке инструментальныхсредств), — однако существенного повышения уровня производительностиразработчиков при этом не происходит.

Существующие немногочисленныеисследования показывают 35% повышение производительности труда [121], в товремя как некоторые из них не отмечают никакого роста производительности вовсе,а иногда даже и ее снижение [66, 81]. На наш взгляд, это вызвано следующимипричинами.Любая модель — упрощение того, что эта модель описывает. В случае MDE,модель — упрощенное представление того, как проектировщик понимаетразрабатываемую программную систему. Это вполне ожидаемо, поскольку модельпо определению должна быть проще моделируемой сущности, однако из-за этого26при переходе к формальным спецификациям определенная часть знаний о системетеряется, образуя семантический разрыв между идеей и её реализацией. Однако,обладая неполной информацией, инструментальные средства оказываются не всостоянии сгенерировать полноценный код по создаваемым моделям.

Требованиеавтоматической генерации кода по моделям на языках общего назначения влечёт засобой серьёзное усложнение описаний систем, что приводит к нежеланиюразработчиков работать с подобными моделями и инструментами.Кпримеру,впопыткахпревратитьUMLвполноценныйязыкпрограммирования3 для описания алгоритмов стали использовать диаграммыдеятельности (activity diagrams).

Язык UML является языком общего назначения, азначит, оперирует практически теми же сущностями, что и текстовые языкипрограммирования, однако текстовые программы являются более компактными, чемсоответствующие им диаграммы активностей. При детальном описании системымодели становятся настолько крупными и сложными, что теряется их основноепреимущество — наглядность и понятность. Если же сохранять моделикомпактными и понятными в ущерб информативности, инструментальные средствабудут способны создать автоматически лишь часть кода системы (например, скелетархитектуры программы или только заголовочные файлы классов для C++ сфункциями-заглушками для методов в файлах реализации).

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

В итоге в настоящее время3Исполнимый UML (Executable UML, xUML) [115, 150]27модельно-ориентированная разработка с помощью языков общего назначения (иUML в частности) используется большей частью для документирования на этапахвыявления требований и проектирования, а разработка ведется “традиционным”способом программированием на текстовых языках.Дальнейшее развитие идея визуального программирования нашла в парадигмепредметно-ориентированного моделирования (domain-specific modeling, DSM).Основу данного подхода к разработке составляет активное использованиеспециализированных языков, создаваемых специально для решения текущей задачи.Языки общего назначения пригодны для решения широкого круга задач, однако ониоперируют абстрактными сущностями.

Ограничив определенную предметнуюобласть, возможно создать инструментальные средства, идеально подходящие длявыбранного круга задач — элементами языка могут быть не абстрактные сущности,как в случае языков общего назначения, а высокоуровневые элементы из предметнойобласти, связями между ними — операции, которые выполняются над этимиэлементами.

Например, соединив на диаграмме элементы “Кнопка” и “Сообщение”,можно при генерации получить код, осуществляющий отправку SMS-сообщения понажатии определенной кнопки на экране мобильного телефона. В случае DSM этостановится возможно, поскольку инструментальная поддержка — визуальныйредактор, генератор, библиотеки времени исполнения и прочее — также созданыспециально для этого круга задач и обладают достаточными знаниями о предметнойобласти, чтобы автоматически получать даже довольно объемные и сложныеучастки кода по компактным и простым моделям. При этом, использованиеподобных языков приводит к преодолению описанного выше семантическогоразрыва — проектировщик строит модели напрямую из сущностей целевойпредметной области, необходимость в промежуточном уровне формализации в видеабстрактных объектов и связей между ними пропадает (см. рис.

2).28Рисунок 2. Преодоление семантического разрыва между моделями и предметнойобластью в DSM4Явноеограничениекругарешаемыхзадачиориентацииязыка(исоответствующих инструментов) на выбранную часть предметной области делаеттакже возможным стопроцентную генерацию исходного кода по моделям. В этомсмыслеDSMпозиционируетсякаканалогпереходанаструктурноепрограммирование с ассемблерных языков — повышение уровня абстракции сотказом к возврату разработчиков на нижний уровень. При написании программ,например, на языке C или C++ программист никогда не исправляет ассемблерныекоды, генерируемые компилятором при сборке проекта.