Моделирование на UML

UML — аббревиатура полного названия Unified Modeling Language. Правильный перевод этого названия на русский язык — унифицированный язык моделирования. Каждое из этих трех слов — точный термин.

UML — это язык
UML — это формальный искусственный язык, или другими словами, UML — это знаковая система для хранения и передачи информации, для которой строго и явно определены правила употребления и которая является плодом видимых усилий определенных лиц (Гради Буча, Ивара Якобсона и Джеймса Рамбо).

Как и любой формальный искусственный язык, UML содержит следующие части:

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

UML — это язык моделирования
Слово «моделирование», входящее в название UML, имеет несколько смысловых оттенков и сложившихся способов употребления. Обычно речь идет или о составлении модели, которая используется для описания моделируемого объекта или явления, или подразумевается составление модели, которая может быть использована для получения существенной информации о моделируемом объекте или явлении. UML является языком моделирования в первом смысле. Таким образом, модель UML — это, прежде всего, описание объекта или явления, а также и кое-что другое, что авторам UML удалось включить в язык, не нарушая принципа унификации.

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

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

Язык UML — это графический язык моделирования общего назначения, предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых при разработке программных систем.

Разберемся.

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

В процессе разработки приложения создается формальные или неформальные документы (артефакты): техническое задание (описание требований к приложению), функциональная спецификация, описание архитектуры приложения и др.

Мы будем все такие артефакты называть спецификациями, исходя из того, что спецификация — это декларативное описание того, как нечто устроено или работает.

При этом необходимо принимать во внимание три толкования спецификаций.

То, которое имеет в виду действующее лицо, являющееся источником спецификации (например, заказчик).
То, которое имеет в виду действующее лицо, являющееся потребителем спецификации (например, разработчик).
То, которое объективно обусловлено природой специфицируемого объекта.
Эти три трактовки спецификаций могут не совпадать, и, к сожалению, как показывает практика, сплошь и рядом не совпадают, причем значительно.

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

Визуализация.
Особенности человеческого восприятия таковы, что текст с картинками воспринимается легче, чем «голый» текст. А картинки с текстом (это называется «комиксы») — еще легче.

Модели UML допускают представление в форме картинок, причем эти картинки наглядны, интуитивно понятны, практически однозначно интерпретируются и легко составляются.

Посмотрите на следующий рисунок. Разве что-нибудь здесь непонятно?

purpose-uml
Таким образом, второе по важности назначение UML состоит в том, чтобы служить адекватным средством коммуникации между людьми.

Проектирование.
В оригинале данное назначение UML определено с помощью слова construct, которое мы передаем осторожным термином «проектирование». Речь идет о том, что UML предназначен не только для описания абстрактных моделей приложений, но и для непосредственного манипулирования артефактами, входящими в состав этих приложений, в том числе такими, как программный код.

Другими словами, одним из назначений UML является, например, создание таких моделей, для которых возможна автоматическая генерация программного кода (или фрагментов кода) соответствующих приложений. Более того, природа моделей UML такова, что возможен и обратный процесс: автоматическое построение модели по коду готового приложения.

Документирование.
Модели UML являются артефактами, которые можно хранить и использовать как в форме электронных документов, так и в виде твердой копии. На данный момент специфицировано представление моделей UML в форме документов в формате XMI, что обеспечивает практическую интероперабельность при работе с моделями. Другими словами, модели UML не являются вещью в себе, которыми можно только любоваться — это документы, которые можно использовать самыми разными способами, начиная с печати картинок и заканчивая автоматической генерацией человекочитаемых текстовых описаний.
Диаграммы UML: зачем они нужны?
Поговорим о том, как из слов языка UML (сущностей и отношений) конструируются предложения.

На первый взгляд, все очень просто: берутся сущности и, если нужно, указываются отношения между ними. В результате получается модель, то есть граф (с разнородными вершинами и ребрами), нагруженный дополнительной информацией. Но при более внимательном рассмотрении обнаруживаются проблемы.

Рассмотрим следующую аналогию с естественным языком. Каждая тройка «сущность» — «отношение» — «сущность» в модели вполне может рассматриваться как простое утверждение: 2 < 5, ртуть тяжелее железа, Ф.А. Новиков является преподавателем Политехнического университета (все это примеры отношений).

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

Если взять какую-нибудь книгу, то можно заметить, что помимо структуры предложений, имеется масса дополнительных структур: предложения объединены в абзацы, абзацы собраны в параграфы и главы, у которых есть заголовки, помимо обычных абзацев и заголовков есть врезки и сноски. И все эти дополнительные структуры по сути ничего не добавляют к содержанию книги, но серьезно влияют на ее читабельность. Текст, в котором нет этих структур, понять очень трудно.

Диаграммы UML и есть та основная накладываемая на модель структура, которая облегчает создание и использование модели.

Диаграмма (diagram) — это графическое представление некоторой части графа модели.

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

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

Существует специальная нотация для оформления диаграмм — фрейм (frame). Фрейм представляет собой рамку и ярлычок с названием диаграммы. Если с рамкой все просто – это прямоугольник, ограничивающий область в котором должны находиться элементы диаграммы, то название диаграммы записывается в ярлычке в специальном формате, приведенном на рисунке.

Возможные теги (типы) для диаграмм приведены в таблице. Теги, предлагаемые стандартом, записаны во второй столбец. Однако, как показывает практика использования языка, предлагаемые стандартом правила не всегда удобны и логически обоснованы, поэтому третий столбец таблицы содержит достаточно часто использующуюся альтернативу.

Название диаграммы Тег (стандартный) Тег (часто используемый)
Диаграмма использования use case или uc use case
Диаграмма классов class class
Диаграмма автомата state machine или stm state machine
Диаграмма деятельности activity или act activity
Диаграмма последовательности interaction или sd sd
Диаграмма коммуникации interaction или sd comm
Диаграмма компонентов component или cmp component
Диаграмма размещения не определен deployment
Диаграмма объектов не определен object
Диаграмма внутренней структуры class class или component
Обзорная диаграмма взаимодействия interaction или sd interaction
Диаграмма синхронизации interaction или sd timing
Диаграмма пакетов package или pkg package
Инструментальная поддержка UML
Авторы определяют UML следующим образом:

Язык UML — это графический язык моделирования общего назначения, предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых при разработке программных систем.
Вариант использования drawing ("Рисование диаграмм") подразумевает изображение диаграмм UML с целью обдумывания, обмена идеями между людьми, документирования и тому подобного. Значимым для пользователя (User) результатом в этом случае является само изображение диаграмм. Вообще говоря, в этом варианте использования языка поддерживающий инструмент не очень нужен. Иногда рисование диаграмм от руки фломастером с последующим фотографированием цифровым аппаратом может оказаться практичнее.

Вариант использования modeling ("Моделирование систем") подразумевает создание и изменение модели системы в терминах тех элементов моделирования, которые предусматриваются метамоделью UML. Значимым результатом в этом случае является машинно-читаемый артефакт с описанием модели. Мы будем называть такой артефакт моделью, деятельность по составлению модели называть моделированием, а субъекта моделирования называть архитектором (Architect). Вариант использования development ("Разработка приложений") подразумевает детальное моделирование, реализацию и тестирование приложения в терминах UML. Значимым для пользователя (Developer) результатом в этом случае является работающее приложение, которое может быть скомпилировано в язык, поддерживаемый конкретной системой программирования (Programming System) или сразу интерпретировано средой выполнения инструмента. Этот вариант использования наиболее сложен в реализации.

Современные инструменты поддерживают указанные варианты использования далеко не в равной степени. Все инструменты умеют (плохо или хорошо) визуализировать основные типы диаграмм UML, некоторые инструменты позволяют построить модель, допускающую какое-то дальнейшее использование, но только немногие инструменты могут генерировать исполняемый код и то, отнюдь, не для всех диаграмм.

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

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

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

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