Сразу хочу оговориться. Варианты использования - отличный инструмент работы с требованиями, областью знаний и т.п. Вообщем отличное средство. Однако, что касается диаграммы вариантов использования, то тут в семье не без урода.

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

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

Типичный пример (детальнее смотрите здесь)


С какого бодуна вообще решено изображать работу с файловым менеджером таким образом. И выделение пользователей не по ролевому признаку, а по опытности - что за бред??

А как вам нравится это "декомпозиция" ВИ Управление ресурсами файловой системы: Добавление, Правка и Удаление. А что простите такое управление ресурсами, которое должно обязательно включать добавление, правку и удаление - заметьте ОДНОВРЕМЕННО, если все-таки следовать букве закона использования ДВИ.

В общем пришло время поговорить серьезно. Есть плюсы или только минусы? Или минусы - это и есть плюсы?

Поскольку эта тема тревожит умы форумчан, а последовательный противник ДВИ - Денис Бесков, то я хотел бы призвать вас высказаться по существу, со своими аргументами.

Надеюсь, в споре родится истина. Родится что-то полезное. возможно правило форума - те кто попытается обратится с вопросом по ДВИ - тотчас исключается из форума 

Претензии в приведенном примере относятся к тому,
1. как именно была использована (нарисована) ДВИ или
2. к самой спецификации ДВИ?

Если 1, то, может быть стоит взять менее "игрушечные" примеры (например ДВИ из Universal Business Language 2.0 Public Review Draft)? А то всякие примеры с наливанием чашки кофе или чая, честно говоря, достали. Можно подумать, что именно автоматизация наливания кофе в чашку является для ИТ такой же фундаментальной проблемой, какой была теорема Ферма для развития математики. Для таких "мелких" задач ДВИ точно бесполезна.
ИМХО, значение ДВИ для проекта определяется возможными вариантами этой диаграммы, из которых нужно сделать одну по результатам обсуждения с Заказчиком (а то и в результате объединенмя несколькмх диаграмм по результатам обсуждения с разными представитлеями Заказчика). Поэтому рассматривать диаграммы в отрыве от конкретной ситуации, различных пониманий бизнеса Заказчика, которые должны быть приведены к "общему знаменателю", весьма затруднительно. А без общего (для участников обсуждения) бизнес-контекста вряд ли удастся к этому знаменателю приблизиться.
Кстати, истина рождается в обсуждении, в споре она умирает .

Ну вы блин даете.

ДИ - очень нужная диаграмма.
Она показывает ЧТО делает система в этом сумашедшем мире.
По сути правильная ДИ - это спецификация на систему в виде комиксов. Все наглядно и понятно.
ДИ рисуют аналитики. Надеюсь понятно зачем.
ДИ могут рисовать архитекторы, например, чтобы описать ЧТО делает та или иная подсистема и с кем и зачем она взаимодействует.
ДИ могут рисовать программисты, например, чтобы описать ответственности классов, компонент или других модулей. Все знают что такое CRC-карты? Так вот ДИ - это те же CRC-карты, только по другому нарисованные.
ДИ могут использоваться тестировщиками, так как ДЛ на ДИ - это роль, которую должен сыграть тестировщик при системном тестировании. ДИ показывает тестировщику систему не в виде черного ящика, как обычно, а как белый ящик. Каждый ВИ - набор тестов (сценариев).
Да масса применений ГРАМОТНО нарисованной ДИ.

Надо просто учиться и учить других. Вот и все. А то что кто-то там (ссылка Эдуарда) вообще не понимает что рисует ... так идиотов хватает.

Давайте на эмоциях-то ребенка не выплескивать.

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

Что ещё забыл?

Претензии в приведенном примере относятся к тому,
1. как именно была использована (нарисована) ДВИ или
2. к самой спецификации ДВИ?

Кстати, истина рождается в обсуждении, в споре она умирает .

Привет, Shur. Я уже думал, Вы нас покинули
Пример приведен лишь как пример - не более и не менее. Обсуждаем не пример. Обсуждаем + и -.

Насчет истины - согласен Однако я говорю об устоявшемся изречении.

Мне бы хотелось, чтобы участники полемики высказывались ясно и по существу. Т.е. не абстрактно -это полезно или не полезно, а конкретно. С четко обозначенной аргументацией за и против, демонстрацией примеров, возможно жизненного опыта и т.п.

Ну вы блин даете.

Надо просто учиться и учить других. Вот и все. А то что кто-то там (ссылка Эдуарда) вообще не понимает что рисует ... так идиотов хватает.

Давайте на эмоциях-то ребенка не выплескивать.

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

Нужна точность до абсолюта - типа вот пример смотрите понимайте.

Кстати насчет совпадения с CRC - у меня были такие же ассоциации, но все-таки CRC ближе к диаграмме класов, чем ДИ, разве нет?

Эдуард, как обычно выступает с провокационными предложениями в поисках бури Можно сказать: "Над седой равниной моря гордо реет..."

Эх.... ничто не скроется от опытного взгляда, умудренного опытом Лодочника

Сергей, ты как всегда в ударе? Твой любимый метод индукции поясняет для окружающих много. Осталось записать это в скрижалях. Твой пример убедителен.

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

Есть опровержения, дополнения, усиления?

Кстати насчет совпадения с CRC - у меня были такие же ассоциации, но все-таки CRC ближе к диаграмме класов, чем ДИ, разве нет?

А какая разница-то? ДИ можно рисовать для любой сущности (считая ее системой), а всех с кем это сущность взаимодействует описывать как ДЛ.

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

Нужна точность до абсолюта - типа вот пример смотрите понимайте.

Кто не понял, что я написал? Задайте конкретные вопросы.

В качестве примера - ЛЮБАЯ ГРАМОТНО составленная ДИ.

Итого — вроде рассказ Сергея не добавил каких-то новых функций диаграмм.

Что говорит Сергей?
Что ДВИ полезны для выявления назначения системы в диалоге с Заказчиком/Пользователем.
Как понятно из его рассказа, это целиком и полностью зависит от умения аналитика вести эту работу в качестве Коммуникатора.
Рисует он там овальнички или прямоугольнички — Заказчику всё равно. Рисует он там мужиков с яйцами или мордочки-смайлики — всё равно.

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

ДИ - очень нужная диаграмма.
Она показывает ЧТО делает система в этом сумашедшем мире.

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

А:


Не:

А:

По сути правильная ДИ - это спецификация на систему в виде комиксов. Все наглядно и понятно.

Вообще, слово «спецификация» в переводе с латинского, английского это «указания» в смысле «детализация»,«проработка». ДИ — это наоборот, скорее верхнеуровневый взгляд на систему, а не детализация.

Теперь по поводу «наглядно и понятно».

Как показывает пример Сергея, наглядно и понятно это может быть, если мы вместе с Заказчиком/Пользователем рисуем ДИ вместе, как некоторую неформальную картинку.

А не присылаем её в составе документа, самостоятельно нарисовав и он недоумевает — ну да, всё так, только зачем она нужна, эта картинка?

А многочисленные примеры в форуме показывают, что ДИ рисуется в отрыве от З/П, и когда последний получает готовый результат, он не понимает её пользу.

Ну понаписали .... Особенно Сергей

1. Давайте все таки придерживаться обозначений, принятых на Форуме:
http://www.uml2.ru/index.php?option=com_content&task=view&id=71&Itemid=50

2. Как правильно сказал Сергей, многие западные коллеги используют ВИ именно как технику выявления Требований

3. Денис, если ты хочешь показать назначение ВИ, то твой пример не подходит:
Не "Добраться на работу", а "Добраться до пункта назначения", и не Автолюбитель, а Человек
Не "Убедиться в ..", а "Проверить безопасность компьютера" или "Вылечить Компьютер от Вирусов" (а от чего его спасает Антивирус, кроме как от Вирусов?)

4. Если же мы все таки говорим о + и - ДВИ, то давайте о них и говорить. Или мы говорим о ВИ и ДВИ?!
+ ДВИ:
* Охватить одним взглядом функционал Системы, Пользовательские Требования
* Хорош при выявлении Требований
* Служит каркасом для дальнейшей детализации Требований и Архитектуры
* Служит для формирования первоначального набора Тестов, Ролей и Пользовательской Документации
- ДВИ:
* Сложность выявления ВИ и рисования ДВИ
* Сложность понимания
* Не применимость для ряда задач - Интеграционные решения, Один Пользователь и т.д.
* Много взглядов (вариантов) на одну и ту же ДВИ

5. Можно еще поговорить о (не) применимости ДВИ
Применимость ДВИ:
* Бизнес приложения, веб
* Сложные приложения
* Выявление пользовательских требований
* Сильная подготовка Аналитиков
* Итерационная разработка ДВИ
* Не более 5-7 ВИ на одной Д
Неприменимость ДВИ:
* Интеграционные решения, Один Пользователь
* Простые приложения
* Слабая подготовка Аналитика, и других членов Команды
* Постфактумная демонстрация ДВИ в Документации (без объяснений)
* ДВИ без описанных Сценариев ВИ
* Более 5-7 ВИ на одной Д

3. Денис, если ты хочешь показать назначение ВИ, то твой пример не подходит:
Не "Добраться на работу", а "Добраться до пункта назначения", и не Автолюбитель, а Человек

Откуда ты знаешь, о какой системе идёт речь?

Не "Убедиться в ..", а "Проверить безопасность компьютера" или "Вылечить Компьютер от Вирусов" (а от чего его спасает Антивирус, кроме как от Вирусов?)

Ну проверили безопасность, на выходе получили отчёт о 678 вирусах. Это ли настоящая цель пользователя? Не думаю.
Хорошая система должна помогать человеку в реализации интересов. Нет такого интереса — проверять.
Почему антивирус? Опять же, я не называл систему. В этом и прелесть ВИ, что они могут формулироваться тогда, когда ещё никакой системы нет и её категория неизвестна (ОС? Подсистема безопасности? Антивирус? — Да что угодно).

Денис, исправил пока писал, см. еще раз.