UML 2.0 — первая серьезно переработанная версия UML. Данная спецификация опирается на идею разработки на основе модели
Object Management Group (OMG) проводит голосование по ратификации Unified Modeling Language (UML) 2.0, последней версии спецификации на разработку на основе модели. Ответственный редактор InfoWorld Пол Крил беседовал об этом с Брайаном Селиком, ведущим инженером IBM и сопредседателем рабочей группы OMG по UML 2.0.
Чем важен для нас UML 2.0?
UML 2.0 — первая серьезно переработанная версия UML. Данная спецификация опирается на идею разработки на основе модели. Как мне кажется, это уже достаточная причина для того, чтобы проявить к ней интерес. По-существу, это стандарт, который был преобразован таким образом, чтобы лучше поддерживать саму концепцию моделей, играющих первостепенную роль в разработке ПО.
Чем разработка на основе модели лучше традиционного подхода?
Существует множество вариантов разработки на базе модели, но все они основаны на общей идее, хотя существует масса различных аспектов. Так, например, благодаря более высокому уровню абстракции можно учитывать специфику предметной области, а языки моделирования позволяют работать, если так можно выразиться, «над технологией». Другие аспекты связаны с эффективным использованием автоматизации, то есть компьютеры применяются для того, чтобы устранить разрыв между отвлеченным уровнем абстракции и реализацией.
На какой стадии сейчас находится процесс утверждения UML 2.0?
Мы завершили спецификацию. Этап окончательного оформления был необходим, поскольку раньше спецификация публиковалась, но никогда не реализовывалась. В начале ноября этот этап был закончен, и теперь мы проводим процедуру утверждения. По-моему, пока никто не высказался против.
Когда вы ожидаете окончательных результатов?
В самое ближайшее время. Скорее всего, все решится еще до рождественских каникул. А затем где-то в середине января UML 2.0 будет официально утверждена советом директоров OMG.
Некоторые компании, например Borland, уже продают продукты, поддерживающие UML 2.0. Но если такие продукты уже существуют, тогда в чем смысл утверждения спецификации?
Кстати, IBM ее тоже поддерживает, но, как это бывает практически во всех аналогичных случаях, стандарт будет обновлен в соответствии со всеми внесенными нами изменениями. Компании, которые выпускают продукты, поддерживающие UVL 2.0 , принимали активное участие в работе на этапе завершения спецификации. Продукты будут развиваться по мере развития стандарта.
Что говорят об UML 2.0 в сообществе разработчиков? Какие у него плюсы и минусы?
UML 2.0 применим повсеместно. Есть, конечно, критики, чьи утверждения, с моей точки зрения, во многом не соответствуют действительности, но в целом UML 2.0 вызывает большой интерес. На прошлой неделе я был в Корее, а за неделю до этого — в Бразилии. Четыре недели перед этим я находился в Европе и могу со всей определенностью сказать, что интерес к спецификации огромный. Вот почему я уверен, что технология разработки на базе моделей будет завоевывать все большую популярность. Темпы внедрения такого подхода будут расти.
Критические высказывания чаще всего касаются двух моментов. Во-первых, спецификация слишком объемная, а во-вторых, в ней отсутствует семантика, то есть она представляет собой в основном нотацию. Каждый, кто хотя бы раз внимательно смотрел стандарты, не стал бы так говорить. Язык — это довольно емкая сущность, но организованная в виде модулей, в силу чего его не нужно изучать полностью. Для эффективной работы с ним достаточно узнать лишь небольшую часть. А затем можно постепенно расширять знания либо применять модули языка по мере необходимости. Ведь для того, чтобы говорить по-английски, не нужно знать весь английский язык. То же самое относится и к UML. И нечто подобное мы сделали в UML 2.0.
Вы называете его языком. Значит, допустимо его использовать вместе с другими распространенными языками программирования, такими как C++, Си или Java?
Да, можно. Многие так и делают, причем я бы сказал, что значительная часть пользователей UML, по-существу, применяют его для моделирования традиционных, как правило, объектно-ориентированных языков программирования, а также в некоторых случаях и унаследованных языков, таких как Кобол и ему подобные. Те, которые моделируются.
Однако такие языки, как, например, Кобол, не имеют концепции, подобной машине состояний, верно? То есть той сущности, которая в некоторых предметных областях является первостепенным понятием. Но если работать с языками, подобными Си или C#, то в них такая сущность должна быть.
Да, в UML есть машина состояний. Более того, в версии 2.0 добавлены описания программной архитектуры, в частности позаимствовано понятие очереди. Над этими определениями работали эксперты из университета Карнеги—Меллона. Основная идея заключается в том, чтобы иметь возможность моделировать крупномасштабные системы, поскольку именно в этих случаях моделирование необходимо в первую очередь.
В крупномасштабных системах, подобных чему?
Например, в крупных телекоммуникационных системах, которые, как правило, являются очень сложными и содержат миллионы строк кода.
Что вы понимаете под машиной состояний и описаниями программной архитектуры?
Программная архитектура, по сути, это описание системы в терминах ее крупных компонентов и того, как эти компоненты взаимодействуют. Поэтому она дает абстрактное представление о системе, которое определяет основные связи, влияющие, помимо прочего, на способность системы к развитию, удобство ее обслуживания и даже реализации. Хорошая архитектура, как правило, использует план, определяющий разработку системы, но позже она указывает, как система может развиваться, или, если хотите, ограничивает ее развитие.
Машина состояний — это один из способов описания поведения, определяемого событиями. Поэтому, она есть, например, в распределенных системах (в банковских приложениях и во многих встроенных приложениях реального времени), то есть везде, где возникают события и необходимо соответствующим образом на них реагировать. А машина состояния дает возможность реагировать по-разному, в зависимости от того, что произошло раньше, поскольку в нее интегрировано понятие «истории предшествующих событий».
Предусматривает ли UML 2.0 возможность автоматической генерации кода? Или это особенность конкретной реализации UML 2.0?
UML 2.0 предоставляет основу для этого, но сам UML 2.0 не является, например, исполняемым языком. Необходимо уточнить его с помощью так называемых профилей. Можно создать профиль, скажем, для EJB или для определенной платформы, с учетом специфики предметной области, либо для конкретной компании. Другими словами, нужно уточнить язык, который позволяет это делать, так как это уточнение UML. Можно использовать в этих профилях стандартные инструменты UML.
Какими, по вашему, будут у UML «наследники», скажем, UML 3.0 или 2.1?
Конечно, будет еще немало версий, как и у других традиционных языков программирования. Но я рассчитываю на то, что нам удастся накопить больший опыт в разработке на базе моделей и мы начнем создавать всеобъемлющую теорию архитектуры языка моделирования. Я рассчитываю, что последующие поколения языков моделирования появятся достаточно скоро.
Это будет преемник UML?
Преемник UML, где устранены все ошибки, которые, безусловно, есть. Между прочим, авторы Фортрана признали, что и они делали ошибки. Сейчас у нас нет теории, которая позволила бы понять, как именно нужно было действовать. Но примерно через четыре-пять лет мы начнем создавать такую теорию, и тогда появится следующее поколение языков моделирования.
И вы считаете, что UML 2.0 станет последней серьезно переработанной версией этого языка?
Нет, я думаю, что повторится ситуация, которая была с Фортраном. Есть достаточно серьезная основа для того, чтобы люди его использовали и работали над ним еще долгое время. Так что будут появляться новые версии UML. Вопрос только в том, будет ли следующая версия столь же радикальной, как UML 2.0. И какие кардинально новые возможности появятся в следующем языке, который станет преемником UML.
Какого рода могут быть эти кардинально новые возможности?
Сейчас трудно сказать. Мы можем больше узнать о том, как уточнять эти языки таким образом, чтобы избежать ситуации, которая возникла при строительстве Вавилонской башни. Я думаю, что появится много новаторских идей, поскольку большинство таких языков требуют определенного базового набора концепций.
Кроме того, появляются определенные трудности из-за использования различных инструментов. Кто намерен создавать инструменты для языка для приложений страхования? Кто собирается его учить, кто планирует писать по этому поводу книги? Кто будет обучать специалистов и т. д.? Так что в наличии единой базы есть немало ценного.
И конечно, если общая основа неприемлема, тогда будут добавлены другие языки моделирования. И OMG действительно предоставила для этого возможность. Есть стандарт, который позволяет определять новые языки моделирования. Сам UML определен в таком языке, и пока существует только два необходимых, по мнению OMG, языка. Кроме того, имеется около 10 различных уточнений, стандартные уточнения UML или профили UML.
Именно в таком направлении мы движемся. Посуществу, UML достаточно адекватен для создания языков, специфических для предметной области. Поэтому вопрос не сводится к «противостоянию» конкретной предметной области и UML. Это, по-моему, не проблема.
Что вы понимаете под языком, специфическим для предметной области?
Специфический для предметной области язык — это язык, в котором есть абстракции, близкие к определенной предметной области и используемые в ней как базовые понятия. Скажем, есть понятие политики страхования или то, что в бизнесе является основной концепцией. Например, я должен иметь возможность выразить с помощью языка концепцию страховой политики. Если я могу определить стандартный, специфический для страхового бизнеса язык и использовать его в качестве основы, то от этого выиграют все.
Брайан Селик о критиках UML
В числе критиков UML — корпорация Microsoft. Они утверждают что в этом языке отсутствует семантика. Мы очень внимательно подошли к этому вопросу при создании UML 2.0 и тщательно определили семантику UML. Фактически, наверное, 70% работы, которую мы выполнили по UML 2.0, была связана именно с тем, чтобы как можно точнее определить семантику.
Среди критиков — самые разные люди, а также определенные компании, которые имеют здесь свой интерес. Их критика зачастую не имеет под собой реального основания. Например, один из сотрудников Microsoft утверждает, что использовать часть UML невозможно. Это неправда. Если не нужна машина состояний, то можно ее игнорировать и фактически работать с неким подмножеством концепций UML, теми, которые нужны. Допустимо полностью игнорировать остальные, и такая возможность действительно поддерживается в языке.
Очень жаль, что компании, столь значительные, как Microsoft, не принимают участия в определении UML. Так сложилось исторически. На мой взгляд, это приводит лишь к ненужной путанице на рынке. Поскольку то, что они делают, — это модификация UML, по крайней мере в моем понимании, и модификация лишь отчасти.
Недавно мне попалась статья о том, как Airbus и Boeing, эти два ярых конкурента, пришли к соглашению о стандарте на поставку частей для самолетов, признав, что за счет использования стандарта каждая из них сможет сэкономить 400 млн. долл. То разнообразие, которое сейчас у нас есть, только усложняет всем нам жизнь.
Не знаю, что именно движет Microsoft. Но, насколько мне известно (а я часто бываю в университетах, беседую с профессорами и могу сказать, что так происходит на всех континентах, где я был), UML изучают в рамках учебного курса. Спецификацию поддерживают многие производители. Так что никаких сомнений в том, будет ли UML сопутствовать успех или нет, не возникает. Он уже добился успеха. Вопрос заключается в том, что мы можем сделать, чтобы продвигать UML дальше.