Унифицированный язык моделирования (UML) завоевал широкое признание в качестве стандартного отраслевого языка для определения, визуализации, создания и документирования артефактов программных систем. Он упрощает сложный процесс проектирования ПО путем создания "чертежа" для построения системы. Созданием языка UML руководили ведущие специалисты по методологии компании Rational Software - Грэйди Буч (Grady Booch), Ивар Якобсон (Ivar Jacobson) и Джим Рамбо (Jim Rumbaugh). В этой статье Джим Рамбо делится своим мнением о новой эпохе разработки ПО, о ее влиянии на новые требования, выдвигаемые к языку UML, и об оптимальных методах их выполнения.
Новая эпоха разработки ПО
Новая эпоха в электронном мире перевернула прежние предположения с ног на голову - прежние подходы к бизнесу и программному обеспечению более не смогут приносить успех. Недавние новички интерактивного бизнеса стоят больше, чем солидные корпорации, кующие железо. Такие традиционные предприятия, как банки и биржи, пробиваются в Интернет, пытаясь не допустить перехода своих клиентов к новым конкурентам. Музыкальные издатели борются со свободным распространением своих продуктов по сети. Даже Верховный суд публикует свои решения в Интернете.
Электронный мир теперь распределен, параллелен и взаимосвязан. Распределен - поскольку информация размещена во многих различных местах по всему миру. Времена единых центральных компьютеров давно прошли. Параллелен - поскольку деятельность происходит децентрализовано и одновременно. Одного потока управления теперь недостаточно ни для принятия делового решения, ни для выполнения программ. Взаимосвязан - поскольку какое-либо действие в одном месте может значительно повлиять на окружающий мир. Филиппинский создатель вируса может отключить половину серверов планеты. Простые компьютерные системы, языки и модели прошлого не могут соответствовать современным требованиям.
В этом новом мире существует множество движущих факторов. Десять лет назад большинство людей в компьютерной отрасли считали Интернет исследовательской забавой - сейчас у каждой пиццерии (по крайней мере в Калифорнии) есть своя web-страница. Возрастает число компаний, доверяющих критически значимые операции системам распределенных объектов предприятия. Эти объектно-ориентированные системы содержат распределенные серверы и базы данных, объединенные для поддержки высокопараллельных бизнес-операций. Все большее число отраслей для осуществления своей деятельности вынуждено взаимодействовать в режиме реального времени. Банки, авиалинии и телефонные компании не могут работать без интенсивного обмена информацией между всеми действующими лицами. Наконец, устройства реального времени встречаются теперь повсюду - в машинах, приборах, бытовой электронике, зданиях. Проблемы их работы перестали быть узкой специализированной областью и касаются теперь каждого из нас.
Новый электронный мир несет с собой большие возможности, но они даются ценой высоких затрат на разработку. В чрезвычайно сложных взаимодействиях параллельных распределенных систем очень трудно разобраться, не говоря уже о предсказании. Основной проблемой являются нечеткие определения. Раньше определения монолитной системы влияли только на нее саму, и если она работала не в точном соответствии с определениями, никто особо не беспокоился. Но современной бизнес-системе может понадобиться взаимодействие с системой на другом конце земного шара, причем обе могли быть созданы людьми, никогда не слыхавшими друг о друге. Ошибка в следовании определениям может вызвать ошибки, распространяющиеся по всему миру. С распределенной системы нельзя снять резервную копию и ее нельзя перезапустить, если в какой-либо части обнаружится сбой. Система в целом должна работать, несмотря на сбои, ошибки или порчу данных в некоторых ее частях. Большинство современных систем являются системами реального времени. Большое значение для клиентов и партнеров имеет согласованность по времени. И в завершение всего, производительность сложных систем часто бывает нелинейной и не может быть предсказана путем простой экстраполяции.
Как же справиться со всеми этими проблемами? Для этого можно использовать те же методы, которые применяются инженерами любой области: моделирование до построения, создание архитектуры на основе прежнего опыта, процесс, основанный на оптимальным методиках, повторное использование компонентов, а также инструменты, позволяющие повысить эффективность использования времени и навыков разработчика. Предоставление этих возможностей разработчикам является основной задачей компании Rational.
Язык UML в электронном мире
Хорошо вписывающийся в условия нового мира, язык UML был специально разработан для распределенной, параллельной и связанной среды. Он основан на объектах. Объекты распределены - каждый поддерживает свое собственное состояние, отличное от других. Объекты параллельны - каждый из них потенциально может действовать параллельно с другими. Объекты связаны - каждый из них может отправлять другим сообщения через сеть соединений. Язык UML не привязан к какой-либо отдельной платформе или языку программирования, поэтому он хорошо подходит для соединения сетей различных систем. Он разрабатывался с учетом гибкости и поэтому способен адаптироваться к возникающим новым проблемам.
Разработка языка UML началась в компании Rational в 1995 году с объединения методов Буча и OMT. Процесс разработки было решено сделать общедоступным. В 1997 году созданная общими усилиями многих компаний спецификация языка была принята группой OMG (рабочей группой по развитию стандартов объектного программирования). Это был язык UML версии 1.1. Компания Rational затем передала права на UML группе OMG cцелью сделать этот язык общедоступным стандартом. С тех пор комиссия OMG, включающая представителей различных компаний, работала над разъяснением и исправлением ошибок исходной спецификации, выпустив ее обновление в 1998 г. (версия 1.3). Выпуск второго обновления ожидается в конце 2000 г. (версия 1.4). Активное участие в работе комиссии приняли эксперты компании Rational. В процессе обновления были устранены многие внутренние проблемы в метамодели языка UML, пояснены неопределенности исходного документа, улучшено единообразие обозначений и исправлен ряд средств, использующихся в специализированных областях. Но в общем и целом, большинство обычных пользователей не заметит многих отличий. Пожалуй, наиболее существенным изменением в версии UML 1.3 стал пересмотр формулировок отношений между прецедентами, но даже это не представляет собой очень крупную модификацию. Наиболее значительным дополнением версии UML 1.4 станут руководства по созданию профилей - адаптаций языка UML для конкретных прикладных областей. Конечно, специфические детали языка претерпели много изменений, но в общем язык UML пока остается тем же языком с теми же возможностями, что и исходная версия.
Усилия компании Rational по расширению языка UML
Параллельно с работой по очистке документации по UML было предпринято несколько инициатив по расширению языка UML для новых прикладных областей, включая системы и базы данных Web. Некоторые из этих инициатив были предприняты группой OMG, другие - отдельными компаниями, такими как Rational.
Чтобы не отстать от быстро изменяющегося мира электронного бизнеса, почти всем компаниям необходима разработка своих web-систем. Джим Коннален (Jim Conallen) вместе с другими специалистами Rational разработал способ моделирования web-систем с помощью языка UML и приложения Rational Rose. Эта возможность предлагается в виде профиля UML, позволяющего разработчикам моделей представлять различные виды элементов web-приложения - клиентские и серверные страницы, формы, кадры и т.д. Профиль содержит набор стереотипов для различных элементов и их отношений. Этот подход описан в книге Коналлена Building Web Applications with UML (Addison Wesley Longman, 2000). Данный профиль входит в состав последних версий Rational Rose.
Почти все приложения электронного бизнеса используют базы данных. Одной из наиболее сложных проблем разработки систем долго являлось координирование языков программирования и баз данных, поскольку их различные способы объявления структуры данных приводят к неуловимым противоречиям и трудностям при переносе информации между программами и базами данных. Использование единой модели UML, лежащей в основе как программного кода, так и схем баз данных, позволяет избежать многих из этих проблем. Компания Rational разработала для UML профиль моделирования баз данных, который поддерживается в различных версиях приложения Rational Rose. Этот профиль позволяет разработчику сконструировать логическую модель информации и модель таблиц физической базы данных, полученную на основе этой информации. Наличие двух моделей позволяет разработчику настроить и оптимизировать структуру базы данных, что имеет немаловажное значение при разработке баз данных. Поскольку обе модели связаны между собой, изменения в одной из них отражаются на другой, что позволяет избежать противоречий.
Инициативы группы OMG
Инициативы группы OMG реализуются через процесс создания RFP (запросов на предложения). Рабочая группа OMG определяет существующую потребность и выпускает RFP с формулировкой требований и рекомендацией компаниям-участникам предлагать свои решения. Обычно несколько компаний объединяются вместе для подачи совместного предложения. Группа OMG предлагает подателям отдельных предложений не втягиваться в споры, а совместно выработать объединенные предложения. Это вынуждает идти на компромисс, который, несмотря на частое раздувание содержания предложения, также способствует его всеобщему принятию - желанной цели любого стандарта. По этим причинам язык UML более запутан, чем он мог бы быть, являясь жестко согласованным со взглядами одной компании, но зато более всеобъемлющ и общепринят.
Ниже приведены несколько основных инициатив OMG.
Моделирование систем реального времени - важнейшая инициатива, добавившая в язык UML возможность моделирования систем реального времени и разработанная под руководством Брэна Силика (Bran Selic) из компании Rational. Из-за своего большого объема эта работа была разбита на несколько меньших RFP. Первый запрос касается моделирования аспектов времени, планирования и производительности. Исходное предложение было недавно представлено консорциумом, включающим всех лидеров в области моделирования систем реального времени (поэтому это предложение, вероятно, будет принято). Каждое исходное предложение должно сначала получить отзывы от членов OMG, а затем пройти повторно, поэтому эта работа будет завершена в следующем году. После этого, инициаторы предложения о моделировании систем реального времени поднимут следующую часть проблемы: моделирование надежности и отказоустойчивости. Вероятнее всего, второе предложение будет подано теми же разработчиками.
Важным аспектом систем реального времени является их архитектурная структура. В 1999 году мы с вместе с Брэном Силиком разработали профиль UML под названием UML-RT, который позволяет иерархически строить системы из инкапсулированных модулей (капсул) с четко определенными интерфейсами (портами) и явными каналами связи (соединителями). С тех пор мы обнаружили, что эти архитектурные концепции полезны для большинства систем. В то же время, подготовка к следующему значительному обновлению языка UML (версии 2.0) показала, что некоторые другие эксперты и языки моделирования используют очень похожие концепции. Подобными концепциями обладает, например, язык SDL, используемый в телекоммуникации, а также некоторые языки описания аппаратного обеспечения. Таким образом, внедрение в язык UML конструкций архитектурного моделирования является частью общей работы по его расширению и не будет ограничено только группой по моделированию систем реального времени.
Определенная модель выполнения - отсутствие этой модели является, возможно, наиболее крупным недостатком исходной спецификации языка UML. Статическая структура моделей UML получила четкое определение, но последовательности выполнения этих моделей были лишь расплывчато словесно описаны. Пропуск точной спецификации поведения моделей при выполнении был первоначально верным решением, поскольку нашей целью являлось определение и опубликование конструкций UML. Однако, один из первых запросов на предложение по расширениям UML заключался в определении действий, поддерживаемых UML, и семантики их выполнения. Со стороны Rational эта работа проводилась Брэном Силиком и мной в сотрудничестве со специалистами других компаний, занимающимися моделированием систем реального времени, языками описания действий и телекоммуникациями. Все участники объединились в единую команду. Первая версия этого предложения недавно была подана на рассмотрение. В нем содержится модель выполнения, поддерживающая высокопараллельные действия без излишних определений управления, необходимых в основных языках программирования. Это предложение нацелено не на изобретение еще одного языка программирования, а на создание семантической базы, на основе которой в UML можно точно определить воздействие языков программирования.
Обработка данных предприятия - в этой области было выдвинуто несколько инициатив. Предстоит рассмотрение предложений по распределенной объектной обработке данных предприятия (EDOC, Enterprise Distributed Object Computing) и интеграции приложений предприятия (EAI, Enterprise Application Integration). Эти предложения существенно совпадают между собой (побочный эффект демократических методов группы OMG), но они поданы практически одними и теми же разработчиками, предпринимающими шаги по координации обоих предложений. Эти инициативы будут определять профили, описывающие способы создания крупных, распределенных, параллельных систем предприятия, управляемых событиями. В компании Rational это направление возглавляет Войтек Козачинский (Wojtek Kozaczynski).
Процесс разработки - другая инициатива касается структуры определения процессов разработки программного обеспечения. Ее создание могло бы обеспечить стандартный способ определения таких процессов, как RUP (Rational Unified Process). Рекомендатели заявляют, что это позволит организациям использовать несколько процессов и легко сравнивать их между собой. Я скептически отношусь к этому утверждению - по моему мнению, организация должна выбрать один процесс и придерживаться его, - но в любом случае, возможность выразить процесс RUP в такой структуре достаточно важна, поэтому компания Rational принимает участие в этой инициативе. Со стороны Rational эту работу ведет Филипп Крюхтен (Philippe Kruchten).
Другие инициативы - существует также еще несколько связанных инициатив, таких как стандарт хранения данных, сопоставление CORBA и UML, а также формат XMI для обмена моделями UML в текстовом формате. Существуют группы, создающие профили на основе UML для различных прикладных областей, но я не буду их обсуждать, поскольку они представляют скорее способы использования языка UML, чем его изменение.
Работа над созданием UML 2.0
В качестве стандарта UML во многих отношениях подобен языку программирования. Используя язык, люди открывают потребности внесения в него новых возможностей. Однако, слишком частое изменение языка нежелательно - пользователям необходимо время, чтобы понять новую версию и накопить опыт ее использования. Разработка инструментов (таких как Rational Rose) поддержки языка также требует времени и слишком быстрое его изменение приводит к риску потери этой инструментальной поддержки. Тем не менее, для поддержки возникающих новых потребностей языкам необходимо развитие. По моему мнению, коренное обновление языков, включая UML, должно проводиться примерно через каждые пять лет. Некоторые разработчики UML приводят доводы в пользу более быстрых изменений, но я думаю, что это мнение неадекватно завышает преимущества новых возможностей по сравнению со стоимостью нестабильности. В любом случае, такой политический, основанный на работе комиссии процесс, как работа группы OMG (или любой организации, занимающейся стандартами), достаточно инерционен, поэтому эволюция языка UML требует времени независимо от желания людей.
Планирование новой версии UML уже началось. Группа OMG разослала запрос на предлагаемые изменения, на который было получено почти 30 ответов. Некоторые ответы касались лишь конкретных областей, другие содержали длинные списки предлагаемых новых возможностей. Для получения более короткого списка изменений, которые могут быть реализованы в разумные сроки, ответы были сжаты и разбиты по приоритетам. Результатом явился набор RFP, выпущенный группой OMG в сентябре 2000 года.
- Инфраструктура UML . Реорганизация внутренней структуры метамодели UML в более модульный вид для повышения расширяемости и лучшего соответствия другим стандартам OMG, в особенности использованию метаобъектов (MOF, meta-object facility) и формату обмена XMI. Эта инициатива не затрагивает непосредственно конечных пользователей, но упрощает изменение языка и создание профилей, которые в результате должны стать более понятными и удобными.
- OCL . Язык ограничения объектов (OCL, Object Constraint Language) является описательным текстовым языком для создания ограничений. Он используется в спецификации UML, выражая правила для корректно построенных моделей. Этот язык нуждается в собственной метамодели (в UML) и дополнительных возможностях для поддержки последних изменений UML. Цель этой инициативы достаточно узка и не затрагивает непосредственно большинство конечных пользователей.
- Суперструктура UML . Этот вопрос касается конечных пользователей. К основным направлениям работы относятся: моделирование архитектурной структуры, разработка на основе компонентов, ослабление ограничений структуры графиков операций и настройка некоторых отношений UML. Пользователи, вероятно, смогут использовать некоторые новые обозначения. Эти изменения должны расширить применение UML на тех стадиях процесса разработки, где этот язык в настоящее время несколько слаб.
- Формат обмена диаграмм . Исходная спецификация UML определила метамодель для семантической модели диаграмм, но не для их формата. Теперь формат диаграмм должен позволять их обмен между инструментами различных производителей. Я надеюсь (хотя и несколько сомневаюсь), что этим вопросом займутся только действительные разработчики инструментов, а не дилетанты, ни разу не создававшие инструментальных программ. Этот запрос был выпущен позже остальных в целях смещения начала работы над предложением.
После разработки изменений для UML 2.0 на них будет наложено требование поддержки максимально возможной совместимости с существующими моделями UML. Разработчики и их компании вложили крупные инвестиции в свои модели и необходимость изменения этих моделей крайне нежелательна. Кроме того, в тех вопросах, в которых для удовлетворения новых потребностей могут быть расширены существующие концепции, распространение новых концепций должно быть ограничено. В то же время будет предпринята попытка избавиться от неиспользуемых концепций, в особенности от стереотипов, имеющих лишь имена без семантического описания. (Подсказка: если определение состоит из одного или двух предложений без структуры или семантики - это вероятный кандидат на удаление.)
Работа будет проводиться в две стадии с получением промежуточных отзывов. Планируемая дата ее завершения - январь 2002 года. Я ожидаю, что создание UML 2.0 затянется до конца года. (Я не боюсь давать прогнозы в печати. Проверим их правоту через два года.) Я ожидаю, что над различными областями этой задачи будут работать консорциумы из нескольких компаний. По некоторым запросам могут быть несколько предложений, но я рассчитываю на сотрудничество разработчиков в объединении своих предложений на второй стадии проекта. Наибольшей проблемой будет ограничение размножения средств языка, что всегда трудно осуществить в политическом процессе.
Перспективы
Сегодня UML является вполне применимым и удобным языком, поэтому не следует откладывать его изучение только потому, что он будет расширен через два года. Большая часть UML останется неизменной, а большинство его расширений скорее повлияют на границы его применения, чем изменят существующую семантику. Подобно любому языку, включая тот, на котором написана эта статья, UML является живым языком, развивающимся в соответствии с меняющимися потребностями. Его широкое признание вместе с возможностью расширения должны убедить любого потенциального пользователя UML в необходимости приложения усилий для изучения этого языка.