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

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

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

Выражаю свое мнение по второму вопросу (по первому повторяться смысла нет).

Если у монетоприемника есть цель, и он может привлечь пассажира, то можно, только у ассоциации нужно стрелку поставить, что манетоприемник инициирует взаимодействие.
В жизни ситуация нереальная. Он что, в зале ожидания будет человека за руку хватать?
Иначе это будет "проход через турникет", см. выше все обсуждения.

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

Обоснование?

А из какого простите контекста вы вообще говорите об автомате в каком-то вокзале?
Я вообще имел в виду, обычный автомат, ручной прототип которого долгие годы существовал во всех видах общественного городского транспорта   

Если у монетоприемника есть цель, и он может привлечь пассажира, то можно, только у ассоциации нужно стрелку поставить, что манетоприемник инициирует взаимодействие.
В жизни ситуация нереальная. Он что, в зале ожидания будет человека за руку хватать?
Иначе это будет "проход через турникет", см. выше все обсуждения.

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

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

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

Не указывает. Поскольку варианты использования, это только часть UML, причем часть как бы, стоящая несколько в стороне.

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

Извини.
Я невнимательно прочитал. Увидел слово Субъект. А в русском переводе RUP 7.x Субъект = Actor.
Наверное, нужно использовать английские слова.

Если пассажир - actor, а манетоприемник - system, то все правильно.

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

Я сейчас попробую тебе выложить две диаграммки про Merge и Fork.

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

я еще не так могу выражаться :о))) поверьте на слово. а если серьезно, мы же говорим о некоем конкретном процессе  получения билета. соответственно, в данном случае должна идти речь о конкретном результате: "билет получен" (в данном случае наличие сдачи несущественно, ибо это как раз один из вариантов) или "билет не получен, деньги возвращены" (мало ли передумал или денег не хватило).

прецедент описывает варианты процесса

IMHO будет лучше не "варианты", а "элементы","функции","составляющие" и т.п., т.е. то, из чего процесс состоит. но может и весть процесс описывать.

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

тут же что важно - точка зрения.
если мы рассматриваем систему с точки зрения пассажира, то будет, соответственно:
 - забрать/получить деньги
 - забрать/получить сдачу
 - забрать/получить билет
 - внести деньги (засунуть их в дырочку монетоприемника)

если с точки зрения автомата, то как ты написал.
следствием может быть интересная особенность, если мы разрабатываем автомат для пользователя, то наличие пользователя при работе автомата сама собой разумеющаяся вещь. а в случае разработки автомата самого по себе, то наличие пользователя bla-bla-bla - обязательное требование :о))) это может быть важно при твоем любимом тестировании.

так что ты уж определись...

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

я бы сказал, что нет.
лучше всех, кого надо, в actor'ы записать, а кого не надо - тех вообще забыть. предлагаю монетоприемник забыть до определенного времени (пока проектировать состав подсистем не начнем). ну и термин "субъект" не надо использовать,  чтобы не забивать голову честным людям.

Эдуард, не нашел как в личных сообщениях вставить картинку.
Не всем это интересно.

Это фрагмент описания бизнес процесса (в RUP - синоним BUC) ("белый ящик").
Диаграммы представлены с целью показать использование некоторых новых (относительно UML1) элементов диаграммы деятельности UML2.

Эдуард, не нашел как в личных сообщениях вставить картинку.
Не всем это интересно.

Спасибо, в личке нельзя ...

я еще не так могу выражаться :о))) поверьте на слово. а если серьезно, мы же говорим о некоем конкретном процессе  получения билета. соответственно, в данном случае должна идти речь о конкретном результате: "билет получен" (в данном случае наличие сдачи несущественно, ибо это как раз один из вариантов) или "билет не получен, деньги возвращены" (мало ли передумал или денег не хватило).

IMHO будет лучше не "варианты", а "элементы","функции","составляющие" и т.п., т.е. то, из чего процесс состоит. но может и весть процесс описывать.

Я опять неточно выразился: use case (класс) описывает все возможные варианты (в том числе - неудачные) достижения цели. Под вариантом я здесь понимаю совокупность "одинаковых" экземпляров (в смысле "пути" выполнения).

Что касается "билет получен", то цель пользователя системы состоит только в этом: корректно получить билет (со здачей и т.п.) Но цель обращения к системе одна, и Use Case один! (Если не плодить UCE и/или UCI). И Эдуард правильно поступил, нарисовав диаграмму деятельности. Скорее всего, этот небольшой Use Case не будет иметь существенных (сложных, требующих отдельного описания и планирования, частей.

Примечание: В RUP имеется ввиду архитектурная существенность.

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

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

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

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

Или может следовало бы показать структуру этого автомата через его части?

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

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

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

К стати, именно эта часть бизнес-процесса (не до конца) представлена на моем фрагменте выше.

Ну, и так далее.

Резюме: фактически перечень прецедентов - это несколько иное представление целей всех потенциальных пользователей. А их описания представляют функциональные (что должна делать) требования к системе.

Спасибо тем, кто прочитал эту нудятину до конца! 

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

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

Или может следовало бы показать структуру этого автомата через его части?

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

К диаграмме деятельности эта новая диаграмма ничего не добавляет.

Если в жизни, дальше нужно создавать модель анализа или проектную модель, в которой для каждого use case создавать кооперацию use case realization и рисовать диаграммы последовательности, имея перед глазами соответствующую диаграмму деятельности.

Я иногда такой курс читаю в московском Интерфейсе. Правда, я основной упор делаю на "беззатратное" документирование проектов разработки ПО.