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

План

3.1 Виды диаграм

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

Виды диаграм

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

· Диаграмма вариантов использования (use case diagram)

· Диаграмма классов (class diagram)

· Диаграммы поведения (behavior diagrams)

· Диаграмма состояний (statechart diagram)

· Диаграмма деятельности (activity diagram)

· Диаграммы взаимодействия (interaction diagrams)

· Диаграмма последовательности (sequence diagram)

· Диаграмма кооперации (collaboration diagram)

· Диаграммы реализации (implementation diagrams)

· Диаграмма компонентов (component diagram)

· Диаграмма развертывания (deployment diagram)

Из перечисленных выше диаграмм некоторые служат для обозначения два и более за другие подвиды диаграмм. При этом как самостоятельные представления в языке UML используются следующие диаграммы:

· Диаграмма вариантов использования

· Диаграмма классов

· Диаграмма состояний

· Диаграмма деятельности

· Диаграмма последовательности

· Диаграмма кооперации

· Диаграмма компонентов

· Диаграмма развертывания

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

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

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

Рис. 3.1. Интегрированная модель сложной системы в нотации UML

В ранней литературе по UML как отдельная диаграмма рассматривалась еще диаграмма объектов. Однако в версии 1.3 она не включена в перечень канонических диаграмм, поскольку ее элементы могут присутствовать на диаграммах других типов.

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

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

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

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

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

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

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

Таким образом, в языке UML используется четыре основных вида графических конструкций :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процесс построения отдельных типов диаграмм имеет свои особенности, которые тесно связаны с семантикой элементов этих диаграмм. Сам процесс ООАП в контексте языка UML получил специальное название - рациональный унифицированный процесс (Rational Unified Process, RUP). Концепция RUP и основные его элементы разработаны А. Джекобсоном в ходе его работы над языком UML [18].

При дословном переводе термина RUP теряется некоторая дополнительная семантическая расцветка, связанная с двусмысленным толкованием английского Rational. Речь идет о другому варианте перевода - унифицированный процесс от фирмы Rational Software, сотрудниками которой являются из некоторых пор его разработчики, включая упомянутого выше А. Джекобсона.

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

Не нашли, что искали? Воспользуйтесь поиском по сайту: