Видение такого известного популяризатора стандарта UML как Kirill Fakhroutdinov проиллюстрировано примером на его сайте:
http://www.uml-diagrams.org/bank-atm-uml-use-case-diagram-example.html
На минуту представим себя на планете, где банкоматы выдают деньги в обход банка. Или силами, почерпнутыми у Арлоу и Нейштадта на минуту обобщим Customer и Bank и "исправим" диаграмму. По-моему, неплохая выходит планета. Уже лечу к ней.

Приводя Арлоу и Нейштадта я лишь показал, что рассуждения для чтения или изменения исходной диаграммы должны во многом основываться на контексте и предметной области. И что дальнейшее уточнение диаграммы может идти разными путями, или это будет обощение, или абстрагирование (выделение каких-то абстрактных ВИ) или предполагание, что два актора тут присутствуют неслучайно. При этом ясно, что Банк тут не инициатор ВИ, а лишь его участник, раньше (в розе) для этого предлагалась рисовать стрелку или указывать стереотип "инициирует".

Если бы имена элементов модели были бы важнее типов элементов и связей между ними, то для лучшего моделирования нужно было бы стереть человечков, овальчики, стрелочки. И заменить их на слова. Но напала блажь -- высказываться невербально, на графическом (и в том числе программно читаемом) языке. Представим себя программами-чеккерами. С такой точки зрения имена элементов модели -- лишь строчки. Смысл модели в наборе элементов, их свойствах, их связях. И тут везде одно и то же: один ВИ и два связанных с ним ДЛ. В каждом случае чеккер прочтёт модель с одинаковым смыслом.

[Про остальное написало в личку.]

И тут везде одно и то же: один ВИ и два связанных с ним ДЛ. В каждом случае чеккер прочтёт модель с одинаковым смыслом.

Именно, как только мы начинаем производить автоматическую трансформацию с целью получения исполняемого кода или другого интерпретируемого продукта.

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

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

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

В Agile Modeling, к слову, допускается противоречивость. Накосячили в одном месте (где неважно), исправили в другом (где важно).

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

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

Ну да, Вы правы. Я вспомнил такое правило. У каждого ВИ есть только одно основное действующее лицо (первичное), то, которое инициирует ВИ, остальные могут быть только вспомогательными.

Вижу в ленте провод для некропоста. Приклею это и ненадолго отлечу.

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

Вижу в ленте провод для некропоста. Приклею это и ненадолго отлечу.

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

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

Это что за ужас инопланетный тут представлен?

А что тут такого ужасного?
Все вроде бы правильно.

А что тут такого ужасного?
Все вроде бы правильно.

Для начала не плохо бы начать с соответствия спецификации (стандарту) UML.

Для начала не плохо бы начать с соответствия спецификации (стандарту) UML.

А что на этой схеме не соответствует UML?

А что на этой схеме не соответствует UML?

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

Затруднительно отвечать на заданный вопрос, сохраняя серьёзность.

А вы попробуйте.
Я серьезно не вижу никаких нарушений стандарта UML в этой схеме.
Может быть я плохо знаю стандарт или не внимателен.

Было бы хорошо, если бы без лишних слов Вы просто объясните, чем схема не соответствует стандарту.

Может быть я плохо знаю стандарт или не внимателен.

Ну тогда может Вы для начала узнаете его немного лучше? Тогда ответ будет вполне очевиден.

Было бы хорошо, если бы без лишних Вы просто объясните, чем схема не соответствует стандарту.

Зачем же лишать Вас удовольствия?

Ну тогда может Вы для начала узнаете его немного лучше? Тогда ответ будет вполне очевиден.

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

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