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

Когда говорят о UML, часто упоминают об MDA (Model Driven Ar­chitecture - архитектура, управляемая моделью) [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) и реализацию (implementa­tion). Сейчас я понял, что на практике довольно трудно провести меж­ду ними точную границу, поэтому чувствую, что не нужно больше бес­покоиться о различиях между ними. Однако я всегда был склонен в своих диаграммах делать ударение на интерфейсе, а не на реализации.

Следствием различных способов применения TJML является масса спо­ров о том, что означают диаграммы UML и как они связаны с осталь-

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

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

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

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

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

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

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

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

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