Поговорим о том, как из слов языка 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 |