На этом шаге рассмотрим типичные приемы моделирования аварийных ситуаций в UML.
Важная часть визуализации, специфицирования и документирования поведения класса или интерфейса – выявление аварийных ситуаций, которые могут порождать его операции. Если вы имеете дело с некоторым классом или интерфейсом, то его операции ясны из описания, но понять, какие аварийные ситуации они могут вызвать, нелегко, если это явно не указано в модели.
В UML аварийные ситуации представляют собой разновидность событий и моделируются как сигналы. События-ошибки можно присоединить к спецификации операций. Моделирование исключений в некотором смысле противоположно моделированию семейств сигналов. Основная цель последнего – специфицировать, какие сигналы могут получать активные объекты; цель же моделирования аварийных ситуаций состоит в том, чтобы показать, какие аварийные ситуации может порождать объект.
Чтобы выполнить эту задачу, требуется:
- для каждого класса и интерфейса и для каждой определенной в них операции рассмотреть нормальные и аварийные ситуации и смоделировать их в виде сигналов, передаваемых между объектами;
- организовать иерархию сигналов: на верхних уровнях разместить общие сигналы, на нижних – специализированные, и при необходимости ввести промежуточные исключения;
- указать для каждой операции, какие аварийные ситуации (сигналы) она может порождать. Это можно сделать явно на диаграмме (проведя зависимости со стереотипом send от операции к ее сигналам) или же использовать диаграммы последовательности, изображающие различные сценарии.
На рис. 1 представлена модель иерархии аварийных ситуаций, которые могут порождаться контейнерными классами из стандартной библиотеки, например классом-шаблоном Set (Установка).
Рис.1. Моделирование условий ошибки
В корне этой иерархии находится абстрактный сигнал SetError (УстановитьОшибку), а ниже расположены специализированные виды ошибок: Duplicate (Дублирование), Overflow (Переполнение) и Underflow (Потеря значимости). Как видно, операция add (добавить) может породить сигналы Duplicate и Overflow, а операция remove (удалить) – только сигнал Underflow. Вместо этого можно было бы убрать зависимости с переднего плана, перечислив их в спецификации каждой операции. Как бы то ни было, зная, какие сигналы может породить операция, вы сможете успешно создавать программы, использующие класс Set.
Сигналы, в том числе аварийных ситуаций, – это асинхронные события, происходящие между объектами. UML также предусматривает исключения, которые можно обнаружить в таких языках программирования, как С++ или Ada. Исключение является условием, при котором основной поток выполнения задачи прерывается и выполняется другой поток. Исключения – это не сигналы; они просто представляют собой удобный механизм для спецификации альтернативного потока управления внутри единственного синхронного потока выполнения задачи.
При моделировании событий исходите из следующих соображений:
- стройте иерархию сигналов так, чтобы можно было воспользоваться общими для них свойствами;
- не забывайте ассоциировать подходящий автомат с каждым элементом, который может получать события;
- обязательно моделируйте не только те элементы, которые могут получать события, но и те, которые могут их посылать.
Изображая событие в UML, в общем случае моделируйте иерархии событий явно, а их использование специфицируйте на заднем плане тех классов или операций, которые посылают или получают событие.
На следующем шаге рассмотрим термины и понятия конечных автоматов в UML.
