Было уже несколько разговоров на тему того, что use-case'ов на систему, не зависимо от её масштабов, должно быть порядка 20-30.

У меня постоянно получается много маленьких детальных use-casе'ов, с помощью которых я раскрываю логику их взаимосвязи. Предлагаю в качестве примера разобрать картинку ниже, с удовольствием выслушаю ваши рекомендации по реорганизации.

Здесь красными овалами изображены цели пользователя относительно системы, зелёными - соответственно задачи, средства достижения этих целей.

Для этого в РУПе и был придуманы ВИ реализации. Это изображается на другой диаграмме - ДРВИ (диаграмма реализации ВИ). Или если по Коберну, то это другой уже уровень - не помню (ниже моря).

Саша, не понял. Что конкретно не так и что делать?

Зелёненькие ВИ убрать на другие ДВИ, кол-во ДРВИ = кол-ву ВИ

Денис, хотелось бы для начала понять несколько моментов.

Все зависимости у тебя какой носят характер? Характер инклюдов? Или ты подчеркиваешь здесь пунктирной линией виртуальность связи для данной точки зрения? Т.е. ты практически фиксируешь функциональную декомпозицию? Что в твоем случае обозначает синий полый прямоугольник - просто группировку задач и раскрытие уровня декомпозиции?

Насколько я знаю под реализацией в RUP и UML понимается все-таки диаграмма классов, реализующая вариант использования. Для фиксации используется трассировка. Однако как я думаю, Денис это сам прекрасно знает.

У меня есть мнение, что здесь показаны как бы два уровня. Скажем некий высокоуровневый слой и слой уже пользовательский ближе к системному. Каждая из задач - кажется не тянет на полную цель пользователя, но если рассматривать каждый пункт как использование системы - то вполне подойдет как СИСТЕМНЫЙ ВИ.

ВИ обновить свои данные и ее реализация? редактировать профиль - не если это одно и тоже, просто на разных уровнях. Если так, то это похоже на трассировку к реализации ВИ, аналогично Подержать и Одобрить рецензию.

Что касается левых ВИ, то это похоже на соотношение ВИ уровня облака и Ви уровня моря, как у Коберна, но как-то не то. Понятно что пользователю врядли нужна просто информация о пользователе, ему она нужна в свете знаний об объекте. Так ли я понимаю. Что ту  первично объект - так? А пользователь вторичен, важен его авторитет в данном случае. Тогда Цель узнать о другом пользователе - явно подчинена Узнать об объекте. Хотя системой может быть предоставлена услуга сразу посмотреть информацию о пользователях и уже, выбрав авторитета, перейти для просмотра некоторых объектов.

Зелёненькие ВИ убрать на другие ДВИ, кол-во ДРВИ = кол-ву ВИ

Т.е. ты считаешь, что зелёные тоже пригодятся? А то мне туту как-то Ботман рассказывал, что детали надо в текст сценария засовывать.

Т.е. ты считаешь, что зелёные тоже пригодятся? А то мне туту как-то Ботман рассказывал, что детали надо в текст сценария засовывать.

Ну это как говориться - все зависит от ... Т.к. ты у нас известный художник, то можно и оставить. Я обычно это раскрываю в тексте.
Но если ты оставляешь зелёненькие, то они явно должны быть на отдельной диаграмме, диаграмме более детального уровня (уровня земли, я все таки не согласен с Эдом - у Дениса не уровень облака и моря, а все же больше уровень моря (пользовательские ВИ) и земли (уже функц. декомпозиция больше) - но это больше термины, спорить не будем)

(уровня земли, я все таки не согласен с Эдом - у Дениса не уровень облака и моря, а все же больше уровень моря (пользовательские ВИ) и земли (уже функц. декомпозиция больше) - но это больше термины, спорить не будем)

Да нет, я не утверждаю, что тут уровень облака, а говорю КАК БЫ.
Вообще при построении не смешивать уровни ВИ на одной диаграмме. Однако у Дениса нестандартная диаграмма, т.е. диаграмма не по правилам.

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

Предлагаю ограничиться при использовании диаграммы ВИ изображением деятельности "крупным планом". Для детализации того, что происходит в рамках конкретного кейса (варианта использования) рисовать диаграмму деятельности, причем, возможно, не одну (если получается большая - разбивать диаграмму деятельности на несколько - в идеале, чтобы каждую можно было распечатать на формат не больше чем A4 и при этом все буковки были бы видны.
ИМХО на предложенной для обсуждения диаграмме зеленые ВИ-задачи можно рассматривать как действия (actions) и попытаться упаковать в диаграммы деятельности, соответствующие красным кейсам (ВИ-целям), а на самой диаграмме оставить только красные ВИ, указав связи между ними. ИМХО именно связи между ВИ, а через них - связи между действующими лицами, представляют основную ценность диаграммы. Интересные диаграммы ВИ получаются, если действующих лиц 3-5, для двух диаграмма может показаться тривиальной...

Э, добавлю свои 5 копеек:
По-моему, зеленые use-case не являются action, они больше, чем отдельное действие.
А случайно красненькие не являются business use-case, а зелененькие - use-case? Тогда получается, что у нас на диаграмме сразу представлены части 2 слоев модели Системы: бизнес-анализа и системного анализа. Если принять эту гипотезу за основную, то у меня бы получилось 3 диаграммы: одна - экторы (или бизнес-экторы) и красненькие use-case как busines use-case, вторая - экторы (пользователи системы) и зелененькие use-case, и отдельная диаграмма трассировки  между зелеными и красными.
Имхо, такое разбиение позволяет взглянуть на систему с разных точек зрения (бизнеса, системного анализа) и при этом не потерять связей между целями и задачами.

Меня и так начальство корит, что в веб-разработке такой overthinking не нужен, достаточно диаграммы навигации (по Гаррету), а вы предлагаете 3 уровня создавать )

Там основная проблема со страницами - что человек может в любой момент решать - идти дальше или нет. Это порождает множество вариантов прохода по страницам и нечёткие use-case'ы.

Хм, множество вариантов прохода по страницам можно вообще матрицей отобразить: с какой страницы на какую есть переход - на пересечении строки и столбца ставим +.
А про количество диаграмм есть такое соображение: с клиентом и с начальством обычно общаются на уровне документов, а не моделей, соответственно, диаграмма бизнеса уходит в документ бизнес-уровня - предпроектное обследование или Vision какой-нибудь, а диаграмма системного анализа - в ТЗ или SRS, а диаграмма трассировки используется для текущей работы.
Но опять таки все зависит, для чего нужны эти диаграммы, для красоты или для разработки.

Меня и так начальство корит, что в веб-разработке такой overthinking не нужен, достаточно диаграммы навигации (по Гаррету), а вы предлагаете 3 уровня создавать )

Там основная проблема со страницами - что человек может в любой момент решать - идти дальше или нет. Это порождает множество вариантов прохода по страницам и нечёткие use-case'ы.

В пределе UC могут быть "перпендикулярны" диаграммам перехода. Возможно не стоит смешивать эти 2 понятия. Т.к. диаграммы перехода между страницами -- это область решения, в отличие от UC.

В пределе UC могут быть "перпендикулярны" диаграммам перехода. Возможно не стоит смешивать эти 2 понятия. Т.к. диаграммы перехода между страницами -- это область решения, в отличие от UC.

Юра, в наших проектах полные дизайн-макеты появляются раньше ТЗ. А до них есть только концептуальный документ с целями и задачами.