|
Страница 4 из 6
Реакция против вариантов использованияКак только вышеизложенная модель стала общепринятой, люди тут же, как и следовало ожидать, взбунтовались против нее. Для формалистов она была недостаточно формальной, и они продолжали поиски абсолютно формального способа описания варианта использования. В то же время, она была слишком формальной для тех, кто предпочитал видеть в вариантах использования некие неформальные описания, не обладающие предопределенной структурой и не похожие на описания требований к системе. Эти последние в дальнейшем пошли в трех направлениях: списки функциональных возможностей системы, карточки с рассказами пользователей и варианты задач (task cases2). Отдельный вариант использования может включать в себя задачи сразу для нескольких программистов. Задачи для каждого конкретного программиста в нем не выделяются. Поэтому некоторые программисты требуют списки функциональных возможностей системы, которые можно было бы принимать за индивидуальный план работы. Несмотря на то, что создание и поддержание таких списков значительно увеличивают объем работы, к ним прибегают довольно часто. Авторы Экстремального Программирования (ХР3) остались верны идее неформальных сценариев, у которых нет никакой заданной структуры. Кент Бек (Kent Beck) создал термин "рассказ пользователя" (user story). Именно им и стали называть такие неформальные требования к системе. Рассказ пользователя состоит из нескольких фраз, записанных на маленькой бумажной карточке. В них пользователь объясняет, что именно он хочет от системы. В ХР рассказ пользователя представляет собой не требование к системе, а некое напоминание о будущем обсуждении этой функциональности с заказчиком. Таким образом, на карточке достаточно записать ровно столько информации, чтобы и заказчики, и программисты поняли, что именно им нужно будет обсудить в дальнейшем. Ларри Константайн (Larry Constantine) рассматривает описание сценариев с точки зрения проектирования пользовательского интерфейса. Он обнаружил, что для этого ему совершенно не нужно описывать внутреннее поведение системы или ее взаимодействие с второстепенными действующими лицами. Для проектирования интерфейсов вполне достаточно текста, записанного в две колонки. В первой пишут то, что пользователь пытается сделать, во второй - как реагирует на его действия система. Такая простейшая структура позволяет создать интерфейс, отвечающий задачам пользователя. Чтобы избежать путаницы, Константайн переименовал "вариант использования" (use case) в "вариант задачи" (task case), так как варианты использования традиционно представляют собой спецификацию системы. Однако это не погасило спор между теми, кто хотел видеть варианты использования простыми и неформальными, и теми, кто хотел писать детализированные описания, которые бы соответствовали заданным шаблонам и поддерживали автоматически обновляющиеся ссылки на другие документы. Между сторонниками этих подходов очень мало общего, кроме, пожалуй, одного... и те, и другие хотят зафиксировать поведение системы с помощью того, что все они называют "вариантами использования". |