Какие встречаются основные ошибки при работе с ВИ?

1. Отсутствие системы или действующего лица

Это одна из самых распространенных ошибок. Возможная причина невнимательность и избыточная торопливость. Однако я обнаружил и другие более глубинные причины. Даже после четкого объяснения, что вариант использования показывает возможное взаимодействие, по крайней мере, между ДВУМИ действующими лицами, где одно из них – это система по умолчанию, все равно ошибки, связанные с  отсутствием системы превалируют. Проанализировав ситуацию, я пришел к выводу, что студенты имеют либо малый навык программирования именно интерактивных систем, а отсюда подход к система как в вычислительному ресурсу, который может работать без вмешательства из вне, либо они никак не могу ассоциировать систему с объектом, имеющим поведение, т.е. реагирующего на внешние «раздражители».

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

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

2. Смешивание уровней детализации

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

3. Функциональная декомпозиция

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

4. Стремление описывать сценарии в интерфейсном стиле

Типичная ошибка. Убить невозможно, вероятно, устраняется только опытом разработки от начала и до конца, при чем в команде.

5. Проблемы написания альтернативных сценариев и исключений

Возможно, здесь не совсем логичен был я сам, тем не менее, возникают такие проблемы, когда при описании одного сценария в разных местах хочется писать одинаковую альтернативу или исключение. Я полагаю, что тут неверность написания самого основного потока. Часто случается попытка писать исключение к исключению. Нет четкости (и у меня кстати) как правильно дифференцировать альтернативные потоки и исключительные ситуации. В частности, Вигерс довольно четко трактует это. Альтернативные потоки он включает в основной поток, как разные варианты этого основного потока, а исключения приводит отдельно. Однако здесь возникает проблема когда к нескольким альтернативным потокам хочется применить одно исключение (особенно если имеет место возврат в основной поток). 

6. Нечеткое понимание различия между «черным» и «прозрачным» ящиками

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

7. Наделение поведением бизнес-сущностей

Часто возникает у студентов при описании сценария в виде диаграммы деятельности в качестве действующего лица описывать некоторую бизнес-сущность. Например: клиент запрашивает баланс счета в задаче про банкомат, счет предоставляет ему информацию о балансе. Ошибка надо сказать тонкая. Особенно, когда мы говорим об операциях счета, рассматривая его как объект системы, обладающий поведением. Думаю здесь присутствует ошибка реализации.