Точки расширения

Отсутствуют

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

Время от времени мы сталкиваемся с созданием почти одинаковых вариантов использования. Наиболее распространенные примеры — Найти клиента, Найти продукт, Найти данные о продвижении и т.д. Скорее всего, только одна группа разработчиков будет создавать общий механизм поиска, а другие команды будут его использовать.

Написать полдюжины похожих вариантов использования в свободной форме не составляет большого труда. Однако писать шесть подобных вариантов использования по полной форме довольно трудоемкое и нудное занятие. Здесь необходим метод, экономящий усилия. Я опишу такой метод с помощью варианта использования 23.

Для этого варианта использования, прежде всего, характерно следующее:

■ Именование цели в шаге очень похоже на вызов подпрограммы.

■ Варианты использования будут читать люди, а не компьютеры.

При дальнейшем рассмотрении мы отметили, что при поиске предмета, чем бы он ни был, нужна одна и та же логика:

1. Пользователь определяет предмет, который необходимо найти.

2. Система производит поиск, выдает список возможных вариантов.

3. Пользователь выбирает, возможно, повторно сортирует список и изменяет критерий поиска.

4. Система находит предмет (или не находит).

При каждом использовании изменяются:

■ Название предмета, который нужно найти

■ Критерии поиска (поля поиска) предмета, который нужно найти

■ Набор выводимых атрибутов предмета, который нужно найти (показываемые значения одно за другим)

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

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

Для значений данных мы определили три уровня точности. Первым была фраза из текста варианта использования — краткое имя данных, такое как Профиль клиента. Вторым были списки полей, связанных с кратким именем данных, именующим всю собранную под ним информацию, например имя, адрес, служебный телефон, домашний телефон и т.д. Третий уровень точности был точным определением поля: длина, критерии оценки и т.д.

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

Результатом стал шаг действия, выглядевший примерно так:

Служащий находит клиента с помощью параметров поиска клиента.

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

Вариант использования Найти что угодно теперь выглядит так:

1. Пользователь определяет параметры поиска чего-либо.

2. Система находит все, что соответствует параметрам поиска, и выводит

список их отображаемых значений.

3. Пользователь может пересортировать их согласно критерию

сортировки.

4. Пользователь выбирает интересующий его вариант.

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

Довольно советов. Закончите упражнение 5.4. Обратите особое внимание на гарантии и расширения, потому что и те, и другие важны для вызывающих вариантов использования.

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

Рис. 7. Простейший вариант использования

Рис. 8. Варианты использования для библиотеки

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

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

Схема применения прецедентов