Как моделировать альтернативные потоки?

В предыдущей статье я предложил некоторые рекомендации по написанию спецификации вариантов использования. Статья вызвала бурные дискуссии на форуме. Среди прочих поднимался вопрос о том, что считать альтернативными потоками и как их записывать. Действительно, что мы считаем альтернативными потоками? Если существует альтернатива чему-либо, то, очевидно, существует что-то, что мы считаем главным или исходным по отношению к ней. Как мы хорошо знаем, принято выделять в варианте использования основной поток событий. Это, так называемый, «идеальный» сценарий развития событий. Часто такой сценарий можно считать типовым. Остальные сценарии или потоки событий можно считать альтернативными, т.е. альтернативными к основному.

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

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

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

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

Если альтернативные потоки-ответвления более сложные или перехватывают ошибки и прерывания основного потока, то их следует описывать отдельно. Мы предложили записывать такие альтернативные потоки отдельно, а в шаблоне основного потока перечислять их наименования (см. предыдущую статью)

Стоит отметить важный момент. У альтернативного потока не должно быть альтернативных потоков, иначе описание ВИ становится слишком запутанным. Это, конечно, искусственное, но необходимое ограничение. Следует понимать, что ВИ выявляются для того, чтобы понять требуемое поведение системы, а не с целью создания полной модели вариантов использования. Очень легко увязнуть в альтернативных потоках. Поэтому следует указывать только наиболее важные из них. Как только понимание поведения системы достигнуто, моделирование вариантов использования следует остановить. Кроме того, поскольку процесс разработки ПО является итеративным жизненным циклом, всегда можно вернуться к вариантам использования и доработать их, если какие-то аспекты поведения системы не до конца понятны.

{smfdispute}