Страница:
Несмотря на репутацию хакеров, члены сообщества Perl являются стойкими приверженцами регрессионного и модульного тестирования. Стандартная процедура инсталляции модуля в Perl поддерживает регрессионное тестирование с помощью команды
% make test
В этом отношении сам по себе Perl не является чем-то сверхъестественным. Perl облегчает сопоставление и анализ результатов тестирования для обеспечения соответствия, но его большое преимущество состоит в том, что он является стандартом – тестирование проводится в конкретном месте и имеет предсказуемый результат. Тестирование в большей степени является вопросом культуры, а не техники, независимо от используемого вами языка.
• Ортогональность
• Проектирование по контракту
• Реорганизация
• Безжалостное тестирование
35
Глава 7
36
В поисках требований
Документация требований
Чрезмерная спецификация
Видеть перспективу
% make test
В этом отношении сам по себе Perl не является чем-то сверхъестественным. Perl облегчает сопоставление и анализ результатов тестирования для обеспечения соответствия, но его большое преимущество состоит в том, что он является стандартом – тестирование проводится в конкретном месте и имеет предсказуемый результат. Тестирование в большей степени является вопросом культуры, а не техники, независимо от используемого вами языка.
Подсказка 49: Тестируйте ваши программы, в противном случае это сделают ваши пользователи
Другие разделы, относящиеся к данной теме:
• Мой исходный текст съел кот Мурзик• Ортогональность
• Проектирование по контракту
• Реорганизация
• Безжалостное тестирование
Упражнения
41. Спроектируйте тестовый шаблон для интерфейса блендера для коктейлей, описанного в ответе к упражнению 17 (см. Приложение В). Напишите сценарий оболочки, который осуществит регрессионное тестирование блендерa. Необходимо проверить основные функциональные возможности, ошибки и граничные условия, а также любые обязательства по контракту. Какие ограничения налагаются на изменение скорости вращения ротора блендера? Соблюдаются ли они?
35
Злые волшебники
Никто не может отрицать – создавать приложения становится все сложнее и сложнее. В частности, пользовательские интерфейсы становятся все более утонченными. Двадцать лет назад приложение среднего масштаба обошлось бы интерфейсом "стеклянного телетайпа" (а может быть, интерфейса не было бы и вовсе). Асинхронные терминалы обеспечивали интерактивное отображение символов, а устройства ввода (наподобие вездесущей IBM 3270) позволяли набирать целую экранную страницу перед нажатием клавиши SEND. Теперь пользователи требуют графический интерфейс с контекстно-зависимой справкой, средствами типа "вырезать и вставить", "перетащить и отпустить", средством OLE, много- или однодокументным интерфейсом. Пользователям потребна интеграция с web-браузером и поддержка архитектуры с тонким клиентом.
Усложняются и сами приложения. В настоящее время большинство разработок использует многозвенную модель, возможно, с промежуточным программным обеспечением или монитором транзакций. Эти программы отличаются динамичностью, гибкостью и способностью работать во взаимодействии с приложениями, написанными сторонними фирмами.
Кажется, мы не сказали о том, что нам это было нужно на прошлой неделе – вес и сразу!
Разработчики стараются быть в форме. Если бы мы использовали те же самые инструментальные средства, которые применялись для терминалов ввода-вывода двадцатилетней давности, то ничего бы не добились.
Поэтому производители инструментальных средств и поставщики средств инфраструктуры придумали палочку выручалочку – функцию-мастера. Это замечательное средство. Вам нужно приложение с многодокументным интерфейсом и поддержкой контейнера OLE? Один щелчок мыши, ответ на пару простых вопросов – и функция-мастер автоматически сгенерирует для вас скелет программы. При выполнении данного сценария среда Microsoft Visual С++ автоматически создает программу, содержащую свыше 1200 строк. Функции-мастера хорошо справляются и с другими заданиями. Вы можете воспользоваться мастерами при создании серверных компонентов, реализации Java beans, работе с сетевыми интерфейсами – все это достаточно сложные области, где не обойтись без помощи эксперта.
Но применение функции-мастера, спроектированной неким компьютерным гуру, не делает автоматически из разработчика Джо компьютерного эксперта. Джо чувствует себя недурно – он ведь сгенерировал большое количество исходного текста и довольно элегантную на вид программу. Ему нужно лишь добавить функциональную возможность, характерную для данного приложения, и программу можно отправлять заказчику. Но покуда Джо реально не осознает сути программы, сгенерированной от его имени, он вводит самого себя в заблуждение. Он программирует в расчете на стечение обстоятельств. Функция-мастер подобна улице с односторонним движением – она лишь «вырезает» программу и затем движется далее. Если сгенерированная программа не совсем правильна (или обстоятельства изменились), а вам необходимо адаптировать ее, вы остаетесь с ней один на один.
Мы не выступаем против функций-мастеров. Напротив, их созданию в книге посвящен целый раздел "Генераторы исходных текстов". Но если вы все же используете функцию-мастера и не понимаете всей создаваемой ею программы, то не сможете управлять вашим собственным приложением. Вы не сможете сопровождать его и будете затрачивать неимоверные усилия при отладке.
Некоторые полагают, что это совсем уж экстремистская позиция. Они говорят, что разработчики всегда основывают свою работу на предметах, которые до конца им непонятны, – на квантовой механике в интегральных схемах, схеме прерываний в процессоре, алгоритмах, используемых при диспетчеризации процессов, программах из имеющихся библиотек и т. д. Мы согласны. И мы придерживались бы того же мнения о функциях-мастерах, если бы они представляли собой просто набор библиотечных вызовов или стандартные службы операционной системы, на которые могли положиться разработчики. Но это не так. Функции-мастера генерируют программу, которая становится неотъемлемой частью приложения, написанного разработчиком Джо. Сгенерированная программа не выносится за скобки, прячась за опрятным интерфейсом, она переплетена, строчка за строчкой, с теми функциональными возможностями, которые созданы самим Джо [40]. В конечном итоге она перестает быть программой функции-мастера и становится программой самого Джо. Никто не должен генерировать программу, не понимая ее до конца.
• Генераторы исходных текстов
Усложняются и сами приложения. В настоящее время большинство разработок использует многозвенную модель, возможно, с промежуточным программным обеспечением или монитором транзакций. Эти программы отличаются динамичностью, гибкостью и способностью работать во взаимодействии с приложениями, написанными сторонними фирмами.
Кажется, мы не сказали о том, что нам это было нужно на прошлой неделе – вес и сразу!
Разработчики стараются быть в форме. Если бы мы использовали те же самые инструментальные средства, которые применялись для терминалов ввода-вывода двадцатилетней давности, то ничего бы не добились.
Поэтому производители инструментальных средств и поставщики средств инфраструктуры придумали палочку выручалочку – функцию-мастера. Это замечательное средство. Вам нужно приложение с многодокументным интерфейсом и поддержкой контейнера OLE? Один щелчок мыши, ответ на пару простых вопросов – и функция-мастер автоматически сгенерирует для вас скелет программы. При выполнении данного сценария среда Microsoft Visual С++ автоматически создает программу, содержащую свыше 1200 строк. Функции-мастера хорошо справляются и с другими заданиями. Вы можете воспользоваться мастерами при создании серверных компонентов, реализации Java beans, работе с сетевыми интерфейсами – все это достаточно сложные области, где не обойтись без помощи эксперта.
Но применение функции-мастера, спроектированной неким компьютерным гуру, не делает автоматически из разработчика Джо компьютерного эксперта. Джо чувствует себя недурно – он ведь сгенерировал большое количество исходного текста и довольно элегантную на вид программу. Ему нужно лишь добавить функциональную возможность, характерную для данного приложения, и программу можно отправлять заказчику. Но покуда Джо реально не осознает сути программы, сгенерированной от его имени, он вводит самого себя в заблуждение. Он программирует в расчете на стечение обстоятельств. Функция-мастер подобна улице с односторонним движением – она лишь «вырезает» программу и затем движется далее. Если сгенерированная программа не совсем правильна (или обстоятельства изменились), а вам необходимо адаптировать ее, вы остаетесь с ней один на один.
Мы не выступаем против функций-мастеров. Напротив, их созданию в книге посвящен целый раздел "Генераторы исходных текстов". Но если вы все же используете функцию-мастера и не понимаете всей создаваемой ею программы, то не сможете управлять вашим собственным приложением. Вы не сможете сопровождать его и будете затрачивать неимоверные усилия при отладке.
Подсказка 50: Не пользуйтесь программой функции-мастера, которую не понимаете
Некоторые полагают, что это совсем уж экстремистская позиция. Они говорят, что разработчики всегда основывают свою работу на предметах, которые до конца им непонятны, – на квантовой механике в интегральных схемах, схеме прерываний в процессоре, алгоритмах, используемых при диспетчеризации процессов, программах из имеющихся библиотек и т. д. Мы согласны. И мы придерживались бы того же мнения о функциях-мастерах, если бы они представляли собой просто набор библиотечных вызовов или стандартные службы операционной системы, на которые могли положиться разработчики. Но это не так. Функции-мастера генерируют программу, которая становится неотъемлемой частью приложения, написанного разработчиком Джо. Сгенерированная программа не выносится за скобки, прячась за опрятным интерфейсом, она переплетена, строчка за строчкой, с теми функциональными возможностями, которые созданы самим Джо [40]. В конечном итоге она перестает быть программой функции-мастера и становится программой самого Джо. Никто не должен генерировать программу, не понимая ее до конца.
Другие разделы, относящиеся к данной теме:
• Ортогональность• Генераторы исходных текстов
Вопросы для обсуждения
• Если в вашем распоряжении имеется функция-мастер построения графического интерфейса, воспользуйтесь ей для генерирования «скелета» приложения. Внимательно изучите каждую строку сгенерированной программы. Всели в ней вам понятно? Могли бы написать ее сами? Лучше написать ее самому, или же она делает то, что вам не нужно?
Глава 7
Перед тем, как начать проект
У вас никогда не возникало ощущения, что ваш проект обречен еще до его начала? Иногда так и происходит, если вначале вы не установите некоторые основополагающие правила. В противном случае вы можете объявить проект закрытым и сэкономить спонсору некоторую сумму.
В самом начале проекта вам придется определить требования. Недостаточно лишь выслушать пользователей, необходимо прочесть раздел "Карьер для добычи требований".
Житейская мудрость и управление сдерживающими факторами являются основными темами раздела "Разгадка невероятных головоломок". Неважно, какую операцию вы осуществляете – анализ, составление текста программы или тестирование, проблемы возникают все равно. Чаще они не будут настолько сложными, какими показались вначале.
Даже когда вы подумаете, что решили все проблемы, то все равно будете чувствовать неудобства, начав работать над проектом. Является ли это простым промедлением или чем-то большим? В разделе "Пока вы не готовы" предлагается совет – в какой момент благоразумно прислушаться к предостережению внутреннего голоса.
Слишком раннее начало – это проблема, но слишком долгое ожидание еще хуже. В разделе "Западня со стороны требований" обсуждаются преимущества создания спецификаций по образцу.
В разделе "Круги и стрелки" рассматриваются некоторые ловушки, в которые можно попасть при использовании формальных процессов и методологий. Неважно, насколько хорошо он продуман, и какие "лучшие случаи из практики" в нем использованы, – никакой метод не заменит мышления.
Если вы устраните эти критические аспекты до того, как проект будет запущен, вы лучше справитесь с "аналитическим параличом" и начнете выполнять реальный успешный проект.
В самом начале проекта вам придется определить требования. Недостаточно лишь выслушать пользователей, необходимо прочесть раздел "Карьер для добычи требований".
Житейская мудрость и управление сдерживающими факторами являются основными темами раздела "Разгадка невероятных головоломок". Неважно, какую операцию вы осуществляете – анализ, составление текста программы или тестирование, проблемы возникают все равно. Чаще они не будут настолько сложными, какими показались вначале.
Даже когда вы подумаете, что решили все проблемы, то все равно будете чувствовать неудобства, начав работать над проектом. Является ли это простым промедлением или чем-то большим? В разделе "Пока вы не готовы" предлагается совет – в какой момент благоразумно прислушаться к предостережению внутреннего голоса.
Слишком раннее начало – это проблема, но слишком долгое ожидание еще хуже. В разделе "Западня со стороны требований" обсуждаются преимущества создания спецификаций по образцу.
В разделе "Круги и стрелки" рассматриваются некоторые ловушки, в которые можно попасть при использовании формальных процессов и методологий. Неважно, насколько хорошо он продуман, и какие "лучшие случаи из практики" в нем использованы, – никакой метод не заменит мышления.
Если вы устраните эти критические аспекты до того, как проект будет запущен, вы лучше справитесь с "аналитическим параличом" и начнете выполнять реальный успешный проект.
36
Карьер для добычи требований
Совершенство достигается не тогда, когда уже нечего прибавить, но когда уже ничего нельзя отнять.
Антуан де Сент-Экзюпери, Ветер, песок и звезды, 1939
Многие книги и учебные пособия относят процедуру сбора исходных требований к начальной фазе проекта. Термин «сбор» напоминает о племени счастливых аналитиков, занимающихся собирательством камней-самородков мудрости, разбросанных по земле на фоне приглушенного звучания "Пасторальной симфонии". Этот термин напоминает о том, что все требования уже имеются в наличии, нужно лишь отыскать их, положить в корзину и весело шагать дальше.
Это не совсем так. Требования редко лежат на поверхности. Обычно они находятся глубоко под толщей предположений, неверных представлений и политики.
Это не совсем так. Требования редко лежат на поверхности. Обычно они находятся глубоко под толщей предположений, неверных представлений и политики.
Подсказка 51: Не собирайте требования – выискивайте их
В поисках требований
Как распознать истинное требование, пробиваясь к нему сквозь толшу грязевых наносов? Ответ на этот вопрос и прост, и сложен одновременно.
Простой ответ состоит в том, что требование формулирует необходимость осуществления чего-либо. Грамотно составленное требование выглядит следующим образом:
• Доступ к личному делу сотрудника ограничен группой уполномоченных на то лиц.
• Температура головки блока цилиндров не должна превышать определенного критического значения, зависящего от марки двигателя.
• Редактор выделяет ключевые слова, выбор которых зависит от типа редактируемого файла.
Однако подобной четкостью могут похвастаться лишь немногие требования, что и делает их анализ весьма сложной задачей.
Первая формулировка в списке, приведенном выше, вероятно, была составлена пользователями следующим образом: "Доступ к личному делу сотрудника ограничен его руководителями и работниками отдела кадров". Является ли эта формулировка требованием? Возможно, что сегодня и является, но она воплощает бизнес-политику в абсолютной формулировке. Политика же регулярно меняется, поэтому, скорее всего, мы не захотим жестко встраивать ее в наши требования. Мы рекомендуем документировать положения политики отдельно от требований и связывать их посредством гиперссылки. Сделайте требование общей формулировкой и снабдите разработчиков информацией о политике в качестве примера того, что им придется поддерживать в реализации. В конечном счете политика конечна, как и метаданные в приложении.
Это весьма тонкое различие, но именно оно окажет серьезное воздействие на разработчиков. Если требование сформулировано как "Доступ к личному делу сотрудника ограничен персоналом фирмы", то разработчик может прекратить составление программы проверки на том месте, где приложение обращается к этим файлам. Однако если эта формулировка звучит как "Доступ к личному делу сотрудника ограничен уполномоченными на то пользователями", то разработчик, по всей вероятности, спроектирует и реализует нечто вроде системы управления доступом. При изменении политики (а оно обязательно произойдет) потребуется лишь обновление метаданных системы. На самом деле подобный метод сбора требований приведет к созданию системы, четко структурированной для поддержки метаданных.
Различия между требованиями, политикой и реализацией могут быть весьма размытыми, если речь идет о пользовательских интерфейсах. Слова "Система должна давать возможность выбора срока предоставления ссуды" представляют собой формулировку требования. Выражение "Для выбора срока предоставления ссуды необходимо окно списка" может являться формулировкой, а может таковой и не являться. Если пользователям позарез нужно окно списка, то в этом случае речь идет о требовании. Если же вместо этого они описывают свою способность выбирать, используя окно списка лишь в качестве примера, то здесь говорится не о требовании. Врезка ниже "Когда интерфейс становится системой" описывает проект, который пошел совсем не в ту сторону, поскольку потребности пользователей в интерфейсе были проигнорированы.
Важно обнаружить основополагающую причину того, почему пользователи поступают определенным образом, а не так, как они привыкли это делать. В конечном итоге разрабатываемой программе придется решать проблемы их бизнеса, а не просто отвечать их заявленным требованиям. Документируя причины, по которым были выдвинуты требования, команда разработчиков получит бесценную информацию, необходимую для принятия ежедневных решений, связанных с реализацией.
Существует простая методика: чтобы взглянуть изнутри на требования (которые часто являются весьма недостаточными) ваших пользователей, нужно самому стать пользователем. Пишете систему для службы поддержки? Посидите пару дней на телефоне вместе с опытным сотрудником этой службы. Занимаетесь автоматизацией ручной системы управления складскими запасами? Поработайте на складе с неделю [41]. Вы получите представление о реальном использовании системы и вдобавок будете просто поражены тем, насколько просьба "Можно я посижу рядом с вами недельку и посмотрю, как вы работаете?" способствует доверию и закладывает основы ваших взаимоотношений с пользователями. Но не путайтесь у них под ногами!
Добыча полезных требований важна – в это время начинают складываться связи с вашим пользовательским ядром, изучаются их ожидания и надежды на создаваемую вами систему. Более подробно это обсуждается в разделе "Большие надежды".
Простой ответ состоит в том, что требование формулирует необходимость осуществления чего-либо. Грамотно составленное требование выглядит следующим образом:
• Доступ к личному делу сотрудника ограничен группой уполномоченных на то лиц.
• Температура головки блока цилиндров не должна превышать определенного критического значения, зависящего от марки двигателя.
• Редактор выделяет ключевые слова, выбор которых зависит от типа редактируемого файла.
Однако подобной четкостью могут похвастаться лишь немногие требования, что и делает их анализ весьма сложной задачей.
Первая формулировка в списке, приведенном выше, вероятно, была составлена пользователями следующим образом: "Доступ к личному делу сотрудника ограничен его руководителями и работниками отдела кадров". Является ли эта формулировка требованием? Возможно, что сегодня и является, но она воплощает бизнес-политику в абсолютной формулировке. Политика же регулярно меняется, поэтому, скорее всего, мы не захотим жестко встраивать ее в наши требования. Мы рекомендуем документировать положения политики отдельно от требований и связывать их посредством гиперссылки. Сделайте требование общей формулировкой и снабдите разработчиков информацией о политике в качестве примера того, что им придется поддерживать в реализации. В конечном счете политика конечна, как и метаданные в приложении.
Это весьма тонкое различие, но именно оно окажет серьезное воздействие на разработчиков. Если требование сформулировано как "Доступ к личному делу сотрудника ограничен персоналом фирмы", то разработчик может прекратить составление программы проверки на том месте, где приложение обращается к этим файлам. Однако если эта формулировка звучит как "Доступ к личному делу сотрудника ограничен уполномоченными на то пользователями", то разработчик, по всей вероятности, спроектирует и реализует нечто вроде системы управления доступом. При изменении политики (а оно обязательно произойдет) потребуется лишь обновление метаданных системы. На самом деле подобный метод сбора требований приведет к созданию системы, четко структурированной для поддержки метаданных.
Различия между требованиями, политикой и реализацией могут быть весьма размытыми, если речь идет о пользовательских интерфейсах. Слова "Система должна давать возможность выбора срока предоставления ссуды" представляют собой формулировку требования. Выражение "Для выбора срока предоставления ссуды необходимо окно списка" может являться формулировкой, а может таковой и не являться. Если пользователям позарез нужно окно списка, то в этом случае речь идет о требовании. Если же вместо этого они описывают свою способность выбирать, используя окно списка лишь в качестве примера, то здесь говорится не о требовании. Врезка ниже "Когда интерфейс становится системой" описывает проект, который пошел совсем не в ту сторону, поскольку потребности пользователей в интерфейсе были проигнорированы.
Важно обнаружить основополагающую причину того, почему пользователи поступают определенным образом, а не так, как они привыкли это делать. В конечном итоге разрабатываемой программе придется решать проблемы их бизнеса, а не просто отвечать их заявленным требованиям. Документируя причины, по которым были выдвинуты требования, команда разработчиков получит бесценную информацию, необходимую для принятия ежедневных решений, связанных с реализацией.
Существует простая методика: чтобы взглянуть изнутри на требования (которые часто являются весьма недостаточными) ваших пользователей, нужно самому стать пользователем. Пишете систему для службы поддержки? Посидите пару дней на телефоне вместе с опытным сотрудником этой службы. Занимаетесь автоматизацией ручной системы управления складскими запасами? Поработайте на складе с неделю [41]. Вы получите представление о реальном использовании системы и вдобавок будете просто поражены тем, насколько просьба "Можно я посижу рядом с вами недельку и посмотрю, как вы работаете?" способствует доверию и закладывает основы ваших взаимоотношений с пользователями. Но не путайтесь у них под ногами!
Подсказка 52: Работайте с пользователем, чтобы мыслить категориями пользователя
Добыча полезных требований важна – в это время начинают складываться связи с вашим пользовательским ядром, изучаются их ожидания и надежды на создаваемую вами систему. Более подробно это обсуждается в разделе "Большие надежды".
Документация требований
Итак, вы садитесь за стол с пользователями и начинаете выпытывать у них, что же им нужно на самом деле. Вы столкнетесь с несколькими вероятными сценариями, описывающими, что должно делать ваше приложение. Поскольку вы остаетесь профессионалом во всем, то вам хочется опубликовать такой документ, которым все смогут пользоваться в качестве основы при обсуждении, – разработчики, конечные пользователи и спонсоры проекта. Это весьма широкая аудитория.
Ивар Джекобсон [Jac94] предложил концепцию "сценариев использования системы" для фиксирования требований. Они позволяют описывать частные случаи использования системы не с точки зрения пользовательского интерфейса, а в более абстрактном виде. К сожалению, книга И. Джекобсона несколько расплывчата в деталях, поэтому в настоящее время не существует единого мнения о том, что же считать "сценарием использования системы". Что это – формальный или неформальный термин, прозаический или структурированный документ (подобный канцелярской форме)? Каким должен быть уровень детализации (помните, что у нас весьма широкая аудитория)?
Чтобы понять, почему это происходит, необходимо взглянуть на работу инженеров студии звукозаписи. Они сводят звук интуитивно. За годы работы в студии у них вырабатывается врожденный цикл обратной связи между ушами и кончиками пальцев, управляющих плавно движущимися регуляторами, вращающимися ручками и т. д. Однако компьютерный интерфейс нового микшерного пульта не усиливал их способностей. Вместо этого он заставлял пользователей набирать текст на клавиатуре и/или щелкать мышью. Функции, обеспечиваемые этим интерфейсом, были универсальными, но они были скомпонованы неизвестными и экзотическими способами. Функции, необходимые инженерам в их работе, иногда скрывались за невразумительными названиями или же достигались за счет неестественных сочетаний базовых средств.
Эта среда характеризовалась требованием – усилить существующие навыки работы. Вместо того, чтобы раболепно дублировать то, что уже существует, нужно было обеспечить переход на новую ступень развития.
Например, хорошим подспорьем в работе инженеров звукозаписи мог бы оказаться сенсорный интерфейс, смонтированный в виде классического микшерного пульта, но при этом позволяющий программам выходить за границы, определенные фиксированными ручками и переключателями. Единственным способом завоевать рынок является обеспечение удобства во время перехода на новую ступень за счет уже известных метафор.
Этот пример также иллюстрирует нашу уверенность в том, что удачные инструменты всегда привыкают к рукам, их держащим. В данном случае речь идет о привыкании инструментов, которые создаются вами для других людей.
При рассмотрении сценариев использования системы стоит отметить их целенаправленную природу. Алистер Кокбэрн опубликовал статью, в которой описывается этот подход, а также шаблоны, используемые (строго или нестрого) при этом в качестве отправной точки ([Сос97а]; имеется Интернет-версия этой статьи [URL 46]). На рисунке 7.1. показан (в сокращении) пример подобного шаблона, на рис. 7.2 представлен пример сценария его использования.
Рис. 7.1. Шаблон сценария использования системы по А. Кокбэрну
A. ХАРАКТЕРНАЯ ИНФОРМАЦИЯ
– Цель в контексте
– Область действия
– Уровень
– Предусловия
– Условие успешного завершения
– Условие неудачного завершения
– Первичный действующий субъект
– Условие начала действия
B. ОСНОВНОЙ СЦЕНАРИЙ ПРИ УСПЕШНОМ ЗАВЕРШЕНИИ
C. РАСШИРЕНИЯ
D. ВАРИАНТЫ
E. СОПУТСТВУЮЩАЯ ИНФОРМАЦИЯ
– Приоритет
– Рабочая характеристика
– Частота
– Превосходящий прецедент использования
– Подчиненный прецедент использования
– Канал связи с первичным действующим субъектом
– Вторичные действующие субъекты
– Канал связи со вторичными действующими субъектами
F. РАСПИСАНИЕ
G. ОТКРЫТЫЕ ПРОБЛЕМЫ
Используя формальный шаблон в качестве шпаргалки, вы можете быть уверены в том, что включили всю необходимую информацию в сценарий использования системы: характеристики производительности, другие стороны-участники, приоритет, частоту использования и разнообразные ошибки и исключения, которые могут появляться неожиданно ("нефункциональные требования"). Шаблон удобен для записи комментариев пользователей, наподобие "если мы получим условие ххх, тогда нам придется сделать ууу". Шаблон может послужить в качестве готовой повестки дня при встрече с пользователями ваших программ.
Рис. 7.2. Пример сценария использования системы
ПРЕЦЕДЕНТ ИСПОЛЬЗОВАНИЯ № 5: ПРИОБРЕТЕНИЕ ТОВАРА
A. ХАРАКТЕРНАЯ ИНФОРМАЦИЯ
• Цель в контексте: Покупатель напрямую направляет коммерческий запрос в нашу фирму и ожидает отгрузки товаров и выставления счета за указанные товары.
• Область действия: Фирма
• Уровень: Итоговая информация
• Предусловия: Нам известен покупатель, его адрес, и т. д.
• Условие успешного завершения: Покупатель получает товары, мы получаем оплату.
• Условие неуспешного завершения: Мы не производим отгрузку товаров, покупатель не производит оплату.
• Первичный действующий субъект: Покупатель, любой агент (или компьютер), действующий от имени заказчика
• Условие начала действия: Получение запроса на приобретение товара.
B. ОСНОВНОЙ СЦЕНАРИЙ С УСПЕШНЫМ ЗАВЕРШЕНИЕМ
1. Покупатель обращается в фирму с запросом на приобретение товара.
2. Фирма фиксирует имя покупателя. его адрес, требуемые товары. и т. д.
3. Фирма предоставляет покупателю информацию о товарах, ценах, сроках поставки, и т. д.
4. Покупатель подтверждает заказ.
5. Фирма компонует заказ, отправляет заказ покупателю.
6. Фирма высылает покупателю счет-фактуру.
7. Покупатель оплачивает счет-фактуру.
C. РАСШИРЕНИЯ
3а. Один из пунктов заказа отсутствует у данной фирмы: Заказ переоформляется.
4а. Покупатель производит оплату непосредственно кредитной картой: Прием оплаты кредитной картой (прецедент использования № 44).
7а. Покупатель возвращает товар: Оформление возвращенного товара (прецедент использования № 105).
D. ВАРИАНТЫ
1. Покупатель может осуществить заказ по телефону, факсу, при помощи Интернет-формы (на странице), по другим сетям электронного обмена информацией.
7. Покупатель может оплатить заказ наличными денежным переводом, чеком, или кредитной картой.
E. СОПУТСТВУЮЩАЯ ИНФОРМАЦИЯ
• Приоритет: Высший
• Производительность: 5 минут на оформление заказа, оплата в течение 45 дней
• Частота: 200 заказов в день
• Превосходящий прецедент использования: Управление взаимоотношением с заказчиком (прецедент использования № 2).
• Подчиненные прецеденты использования: Компоновка заказа (прецедент использования № 15)
• Прием оплаты кредитной картой (прецедент использования № 44). Возврат товара покупателем (прецедент использования № 105).
• Канал общения с первичным действующим субъектом: по телефону, факсу или компьютерной сети.
• Вторичные действующие субъекты: компания – оператор платежной системы, банк, экспедиторская фирма.
F. РАСПИСАНИЕ
• Должная дата: Выпуск 1.0
G. ПРОБЛЕМЫ, ЯВЛЯЮЩИЕСЯ ОТКРЫТЫМИ
• Что происходит, если имеется лишь часть заказа?
• Что происходит, если кредитная карта похищена?
Подобного рода организация поддерживает иерархическое структурирование сценариев использования системы – вложение более подробных сценариев в сценарии более высокого уровня. Например, сценарии post debit и post credit дополняют друг друга в сценарии post transaction.
Рис. 7.3. Сценарии использования, выраженные UML, понятны даже ребенку!
Кажется невероятным, что кто-нибудь может всерьез воспринимать документирование информации, используя примитивные символы, подобные изображенным на рисунке 7.3. Не будьте рабом системы обозначений: используйте любой метод общения, с помощью которого можно обмениваться требованиями с вашей аудиторией.
Ивар Джекобсон [Jac94] предложил концепцию "сценариев использования системы" для фиксирования требований. Они позволяют описывать частные случаи использования системы не с точки зрения пользовательского интерфейса, а в более абстрактном виде. К сожалению, книга И. Джекобсона несколько расплывчата в деталях, поэтому в настоящее время не существует единого мнения о том, что же считать "сценарием использования системы". Что это – формальный или неформальный термин, прозаический или структурированный документ (подобный канцелярской форме)? Каким должен быть уровень детализации (помните, что у нас весьма широкая аудитория)?
Когда интерфейс становится системой
В своей статье (журнал «Wired», январь 1999, с. 176) продюсер и музыкант Брайан Иноу описал чудо техники – новейший микшерный пульт. Этот пульт заставляет звучать все, что в принципе может звучать. И все же, вместо того, чтобы помочь музыкантам в создании лучших произведений или ускорить (или удешевить) процесс записи, он "путается под ногами", нарушая творческий процесс.Чтобы понять, почему это происходит, необходимо взглянуть на работу инженеров студии звукозаписи. Они сводят звук интуитивно. За годы работы в студии у них вырабатывается врожденный цикл обратной связи между ушами и кончиками пальцев, управляющих плавно движущимися регуляторами, вращающимися ручками и т. д. Однако компьютерный интерфейс нового микшерного пульта не усиливал их способностей. Вместо этого он заставлял пользователей набирать текст на клавиатуре и/или щелкать мышью. Функции, обеспечиваемые этим интерфейсом, были универсальными, но они были скомпонованы неизвестными и экзотическими способами. Функции, необходимые инженерам в их работе, иногда скрывались за невразумительными названиями или же достигались за счет неестественных сочетаний базовых средств.
Эта среда характеризовалась требованием – усилить существующие навыки работы. Вместо того, чтобы раболепно дублировать то, что уже существует, нужно было обеспечить переход на новую ступень развития.
Например, хорошим подспорьем в работе инженеров звукозаписи мог бы оказаться сенсорный интерфейс, смонтированный в виде классического микшерного пульта, но при этом позволяющий программам выходить за границы, определенные фиксированными ручками и переключателями. Единственным способом завоевать рынок является обеспечение удобства во время перехода на новую ступень за счет уже известных метафор.
Этот пример также иллюстрирует нашу уверенность в том, что удачные инструменты всегда привыкают к рукам, их держащим. В данном случае речь идет о привыкании инструментов, которые создаются вами для других людей.
При рассмотрении сценариев использования системы стоит отметить их целенаправленную природу. Алистер Кокбэрн опубликовал статью, в которой описывается этот подход, а также шаблоны, используемые (строго или нестрого) при этом в качестве отправной точки ([Сос97а]; имеется Интернет-версия этой статьи [URL 46]). На рисунке 7.1. показан (в сокращении) пример подобного шаблона, на рис. 7.2 представлен пример сценария его использования.
Рис. 7.1. Шаблон сценария использования системы по А. Кокбэрну
A. ХАРАКТЕРНАЯ ИНФОРМАЦИЯ
– Цель в контексте
– Область действия
– Уровень
– Предусловия
– Условие успешного завершения
– Условие неудачного завершения
– Первичный действующий субъект
– Условие начала действия
B. ОСНОВНОЙ СЦЕНАРИЙ ПРИ УСПЕШНОМ ЗАВЕРШЕНИИ
C. РАСШИРЕНИЯ
D. ВАРИАНТЫ
E. СОПУТСТВУЮЩАЯ ИНФОРМАЦИЯ
– Приоритет
– Рабочая характеристика
– Частота
– Превосходящий прецедент использования
– Подчиненный прецедент использования
– Канал связи с первичным действующим субъектом
– Вторичные действующие субъекты
– Канал связи со вторичными действующими субъектами
F. РАСПИСАНИЕ
G. ОТКРЫТЫЕ ПРОБЛЕМЫ
Используя формальный шаблон в качестве шпаргалки, вы можете быть уверены в том, что включили всю необходимую информацию в сценарий использования системы: характеристики производительности, другие стороны-участники, приоритет, частоту использования и разнообразные ошибки и исключения, которые могут появляться неожиданно ("нефункциональные требования"). Шаблон удобен для записи комментариев пользователей, наподобие "если мы получим условие ххх, тогда нам придется сделать ууу". Шаблон может послужить в качестве готовой повестки дня при встрече с пользователями ваших программ.
Рис. 7.2. Пример сценария использования системы
ПРЕЦЕДЕНТ ИСПОЛЬЗОВАНИЯ № 5: ПРИОБРЕТЕНИЕ ТОВАРА
A. ХАРАКТЕРНАЯ ИНФОРМАЦИЯ
• Цель в контексте: Покупатель напрямую направляет коммерческий запрос в нашу фирму и ожидает отгрузки товаров и выставления счета за указанные товары.
• Область действия: Фирма
• Уровень: Итоговая информация
• Предусловия: Нам известен покупатель, его адрес, и т. д.
• Условие успешного завершения: Покупатель получает товары, мы получаем оплату.
• Условие неуспешного завершения: Мы не производим отгрузку товаров, покупатель не производит оплату.
• Первичный действующий субъект: Покупатель, любой агент (или компьютер), действующий от имени заказчика
• Условие начала действия: Получение запроса на приобретение товара.
B. ОСНОВНОЙ СЦЕНАРИЙ С УСПЕШНЫМ ЗАВЕРШЕНИЕМ
1. Покупатель обращается в фирму с запросом на приобретение товара.
2. Фирма фиксирует имя покупателя. его адрес, требуемые товары. и т. д.
3. Фирма предоставляет покупателю информацию о товарах, ценах, сроках поставки, и т. д.
4. Покупатель подтверждает заказ.
5. Фирма компонует заказ, отправляет заказ покупателю.
6. Фирма высылает покупателю счет-фактуру.
7. Покупатель оплачивает счет-фактуру.
C. РАСШИРЕНИЯ
3а. Один из пунктов заказа отсутствует у данной фирмы: Заказ переоформляется.
4а. Покупатель производит оплату непосредственно кредитной картой: Прием оплаты кредитной картой (прецедент использования № 44).
7а. Покупатель возвращает товар: Оформление возвращенного товара (прецедент использования № 105).
D. ВАРИАНТЫ
1. Покупатель может осуществить заказ по телефону, факсу, при помощи Интернет-формы (на странице), по другим сетям электронного обмена информацией.
7. Покупатель может оплатить заказ наличными денежным переводом, чеком, или кредитной картой.
E. СОПУТСТВУЮЩАЯ ИНФОРМАЦИЯ
• Приоритет: Высший
• Производительность: 5 минут на оформление заказа, оплата в течение 45 дней
• Частота: 200 заказов в день
• Превосходящий прецедент использования: Управление взаимоотношением с заказчиком (прецедент использования № 2).
• Подчиненные прецеденты использования: Компоновка заказа (прецедент использования № 15)
• Прием оплаты кредитной картой (прецедент использования № 44). Возврат товара покупателем (прецедент использования № 105).
• Канал общения с первичным действующим субъектом: по телефону, факсу или компьютерной сети.
• Вторичные действующие субъекты: компания – оператор платежной системы, банк, экспедиторская фирма.
F. РАСПИСАНИЕ
• Должная дата: Выпуск 1.0
G. ПРОБЛЕМЫ, ЯВЛЯЮЩИЕСЯ ОТКРЫТЫМИ
• Что происходит, если имеется лишь часть заказа?
• Что происходит, если кредитная карта похищена?
Подобного рода организация поддерживает иерархическое структурирование сценариев использования системы – вложение более подробных сценариев в сценарии более высокого уровня. Например, сценарии post debit и post credit дополняют друг друга в сценарии post transaction.
Диаграммы сценариев использования
Последовательность операций может быть зафиксирована при помощи диаграмм на языке UML, а схемы концептуального представления иногда могут быть полезны для оперативного моделирования бизнес-процессов. На самом деле сценарии использования представляют собой текстовые описания с иерархией и перекрестными ссылками. Сценарии использования могут содержать гиперссылки на другие сценарии и могут вкладываться друг в друга.Рис. 7.3. Сценарии использования, выраженные UML, понятны даже ребенку!
Чрезмерная спецификация
При генерации документов, содержащих требования, возникает серьезная опасность чрезмерной спецификации. Хорошие документы остаются абстрактными. Там, где думают о требованиях, простейшая формулировка, точно отражающая суть потребности, является наилучшей. Это не означает, что вы можете допустить неопределенность, нужно зафиксировать основополагающие семантические инварианты в качестве требований и задокументировать конкретную или же существующую на данный момент практику в качестве политики.
Требования не являются архитектурой. Требования – это не конструкция, и не пользовательский интерфейс. Это потребность.
Требования не являются архитектурой. Требования – это не конструкция, и не пользовательский интерфейс. Это потребность.
Видеть перспективу
Вина за возникновение "проблемы 2000 года" часто возлагается на близоруких программистов, пытавшихся сэкономить несколько байтов в те дни, когда объем памяти мэйнфреймов был меньше, чем у современных пультов дистанционного управления телевизорами.
Но это не зависело от программистов и не являлось вопросом использования памяти. Если уж быть честным до конца, вина за это лежит на системных аналитиках и проектировщиках. "Проблема 2000 года" возникла по двум основным причинам: нежелание выйти за пределы существующей бизнес-практики и нарушение принципа DRY.
Двухразрядное обозначение года использовалось в деловой практике задолго до появления компьютеров. Это было обычной практикой. В то время приложения, предназначенные для обработки данных, в основном занимались автоматизацией существующих бизнес-процессов и просто повторили ошибку. Даже в том случае, когда архитектура требовала двухразрядного обозначения при вводе данных, создании отчетов и хранении данных, должна была бы появиться абстракция DATE, которая «знала» о том, что две цифры представляли собой усеченную форму реальной календарной даты.
Но это не зависело от программистов и не являлось вопросом использования памяти. Если уж быть честным до конца, вина за это лежит на системных аналитиках и проектировщиках. "Проблема 2000 года" возникла по двум основным причинам: нежелание выйти за пределы существующей бизнес-практики и нарушение принципа DRY.
Двухразрядное обозначение года использовалось в деловой практике задолго до появления компьютеров. Это было обычной практикой. В то время приложения, предназначенные для обработки данных, в основном занимались автоматизацией существующих бизнес-процессов и просто повторили ошибку. Даже в том случае, когда архитектура требовала двухразрядного обозначения при вводе данных, создании отчетов и хранении данных, должна была бы появиться абстракция DATE, которая «знала» о том, что две цифры представляли собой усеченную форму реальной календарной даты.
Подсказка 53: Абстракции живут дольше, чем подробности