Добрый вечер!
Т.к. Эдуард взял на себя труд "критики" структуры, я продолжу "критику" (если можно так назвать) описания функциональности (в данном случае - диаграммы деятельности и идентификации прецедентов).
В справочнике UML, 2-е издание, авторов Буч и Ко, это "диаграмма, на которой показано разложение некоторой деятельности на ее составные части".
Наверное, основное назначение диаграммы - это описание выполнения прецедента (есть и другие приложения).
При описании прецедента деятельность (activity) принадлежит прецеденту, а диаграмма, естественно, деятельности. Т.е. нужно соблюдать правило: один прецедент -> одна деятельность -> одна диаграмма деятельности.
Примечание: составная часть деятельности сама может быть деятельностью; т.о. может образовываться иерархия диаграмм, ужасно подробно описывающих выполнение прецедента.
Вам это, м.б., и не нужно!
Прецедент - это описание последовательности взаимодействий субъекта (или субъектов, один из которых является первичным) с системой. На Вашей диаграмме никаких взаимодействий не видно. М.б. Вы указали, кто выполняет каждое действие в их описаниях? (Честно говоря, я сомневаюсь, что вы выполняли описания действий!)
Для явного указания на диаграмме, кто выполняет действие, имеется элемент "дорожка" (в UML 2 - Partition). У Вас д.б. две дорожки: субъект и система. Каждый узел диаграммы помещается в тот раздел, который представляет исполнителя.
"Мячик" перекидывается между субъектом и системой. Словами это можно выразит примерно так:
- субъект выбирает тип отчета
- система, если субъект выбрал "Инвентарная книга", отображает окно настройки отчета Инвентарная книга
если субъект выбрал "КСУБФ", отображает окно ...
Все это, конечно, графически. Ну, и названия действий должны кратко, но понятно, отображать их содержание (действия - это не названия окошек, а действия, выполняемые системой или субъектом).
Думаю, с объяснением нового материала, на сегодня, достаточно.
Есть явная ляпа, которую многие, особенно начинавшие на UML 1x, не замечают: в самое верхнее действие входят два потока управления. В UML 1х такой прием даже рекомендовался для лаконичности. UML 2 много формальнее (жесткий формализм объясняется тем, что UML 2 разрабатывался для поддержки концепции MDA). В данном случае получается клинч: если в действие входят два потока управления, то действие начинается только тогда, когда управление "прибежит" по обоим потокам. Здесь этого не может быть в принципе, значит действие никогда не будет выполнено. Т.е. такая нотация применима только, если это параллельные потоки.
Для объединения потоков нужно использовать элемент Mtrge Node (это ромбик, похожий на Decision Node, но это другой элемент с другими свойствами). Если Ваш инструмент такого элемента не имеет, используйте ромбик Decision. На вид все будет корректно, а код генерировать из диаграммы деятельности Вы, как я понимаю, не собираетесь.
Проверьте, нет ли еще таких ситуаций.
Кстати, название этого действия - это явно название окошка. Это весь прецедент - формирование отчета. На самом деле это "Отображение окна ...", после которого следует действие субъекта типа "Выбор продолжения", и снова, на стороне системы - ромбик и альтернативные потоки.