Наткнулся на описание ЮМЛ от МС:
https://msdn.microsoft.com/ru-ru/library/dd409376.aspx

Кто какие ошибки найдет?

На затравку: мне очень не понравилась вот эта схема:


Что это за ЗЛ - Ресторан? Как Клиент заказывает еду без него?

А по-моему, отличный пример. Понятная и простая иллюстрация.

Наткнулся на описание ЮМЛ от МС:
https://msdn.microsoft.com/ru-ru/library/dd409376.aspx

Кто какие ошибки найдет?

На затравку: мне очень не понравилась вот эта схема:


Что это за ЗЛ - Ресторан? Как Клиент заказывает еду без него?

1. Описываются несколько типов диаграмм и предлагается начать разработку с любой, хотя надо идти от общего к частному. Т.е. будет странным от sequence перейти к use case диаграмме.
2. С одной стороны говорится о том что требования описывают внешнее поведение, видимое через UI и API, с другой стороны, к примеру, sequence диаграмма описывается как часть требований, но говорится про взаимодействие с частями системы.
3. Непонятный UC "Доставить еду" на второй диаграмме. Вынесен за границу некой подсистемы, но вместе с тем приведён на той же диаграмме и непонятно к чему он относится. Такое ощущение,  что это неудачно названный бизнес-UC.

Дальше читать не стал. Много букв:) А пример с эктором ресторан конечно не очень удачный. Хотя такой Эктор может существовать если, к примеру, в ресторане работает одно лицо, которое выполняет все роли.

Как эктор Ресторан узнает о заказах, если он взаимодействует с подсистемой только как поставщик сведений о меню.

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

Да начальная UCD вполне понятна, но синтаксически и семантически ошибочная на мой взгляд. Вопрос стоил ли к этому придираться? И если оставить как есть, точно не приведет к логическом разрыву. Учтите, тут моделюшечка то микропусенькая. А в реальности все куда суровее.

Эти картинки только иллюстрируют возможности применения схемы, а вовсе не представляют "полную модель юскейсов".

Если расписать всех возможных пользователей и все их цели по отношению к системе, получится карта, которую можно вешать на стену, а не использовать в качестве иллюстрации к статье.

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

Я в одном могу согласиться: это не диаграмма вариантов использования. Но imho сама схема несправедливо (или, скорее, недальновидно) узурпирована методологами разработки по юскейсам. Хотя это очень мощный инструмент визуализации, возможности применения которого распространяются далеко за пределы ДВИ. Юскейсы отомрут, а схема останется.

Я в одном могу согласиться: это не диаграмма вариантов использования.

а что это?

а что это?

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

я повторяю свой вопрос

Я в одном могу согласиться: это не диаграмма вариантов использования. Но imho сама схема несправедливо (или, скорее, недальновидно) узурпирована методологами разработки по юскейсам. Хотя это очень мощный инструмент визуализации, возможности применения которого распространяются далеко за пределы ДВИ. Юскейсы отомрут, а схема останется.

А почему нет? Я считаю что это вполне себе диаграмма использования. Конечно, "Доставить еду" вылезает за ее рамки, и в таком случае, было бы лучше нарисовать это все как процесс, например в BPMN, но это уже мелочи.
А почему юзкейсы отомрут? Это вполне себе самостоятельный элемент исследования возможностей системы.