Постусловия
Постусловиями называются такие условия, которые всегда должны быть выполнены после завершения варианта использования. Например, в конце варианта использования можно пометить флажком какой-нибудь переключатель. Информация такого типа входит в состав постусловий. Как и для предусловий, с помощью постусловий можно вводить информацию о порядке выполнения вариантов использования системы. Если, например, после одного из вариантов использования должен всегда выполняться другой, это можно описать как постусловие. Такие условия имеются не у каждого варианта использования.
Связи
В языке UML для вариантов использования и действующих лиц поддерживается несколько типов связей. Это связи коммуникации(communication), использования (uses), расширения (extends) и обобщения действующего лица (асtoг generalization). Связи коммуникации описывают связи между действующими лицами и вариантами использования. Связи использования и расширения отражают связи между вариантами использования, а связи обобщения действующего лица - между действующими лицами.
Связь коммуникации (communication relationship) - это связь между вариантом использования и действующим лицом. На языке UML связи коммуникации показывают с помощью обычной стрелки. Направление стрелки позволяет понять, кто инициирует коммуникацию. Например, действующее лицо Клиент инициирует коммуникацию с системой, чтобы запустить функцию Снятия денег. Вариант использования также может инициировать коммуникацию с действующим лицом Кредитная система. Когда выполняется вариант использования "Сделать выплату", система ATM инициирует коммуникацию с Кредитной системой, чтобы завершить транзакцию. Информация при этом движется в обоих направлениях, от системы ATM к Кредитной и обратно; стрелка показывает только, кто инициирует коммуникацию.
Связь использования (uses relationship) позволяет одному варианту использования использовать функциональность другого. С помощью таких связей обычно моделируют многократно используемую функциональность, встречающуюся в двух или более вариантах использования. В примере ATM варианты использования "Снять деньги" и "Положить деньги на счет" должны опознать (аутентифицировать) клиента и его идентификационный номер перед тем, как допустить осуществление самой транзакции. Вместо того, чтобы подробно описывать процесс аутентификации для каждого из них, можно поместить эту функциональность в свой собственный вариант использования под названием "Аутентифицировать клиента". Когда какому-нибудь варианту использования потребуется выполнить эти действия, он может использовать функциональность созданного нами варианта использования "Аутентифицировать клиента".
Связь использования изображается в UML с помощью стрелок и слова «uses» (использование).
Рис 2. Связи использования и расширения.
В этом примере вариант использования "Снять деньги" использует функциональность варианта использования "Аутентифицировать клиента". Этот последний является абстрактным вариантом использования, то есть таким, который предоставляет другим вариантам использования свою функциональность через связи использования и расширения. Вариант использования "Снять деньги" - это конкретный вариант использования.
Связь использования предполагает, что один вариант использования всегда использует функциональные возможности другого. Не важно, как именно осуществляется вариант использования "Снять деньги", вариант использования "Аутентифицировать клиента" будет запущен в любом случае. Напротив, связи расширения (extends relationships')" позволяют варианту использования только при необходимости использовать функциональные возможности другого.
Связи расширения (extends relationships) позволяют варианту использования только при необходимости использовать функциональные возможности, предоставляемые другим вариантом использования. Они напоминают связи использования. В обоих типах отношений некоторая общая функциональность выделяется в отдельный вариант использования.
На языке UML связи расширения показывают в виде стрелки со словом «extends» (расширение).
В нашем примере вариант использования "Снять деньги" иногда использует функциональные возможности, предоставляемые вариантом использования "Выполнить ускоренное снятие денег". Это происходит тогда и только тогда, когда клиент выбирает пункт "Быстро снять 40грн." во время работы варианта использования "Снять деньги".
Предоставляющий дополнительные возможности вариант использования "Выполнить ускоренное снятие денег" является абстрактным. Вариант использования "Снять деньги" - это конкретный вариант использования.
С помощью связи обобщения действующего лица (actor generalization relationship) показывают, что у нескольких действующих лиц имеются общие черты. Например, клиенты могут быть двух типов: корпоративные и индивидуальные. Это отношение можно моделировать с помощью нотации, показанной на рис.
Рис 3. Абстрактное действующее лицо.
Например, у нас имеется два типа клиентов - индивидуальные и корпоративные. Это конкретные действующие лица. Они будут инстанцированы (наполнены) непосредственно. Действующее лицо Клиент - это абстрактное действующее лицо. Оно никогда не инстанцируется непосредственно. Оно нужно, только чтобы показать наличие двух типов клиентов.
При необходимости можно усиливать ветвление (если имеется два типа корпоративных клиентов - правительственные агентства и частные компании).
Нет необходимости всегда создавать связи этого типа. В общем случае, они нужны, если поведение действующего лица одного типа отличается от поведения другого постольку, поскольку это затрагивает систему. Если, например, корпоративные клиенты инициируют некоторые варианты использования, которые не могут запустить индивидуальные клиенты, вероятно, включить в диаграмму связи этого типа имеет смысл. Если клиенты обоих типов используют одни и те же варианты использования, показывать обобщение действующего лица не требуется. Если оба типа действующих лиц используют одни и те же варианты использования, но слегка по-разному, все-таки, не стоит включать их обобщение. Небольшие различия можно документировать в потоке событий варианта использования.
Еще раз повторим, что основным назначением этих диаграмм является коммуникация между участниками команды. Если обобщение действующих лиц предоставляет им некоторую полезную информацию, включайте ее в диаграмму. Если нет - не загромождайте диаграмму избыточной информацией.
Варианты использования являются необходимым средством на стадии формирования требований к ПО. Каждый вариант использования - это потенциальное требование к системе, и пока оно не выявлено, невозможно запланировать его реализацию.
Различные разработчики подходят к описанию вариантов использования с разной степенью детализации. Например, Ивар Якобсон утверждает, что для проекта с трудоемкостью в 10 человеко-лет количество вариантов использования может составлять около 20 (не считая связей «использования» и «расширения»). Следует предпочитать небольшие и детализированные варианты использования, поскольку они облегчают составление и реализацию согласованного плана проекта.
В заключение перечислим типичные ловушки, которых следует избегать при моделировании вариантов использования:
Границы системы четко не определены;
Варианты использования рассматриваются с точки зрения системы, а не действующих лиц;
Слишком много вариантов использования;
Многочисленные и запутанные связи между действующими лицами и вариантами использования;
Слишком объемные или нечеткие спецификации вариантов использования;
Варианты использования не соответствуют реальным функциям;
Пользователи плохо понимают варианты использования.