Главная » UML » Архитектура, управляемая моделью,  и исполняемый UML

0

Когда говорят о UML, часто упоминают об MDA (Model Driven Architecture – архитектура, управляемая моделью) [27]. По сути дела, MDA представляет собой стандартный подход к использованию UML в качестве языка программирования; этот стандарт находится под управлением группы OMG, как и сам UML. Создавая систему моделирования, соответствующую MDA, поставщики могут разработать модели, способные работать и в MDA-совместимом окружении.

Говоря об MDA, часто подразумевают и UML, поскольку MDA использует UML в качестве основного языка моделирования. Но, конечно, вы не обязаны следовать MDA, применяя UML.

MDA разделяет процесс разработки на две основные части. Разработчики моделей представляют конкретное приложение, создавая PIM (Platform Independent Model – модель, не зависящая от платформы), PIM – это модель UML, не зависящая от какой-то конкретной технологии. Затем инструменты могут превратить PIM в PSM (Platform Specific Model – модель, зависящая от платформы). PSM -это модель системы, нацеленная на определенную среду выполнения. Другие инструменты берут PSM и генерируют код для этой платформы. В качестве PSM можно использовать UML, но это необязательно.

Поэтому если вы хотите создать систему складского учета с использованием MDA, вам придется начать с единой модели PIM вашей системы. Затем при желании запустить эту систему складского учета в J2EE или .NET вы должны будете использовать инструменты каких-либо производителей для создания двух моделей PSM – по одной на каждую из этих двух платформ.

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

Стив Меллор (Steve Mellor) долгое время активно работал в этой области и с недавнего времени стал употреблять термин исполняемый UML (Executable UML) [32]. Исполняемый UML похож на MDA, но использует немного другую терминологию. Точно так же вы начинаете с модели, не зависящей от платформы, которая эквивалентна MDA-модели PIM. Однако на следующем этапе применяется компилятор модели (Model Compiler), для того чтобы за один прием превратить UML-модель в готовую к развертыванию систему; поэтому модель PSM не нужна. Как и предполагает термин компилятор, этот этап полностью автоматизирован.

 

Компиляторы модели основаны на повторно используемых прототипах. Прототип (archetype) описывает способ превращения исполняемого UML в соответствующую программную платформу. Поэтому в случае с системой складского учета придется купить компилятор модели и два прототипа (J2EE и .NET). Примените эти прототипы к вашему исполняемому UML, и у вас будет две версии системы складского учета.

Исполняемый UML не использует полный стандарт UML; многие конструкции языка считаются ненужными и не применяются. Поэтому исполняемый UML проще, чем полный.

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

Более фундаментальным аспектом является сама идея применения UML в качестве языка программирования. С моей точки зрения, использовать UML как язык программирования стоит, только если в результате получается нечто более продуктивное, чем в случае применения другого языка программирования. Однако исходя из своего опыта работы в различных графических средах разработки, я не стал бы это утверждать. Даже если UML и более продуктивен, надо еще накопить критическую массу пользователей, чтобы принять его в качестве основного направления. UML сам по себе представляет большое препятствие. Подобно многим пользователям, имеющим опыт работы с языком Smalltalk, я считаю его более продуктивным, чем многие современные основные языки. Но в настоящее время Smalltalk представляет только небольшую нишу в пространстве языков, и я не наблюдаю большого количества проектов, написанных на нем. Чтобы избежать судьбы языка Smalltalk, UML должен быть счастливчиком, даже если он самый лучший.

и понять различные значения терминов «пул активов» (asset pool) с группой бухгалтеров, то следует принять точку зрения значительно более близкую к концептуальной.

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

Следствием различных способов применения TJML является масса споров о том, что означают диаграммы UML и как они связаны с остальным миром. Особенно это влияет на отношение между UML и исходным кодом. Некоторые разработчики считают, что UML нужно применять для создания модели, не зависящей от языка программирования, который используется для реализации проекта. Другие убеждены в том, что модель, не зависимая от языка, – это оксюморон с выраженным ударением на слово «морон» (moron – идиот).

Другое различие во взглядах относится к вопросу о сущности UML.

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

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

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

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

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

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

 

ходимо. Для тех же, кого интересуют только эскизы, данное издание может оказаться именно тем, что нужно.

Источник: Фаулер М.UML. Основы, 3-е издание. – Пер. с англ. – СПб: Символ-Плюс, 2006. – 192 с.,ил.

По теме:

  • Комментарии