6. Диаграммы состояний класса

Диаграмма состояний в UML описывает все возможные состояния одного экземпляра определенного класса и возможные переходы между этими состояниями. Таким образом, она представляет все изменения состояний объекта как его реакцию на внешние воздействия.

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

1. Круг, обозначающий начальное состояние.

2. Окружность с маленьким кругом внутри, обозначающая конечное состояния (если есть).

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

4. Стрелка, обозначающая переход. Название события (если есть), вызывающего переход, отмечается рядом со стрелкой. Здесь же записывается охраняющее выражение. Оно может быть добавлено перед «/» и заключено в квадратные скобки (название_события[охраняющее_выражение]), т.е. это выражение должно быть истинным, чтобы переход имел место. Если при переходе производится какое-то действие, то оно добавляется после «/» (название_события[охраняющее_выражение]/действие).

5. Толстая горизонтальная линия либо с множеством входящих линий и одной выходящей, либо с одной входящей линией и множеством выходящих. Она обозначает объединение и разветвление соответственно (как в диаграммах деятельности).

Пример простейшей диаграммы представлен на рисунке 6.32. В ней отображены два состояния DVD диска и переходы между ними. Действия для каждого состояния не указываются.

Рис. 6.32

Диаграммы состояний могут быть вложены друг в друга для более детального представления отдельных элементов модели. Например, прохождение студентом некоторого учебного курса может быть представлено диаграммой сложного (составного) состояния, приведенной на рис. 6.33.

Рис. 6.33

6. Диаграммы компонентов системы

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

Рассматриваемая диаграмма является одним из двух типов так называемых диаграмм реализации. Вторым служит диаграмма размещения, которая будет рассмотрена позднее.

Компонент (component) — физически существующая часть системы, которая обеспечивает реализацию классов и отношений.

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

Рис. 6.34

Если компонент представляется на уровне типа, то в прямоугольнике записывается только имя типа с заглавной буквы в форме: <Имя типа> (см. рис. 6.35, а). Если же он представляется на уровне экземпляра (объекта), то его имя записывается в форме: <имя_компонента‘:' Имя типа> (см. рис. 6.35, б).

Р ис 6.35

В языке UML выделяют три вида компонентов:

1. развертывания, которые обеспечивают непосредственное выполнение системой своих функций. Ими могут быть библиотеки с расширением dll, Web-страницы на языке разметки гипертекста с расширением html и файлы справки с расширением hlp;

2. рабочие продукты, как правило, это файлы с исходными текстами программ, например, с расширениями h или срр для языка C++;

3. исполнения, представляющие собой исполняемые модули - файлы с расширением ехе.

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

• библиотека (library) - определяет разновидность компонента - в форме библиотеки;

• таблица (table) - разновидность - в форме таблицы базы данных;

• файл (file) - разновидность в виде файлов с исходными текстами программ;

• документ (document) - разновидность в форме документа;

• исполнимый (executable) —компонент, который может исполняться в узле.

Стандартные типы компонентов (стереотипов) имеют традиционные графические изображения. Это – библиотеки или файлы с исходными текстами программ или документами, изображения которых показаны на рис. 6.36.

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

Р ис. 6.36

Рис. 6.37. Графическое изображение интерфейсов на диаграмме компонентов.

Кроме того, интерфейс на диаграмме компонентов может быть изображен в виде прямоугольника класса со стереотипом <<interface>> и секцией поддерживаемых операций (рис. 6.37, б). Как правило, этот вариант обозначения используется для представления внутренней структуры интерфейса.

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

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

Рис.6.38.

Так, например, изображенный на рис. 6.38 фрагмент диаграммы компонентов представляет информацию о том, что компонент с именем Control зависит от импортируемого интерфейса IDialog, который, в свою очередь, реализуется компонентом с именем DataBase. При этом для второго компонента такой интерфейс является экспортируемым. Изобразить связь второго компонента DataBase с интерфейсом IDialog в форме зависимости нельзя, поскольку этот компонент реализует указанный интерфейс.

Другим случаем отношения зависимости на диаграмме компонентов является отношение программного вызова и компиляции между различными видами компонентов. Для фрагмента диаграммы компонентов, приведенного на рис. 6.39, наличие подобной зависимости означает, что исполнимый компонент Control.exe использует или импортирует некоторую функциональность компонента Library.dll, вызывает страницу гипертекста Home.html и файл помощи Search.hlp, а исходный текст самого компонента хранится в файле Control.cpp. При этом характер отдельных видов зависимостей может быть отмечен дополнительно с помощью текстовых стереотипов.

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

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

Рис. 6.39

Р ис. 6.40. Графическое изображение зависимости между компонентом и классами.

Рис. 6.41. Графическое изображение компонента-экземпляра, реализующего отдельные объекты.

Пример диаграммы компонентов в нотации UML 2 приведен на рис. 6.42.

Рис. 6.42

В этом примере компонент Till (Касса) может взаимодействовать с компонентом Sales Server (Сервер продаж) с помощью интерфейса sales message (Сообщение о продажах). Поскольку сеть ненадежна, то компонент Message Queue (Очередь сообщений) установлен так, чтобы касса могла общаться с сервером, когда сеть работает, и разговаривать с очередью сообщений, когда сеть отключена. Тогда очередь сообщений сможет поговорить с сервером, когда сеть снова станет доступной. В результате очередь сообщений предоставляет интерфейс для разговора с кассой, и требует такой же интерфейс для разговора с сервером. Сервер разделен на два основных компонента: Transaction Processor (Процессор транзакций), реализующий интерфейс сообщений, и Accounting Driver (Драйвер счетов), который общается с Accounting System (Системой ведения счетов).