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

Коллеги, давайте не умножать сущностей сверх меры.

Есть задача - автомат продажи билетов. Определен принцип его работы.
Учет билетов крайне просто. Вставили рулон билетов - знаете количество, кончился рулон, значете сколько продано, сравнили с деньгами, узнали кто кого ну это самое... обманул

То есть ты полагаешь, что диаграмма использования должна отражать все эффекты использования системы?

Спасибо, что помог сформулировать мне мой вопрос:)

Итак.
Должна ли диаграмма использования отражать ВСЕ эффекты использования системы?

Коллеги, давайте не умножать сущностей сверх меры.

Есть задача - автомат продажи билетов. Определен принцип его работы.
Учет билетов крайне просто. Вставили рулон билетов - знаете количество, кончился рулон, значете сколько продано, сравнили с деньгами, узнали кто кого ну это самое... обманул

Если рассматривать данную задачу с такой "упрощённой" точки зрения, то, на мой взгляд, первая диаграмма ВИ, вполне поясняется представленной диаграммой деятельности и более подходит для визуализации задачи, нежели диаграмма ВИ №2

Может быть, это старческий маразм, и я разучился ясно излагать свои мысли!

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

Наглядный пример - Use Case по UML и по Коберну. Это близкие, но разные понятия. В UML - это всегда "черный ящик", у Коберна - это может быть и "черный", и "прозрачный" ящик. В ядре UML есть только один уровень (взаимодействие пользователя с компьютерной системой), у Коберна их пять. В определении UML - это класс (набор экземпляров), у Коберна - это "соглашение о ...." (долго перепечатывать!).

Авторы во втором контексте - это авторы UML и понятия Use Case в смысле UML (Буч, Рамбо и Джекобсон, "три друга"). Они же - "инициаторы" создания RUP. В принципе, RUP можно рассматривать как описание технологии использования UML (сам язык, естественно, технологии иметь не может). Рекомендации RUP можно рассматривать как дополнительный материал, отражающий точку зрения авторов UML.
Можно и не использовать, воля ваша! Но это будет ваша концепция, ваш термин. Это язык! Кто-то Вас не поймет!

А теперь представьте себе автомат на вокзале, единственной функцией которого является возврат денег! Вы не согласны с рекомендацией RUP о существенности и планировании пошаговой поставки? Тогда другой пример, более строгий:

Представьте себе полноценный автомат, к нему подходит человек с целью возвратить свои деньги. Если автомат функционирует правильно, то он не отдаст чужие деньги. Т.о., полный процесс должен включать и засовывание монеток в монетоприемник! А это у вас отдельный Use Case?

Но Возврат денег вполне может рассматриваться как абстрактный Use Case, расширяющий основной UseCase при некоторых условиях (уровень рыбы у Коберна).

Еще раз прошу извинить за "мутный" язык. Простым языком говорить разучился. Жена меня называет "прикладной теоретик".

В дополнении к обсуждению. что вы думаете об этой диаграмме. Поясняет ли она действие 1 диаграммы UC и устраняет потребность во второй?

Вполне!

Примечание: Касается только UML2.
В узел (кроме Merge и Join) не может входить больше одного потока управления. Большинство инструментов это не контролируют. Но правилами это интерпретируется как последовательность двух элементов: Join и сам элемент, например, Action. Т.е. в данной ситуации управление никогда не будет передано из действия (и конец никогда не наступит!).
В данном случае (в UML2) стрелки от Начала и от Решения должны входить в Merge, а затем в первое действие.
То же относится к Финалу.

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

Представьте себе полноценный автомат, к нему подходит человек с целью возвратить свои деньги. Если автомат функционирует правильно, то он не отдаст чужие деньги. Т.о., полный процесс должен включать и засовывание монеток в монетоприемник! А это у вас отдельный Use Case?

неее, не надо путать отождествлять процесс и use case.

неее, не надо путать отождествлять процесс и use case.

Не понял критики?

Безусловно, Use Case описывает некоторый особый процесс, определенный в UML. М.б. я выразился некорректно.
А что по смыслу неверно?

IМНО процесс позволяет достигнуть цели - купить билет (либо в приведенном Вами варианте - получить деньги). для достижения этой цели необходимо использовать несколько UC, т.е. процесс реализуется несколькими (или всеми) UC

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

Это я к тому, что процесс - это одно, а UC - другое. они между собой могут быть связаны, а могут и нет.

В узел (кроме Merge и Join) не может входить больше одного потока управления. Большинство инструментов это не контролируют. Но правилами это интерпретируется как последовательность двух элементов: Join и сам элемент, например, Action. Т.е. в данной ситуации управление никогда не будет передано из действия (и конец никогда не наступит!).
В данном случае (в UML2) стрелки от Начала и от Решения должны входить в Merge, а затем в первое действие.
То же относится к Финалу.

А нарисовать? Что много буковок и трудно понять о чем речь

Я-таки, не понял
Может быть вариантом использования: вернуть деньги, выдать сдачу, выдать билет, принять деньги?

Да и вопрос, а если Actor = Пассажир, а Субъект = Монетоприемник, чья единственная функция - принимать монеты

Будет ли это правильно?

В общем случае, процесс может и не иметь выраженной цели. Пример: "Это вполне естественный природный процесс!"

Экземпляр UC описывает процесс взаимодействия (у Коберна - Actor & Actor, в UML - Actor & System). UС - это совокупность всех возможных вариантов процесса (в том числе - неудачных) для достижения цели первичного субъекта (primary actor) в UML и всех взаимодейстующих субъектов (у Коберна).

В книжке Коберна (русский перевод): глава 2, Вариант использования как соглашение о поведении, раздел 2.1, Взаимодействие действующих лиц, имеющих цели.

В RUP - рекомендации по именованию: название должно раскрывать цель первичного актера.

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

А нарисовать? Что много буковок и трудно понять о чем речь

Рисовать не умею.
Могу диаграмму прислать по почте.

Merge обозначается таким же ромбиком, как Decision, но Decision имеет один вход и много выходов по условию, а Merge- много входов и один выход.
В UML1 Merge небыло, а Decision допускал много входов и много выходов. Любой сигнал проскакивает без задержки.

Fork и Join. В UML1 была "полоса синхронизации" (не помню, как элемент назывался) для распараллеливания потоков. Сколько из первой полосы вышло, столько должно войти во вторую. Пока не войдут все, курсор дальше не идет.
В UML2 Fork - это элемент, обозначающий разветвление: один вход и множество (безусловных) выходов. Каждая нить может выполняться, и может либо объединиться с другими потоками управления в элементе Join, либо завершиться узлом Activity Final (завершается весь процесс) или Flow Final (прекращается только эта нить управления).
Элемент Join: много входов и один выход. Те потоки, которы прибежали раньше, ждут, пока не придут все.

Может быть вариантом использования: вернуть деньги, выдать сдачу, выдать билет, принять деньги?

Да, но только не связанными напрямую с Пассажиром (Билетопокупателем).
Мой вариант диаграммы ВИ:
С Пассажиром связан один ВИ: Продажа билета.
ВИ Продажа билета "включает" ВИ: Прием оплаты, Выдача билета
ВИ Возврат оплаты "расширяет" ВИ Прием оплаты.
ВИ Выдача сдачи "расширяет" ВИ Выдача билета.

Другим Актором будет Администратор, ВИ: Обслуживание.
ВИ Обслуживание "включает" ВИ: Контроль состояния, Инкассация, Загрузка билетов.  

В дополнении к обсуждению. что вы думаете об этой диаграмме. Поясняет ли она действие 1 диаграммы UC и устраняет потребность во второй?

Нет не поясняет (в смысле не полностью поясняет), нет не устраняет (необходимость и корректность второй UC пока не очевидна).