Соглашусь с Леонидом и Гришей.
2 DinamoYA, ИМХО у Вас есть сильное не понимание модели ВИ.
Пользовательский ВИ - это в первую цель пользователя. Ну нет цели у Пользователя засунуть в автомат деньги! У него есть цель - получить билет, а уже все детали функционирования ВИ (что делает Пользователь и как отвечает Система) описываются в виде сценария ВИ или ДД/ДП/ДВ.

Пользовательский ВИ - это в первую цель пользователя. Ну нет цели у Пользователя засунуть в автомат деньги! У него есть цель - получить билет, а уже все детали функционирования ВИ (что делает Пользователь и как отвечает Система) описываются в виде сценария ВИ или ДД/ДП/ДВ.

Уважаемый bas, Вы не могли бы раскрыть что вы вкладываете в термин "Пользовательский ВИ", в чем по вашему выражено наше непонимание сути диаграммы ВИ.

Формируя свои ответы я исходил из самого первого сообщения уважаемого Автора "Use Case vs. Use Cases - какая должна быть степень детализации?".
В его вопросе нигде не сказано с какой точки зрения мы должны посмотреть на проектируемую систему.

У Пассажира нет цели засунуть деньги я с вами согласен, но ведь у "Автомата" (утрирую, конечно у его владельца) - есть бизнес-цель - "получить деньги взамен билета". Данная цель неявна и не отражена на представленных автором диаграммах.
Ранее я предложил свой вариант диаграммы ВИ демонстрирующую точку зрения на проектируемую систему Автомат http://www.uml2.ru/forum/index.php?topic=3729.msg27642#msg27642

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

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

 

Пока этот вариант Автором или другими участниками не прокомментирован (возможно потому что не представлена картинка).

Уважаемый bas, Вы не могли бы раскрыть что вы вкладываете в термин "Пользовательский ВИ", в чем по вашему выражено наше непонимание сути диаграммы ВИ.

Формируя свои ответы я исходил из самого первого сообщения уважаемого Автора "Use Case vs. Use Cases - какая должна быть степень детализации?".
В его вопросе нигде не сказано с какой точки зрения мы должны посмотреть на проектируемую систему.

У Пассажира нет цели засунуть деньги я с вами согласен, но ведь у "Автомата" (утрирую, конечно у его владельца) - есть бизнес-цель - "получить деньги взамен билета". Данная цель неявна и не отражена на представленных автором диаграммах.
Ранее я предложил свой вариант диаграммы ВИ демонстрирующую точку зрения на проектируемую систему Автомат http://www.uml2.ru/forum/index.php?topic=3729.msg27642#msg27642
 

Пока этот вариант Автором или другими участниками не прокомментирован (возможно потому что не представлена картинка).

Невнимательно читали! Такой вариант предлагался почти в самом начале. Как вариант, если абстрактные UC имеют архитектурную существенность.

И что, всё проектирование должно вестись прямо на этой диаграмме?

Уважаемый, greesha, где вы на моем примере диаграммы ВИ (извините что в тексте, картинку пока не нарисовал) увидели "проектирование"? Что вы вкладываете в этот термин?

На данном этапе я пытаюсь ответить на первоначальный вопрос автора какая из диаграмм правильная.
Есть бизнес-процесс продажи билета через автомат: от "инициирования покупателем функции покупки билета" до "выдачи билета (и сдачи) или возврата денег (при отказе)".
Первая "не правильна" потому что не описаны функции автомата и не отвечает на вопрос что делает автомат взаимодействуя с пользователем, вторая тем что в данном представлении не отражает в комплексе целевого назначения автомата - "продать билет путем приемки оплаты и выдачи билета".
Основная задача первого этапа - сформулировать требования к проектируемому автомату.
Чтобы это сделать необходимо сначала обозначить какие функции будет выполнять автомат при взаимодействии с пользователем.
bas, считает, что следует отобразить только один ВИ (функцию или процесс) - "Приобрести проездной билет".
Я считаю что это бизнес ВИ, и он должен быть отображен с использованием соответствующих стереотипов.
При этом дополнительно имеет смысл добавить на такую бизнес ВИ актора Продавец и отобразить ВИ "Продать проездной билет".

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

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

Да!...

Конечно, граница между моделированием бизнеса и систем размыта!

Но что-то я в данном случае бизнеса не вижу.
Некоторые, например RUP, подразделяют BUC на основной бизнес, поддержку бизнеса и управление бизнесом. К какой категории, уважаемый, вы отнесете "Приобретение билета"?

Нормальный пользователь подходит к нормальной системе и выполняет свою цель. Где тут бизнес? Если покупатель BActor, то кто системный Actor?

Тогда любой UC является BUC?

Наверное, мы о разном UML-е речь ведем!

Но что-то я в данном случае бизнеса не вижу.
Некоторые, например RUP, подразделяют BUC на основной бизнес, поддержку бизнеса и управление бизнесом. К какой категории, уважаемый, вы отнесете "Приобретение билета"?
Нормальный пользователь подходит к нормальной системе и выполняет свою цель. Где тут бизнес? Если покупатель BActor, то кто системный Actor?
Тогда любой UC является BUC?
Наверное, мы о разном UML-е речь ведем!

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

Эти потребности заинтересованных сторон предложено реализовать через систему "автомат по продаже билетов".
Автор в одном из сообщений упомянул что точка зрения на диаграмму ВИ должна быть "Мне хочется как можно проще, и максимально понятно тому, кто будет разрабатывать систему."
Тому кто будет проектировать автомат не так важен бизнес ВИ. Ему нужно понимание какие функции и для кого выполняет система, какие в связи с этим есть ограничения и исключения.

Есть такая задача:
Необходимо сконструировать автомат для продажи билетов. Требования к системе просты. Этот автомат принимает монеты достоинством 1, 2, 3 и 5 руб. и выдает билеты стоимостью 5 руб.

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

Эдуард Геннадьевич, на мой взгляд, правильной из 2-х представленных диаграмм является 1-я, т.к. она отражает верхнеуровневую цель пользователя, которую он хочет достичь с помощью Системы (собственно говоря, цель в данной области действия одна). Как ранее говорил Александр Байкин, если применять теорию Коберна, она будет соответствовать уровню "воздушного змея".

2-я диаграмма не совсем корректна. Почему?
1. Она, в отличие от первой, находится на ином уровне абстракции.
2. Действующим лицом должен быть не пользователь, а сама Система.
3. Если 2-я диаграмма отображает поведение Системы, то незачем применять элемент диаграммы "Границы Системы" (прямоугольник).

А вообще, я бы 1-ю диаграмму декомпозировал на диаграмму деятельности, шагами которой были бы названия, приведённые во 2-й диаграмме. Почему я бы так сделал? В диаграмме 2 явно прослеживается бизнес-процесс.

Смотрю, что в теме уже были такие предложения. Соглашусь с ними.

Основная задача первого этапа - сформулировать требования к проектируемому автомату.

А на каком этапе тогда мы определяем границы системы - будет она билеты продавать или ботинки чистить?

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

Уважаемый bas, Вы не могли бы раскрыть что вы вкладываете в термин "Пользовательский ВИ", в чем по вашему выражено наше непонимание сути диаграммы ВИ.

Мда, смешались в кучу кони RUP, люди Коберн... В общем, если смотреть с т.з. РУПа, то я рассматриваю (надесь, и все) этот пример, как модель Системных ВИ. В понятие МОДЕЛЬ ВИ я включаю:

Use Case Model, which consists of:
    * Use case diagram: A visual representation of system users (actors) and the services they request from the system.
    * Actor definitions: A textual description of the requestors of services provided by your system, and services provided to your system.
    * Use case descriptions: Textual descriptions of the major services provided by the system under discussion.

http://www.ibm.com/developerworks/rational/library/5383.html

Можно еще тут почитать:
http://rup.hops-fp6.org/process/modguide/md_ucmod.htm

У Пассажира нет цели засунуть деньги я с вами согласен, но ведь у "Автомата" (утрирую, конечно у его владельца) - есть бизнес-цель - "получить деньги взамен билета". Данная цель неявна и не отражена на представленных автором диаграммах.

Где Вы такого актера нашли на исходной Д: владелец?

Ранее я предложил свой вариант диаграммы ВИ демонстрирующую точку зрения на проектируемую систему Автомат http://www.uml2.ru/forum/index.php?topic=3729.msg27642#msg27642

1. Нарисуйте, будет понятнее
2. Еще раз повторюсь, что данный простой пример не показательный, можно хоть до функций детализировать... Но при проектировании БОЛЬШОЙ системы, данные ВИ включения и расширения на Д лишние.

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

Эти потребности заинтересованных сторон предложено реализовать через систему "автомат по продаже билетов".
Автор в одном из сообщений упомянул что точка зрения на диаграмму ВИ должна быть "Мне хочется как можно проще, и максимально понятно тому, кто будет разрабатывать систему."
Тому кто будет проектировать автомат не так важен бизнес ВИ. Ему нужно понимание какие функции и для кого выполняет система, какие в связи с этим есть ограничения и исключения.

Совершенно точно, что у Вас разные представления как с теоретиками бизнеса, так и с RUP, что такое бизнес (и бизнес процесс).
Но если Вы можете точно сформулировать, что Вы под этим понимаете, это делает Вам честь!
Только другие могут Вас не понять!

Какая жаркая дискуссия! Но, надеюсь, полезная. По крайней мере, выделяются две точки зрения, вокруг которых и идет спор.

Кроме того, мы видим разногласия по поводу определения бизнес. Я бы предложил уйти от него вообще. Будем говорить о предметном взгляде и системном.

Когда я начинал тему, у меня не то, что было сомнение (1 диаграмма получилась у меня инстинктивно, исходя из массы тех знаний, что успели накопиться в голове), просто я подумал (и мысль впоследствии подтвердилась) а как смотрит на это тот, кто делает, реализует дальше. Полезна ли ему эта диаграмма?

Пока я вижу ответ - сама по себе бесполезна. Описание или диаграмма деятельности скорее всего будет нести больше информации. Но... это только в этом конкретном случае.

Кроме того, если совокупность ВИ должна определить назначение системы, то может ВИ следует сформулировать как: "Выдать проездной билет за внесенную оплату" , а не  "Приобрести проездной билет"?


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

Диаграмма UC не бесполезная. Она является неотъемлемой частью UCM, и предназначена только для того, чтобы указать и структурировать цели пользователей (actor), которые должна выполнять система.
Краткое описание UC - это требование к системе выполнить цель. Когда UC много - это функциональные требования верхнего уровня.
Описание последовательности взаимодействий - набор детализирующих требований к системе в терминах обязанности системы уметь реализовать эти взаимодействия.

Нужно и полезно все!!!

Коберн диаграмм не рисует вообще, но суть та же (за исключением расширения на пять уровней и черный (объектный подход) и прозрачный ящик)

1. Нарисуйте, будет понятнее

А вот "конкуренты" похожую тему обсуждают http://forum.uml3.ru/viewtopic.php?f=18&t=51

А вот "конкуренты" похожую тему обсуждают http://forum.uml3.ru/viewtopic.php?f=18&t=51

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

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

Ну и второе: это тот случай, когда авторам не хватило нотаций UML, и они ввели собственный (не UML) стереотип (или ключевое слово, не знаю, они изображаются одинаково). Это допустимо в рамках группы разработчиков, но посторонние не поймут.

Это как раз то, о чем пишет Коберн, обосновывая (на мой взгляд, ошибочно) бесполезность диаграмм UC. И приводит похожие примеры.

А вот "конкуренты" похожую тему обсуждают http://forum.uml3.ru/viewtopic.php?f=18&t=51

Почему же конкуренты - это наши друзья )

Ваша диаграмма тоже имеет право на жизнь в данном конкретном небольшом примере.

ИМХО дальше не имеет смысла обсуждать, поэтому откланиваюсь ...