Типичные приемы моделирования Семейства сигналов

В большинстве систем, управляемых событиями, события сигналов образуют иерархию. Например, автономный робот может различать внешние сигналы, та­кие как Столкновение, и внутренние, например АппаратныйОтказ. Однако мно­жества внешних и внутренних сигналов могут пересекаться. И даже внутри этих двух широких областей классификации можно обнаружить частные разновидно­сти. К примеру, АппаратныйОтказ можно подразделить на ОтказБатареи и От-казДвигательногоМеханизма. Допускается и дальнейшая специализация. Так, разновидностью сигнала Отказ ДвигательногоМеханизма является Оста-новЭлектромотора. (Об отношениях обобщения рассказано в главах 5 и 10.)

Моделируя таким образом иерархии сигналов, можно специфицировать поли­морфные события. Рассмотрим, к примеру, автомат (см. главу 21), в котором неко­торый переход срабатывает лишь при получении сигнала ОстановЭлектромотора. Поскольку этот сигнал является в иерархии листовым, то переход инициируется только им, так что полиморфизм отсутствует. Но предположим теперь, что вы по­строили автомат, в котором переход срабатывает при получении сигнала Аппа­ратныйОтказ. В этом случае переход полиморфен, его возбуждает как сам сигнал АппаратныйОтказ, так и любая его специализация (разновидность), включая От­казБатареи, ОтказДвигательногоМеханизма и ОстановЭлектромотора.

Моделирование семейства сигналов включает следующие этапы:

1. Рассмотрите все разновидности сигналов, на которые может отвечать дан­ное множество активных объектов.

2. Выявите схожие виды сигналов и поместите их в иерархию типа «обобщение/специализация», используя наследование. На верхних уровнях иерар­хии будут располагаться общие сигналы, а на нижних - специализиро­ванные.

3. Определите возможности полиморфизма в автоматах этих активных объек­тов. Обнаружив полиморфизм, скорректируйте иерархию, добавив при не­обходимости промежуточные абстрактные сигналы.

На рис. 20.6 приведена модель семейства сигналов, которые могли бы обрабатываться автономным роботом. Обратите внимание, что корневой сигнал (СигналРоботу) является абстрактным (см. главу 5), то есть прямое создание его экземпляре невозможно. У этого сигнала есть две конкретные специализации (Столкновени и АппаратныйОтказ), одна из которых (АппаратныйОтказ) специализируете и дальше. Заметьте, что у сигнала Столкновение есть один параметр.

Исключения

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

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

моделирование исключений производится так:

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

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

3. Укажите для каждой операции, какие исключения она может возбуждать. Это можно сделать явно на диаграмме (проведя зависимости типа send от операции к ее исключениям) или же поместить перечень исключений в спе­цификацию операции.

На рис. 20.7 представлена модель иерархии исключений, которые могут возбуж­даться контейнерными классами из стандартной библиотеки, например шаблоном (см. главу 9) класса Set. В корне этой иерархии находится абстрактный сигнал Exception, а ниже расположены специализированные исключения: Duplicate, Overflow и Underflow. Как видно, операция add возбуждает исключения Duplicate и Overflow, а операция remove - только исключение Underflow. Вме­сто этого можно было бы убрать зависимости с переднего плана, перечислив воз­буждаемые исключения в спецификации каждой операции. Как бы то ни было, зная, какие исключения может возбудить операция, вы сможете успешно создавать про­граммы, использующие класс Set.

Советы

При моделировании событий исходите из следующих соображений:

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

• не прибегайте к посылке сигналов и тем более к возбуждению исключении, если позволительно обойтись обычным потоком управления;

• не забывайте ассоциировать подходящий автомат с каждым элементом, ко­торый может получать события;

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

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