Графическая нотация uml

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

Таблица 9-1

Cущности	Отношения	Диаграммы…
Структурные (имена существительные) – классы, интерфейсы, кооперации, прецеденты, активные классы, компоненты, узлы. Поведенческие (глаголы, описывают поведение модели во времени и пространстве) – взаимодействия, автоматы. Группирующие (организующая часть модели) – пакеты. Аннотационные (комментарии) – примечания.	Зависимость (отношение ис-пользования, согласно которо-му изменение в спецификации одного элемента может повли-ять на другой элемент, его использующий); Ассоциация (структурное отношение, описывающее совокупность связей; например, целое – часть); Обобщение (отношение “специализация-обобщение”; так потомок наследует свойства своего родителя); Реализация (семантическое от-ношение между классификато-рами; например, “интерфейс-класс”).	классов; объектов; прецедентов; последовательостей; кооперации; состояний; действий; компонентов; развёртывания; Диаграмма – это подмножетво всех комбинаций сущностей и отношений.

Для проектирования используются диаграммы следующих видов:

• use case – прецедентов использования

• class – классов

• behavior – поведения:

• statechart – состояний

• activity – деятельности

• interaction– взаимодействия:

• sequence – следования

• collaboration – совместной работы, кооперации

• implementation – реализации:

• component – компонентов (конфигурации)

• deployment – распределения (размещения процессов на процессорах)

Вопрос 2. Диаграммы классов

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

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

Рис 9-6. Изображение отношений между классами: ассоциации, зависимости и обобщения (наследования)

Агрегирование (Aggregation) – это особый тип отношения ассоциации, когда его можно рассматривать как отношение «часть-целое». Пример приведён на рис. 9-7, где объект класса Institute может состоять из произвольного количества объектов класса Faculty. Очевидно, что такая диаграмма близка к логической схеме данных типа ER.

Рис 9-7. Пример изображения отношений агрегирования между классами

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

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

Диаграмма следования делает упор на временную последовательность передаваемых сообщений; она имеет два измерения (см. рис. 9-8). Одно - слева направо в виде вертикальных линий, изображающих объекты, участвующие во взаимодействии.

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

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

Рис 9-8. Пример диаграммы следования

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

Рис. 9-9. Пример: диаграмма состояний кондиционера воздуха

Кроме того, на переходе могут указываться действия, производимые объектом в ответ на внешние события (при переходе из одного состояния в другое или при нахождении в определенном состоянии). Срабатывание перехода может зависеть не только от наступления некоторого события, но и от выполнения определенного условия, называемого пусковым условием. Пусковое условие записывается в квадратных скобках. Объект перейдет из одного состояние в другое, только если произошло указанное событие и пусковое условие приняло значение "истина". Вопрос 3.

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

Рис. 9-10. Пример: диаграмма активности при приготовлении напитка

Изложенное описывает только небольшую часть SDL. В целом язык заимствует многое из известных методик и унифицирует, стандартизует все это. Степень общности, уровень абстракции языка виден уже из Таблицы 9-1. Язык нацелен на передачу знаний между разработчиками-программистами. Под моделированием понимается специфика-ция проекта и проверка спецификаций путем «прокрутки» проекта на бумаге или в голове. Предполагается, что разработчики будут применять в проектах свои подмножества средств языка, расширяя при необходимости ядро (средства расширения формализованы и потому понятны). При этом поощряется многомодельность – описание одного проекта различными моделями.