Что такое The UML

Структура определения языка

Это, наверное, самая короткая часть лекции. Здесь нам хотелось бы рассказать о том, как описан UML его авторами. Но прежде нужно поговорить о способах описания искусственных языков вообще (например, языков программирования).

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

Как же определен UML? Довольно часто компиляторы и IDE языков программирования написаны с использованием этих же языков (вспомните хотя бы Turbo Pascal!). Подобный метод применяется и при описании UML. Авторы использовали так называемое четырехуровневое мета-моделирование. Первый уровень - это сами данные. Второй - это их модель, т. е., например, описание их в программе. Третий - метамодель, т. е. описание языка построения модели. Четвертый - мета-метамодель, т. е. описание языка, на котором описана метамодель. Для примера - следующий рисунок, позаимствованный из стандарта UML, показывает применение этого подхода к простым записям о котировках акций (рис. 1.4).

увеличить изображение
Рис. 1.4.

UML, как уже говорилось выше, описывается подобным образом. Метамодель - описание самого языка, мета-метамодель - описание формализма, с помощью которого производится описание языка. Все это сопровождается комментариями на естественном языке и примерами моделей. Организованное таким образом описание UML распространяется OMG абсолютно свободно и "лежит" на сайте OMG, по адресу http://www.omg.org/. Этот грандиозный документ насчитывает около тысячи страниц, и неподготовленному читателю имеет смысл ознакомиться в нем лишь с первым и последним разделами (краткий обзор и словарь терминов). Зато, если человек уже знаком с UML, изучение метамодели языка - весьма интересное и полезное занятие.

Терминология и нотация

Вопрос терминологии в программной инженерии, а тем более РУССКОЙ (не говоря уже об украинской) терминологии, - вопрос сложный. Дело в том, что оригинальная терминология UML не всегда последовательна и довольно запутана. Русская же терминология еще не успела сложиться, ведь UML как технология проектирования сама по себе очень молода, да и русскоязычная литература по нему стала появляться, как всегда, с некоторым опозданием. Некоторые авторы пытаются каждый термин передать "осмысленными", "хорошими русскими словами", что не всегда удается. С точки зрения автора, искать русские аналоги уже привычных английских терминов - занятие ненужное и даже вредное: вспомните, как трудно было вам найти нужную команду в меню русского MS Office, если вы привыкли пользоваться английским (в таких случаях родной язык сильно замедляет работу). Поэтому, наверное, проще использовать транскрипцию и не изобретать велосипед! В конце концов, хорошие английские слова (даже записанные русскими буквами) так же хороши, как и хорошие русские!

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

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

Вообще же, в UML используется четыре вида элементов нотации:

1. фигуры,
2. линии,
3. значки,
4. надписи.

Разберем все по порядку. Фигуры используются "плоские" - прямоугольники, эллипсы, ромбы и т. д. Но есть одно исключение - как мы увидим далее, на диаграмме развертывания для обозначения узлов инфраструктуры применяется "трехмерное" изображение параллелепипеда. Это единственное исключение из правил. Внутри любой фигуры могут помещаться другие элементы нотации.

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

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

Кстати об инструментах рисования. Мы уже упоминали, что такое ПО существует, и далее мы рассмотрим этот вопрос более подробно (проведя сравнительные исследования), пока же скажем лишь о нескольких наиболее заметных программах этого класса. К таким пакетам можно отнести:

• IBM Rational Rose;
• Borland Together;
• Gentleware Poseidon;
• Microsoft Visio;
• Telelogic TAU G2.

Наиболее известными из этой пятерки являются Rational Rose и Together. Это действительно средства для проектирования, а не рисования, как Visio. Долгое время автор этих строк использовал Poseidon, благо имеется бесплатная Community edition-версия этого продукта. Так было до тех пор, пока на одной из конференций по программной инженерии он не увидел TAU G2 от Telelogic. О TAU все слышали, но никто его не видел. Это легендарное средство моделирования, которое сочетает в себе мощь и простоту использования, предоставляя уникальную возможность начальной верификации моделей. И хотя интерфейс TAU выглядит несколько аскетично, его возможности и удобство работы просто потрясают. Все диаграммы в этом курсе созданы именно с использованием TAU, любезно предоставленным фирмой Telelogic (см. http://www.telelogic.com/).

Сейчас немного не к месту об этом говорить, но хочется упомянуть еще об одном чудесном продукте, который очень помог нам в написании этого курса. Это Zicom Mentor от Sparx Systems, выпустившего Enterprise Architect (см. http://www.sparxsystems.com.au/). Zicom Mentor - это простая и понятная утилита, представляющая собой словарь/ассистент по UML 2.0. Zicom Mentor ответит на ваши вопросы, поможет получить и проверить ваши знания, начать новый проект. Zicom Mentor включает интерактивные курсы, электронные книги и тесты и множество другой справочной информации по UML.

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

Выводы

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

Контрольные вопросы

• Как расшифровывается аббревиатура UML?
• Какая версия UML является текущей?
• Кто были авторами UML?
• Чем НЕ является UML?
• Какие программные средства, поддерживающие UML, вы знаете?
• Используются ли в UML "трехмерные" фигуры?