Особенности изображения диаграмм UML

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

В диаграммах UML есть четыре типа графических обозначений.

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

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

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

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

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

Дополнительные значки или украшения - фигуры фиксированного размера и формы. Они размещаются внутри или вне других графических конструкций; их примеры - окончания связей элементов диаграмм или графические обозначения кванторов видимости атрибутов и операций классов.

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

Основные рекомендации при графическом изображении диаграмм:

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

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

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

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

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

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

Количество типов диаграмм для каждой модели приложения не фиксируется. Для простых приложений не нужно строить все типы диаграмм, их перечень зависит от конкретного проекта системы. Так, модель системы может не иметь диаграммы развертывания для приложения, выполняемого на компьютере пользователя, локально.

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

Особенности построения отдельных типов диаграмм связаны с семантикой элементов этих диаграмм, а процесс ООАП в контексте UML называется «Ррациональный унифицированный процесс» (Rational Unified Process, RUP).

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

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