Use cases во второй диаграмме не подпадают под определение (пользователь хочет купить билет, а не копейка свои отдать!).
разрешите отвечу цитатой:
A use case is behaviored classifier which specifies behavior of a subject (system under construction or consideration) by describing a set of sequences of actions performed by the system to yield an observable result of some value to one or more actors or other stakeholders of the system. In other words, each use case describes a unit of complete and useful functionality that the subject provides to its users.
This functionality, which is initiated by an actor, must always be completed for the use case to complete. It is considered complete if after its execution the subject will be in a state in which no further inputs or actions are expected and the use case can be either initiated again or is in an error state.
И добавить. Пассажир вообще-то хочет куда-то доехать. Вряд ли ему нужен и проездной билет, как мне думается, если продолжать Вашу мысль в развитии
Если хочется подробнее, и процессы (и последующие решения по ним) из второй диаграммы предполагается иметь как авуары многоразового использования, их можно поместить на первую диаграмму с отношениями <<include>> от основного.
Сложно как-то вы изъясняетесь
, с трудом понял, что Вы имели в виду. Нет, не хочется. Мне хочется как можно проще, и максимально понятно тому, кто будет разрабатывать систему.
А можно прокомпостировать билет и не поехать напихать в автомат монет и уйти, не покупая билета?
Напихать денег и уйти можно, однако автомат все равно выдаст билет (ну если не выдаст - это проблемы пассажира:))
Прокомпостировать низя.
Или получить сдачу, не напихав предварительно монет?
Можно - чужую, или 0 монет
Но по-серьезному, будем считать, что контроль существует. Пример увиденный мною в английском автобусе. Там нет контролеров, платишь водителю. Причем он шельма видит сразу и не стесняется напоминать. Покупаешь билет примерно так - как я описал выше: кидаешь монеты - получаешь билет, или даешь водиле, он там сам тебе выдает билет.
Или купить билет без денег?
Размечтался!
Если можно, то я за вторую диаграмму. Если нет - за первую.
Понятно, ты за вторую.
Раскрою секрет моих логических размышлений.
1 Диаграмма была получена вследствие также рассуждений, что и у lnew. Какова цель использования автомата - приобрести проездной билет.
2 диаграмма появилась в ходе критики первой и некоторых обсуждений. Критика такова. Мы описали ВИ с точки зрения использования автомата пассажиром. Возникает вопрос, а какая собственно функциональность субъекта (объекта, системы под рассмотрением) тут описывается? Если с позиции системы, то что? Выдать проездной билет? Или что?
Если каждая связь-ассоциация между Актером и Субъектом - есть отражение некоторого интерфейса, то какой интерфейс мы увидим в ВИ Приобрести проездной билет?
В результате получился второй вариант диаграммы, возможно не идеальный, но
принять монету (функциональность автомата!) - предполагает наличие некоторого интерфейса для принятия монеты и отображения суммы
выдать билет - тут может не так очевидно я согласен (но если я еду семьей? или хочу получить больше билетов а не один?)
выдать сдачу - тут может не так очевидно я согласен (но см. выше)
вернуть деньги - да понимаю это странно, но я положил 4 монеты а их сумма не равна стоимости билета, и я хочу вернуть их и положить другую монету?
С другой стороны, не следует ли считать 1 диаграмму диаграммой бизнес ВИ, а 2 диаграммой системных ВИ?
Use Case vs. Use Cases - какая должна быть степень детализации?