Диаграммы прецедентов: крупным планом

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

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

"Хватит ходить вокруг да около!" - воскликнет нетерпеливый читатель. Уже заканчиваем. Мы просто хотели мягко подвести читателя к вопросу об отношениях между прецедентами. А отношения эти весьма многообразны. Начнем со старого знакомого - отношения обобщения (наследования, генерализации). О генерализации мы уже говорили не раз, когда рассматривали диаграммы классов. Но все же напомним суть этого понятия. Как говорят классики, обобщение - это отношение специализации (обобщения), в котором объекты специализированного элемента (потомка) могут быть подставлены вместо объектов обобщенного элемента (родителя, или предка).

Точно так же, как мы обычно поступаем с классами, после того как мы выделили и описали каждый прецедент, мы должны просмотреть их все на предмет наличия одинаковых действий - поискать, а не выполняются ли (используются) некоторые действия совместно несколькими вариантами использования. Этот совместно используемый фрагмент лучше описать в отдельном прецеденте. Таким образом мы уменьшим избыточность модели за счет применения обобщения прецедентов (иногда, правда, говорят не об обобщении, а об использовании прецедентов; почему - сейчас поймете). Как это и "положено" при наследовании, экземпляры обобщенных прецедентов (потомков) сохраняют поведение, присущее обобщающему прецеденту (предку). Другими словами, наличие (использование) в варианте использования X обобщенного варианта использования Y говорит нам о том, что экземпляр прецедента X включает в себя поведение прецедента Y. Обобщения применяются, чтобы упростить понимание модели вариантов использования за счет многократного задействования "заготовок" прецедентов для создания прецедентов, необходимых заказчику (помните, как мы рассматривали вопрос о том, всегда ли необходимо создавать новый класс, или лучше воспользоваться готовым решением, чувствуете аналогию?). Такие "полные" прецеденты называются конкретными прецедентами. "Заготовки" прецедентов, созданные лишь для многократного использования в других прецедентах, называют абстрактными прецедентами. Абстрактный прецедент (как и абстрактный класс) не существует сам по себе, но экземпляр конкретного прецедента демонстрирует поведение, описываемое абстрактными прецедентами, которые он (повторно) использует. Прецедент, который экторы наблюдают при взаимодействии с системой ("полный" прецедент, как мы называли его ранее), часто называют еще " реальным " прецедентом.

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

Изображается обобщение, как, конечно, помнит внимательный читатель, линией с "незакрашенной" треугольной стрелкой на конце. Обобщение - это отношение между предком и потомком, и стрелка всегда указывает на предка. Если вспомнить, что потомки наследуют (используют) свойства предка, то вполне логично вспоминается наше утверждение о том, что стрелки в UML всегда направлены в сторону того, от кого что-то требуют, чьими сервисами пользуются (рис. 6.9):

Рис. 6.9.

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

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

А как же изображается включение? Да очень просто - как зависимость (пунктирная линия со стрелкой, помните?) со стереотипом <<include>>. При этом стрелка направлена, естественно, в сторону включаемого прецедента. Этот факт легко объяснить, если вспомнить утверждение, которое мы уже несколько раз использовали в этом курсе: стрелка всегда направлена в сторону того элемента, от которого что-то требуется, чьими сервисами пользуются. А если считать, что объемлющий прецедент включает в себя, заимствует (использует) поведение включаемых прецедентов, становится ясно, что стрелка может быть направлена только таким образом. А вот и диаграмма, иллюстрирующая вышесказанное, которую мы позаимствовали из Zicom Mentor (рис. 6.10):

увеличить изображение
Рис. 6.10.

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

На очереди - отношение расширения. Чтобы уяснить себе смысл расширения, представим себе, что мы говорим об оплате некоторого купленного нами товара. Мы можем оплатить товар наличными, если сумма не превышает $ 100. Или оплатить кредитной картой, если сумма находится в пределах от $ 100 до $ 1000. Если же сумма превышает $ 1000, нам придется брать кредит. Таким образом мы расширили понимание операции оплаты купленного товара и на случаи, когда используются другие средства оплаты, нежели наличные. Но сами эти случаи возникают только при строго определенных условиях: когда цена товара попадает в определенные рамки.

Расширение дополняет прецедент другими прецедентами, "срабатывающими" при некоторых условиях, - просто добавляет в исходный прецедент последовательность действий, содержащуюся в другом прецеденте. Отношение расширения прецедента А к прецеденту В означает, что экземпляр прецедента В может включать в себя (при определенных условиях, которые могут быть описаны в расширении; как именно описаны, мы скажем чуть позже) поведение, описанное в прецеденте А. Пример показан на следующей диаграмме (рис. 6.11):

Рис. 6.11.

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

Точка расширения описывается в дополнительном разделе прецедента, отделенном от его названия горизонтальной линией - точно так же, как в отдельных разделах перечисляются атрибуты класса и его операции. Ниже показан пример описания точки расширения, позаимствованный нами из Zicom Mentor (рис. 6.12).

Рис. 6.12.

В этом примере регистрация пассажиров авиарейса включает в себя контроль службы безопасности, а при условии (указанном в примечании после служебного слова "Condition:"), что человек часто летает и салон переполнен (обратите внимание на оператор AND, говорящий об одновременности выполнения условий), класс билета может быть повышен, например, с "эконом" до "бизнес-класса". Причем такой апгрейд может произойти только после того, как билет предъявлен на стойку регистрации - это и есть точка расширения. Она описана (ее имя указано) в дополнительном разделе прецедента после служебной фразы "Extension points:". Предваряя вопрос читателя, скажем, что прецедент может иметь сколь угодно много точек расширения. А сопоставить конкретный расширяющий прецедент с определенной точкой расширения можно, прочитав условия расширения, указанные в комментариях, - само условие записывается после служебного слова "Condition:" в фигурных скобках, за которыми идет служебная фраза "Extension point:", и после нее указывается имя точки расширения. Посмотрите еще раз на наш пример с регистрацией пассажиров в аэропорту и убедитесь сами, что все это очень просто!

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

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

Организация прецедентов с помощью выделения общего поведения (включение) и различных вариантов поведения (расширение) - важная составляющая часть процесса разработки простого, сбалансированного и понятного набора прецедентов. Можно сказать даже, что использование включения и расширения - признак хорошего стиля в моделировании прецедентов.

На этом разговор о нотации диаграмм прецедентов можно было бы и завершить. Хотелось бы только сказать еще пару слов о соотношении между понятиями прецедента и кооперации. О кооперации мы уже говорили ранее (помните диаграммы взаимодействия?) как о множестве ролей, работающих вместе, чтобы обеспечить некоторое поведение системы. Мы также упоминали о том, что прецеденты отвечают на вопрос "что делает система?", но не говорят, как именно она это делает. На этапе анализа понимать, как именно система реализует свое поведение, действительно не нужно. Но при переходе к реализации неплохо бы знать, какие именно классы (или другие элементы модели), совместно работая, обеспечивают нужное поведение. То есть мы логично перешли от разговора о прецедентах к разговору о кооперации! Недаром обозначения кооперации и прецедента очень похожи (читатель, конечно, помнит, что кооперация обозначается пунктирным эллипсом) (рис. 6.13).

Рис. 6.13.

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