Добрый день, уважаемые коллеги!

Возник такой вопрос по диаграмме вариантов использования (или use case diagram): если ВИ получается очень много и показывать их на одной диаграмме неинформативно, то по какому принципу/критерию ее лучше разбить на несколько?

Мои варианты:
1. по актерам (т.е. на одной диаграмме показывать ВИ доступные только одному актеру, на второй - другому и т.д.);
2. по функциональным модулям (т.е. на одной диаграмме показыать ВИ, относящиеся к одному модулю; на второй - к другому и т.д.).

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

Образец неразбитой диаграммы можно посмотреть во вложении к моими сообщению

Лучше всего разбивать по функциональным областям, т.к. сразу можно понять контекст. Если необходимо понять какие ВИ может выполнять Актер, то это можно понять из матрицы трассировки.

Критерии нужно выяснять у тех, кто эту диаграмму будет использовать. Если доступа к ним нет, то попробовать поставить себя на их место.

Разработчикам обычно удобнее смотреть по функциональным модулям. Проектировщикам интерфейсов, возможно, по ролям.
Если диаграмма рисуется для преподавателя, то можно ещё что-нибудь придумать.

Эта диаграмма, кстати, не такая уж большая: её можно охватить одним взглядом и понять контекст. Только непонятны связи между ролями, и человечков лучше расположить вокруг системы, а не внутри.

extend и include использовать в реальной жизни вообще не рекомендуется: резко возрастает вероятность, что потребители диаграммы поймут её неправильно.

Ну и у вас там, кажется, CRUD внизу притаился.

Спасибо за комментарии!

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

А что касается CRUD, то прежде всего спасибо за заметку, но на самом деле диаграмма неполная и еще дорабатывается. Так что Вы абсолютно правы, и все что касается CRUD мы добавим позже!

extend и include использовать в реальной жизни вообще не рекомендуется: резко возрастает вероятность, что потребители диаграммы поймут её неправильно.
CRUD внизу притаился.

Да, наверное, Вы правы. Чаще Extend лишь путает пользователя. Но совсем без extend как-то у меня не полчилось, т.к:
1. все-таки некоторые из ВИ являются дополнительными к основным (т.е. расширяют их);
2. если все ВИ напрямую соединять с актером, то, имхо, диаграмма будет перегружена.
Но может у Вас будут альтернативные мнения.

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

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

[вложение удалено администратором] - слишком большой размер, изменил на уменьшенное

Анастасия,

Согласен с Гришей, экстенд и инклуд нужно использовать в крайнем случае. В вашем случае:
Просмотр списка и просмотр элемента лучше всего объединить в один ВИ, а уже детали просмотра списка и элемента описать в виде отдельных основных сценариев.

Не забывайте про основные принципы ООП, в частности про инкапсуляцию.

Почему-то во всех схожих темах предлагается рассматривать диаграмму вариантов использования и способы её "улучшения" в отрыве от описаний use case'ов.

CRUD внизу притаился

Ну имеется в виду объединить эти ВИ в один, как в приведенной greesha статье показано.
Не Edit Student, Add Student, Delete Student (+ еще подразумеваем View Student), а один ВИ - CRUD Student. Вообще так не всегда можно делать, потому что может быть какое-нибудь разграничение прав доступа (скажем, создать объект данному действующему лицу разрешено, а удалить нельзя), но у Вас вроде нет таких условий.

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

Это все равно изображается в виде CRUD, только в бизнес-правилах в спеке ВИ пишутся такие ограничения.

Это все равно изображается в виде CRUD, только в бизнес-правилах в спеке ВИ пишутся такие ограничения

Ага, спасибо за пояснение. Да, так удобнее.
bas, скажите пожалуйста, а это просто применяемая Вами практика, или такой подход рекомендуется какими-нибудь документами (стандартами, best practicies, etc.)?

Почему-то во всех схожих темах предлагается рассматривать диаграмму вариантов использования и способы её "улучшения" в отрыве от описаний use case'ов.

Виктор, вы не были услышаны

Почему-то во всех схожих темах предлагается рассматривать диаграмму вариантов использования и способы её "улучшения" в отрыве от описаний use case'ов.

Хм, почему бы это?

Совет про CRUD можно дополнить вторым приёмом, описанным в книге Алистера Коберна "Современные методы описания функциональных требований к системам" -- "Параметризованный вариант использования". Коберн описывает как набор ВИ "Найти клиента", "Найти продукт" и т. п. заменяется одним параметризованным ВИ "Найти что-либо". Соответственно, ориентируясь на названия ВИ, можно предложить группирующий ВИ "Посмотреть список чего-либо".

Ага, спасибо за пояснение. Да, так удобнее.
bas, скажите пожалуйста, а это просто применяемая Вами практика, или такой подход рекомендуется какими-нибудь документами (стандартами, best practicies, etc.)?

Это мое ноу хау Если серьезно, то я не помню, что где-то про это читал...
Мой подход про БПр и доп требования в ВИ можно посмотреть здесь:
http://www.req-labs.ru/conf2012/agenda/525/

Это мое ноу хау Если серьезно, то я не помню, что где-то про это читал...

2008-й год, Э.Галиаскаров цитирует Г.Увергарда: http://www.uml2.ru/forum/index.php?topic=628.msg7315#msg7315