Эту аббревиатуру часто можно встретить в описании возможностей разных средств разработки приложений. "Встроенные возможности UML-моделирования" - вот как звучит самая распространённая формулировка. Что же стоит за этими тремя буквами? Об этом я сейчас вам и расскажу.

Разработка приложений с давних пор тяготела к объектно-ориентированному подходу. Согласитесь, это действительно удобно - оперировать с переменными-объектами, содержимым базы данных как с объектом, да и вообще практически со всем остальным точно так же. Одно из самых главных достоинств объектов - их структурированность, она и делает их такими привлекательными в работе. Запомнить структуру одного объекта намного проще, чем тысячу переменных. Кроме того, поскольку в абсолютном большинстве объектно-ориентируемых архитектур (сиречь языков программирования и систем управления базами данных) классы объектов наследуемы, то в объектно-ориентированном программном коде (коде "на классах") всегда в основе лежит иерархия объектов. Именно это свойство объектно-ориентированного подхода и позволяет совершить уникальную вещь - автоматизировать процесс его написания.

К сожалению, писать код компьютер самостоятельно никогда не научится - с нуля, по крайней мере. Так сказали математики и даже доказали соответствующую теорему. Но ведь можно свести вбивание строк кода с клавиатуры к чему-то другому, верно? Как показал опыт визуальных конструкторов интерфейсов, окошки гораздо быстрее рисовать, чем описывать в коде "ручками". Если бы не Delphi (а также, в чуть меньшей степени, Visual Basic и PowerBuilder), не видать бы нам такого изобилия среди программ для Windows. Но ведь можно таким же образом упростить написание любого объектно-ориентированного кода - для этого достаточно представить в другом виде объекты и создать генератор кода, который будет из этого вида переводить их на язык компилятора. Процесс написания кода таким манером назвали моделированием.

UML - это специальный язык, описывающий объектно-ориентированные модели, которым в будущем суждено стать программным кодом. Расшифровывается же аббревиатура UML как Unified Modeling Language - унифицированный язык моделирования.

История этого языка началась, по компьютерным меркам, не так уж недавно, но и не сказать, чтобы сильно давно - в 1994 году. Так что UML практически ровесник нашей газеты. Зародился он в недрах компании Rational Software, которая задумала выпустить на рынок новый язык объектно-ориентированного моделирования - естественно, лучший, чем все, которые уже существовали на тот момент. Обычно начало истории UML связывают с фамилиями Буч, Рамбо и присоединившегося к ним позже Якобсона, которые в конце 1995 уже создали консорциум Object Management Group (OMG), который осенью 1996 выпустил версию 0.9 спецификации UML, которую многие считают важной вехой в истории языка. Поскольку после неё к консорциуму присоединились компании Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, сама прародительница UML Rational Software, а также Texas Instruments и Unisys. С их помощью в январе 1997 увидела свет версия 1.0 стандарта. Но сейчас, конечно, более актуальной является выпущенная в 2005-м версия 2.0.

Когда я говорил выше о моделировании, то рассказывал, в основном, о моделировании классов. Но на них UML не заканчивается, просто это самая близкая и милая сердцу программистов абстракция из богатого арсенала UML. На самом деле язык позволяет строить модели программного обеспечения, используя диаграммы классов, компонентов и прочих структурных единиц; диаграммы поведения (деятельности, состояний, прецедентов); диаграммы взаимодействия. Средства UML настолько мощны, что позволяют строить модели не только программного обеспечения, но и бизнес-процессов, т.е. деятельности целых компаний (и не обязательно только тех, которые занимаются разработкой программного обеспечения).

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

Часто такие диаграммы бывают довольно громоздки, особенно если число объектов и связей велико, но, тем не менее, они всегда очень наглядно иллюстрируют все объекты и связи между ними.

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

Кстати, очень часто эта расплывчатость называется критиками в качестве большого минуса UML как средства моделирования. Но мне кажется, что в моделировании, процессе, где участвуют не столько компьютеры, сколько люди, формализовывать всё и вся без разбора будет только во вред качеству. Однако вернёмся к нашим диаграммам.

На диаграмме деятельности показано разложение не чего-то, а именно деятельности на её составные части. Под деятельностью при этом понимается поведение системы, представленное в виде последовательного и параллельного выполнения отдельных действий. Диаграммы этого типа обычно используются при моделировании бизнес-процессов, технологических процессов, а также последовательных и параллельных вычислений. Диаграмма автомата, она же диаграмма состояний - диаграмма, на которой представлен конечный автомат с состояниями и переходами. Конечный автомат - математический термин, за которым скрывается определение последовательности состояний, в которые переходит объект в ответ на внешние события, а также ответные действия объекта на эти события. Конечный автомат прикреплён к какому-то другому элементу (например, классу) и служит для определения поведения его экземпляров. Диаграмма коммуникации (не путайте с диаграммой кооперации) изображает взаимодействия между частями составной. В ней явно указываются отношения между объектами, а время, как отдельное измерение, не используется, вместо этого применяются порядковые номера вызовов. В диаграмме последовательности, на которой изображено упорядоченное во времени взаимодействие объектов, изображаются участвующие в нём объекты и последовательность сообщений, которыми они обмениваются. Есть ещё такая штука, как диаграмма синхронизации. Это альтернативное представление диаграммы последовательности, явным образом показывающее изменения состояния с заданной шкалой времени, что может быть весьма полезно в приложениях реального времени.

Пусть вас не пугает обилие всяких видов диаграмм. На самом деле весь их спектр вряд ли будет использоваться в каждом проекте. Да и современные средства моделирования вряд ли дадут в них запутаться. Кстати, о средствах - я ведь о них ещё не рассказывал, кажется?

Средства UML-моделирования, как я уже говорил в самом начале статьи, есть уже во многих средствах разработки. Например, в CodeGear RAD Studio 2007 (это то, что раньше называлось Borland Developer Studio). Имеет встроенные возможности моделирования и другая среда от тех же разработчиков - JBuilder. Но, тем не менее, встроенные средства моделирования традиционно считаются менее мощными, нежели специализированные программные продукты. У той же Borland есть продукт Together, мощный продукт для UML-моделирования. Говоря о других подобных программах, нельзя не вспомнить Enterprise Architect (www.sparxsystems.com.au), UML Studio (www.pragsoft.com), Visual Paradigm for UML (www.visual-paradigm.com), а также PowerDesigner от Sybase.

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

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

Вадим СТАНКЕВИЧ,
dreamdrusch@tut.by