Примечание

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

Пример построения диаграммы вариантов использования

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

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

Рис. 7. Исходная диаграмма вариантов использования для примера разработки системы продажи товаров по каталогу

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

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

С другой стороны, продажа товаров по каталогу предполагает наличие само­стоятельного информационного объекта — каталога товаров, который в не­котором смысле не зависит от реализации сервиса по обслуживанию поку­пателей. В нашем случае, каталог товаров может запрашиваться покупателем или продавцом при необходимости выбора товара и уточнения деталей его продажи. Вполне резонно представить сервис "Запросить каталог товаров" в качестве самостоятельного варианта использования.

Полученная в результате последующей детализации уточненная диаграмма вариантов использования будет содержать 5 вариантов использования и 2 актеров (рис. 8), между которыми установлены отношения включения и расширения.

Рис. 8. Уточненный вариант диаграммы вариантов использования для примера системы продажи товаров по каталогу

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

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

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

Рис. 9. Один из вариантов последую­щего уточнения диаграммы вариантов использования для примера рассматри­ваемой системы продажи

Второе из основных направлений детализации диаграмм вариантов исполь­зования связано с последующей структуризацией ее отдельных компонентов в форме элементов других диаграмм. Например, конкретные особенности реализации вариантов использования в терминах взаимодействующих объ­ектов, определенных в виде классов данной сущности, могут быть заданы на диаграмме кооперации. Спецификация требований к проектируемой системе в форме диаграммы вариантов использования представляет собой самостоя­тельную модель, которая в языке UML получила название модели вариантов использования и имеет свое специальное стандартное имя или стереотип "useCaseModel"