MDD

Опции документа Опции документа, требующие включения JavaScript, не отображаются Обсудить Выскажите мнение об этой странице Помогите нам улучшить содержание

Уровень сложности: простой

IBM developerWorks, IBM developerWorks, IBM

05.2007

В этой главе разработка, управляемая моделями, рассматривается в контексте других инициатив, присутствующих в индустрии. Мы изучим роль набора промышленных стандартов Object Modeling Group (OMG) в MDD. Мы также сравним с MDD другие подходы к разработке программного обеспечения.

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

В этой главе разработка, управляемая моделями, рассматривается в контексте других инициатив, присутствующих в индустрии. Мы изучим роль набора промышленных стандартов Object Modeling Group (OMG) в MDD. Мы также сравним с MDD другие подходы к разработке программного обеспечения, в том числе:

• архитектуру, управляемую моделями от OMG;
• разработку, основанную на активах;
• разработку, управляемую бизнесом;
• фабрики программного обеспечения (Software Factories) и языки, специфичные для предметной области (domain-specific languages, DSL).

Чтобы перейти к ч. 2, «Реализация», необязательно читать эту главу. При первом чтении этой книги данную главу можно пропустить.

6.1 OMG и архитектура, управляемая моделями

Object Management Group - это открытый консорциум, который создает стандарты взаимодействий в области приложений масштаба предприятия. OMG является ответственной за унифицированный язык моделирования (UML), который играет центральную роль в MDD. Также OMG продвигает идею архитектуры, управляемой моделями (Model-Driven Architecture, MDA). MDA представляет собой формализованный подход MDD, сходный с тем, который в течение многих лет продвигает компания IBM Rational. Согласно OMG, MDA - это способ организации и управления архитектурами масштаба предприятия, поддерживаемый инструментами и службами автоматизации, для определения моделей и облегчения создания трансформаций между моделями разных типов.

Вы увидите, что термины MDA и MDD часто употребляют как синонимы. В этой книге мы используем термин MDD для обозначения деятельности, осуществляемой разработчиками программного обеспечения. Термином MDA мы называем ее формализованное определение, подготовленное OMG, которое больше сконцентрировано на создании формализованного каркаса, на основе которого может работать MDD.

В руководстве по MDA от Object Management Group говорится, что MDA имеет три главные цели:

• переносимость;
• функциональная совместимость;
• возможность повторного использования.

Эти цели должны достигаться путем отделения спецификации работы системы от деталей реализации системы на конкретной платформе.

MDA позволяет создавать инструменты для достижения этих целей, и при этом решаются следующие задачи:

• система определяется независимо от платформы;
• определяются платформы;
• для системы выбирается платформа;
• спецификация системы трансформируется в спецификацию, предназначенную для конкретной платформы.

Понятие о платформе является в OMG MDA центральным. Платформа - это реализация интерфейсов и шаблонов применения набором подсистем и технологий, которые приложение может использовать, не обращая внимания на детали реализации.

В начало

6.2 Модели MDA

В MDA определяются три типа моделей:

• Модель, независимая от вычислений (Computation independent model, CIM). Модель CIM описывает требования, предъявляемые к системе и бизнес-контексту, в котором система будет использоваться. Эта модель обычно описывает, для чего будет применяться система, но не как она будет реализована. Модель часто выражается на языке бизнеса или предметной области, и в ней весьма ограничено упоминание IT-систем, если они входят в данный контекст.
• Модель, независимая от платформы (Platform independent model, PIM). Модель PIM описывает, как будет сконструирована система, но без указания технологий, применяемых для реализации. Модель не описывает механизмы, используемые для построения решения для конкретной платформы. Для одной платформы модель PIM может подходить больше, чем для другой, или же она может быть предназначена для реализации на нескольких платформах.
• Модель, специфичная для платформы (Platform-specific model, PSM). PSM - это модель решения с точки зрения конкретной платформы. В нее входят детали, описывающие, как может быть реализована модель CIM, и подробная информация о реализации на конкретной платформе.

В основе MDA лежит концепция трансформации PIM в PSM. Процесс преобразования одной модели в другую в той же самой системе называется трансформацией моделей. На рис. 6-1 показана трансформация PIM с возможным вводом дополнительной информации в PSM.

В MDA эти модели не рассматриваются как фиксированные уровни и считается, что модели PIM и PSM могут быть многоуровневыми и каждая модель может быть названа PSM по отношению к более абстрактной модели и PIM по отношению к более конкретной модели. Например, у нас может быть высокоуровневая модель дизайна, детальная модель дизайна и модель реализации с двумя шаблонами MDA. На каждом уровне мы вводим дополнительную информацию о платформе реализации. Детальная модель дизайна является PSM по отношению к высокоуровневой модели дизайна и PIM по отношению к модели реализации.

В сообществе MDA дискутируется вопрос о том, нужно ли трансформировать PIM сначала в «некодовую» PSM, а затем в код, или допустимо генерировать код прямо по модели PIM (т. е. моделью PSM будет сам код). При работе с J2EE и Java инструмент Rational Software Architect (RSA) предлагает возможность визуализации кодовых артефактов в виде UML-диаграмм. Поэтому становится возможным визуализировать артефакты, связанные с платформой, не вводя дополнительного уровня трансформации.

Согласно терминологии OMG главным предметом этой книги является моделирование приложений в моделях PIM, а затем трансформация их в модели PSM, зафиксированные непосредственно в артефактах реализации.

Большая часть сведений, приведенных в этой книге, также применима к переходам между другими уровнями моделирования. Например, согласно Rational Unified Process (RUP), мы можем начинать работу с аналитической модели, которую затем преобразовать в набросок модели дизайна. Мы также можемт трансформировать модель WebSphere Business Integration (WBI) Modeler в модель PIM, которая будет служить спецификацией для разработки программного обеспечения. В RSA включена такая трансформация и существует возможность импорта моделей из WBI Modeler.

6.2.1 IBM и MDA

В документе «An MDA Manifesto» выражается видение MDA от IBM. Найти этот документ вы можете по адресу

http://www.ibm.com/software/rational/mda/papers.html

В документе предлагается три основных принципа MDA, показанные на рис. 6-2 и рис. 6-3.

Концепции прямого представления, автоматизации и открытых стандартов являются основой разработки, управляемой моделями.

В начало

6.3 Фабрики программного обеспечения и языки, специфичные для предметной области

Возможно, вам уже встречались идеи языков, специфичных для предметной области (domain-specific language, DSL), и фабрик программного обеспечения (Software Factories), например в книге «Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools» (см. литературу по теме), где эти идее выдвигаются. Для тех из вас, кто встречался с этими понятиями или заинтересовался ими, сравним оба подхода.

На Web-сайте Software Factories термин фабрика программного обеспечения определяется следующим образом:

«Фабрика программного обеспечения - это линия программных продуктов, которая конфигурирует расширяемые средства разработки, такие, как Visual Studio Team System, дополняя их пакетами, содержащими DSL, шаблоны, каркасы и руководства, основанные на рецептах построения определенных видов приложений. Например, можно настроить фабрику программного обеспечения на тип приложений управления взаимоотношениями с клиентами (Customer Relationships Management, CRM), с использованием технологии тонкого клиента и применением сред. NET, C#, Microsoft Business Framework, Microsoft SQL Server и Microsoft Host Integration Server. Имея эту фабрику, мы можем получить бесконечное разнообразие CRM-приложений, каждое из которых будет содержать уникальные возможности, зависящие от требований конкретных клиентов. Более того, с помощью фабрики мы можем создать целое сообщество, сделав ее доступной для сторонних производителей, которые могут расширять ее и быстро создавать приложения, применяя свои расширения».

Главное отличие между подходами состоит во внимании, которое уделяется открытым стандартам, и в частности UML.

За дополнительной информацией о фабриках программного обеспечения обращайтесь на сайт

http://www.softwarefactories.com

6.3.1 UML и DSL

Вопрос о роли UML часто описывается слишком упрощенно. В MDD отстаивается использование UML во всех случаях моделирования предметной области, а в подходе с фабриками программного обеспечения UML не применяется совсем. Это неверное представление о позициях обоих лагерей.

Хотя в MDD UML, при соответствующей настройке, используется при создании моделей большинства приложений, также признается и значение других настраиваемых языков в некоторых специальных ситуациях. Такова основная мысль стандарта OMG Meta-Object Facility (MOF), который играет важную роль в MDD (на с. 80 приведены дополнительные сведения о MOF). Язык UML сам по себе определяется с использованием MOF, и существуют определения MOF для многих других языков. В подходе MDD признается значение не-UML DSL как методов, которые следует применять осмотрительно.

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

http://msdn.microsoft.com/404/default.aspx#vstsmodel_uml

Преимущества использования UML-профилей в качестве DSL

• UML - это язык моделирования с открытым стандартом, по которому написано множество книг и создано много обучающих курсов. Владение UML - это признанный и переносимый на разные области навык для разработчиков программного обеспечения.
• Профили UML - это легкий подход, который весьма просто реализовать с использованием доступных UML-инструментов. В будущем могут появиться инструменты и для DSL, но определенная настройка здесь по-прежнему является практически обязательной.
• Модели с примененными к ним UML-профилями могут читать любые UML-инструменты, даже те, которые не имеют никакой информации об этом профиле. В некоторых случаях расширения, внесенные профилем, игнорируются.
• Если все DSL созданы на основе UML, возникает набор языков, разделяющих общие концепции. Это делает новые профили более понятными и позволяет легко интегрировать модели, созданные с помощью разных DSL. Если набор моделей написан на разных DSL, проблема интеграции, характерная для промежуточного программного обеспечения, воспроизводится на уровне моделей, что, конечно же, нежелательно.
• UML можно применять как для высокоуровневых архитектурных моделей, так и для подробных моделей, по которым генерируется код. Этим обеспечивается согласованность на всем протяжении жизненного цикла программы, и пользователи получают возможность без проблем перейти от менее детальных моделей к более детальным. Если UML применяется только при создании набросков и документации, эта возможность обеспечения согласованности упускается.

Недостатки использования UML-профилей в качестве DSL

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

Альтернативы использованию UML-профилей в качестве DSL, которые есть в MDD

Хотя UML является подходящей основой для многих DSL, бывают ситуации, когда мы рекомендуем использовать альтернативный подход в некоторых частях MDD-про-цесса.

Вместо UML можно применять следующие подходы

• Язык, основанный на MOF. В тех случаях, когда лучше использовать свой язык, определите его при помощи МОЕ Компонент с открытым кодом Eclipse Modeling Framework, который входит в RSA, генерирует на Java реализацию MOF-языка и базовый инструментарий Eclipse для создания экземпляров моделей на языке. В будущем, вероятно, станет возможной генерация полномасштабных графических редакторов.
  Эта методика применяется для реализации многих языков, поддерживаемых RSA, в том числе UML и XSD. При использовании данного подхода следите, чтобы язык интегрировался с UML и другими не-UML-языками, которые применяются в том же самом решении.
• Настраиваемый пользовательский интерфейс. Для некоторых пользователей визуальное моделирование может оказаться неподходящим способом фиксации опыта. Может быть, больше подойдет настраиваемый инструмент с пошаговыми инструкциями и настраиваемыми графическими элементами. Очевидно, что этот подход более дорогостоящий, но, если его применять правильно, это весьма полезный метод.
• Трансформация из существующего формата. Информация, необходимая для работы цепочки инструментов MDD, может уже быть зафиксирована в существующем инструменте. Это может быть другой инструмент моделирования программ, инструмент моделирования бизнеса или офисный инструмент, например, Microsoft Excel. Любую информацию можно трансформировать в UML-модели. Если существуют активы, очень важно использовать для генерации моделей этот подход, чтобы не моделировать ту же информацию вручную.

В начало

6.4 Разработка на основе активов

Разработка на основе активов (asset-based development, ABD) предлагает использовать активы на всех этапах жизненного цикла разработки программного обеспечения. В отличие от предыдущих инициатив ABD делает акцент не только на компонентах, касающихся кода, которые могут быть получены напрямую. В частности, ABD дополняет MDD поддержкой повторного использования моделей, шаблонов и трансформаций. За дополнительной информацией о подходе IBM к разработке, основанной на активах, обращайтесь по адресу

http://www.ibm.com/developerworks/rational/products/patternsolutions/

RUP for asset-based development - это плагин RUP, в котором описаны задачи, роли и выходные материалы, связанные с разработкой на основе активов. Больше узнать о RUP вы можете по адресу

http://www.ibm.com/developerworks/rational/library/4145.html

Стандарт OMG Reusable Asset Specification (RAS) весьма важен для ABD. RAS предлагает стандартный способ формирования пакетов, документирования, поиска и извлечения программных активов. За дополнительной информацией о стандарте RAS обращайтесь по адресу:

http://www.omg.org/cgi-bin/doc?ptc/2004-06-06

Rational Software Architect предлагает перспективу повторно используемых активов, куда входят клиентские возможности для поиска и импортирования активов RAS из репозиториев.

RSA поддерживает удаленные репозитории, например репизиторий RAS для рабочих групп, а также более легковесные локальные файловые репозитории. Репозиторий RAS для рабочих групп представляет собой репозиторий, реализованный с использованием WebSphere Application Server, которое можно найти в сети IBM alphaWorks:

http://www.alphaworks.ibm.com/tech/rasr4w

RSA также поддерживает упаковку артефактов в RAS-активы и публикацию этих активов в локальных и удаленных репозиториях. В RAS-активы можно помещать RSA-мо-дели, шаблоны, трансформации и другие расширения.

В начало

6.5 Разработка, управляемая шаблонами, и шаблоны IBM для электронного бизнеса

Разработка, управляемая шаблонами, связана с разработкой программного обеспечения с применением лучших практик решения проблем.

Существует два основных способа связи шаблонов и MDD:

• MDD может автоматизировать применение шаблонов. Традиционно шаблоны писались как документы, часто с использованием UML-моделей для пояснений. Затем шаблоны применялись вручную. MDD может автоматизировать применение шаблонов.
• Шаблоны обеспечивают MDD содержанием. MDD позволяет перейти от хорошо спроектированных моделей к хорошо спроектированной реализации. В шаблонах зафиксированы практические методы, как на уровне моделирования, так и на уровне реализации. Применение MDD невозможно без знания шаблонов предметной области и шаблонов области реализации.

Шаблоны IBM для электронного бизнеса

Шаблоны IBM для электронного бизнеса (IBM Patterns for e-business) помогают облегчить повторное использование активов, в которых зафиксирован опыт IT-архитекторов, чтобы будущие проекты выполнялись быстрее и проще. Повторное использование активов экономит время, деньги и силы, а также помогает обеспечить создание надежного, хорошо спроектированного решения. Целью шаблонов IBM для электронного бизнеса является фиксация и публикация артефактов для электронного бизнеса, которые использовались, тестировались и доказали свою успешность. Предполагается, что зафиксированная информация должна подходить к большинству (80/20) ситуаций. Шаблоны IBM для электронного бизнеса дополняются руководствами и ссылками на связанные материалы для удобства использования.

Шаблоны для многоуровневой модели активов электронного бизнеса

Шаблоны для электронного бизнеса позволяют архитекторам реализовывать успешные решения для электронного бизнеса при помощи повторно используемых компонентов и элементов из решений, оказавшихся удачными. Данный подход основывается на наборе многоуровневых активов, которые можно применять в любой существующей методологии разработки. Такие многоуровневые активы имеют такую структуру, что каждый уровень детализации основан на предыдущем уровне. Эти активы включают в себя следующие элементы (рис. 6-4):

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

Использование шаблонов и MDD - это ключ к преодалению разрыва между бизнесом и IT и к созданию продукта, имеющего ценность для бизнеса. Применение шаблонов и MDD уменьшает время реакции, позволяет вести проектирование и разработку «по требованию» и уменьшает сложность. Шаблоны и MDD уже входят в пору зрелости и дают ощутимые результаты.

Томас Мерфи (Thomas Murphy) из META Group (которая сейчас является частью Gartner Group) сказал такую часто цитируемую фразу: «Организации, использующие каркасы и инструменты разработки, управляемой моделями и основанной на шаблонах, могут достигнуть существенного роста производительности и качества работы группы разработчиков».

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

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

Шаблоны IBM для электронного бизнеса - это многоуровневые, многократно используемые, интегрированные и проверенные шаблоны, являющиеся высококачественными входными данными для MDD, которая увеличивает возможности повторного использования шаблонов для электронного бизнеса путем их автоматизации для упрощения повторного применения. Шаблоны для электронного бизнеса предоставляют основу для создания MDD-каркасов масштаба предприятия, что особенно важно для фиксации и ввода общего архитектурного стиля во всех IT-системах предприятия.

В нашем сценарии и примере мы используем шаблоны для электронного бизнеса с акцентом на шаблонах приложения и шаблонах среды исполнения. Шаблоны приложения для электронного бизнеса и шаблоны среды исполнения расширяются таким образом, чтобы создать на основе этих расширений шаблоны SOA и ESB. Шаблоны для электронного бизнеса формируют используемый архитектурный стиль.

В начало

6.6 Разработка, управляемая бизнесом

Разработка, управляемая бизнесом (business-driven development, BDD), связана с преодолением разрыва между бизнесом и IT, чтобы бизнес напрямую управлял развитием этих технологий. На рис. 6-5 показан жизненный цикл разработки, управляемой бизнесом, в который входит сам бизнес, разработка и операционная часть бизнеса.

При использовании BDD основной частью жизненного цикла является бизнес-моделирование. Оно проводится с использованием инструмента, подходящего для бизнес-пользователей, например WebSphere Business Integration Modeler (WBI Modeler). Инструмент WBI Modeler дает возможность пользователям фиксировать и имитировать бизнес-процессы на уровне самого бизнеса.

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

Rational Software Architect может импортировать модели бизнес-процессов WBI Modeler для создания спецификации реализуемого программного обеспечения. UML-модели, которые создает RSA из моделей WBI Modeler, содержат прецеденты использования (use cases) и диаграммы кооперации, которые описывают поведение системы. Эти модели не дают решений по реализации бизнес-процессов, например, нужно ли использовать подход с централизованной хореографией или распределенный объектно-ориентированный подход.

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

В некоторых случаях, когда платформа для реализации известна заранее, можно перейти от моделей бизнес-процессов прямо к базовым артефактам реализации. Например, WBI Modeler может экспортировать процессы, используя Business Process Execution Language for Web Services - исполняемый язык, который поддерживается WebSphere Process Choreographer.

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

В начало

6.7 Разработка, управляемая моделями, и бизнес по требованию

Компания IBM дала имя новой ветви бизнеса - бизнесу «по требованию» (On Demand Business). Сэм Палмисано (Sam Palmisano), исполнительный директор IBM, определяет бизнес по требованию следующим образом: «предприятие, чьи интегрированные сквозные бизнес-процессы в самой компании и с ключевыми партнерами, поставщиками и клиентами могут с достаточной гибкостью и скоростью отвечать на любое требование клиента, а также возможность или угрозу на рынке».

Бизнес по требованию понимает, что он делает сейчас, и может быстро превратить бизнес-решения в реальность.

Разработка, управляемая моделями, особенно если она выходит на уровень разработки, управляемой бизнесом, является мощным посредником для бизнеса по требованию.

• При использовании MDD, время, которое занимает добавление новой бизнес-функции, уменьшается, поскольку большая часть работы по реализации автоматизируется с использованием существующих трансформаций.
• Для MDD-систем всегда доступны модели уровня дизайна, поэтому текущее поведение системы понятно. Понимание текущих возможностей системы является критичным для принятия быстрых решений. Это часто бывает проблематичным в не-MDD-системах, где текущие возможности системы бывают плохо осознаваемы и зависимыми от ключевых сотрудников.
• DD-проект может легко пользоваться технологическими нововведениями. Гораздо проще обновить и применить заново трансформации, чем реализовывать систему на новой платформе. MDD-проект может быстро воспользоваться преимуществами, которые дают новые технологические платформы.
• При связывании бизнес-моделей и моделей программного обеспечения в BDD, влияние изменений очень быстро можно оценить на бизнес-уровне. В некоторых случаях изменение бизнес-модели может автоматически привести к изменению модели программного обеспечения.

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

В начало

6.8 Разработка, управляемая моделями, и промежуточное программное обеспечение

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

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

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

В начало

6.9 Визуализация

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

RSA поддерживает визуализацию артефактов Java и J2EE. Такой метод работы - это использование некоторых преимуществ моделирования при кодо-центрическом подходе. При использовании визуализации главным артефактом является код, и модели генерируются из кода. Модели не сохраняются (хотя сохраняется их общая схема), они являются просто визуализацией кода. На рис. 6-7 показан простой J2EE-про-ект с соответствующей UML-визуализацией.

Модель генерируется из кода, а не каким-то другим способом. Визуализация выполняется легче, если модель визуализированных артефактов (которая часто находится в памяти) уже существует, таким образом нет необходимости обрабатывать текстовое представление артефактов. Это пример использования не-UML-моделей в цепочке инструментов MDD.

Визуализация предоставляет ряд преимуществ, характерных для разработки, управляемой моделями.

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

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

Существует два главных способа применения визуализации в разработке, управляемой моделями.

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

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

В начало

6.10 Исполняемый UML

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

Обычно термином «Исполняемый UML» называется подход к UML как к полнофункциональному языку программирования, т. е. не только как к средству выражения высокоуровневых связей, но и как к средству создания полностью исполняемых моделей. Такие модели выполняются либо на виртуальной машине UML, либо путем компиляции на язык программирования более низкого уровня.

Альтернативой исполняемому UML и распространенной в настоящий момент в MDD практикой является переход на язык программирования более низкого уровня и ввод деталей.

В UML есть поддержка детальной семантики при помощи Действий (Actions) и Задач (Activities). Однако для этих конструкций предусмотрена только визуальная система обозначений, тогда как все согласны с тем, что текстовый язык более эффективен для выражения детальной семантики, такой как математические алгоритмы и текстовая обработка.

Существует ряд языков Исполняемого UML, включающих текстовую нотацию для действий, и в настоящее время разрабатывается OMG стандарт Исполняемого UML. См. книгу «Executable UML: A Foundation for Model-Driven Architecture», авторы Stephen J. Mellor и Marc J. Balcer. Также см. книгу «Model-Driven Architecture with Executable UML», авторы Chris Raistrick, Paul Francis, John Wright, Colin Carter и Ian Wilkie. Полные ссылки можно найти в разделе «Литература по теме».

В начало

6.11 Заключение

Архитектура, управляемая моделями (Model Driven Architecture, MDA), от Object Management Group предназначена для формализации идей разработки, управляемой моделями, а также для определения стандартов этого подхода. Мы применяем термин

MDD для обозначения подхода к разработке, который во многом соответствует подходу MDA, который разрабатывается OMG.

MDD имеет много общего с другими инициативами, такими как Фабрики программного обеспечения (Software Factories) от Microsoft и языками, специфичными для предметной области. Хотя между этими подходами есть и существенные различия, например, значение стандартов для MDD, между ними есть и множество общих черт.

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

И, наконец, MDD существует не в изоляции. Он имеет общую основу и взаимосвязи с другими принятыми концепциями разработки программного обеспечения, включая разработку, управляемую шаблонами и разработку, основанную на активах.

На этом завершается ч. 1, «Подход», этой книги. В Части 2, «Реализация», мы будем применять идеи MDD в гипотетическом сценарии, созданном на основе опыта авторов.

Об авторе

		команда developerWorks работает над созданием полезных материалов для разработчиков

Выскажите мнение об этой странице

Пожалуйста, найдите минутку и заполните форму, чтобы повысить уровень сервиса. Помогла ли данная информация достичь Вашей цели? Да Нет Не знаю   Пожалуйста, напишите комментарий, чтобы мы могли улучшить данную страницу:   Насколько полезна эта информация? (1 = Бесполезна, 5 = Очень полезна) 1 2 3 4 5

В начало