Введение
Разработка ПО, управляемая моделями (MDD), - это новая парадигма разработки программного обеспечения, управляемая и поддерживаемая методами архитектуры Model-driven Architecture (MDA) (подход к разработке ПО, созданный командой Object Management Group (OMG). MDA предоставляет ряд рекомендаций для структурирования спецификаций, представленных в качестве моделей, начиная с независимой от платформы модели (PIM), затем при выборе языка программирования исходя из специфики разработки, и наконец, при трансформации модели в одну или несколько моделей, определяемых платформой, в рамках которой они реализуются (PSM). К оличество платформ может быть любым, например: Java 2 Platform, Enterprise Edition (J2EE), CORBA или .Net, реализованные на одном из общепринятых языков программирования, таких как Java, C# или Python. MDA обычно выполняется при помощи автоматизированного инструментария, например, IBM Rational Software Architect. MDD-разработка, основанная на MDA, в основном занимается трансформацией моделей и генерацией кода.
Однако основанный на создании кода подход, используемый MDD, имеет свои недостатки, связанные с ограничениями в сгенерированном коде, низкой компетентностью разработчиков и жесткой привязкой к конкретной модели. Если компания полностью полагается на автоматическую генерацию кода, она оказывается ограниченной в возможностях тонкой настройки кода, особенно когда разработчикам приходится все изменения вносить только через изменение модели.
Разработка на основе шаблонов помогает решить эту проблему. Шаблон - это решение периодически возникающей проблемы в рамках определенного контекста . Шаблоны инкапсулируют время, труд и знания разработчика, однажды уже понадобившиеся для решения проблемы. Более того, после многократного использования в различных проектах шаблон приобретает статус эталона. Используя шаблон как отправную точку в проектировании, разработчики могут более гибко контролировать генерируемый код, который не ограничен, т.к. основан на абстрактной модели.
Кроме того, MDD может автоматизировать реализацию шаблонов на основе трансформаций, что позволит исключить повторение операций низкоуровневой разработки и отразить в коде опыт разработчиков, что должно повысить совместимость и удобство обслуживания. Модифицированная трансформация быстрее запускается при необходимости сгенерировать артефакты решений, отражающие изменения в архитектуре реализации.
В центре внимания этой статьи - оптимизация MDD и разработки на основе ресурсов как интегрированный подход. С его помощью разработчики сначала создают модель объекта на Универсальном Языке Моделирования (UML), а затем генерируют код из этой UML-модели, применяя инструмент генерации кода, который пользуется репозиторием шаблонов.
|
Применение MDD с Rational Software Architect
Ознакомившись с этой информацией, вы, вероятно, поняли, что для применения этого подхода требуется интегрированная среда разработки (IDE) с поддержкой следующего:
- Моделирования на основе UML
- Инфраструктуры шаблонов
- Функций трансформации модели и генерации кода
- Инструмента проектирования и разработки для конкретной платформы, а также среды для тестирования элементов
Rational Software Architect - инструмент, обеспечивающий все эти возможности. Это интегрированное средство проектирования и разработки, которое использует преимущества UML-разработки на основе моделей, позволяя создавать приложения и сервисы с практичной архитектурой. С Rational Software Architect вы можете:
- Усилить открытую и расширяемую платформу моделирования
- Ускорить моделирование и проектирование ПО
- Автоматизировать процессы разработки и максимизировать многократное использование ресурсов
- Повысить производительность при разработке приложений и Web-сервисов
Эта серия статей составлена следующим образом:
Часть 1: Данная статья, дающая общее представление о MDD и о разработке на основе шаблонов
Часть 2: Подход к разработке, управляемой моделями и на основе шаблонов, с использованием Rational Software Architect
Часть 3 (скоро): Учебный пример
Модель UML
Одна из главных особенностей MDD - использование моделей в качестве ключевых артефактов. Модель - это описание системы с определенной точки зрения, с опущением несущественных деталей, с тем чтобы более четко выделить характеристики, представляющие интерес . В MDD модель должна быть машинно-читаемой, чтобы обеспечить автоматический доступ к ее содержанию, а также генерацию артефактов. Диаграмма на демонстрационной доске может соответствовать остальным критериям, необходимым, чтобы считаться моделью, но только зафиксировав ее в машинно-считываемой форме, вы сможете использовать ее в системе инструментов MDD.
Модели ПО обычно представлены на UML. В UML-моделях детали технического исполнения скрыты, поэтому система может разрабатываться с использованием понятий из области вашего конкретного приложения. При разработке приложения обычно применяется инструмент моделирования на UML, например, Rational Software Architect и концепты, имеющие отношение к области вашего приложения.
Использование UML-моделей в разработке ПО широко применялось и до появления MDD. Наиболее распространены два способа их применения:
- В качестве набросков, которые дают упрощенное представление о каком-либо аспекте системы
- В качестве детальных проектов для последующей ручной разработки.
В MDD модели используются не просто как проекты или наброски, а как исходные артефакты, из которых путем трансформаций генерируются эффективные реализации. В MDD подробно описанные предметно-ориентированные модели приложения играют главную роль при разработке новых компонентов ПО. Код и другие артефакты области назначения генерируются с помощью трансформаций, в разработке которых участвуют как специалисты по моделированию, так и специалисты в конкретной области.
Трансформация
UML-моделирование - само по себе полезная технология, однако синхронизация моделей и кодов вручную - трудоемкая и чреватая ошибками процедура. MDD автоматизирует процесс разработки, благодаря чему можно сгенерировать любой артефакт, выведенный из данных, содержащихся в модели. Наряду с кодом, сгенерированные путем трансформации артефакты включают в себя, но не ограничиваются следующим:
Документация: В организациях, которые придерживаются формализованного метода разработки, создание документации требует от разработчиков значительных усилий. Известно, как тяжело поддерживать документацию в соответствии с реализацией. При использовании MDD документы генерируются из моделей. Это обеспечивает и совместимость, и возможность доступа к информации внутри моделей, с которыми разработчики ежедневно имеют дело, вместо документов со сложной навигацией. Документацию можно создавать такими инструментами, как Rational Software Architect’s Report Generator, либо с помощью трансформации.
Тестовые артефакты: Можно генерировать базовые средства (harnesses) тестирования (например, с помощью JUnit) из информации, содержащейся в программных моделях.
Скрипты построения и размещения: Основываясь на своем опыте, разработчики построения и размещения могут создавать трансформации для генерации скриптов построения и размещения.
Другие модели: Система включает множество взаимосвязанных моделей на разных уровнях абстракции (анализ, разработка, внедрение), представляющих разные части системы (пользовательский интерфейс (UI), базу данных, бизнес-логику, системное администрирование), имеющих разные функции (повышение безопасности, производительности или способности системы противостоять ошибкам) или разные задачи (тестирование, моделирование внедрения). Во многих случаях можно частично сгенерировать одну модель из другой (например, идти от модели анализа к модели разработки, или от модели приложения к модели тестирования).
Шаблоны
Еще одна из основных черт MDD - сбор (накопление) опыта. Шаблоны фиксируют лучшие решения периодически возникающих проблем. При MDD-моделировании шаблоны встречаются на всех уровнях абстракции моделирования:
- Шаблоны архитектуры
- Шаблоны дизайна
- Шаблоны реализации
Шаблоны можно составлять для разработки "рецептов" будущих шаблонов для решения более серьезных задач.Шаблоны охватывают передовой опыт соответствующей предметной области.
Они определяют как характеристики элементов модели, так и взаимосвязь этих элементов. Шаблоны можно автоматизировать, в результате чего, когда создаются новые, путем трансформации модифицируются существующие элементы, чтобы соответствовать шаблону, когда его применяют к модели.
Шаблоны повышают совместимость и качество решений. Это достигается благодаря автоматическим шаблонам реализации с трансформациями в MDD, что исключает многократную низкоуровневую разработку. Чтобы раз за разом не создавать артефакты решений вручную, можно закодировать опыт разработчика непосредственно в трансформации. В итоге вы убиваете сразу двух зайцев: повышается совместимость и удобство обслуживания. Модифицированная трансформация быстрее запускается при необходимости генерировать артефакты решений, отражающие изменения в архитектуре реализации.
От коммерческих задач к программным решениям
Рисунок 1 демонстрирует, как с помощью MDD коммерческая проблема преобразовывается в решение ПО. Бизнес-проблема анализируется, а затем применяются общие бизнес-шаблоны. Таким образом, модель разработки частично заполняется, в ней появляются детали конкретной разрабатываемой бизнес-функции. Далее внедряются независимые от платформы шаблоны разработки для трансформации модели разработки в ряд независимых от рабочего цикла компонентов. После этого выбирается исполняемая платформа и специфические для ее рабочего цикла шаблоны применяются для генерации артефактов.
Рисунок 1. Использование MDD для преобразования бизнес-проблемы в программное решение
Преимущества применения шаблонов в MDD
Индустрия разработки ПО реализовала множество преимуществ совмещения MDD с шаблонами. К наиболее важным из них относятся:
Повышение производительности: MDD облегчает разработку ПО за счет генерации кода и артефактов из моделей, что повышает производительность труда разработчиков.
Увеличение многократного использования: MDD особенно эффективна, когда применяется на уровне программы или организации. Это объясняется тем, что отдача от средств, инвестированных в разработку трансформаций, происходит каждый раз при повторном использовании ресурсов. Применение надежных и испытанных трансформаций также повышает предсказуемость в разработке новых функций и снижает проектный риск (поскольку архитектурные и технические проблемы уже решены).
Повышение удобства обслуживания: Вследствие технологического прогресса, компоненты решений становятся наследием от технологий предыдущих платформ. MDD помогает решить эту проблему, благодаря обслуживаемой архитектуре, которая позволяет быстро и согласованно внести изменения и более рационально переустановить компоненты на новую технологическую базу.
Больше гибкости: Высокоуровневые модели не содержат несущественных деталей реализации. Это облегчает внесение изменений в технологию лежащей в их основе платформы и в ее техническую архитектуру. Изменение технической архитектуры внедрения завершается обновлением трансформации. Трансформация повторно применяется к исходным моделям для создания артефактов внедрения, соответствующих новому подходу.
Совместимость: При осуществлении кодирования и принятии архитектурных решений вручную невозможно исключить ошибки. MDD обеспечивает совместимость генерируемых артефактов.
Улучшение взаимодействия: В моделях опущены детали реализации, которые несущественны для понимания логики работы системы. Таким образом, модели приближены к проблемной области, благодаря чему сужается разрыв между понятиями, которые используются заказчиками, и языком реализации решения. Модели также облегчают понимание и обсуждение системы на уровне разработки. И это упрощает процесс коммуникации системы.
Аккумуляция опыта: Проекты или организации часто зависят от ведущих специалистов, которые многократно принимают наилучшие программные решения. Если зафиксировать их опыт в шаблонах и трансформациях, их присутствие будет необязательно для разработки решений (и получения пользы) другими участниками проекта.
Снижение риска: При использовании подхода MDD, разработка приложения на начальном этапе сосредоточена на моделировании. Это означает, что можно отложить выбор определенной технологической платформы или версии продукта до следующего этапа (когда появится новая информация и риск, таким образом, снизится).
Учимся на своих ошибках
MDD - качественная методика разработки. Однако отзывы показывают, что не все проекты, в которых использовалась MDD, были успешными. Это, в основном, связано с несколькими факторами:
- Неудачный выбор проекта
- Недостаточно эффективное планирование (проектирование)
- Нехватка опыта и необходимых навыков
Ниже перечислены уроки, которые мы извлекли из наших предыдущих проектов и которые помогут вам при работе с MDD.
Выбирайте корректные проекты: MDD особенно эффективна, когда внедряется на уровне программы или организации, поскольку рентабельность инвестиций (ROI) в разработку или покупку трансформаций возрастает каждый раз при их повторном использовании. Корректный проект должен иметь четкую архитектуру и работать на основе повторяемых шаблонов поведения, которые можно абстрагировать, фиксировать заключенный в них опыт и в дальнейшем использовать в трансформациях.
Принимайте в расчет дополнительные затраты: Возможно, вам понадобятся дополнительные расходы на разработку и покупку трансформаций, но тщательное планирование затрат в результате обеспечит вам снижение стоимости проекта в целом.
Не торопитесь: Во многих организациях к новым подходам относятся скептически, пока их эффективность не будет доказана на практике. Если это ваш первый проект с использованием MDD, целесообразно разбить разработку инструментария MDD на несколько итерационных циклов (iterations). Каждая последующая итерация будет основан на накопленном вами опыте, что позволит постепенно расширять набор поддерживаемых сценариев для бизнес-приложения.
Развивайте необходимые навыки: Для применения MDD требуются разработчики, знакомые с UML и IDE для MDD. Сначала для накопления этих навыков в команде может потребоваться время, что приведет к замедлению разработки проекта. Однако эта же проектная группа будет гораздо легче справляться с последующими проектами. Если вы впервые используете MDD, хорошим выходом будет привлечь специалистов, чтобы ускорить процесс.
Не забывайте о многократном использовании: Инструментарий MDD, созданный для вашего проекта, будет впоследствии многократно использоваться разработчиками при генерации артефактов для бизнес-приложения. Также возможно повторное применение этого инструментария в последующих проектах. Старайтесь найти многократному использованию широкое применение и в конце концов это принесет значительную прибыль вашей организации.
Выбирайте подходящий инструмент разработки: Правильно вооружившись, вы гарантированно извлечете из MDD максимум пользы. Проектная группа (включая руководителя проекта, бизнес-аналитиков, архитектора решений, разработчиков и испытателей) должна оценить и утвердить используемый инструмент разработки.
Резюме
Первая статья из этой серии дает представление о парадигме разработки, управляемой моделями и на основе шаблонов. Коротко говоря, MDD раскрывает возможности использования шаблонов для создания тщательно спроектированных решений, а шаблоны предоставляют контент для MDD.