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

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

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

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

А вот слайд из презентации корпоративного курса, который читается за деньги и уважаемым мною человеком, тоже стоит включить в презентацию, как образец исключительного заблуждения автора

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

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

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

Это не UML и не диаграмма вариантов использования, но это прекрасная визуализация.

Я считаю очень большой проблемой то, что к схеме типа "люди и их интересы" намертво приклеен ярлык "диаграммы вариантов использования". Варианты использования - это всего лишь один из методов проектирования, применимый в сравнительно узкой области. А область применения этой визуализации намного шире.

Об этом я говорил на Analyst Days в этом году. Видео пока нет, выложена только презентация. http://analystdays.ru/ru/talk/45843 Слайд 31 иллюстрирует один из первых зафиксированных случаев использования этой диаграммы в истории.

Я вообще об этом, по-моему, на каждом углу твержу, но меня не понимают. Ну ничего, мы разрушим эту монополию.
Поэтому решительно предлагаю эту диаграмму переименовать, а выражение "диаграмма вариантов использования" забыть, как страшный сон.
http://visic.info/pictures/roles-n-goals/61/

Ну вот, задвигалось. Благодарю за участие в теме.
Для обозначения ответственностей есть стандартная нотация: http://yuml.me/1f7de978
И есть методика, поясняющая, что исполнитель внутри [бизнес-]системы и элемент контекста [бизнес-]системы aka actor -- не одно и то же. Но зачем, всё это, если можно изобрести какую-то мимикрию под стандартные обозначения и связывать с ними свои собственные смыслы? Красоту подобных визуализаций может оценить лишь тот, кто входит в соответствующее "языковое гетто".
А почему это не UML, если автор, это нарисовавший, считает, что рассказывает про UML?

Ну вот, задвигалось. Благодарю за участие в теме.
Для обозначения ответственностей есть стандартная нотация: http://yuml.me/1f7de978
И есть методика, поясняющая, что исполнитель внутри [бизнес-]системы и элемент контекста [бизнес-]системы aka actor -- не одно и то же. Но зачем, всё это, если можно изобрести какую-то мимикрию под стандартные обозначения и связывать с ними свои собственные смыслы? Красоту подобных визуализаций может оценить лишь тот, кто входит в соответствующее "языковое гетто".

В этой стандартной нотации для "ответственностей" всё прекрасно: и скобочки после ответственностей, и горизонтальные чёрточки, делящие прямоугольник на три части (а зачем посередине пустая, кстати?), а особенно прекрасны интуитивно понятные любому человеку правила написания: МолодойВоин, охотитьсяНаЗверя.

Нет, у тех, кто программировал на Java, никаких затруднений не возникнет, конечно. А вы что, не программировали? Ну, это ваши проблемы. Стандарты нужно знать. Но непременно с методиками, иначе вы обязательно что-то нарушите.

"Вот за это они нас и не любят." (c)

Для обозначения ответственностей есть стандартная нотация: http://yuml.me/1f7de978

По части визуализации она, прямо скажем, не очень.

Это не UML и не диаграмма вариантов использования, но это прекрасная визуализация.

Такая визуализация должна просто сопровождаться легендой.
Овал - интерес
Человечек - тип субъекта в племени
Стрелка с полым треугольником - специализация

Такая визуализация должна просто сопровождаться легендой.
Овал - интерес
Человечек - тип субъекта в племени
Стрелка с полым треугольником - специализация

А без легенды непонятно? В специальных пояснениях нуждается только стрелка.

Недостатки онлайновой рисовалки коллеги по форуму нашли очень быстро. И принесли мне "граблей". Благодарю. Вопросов моих, таким образом, как бы не было. Узнаваемый стиль.

Скобочки можно опустить. Именовать так, как привычнее. "Лишнюю" среднюю палку убрать. Можно убрать и рамочки, заменив на охотников.

Для изобретённой "мужико-яйцевой" схемы можно воспользоваться подмножеством диаграмм классов UML, в него она впишется без нарушения стандарта. Можно даже сделать профиль, и "мужико-яйцевые" схемы начнут понимать UML-инструменты, умеющие профили. Но почему-то это не годится, а годится декларировать, мол, язык негодный.

Скобочки можно опустить. Именовать так, как привычнее. "Лишнюю" среднюю палку убрать. Можно убрать и рамочки, заменив на охотников.

А нотация после таких издевательств точно останется стандартной?

Для изобретённой "мужико-яйцевой" схемы можно воспользоваться подмножеством диаграмм классов UML, в него она впишется без нарушения стандарта. Можно даже сделать профиль, и "мужико-яйцевые" схемы начнут понимать UML-инструменты, умеющие профили. Но почему-то это не годится, а годится декларировать, мол, язык негодный.

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

Так что мужикам - яйца, экспертам - язык.

Для изобретённой "мужико-яйцевой" схемы можно воспользоваться подмножеством диаграмм классов UML, в него она впишется без нарушения стандарта. Можно даже сделать профиль, и "мужико-яйцевые" схемы начнут понимать UML-инструменты, умеющие профили. Но почему-то это не годится, а годится декларировать, мол, язык негодный.

Кто сказал, что язык негодный? UML - отличный язык! Для архитекторов и программистов.

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

Я предлагаю изобрести ещё какой-нибудь язык для тутошней планеты-форума. Чтобы мои (хотя бы) реплики не кастировались по воле составителей ответов на них. Чем не устраивает диаграмма классов как основа "муже-яйцевых" аналитических схем? Тем, что она будет понятна помимо аналитиков ещё и архитекторам, и программистам, и, страшно подумать, каким-то прогам? 

Я предлагаю изобрести ещё какой-нибудь язык для тутошней планеты-форума. Чтобы мои (хотя бы) реплики не кастировались по воле составителей ответов на них.

В смысле, в цитатах? Или был отредактирован какой-то ваш пост?
Спрашиваю, потому что я иногда по ошибке нажимаю кнопку "Редактировать" вместо "Цитировать", и мог непреднамеренно что-то удалить.

Чем не устраивает диаграмма классов как основа "муже-яйцевых" аналитических схем? Тем, что она будет понятна помимо аналитиков ещё и архитекторам, и программистам, и, страшно подумать, каким-то прогам? 

Да всем устраивает, если с её помощью аналитики общаются с архитекторами и программистами и друг друга понимают.

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

А без легенды непонятно? В специальных пояснениях нуждается только стрелка.

Без легенды понятно, если эту диаграмму не  относить к UML. Если же задача была образно что-то показать, то наверное лучше было бы картинками это сделать.

Кто сказал, что язык негодный? UML - отличный язык! Для архитекторов и программистов.

Я в своем опыте ограничен даже поболе - только архитекторами. Не было у меня программистов, готовых (реально, а не "говно вопрос!") работать по спецификациям в uml.

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

Коллега, мы же общаемся "за стройку" не только со строителями. Но и с теми, кто эту самую стройку заказывает и бабло на нее отсчитывает. Чего Вы так рветесь поговорить с ними на строительном языке? Если бы они этого хотели, говорили бы напрямую, без нас.

Чтобы мои (хотя бы) реплики не кастировались по воле составителей ответов на них.

Цитирование оно такое - суровое и беспощадное.