Дааа, тема пошла интереснааааяя

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

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

Далее я предложу еще такую примитивную диаграммку.

Соглашусь с Леонидом, эта диаграмма ничего сейчас не дает, кроме перечня вариантов возможных монет. а это сейчас несущественно. Поэтому предлагаю перейти к его предложению по другим диаграммам. С последовательностью очевидно возникнет некоторая трудность, т.к. у нас еще не определены подэлементы автомата, и она (диаграмма) тоже может нам ничего не дать.

P.S. согласен с Коберном: определить процесс с помощью UC невозможно, хотя что описание UC очень на него похоже и может показаться, все это является одним и тем же.

Во первых, не все так плохо.

Спецификация каждого use case, полученная с помощью диаграммы деятельности или по Коберну (я генерю спецификации по своему шаблону из диаграмм, и они получается точь в точь, как описания Коберна) - это почти готовый тесткейс (добавить, что ввести и что ждать). Почти готовое руководство пользователя.
Когда в диаграмме описываются взаимодействия, они могут описываться в термина граничных классов анализа (boandory).

Диаграмму последовательности многие используют как раз для поиска необходимых модельных элементов. Есть такая замечательная книжка Лармана: Применение UML и шаблонов проектирования. И в RUPе, насколько я помню, эта технология используется.

Откуда брать классы? Придумывать? Не метод для проектировщика, и тем более для аналитика! Смотрим на диаграмму Эдуарда. Там в описании написано:
- Система выводит сообщение о необходимости оплаты
- Пользователь вводит в приемное устройство купюры достоинством ...
      На диаграмме создаем линию жизни приемного устройства. Это экземпляр граничного класса. Думаем, создаем класс. От пользователя рисуем сообщение (принятьДеньги()) к созданной ранее линии жизни устройства. В классе ручками или автоматом создаем операцию с тем же именем.
      Скорее всего, устройство приема будет идентифицировать дензнаки и считать. Соответственно нужны приватные операции идентифицироватьДензнак() и т.д.
      Для хранения суммы создаем атрибут.

И т.д. по диаграмме деятельности (или по описанию Коберна).
Необходимые классы, их атрибуты и операции "вытекают" из логики use case. Use Case - очень продуктивная идея!

При реализации следующего use case какие-то элементы уже есть. Может быть, к ним надо добавить атрибуты и операции, или использовать уже имеющиеся.

Конечно, это еще не окончательные классы. Разные языки, платформы, особенности технологии! Но такую систему можно сделать!

все-таки, думаю, не надо уподобляться Шерлоку Холмсу, ставящему в тупик своего коллегу Ватсона :о)))
лучше все же пояснять внимающему человечеству, откуда берется "приемное устройство" (и потом про купюры  разговора не шло :о))) и про сообщение о необходимости оплаты тоже).

Диаграмму последовательности многие используют как раз для поиска необходимых модельных элементов. Есть такая замечательная книжка Лармана: Применение UML и шаблонов проектирования.

Ага, так и делал. И книжка одна из самых полезных и тоже любимых в свое время.

Друзья, спасибо за продуктивную дискуссию. Думаю не стоит сила тратить на эту задачу. Всем она достаточно понятна, либо у многих свое оригинальное ее понимание. Цель дискуссии все-таки сводилась именно к диаграмме ВИ, и вопросу насколько она практична и полезна в дальнейшем.

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

Кстати, мне кажется, мы как -то игнорировали вопрос Дениса Иванова.

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

Считается, что аналитик, по крайней мере в общем случае, не должен ограничивать проектировщика. Черт его знает сейчас, какие устройства там будут. Но что деньги будет брать приемное устройство, понятно. М.б., это будет манетоприемник, может - щель в крышке. То же и про деньги. Если там написано "купюры", значит я не о том думал, когда писал. Самое нейтральное, наверное, "дензнаки".

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

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

А что такое эффекты? Тем более ВСЕ?

Диаграмм, обычно, рисуют много, каждая для иллюстрации чего-то:
- обзор главных use cases системы
- все use cases определенного ator-а
- контекст определенного use case

Для достаточно большой системы все use case на одной диаграмме никогда не рисуют.

Но
полный список всех use case должен охватывать цели обращения к системе всех actor-ов.

Вот чего не ожидал - так это ТАКОЙ дискуссии по очевидному ответу :-). Эд - если подходить к вопросу с прикладной точки зрения, то более правильно использовать первую диаграмму с одним юзкейсом. Если говорить о Коберне, то это юзкейс уровня "Цель пользователя" (User Goal).

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

Ага, еще юзкейс называют "прецедентом" :-). Переводить Actor как Субъект, это нужно иметь ну очень сильный философско-сисмтемноаналитический бекграунд :-). Мне больше нравится "Основное действующее лицо", хотя тоже "не фонтан", т.к. лицо ассоциируется с человеком ....

По actor = субъект можно обратиться в IBM.

А если по русски, то в старом словаре по системотехнике я нашел такой термин: актор (от англ. actor) - субъект взаимодействия в системе. Правда, это было очень давно, и с тех пор человеческая фантазия родила "актера" и т.д.
М.б. IBM-овские переводчики нашим словарем воспользовались?

Эд - если подходить к вопросу с прикладной точки зрения, то более правильно использовать первую диаграмму с одним юзкейсом.

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

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

Почему не отвечает? Система должна продать билет пассажиру. А не ботинки ему почистить, например.
(А такое требование тоже может возникнуть в процессе разработки - эти заказчики такие заказчики!)

А термин "концептуальная модель" требует раскрытия.

Почему не отвечает? Система должна продать билет пассажиру. А не ботинки ему почистить, например.
(А такое требование тоже может возникнуть в процессе разработки - эти заказчики такие заказчики!)

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

Насчет концептуальности диаграммы ВИ:
http://www.intuit.ru/department/pl/umlbasics/3/

"Диаграмма вариантов использования - это исходное концептуальное представление или концептуальная модель системы в процессе ее проектирования и разработки. Создание диаграммы вариантов использования имеет следующие цели:

 - Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы
 - Сформулировать общие требования к функциональному поведению проектируемой системы
 - Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей
 - Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями

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

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

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

А в от длинной цитаты про концептуальную модель я оставлю только последнюю фразу:

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

Из данного UC "Приобрести проездной билет" - не следует что автомат должен: принимать оплату (монетами), возвращать оплату, выдавать билет, выдавать сдачу.

Боюсь быть неправильно понятым, поэтому добавляю ещё один пост.

Если вам удобнее отразить все эти особенности на ДВИ - отражайте на здоровье.

Любая диаграмма - это инструмент а) анализа и б) обмена информацией. Если она эффективно решает эти задачи, то это хорошая, годная диаграмма.

Диаграмма 2 на исходном рисунке мне не нравится именно потому, что она может быть неправильно понята. Если на неё посмотрит разработчик (или проектировщик интерфейса автомата), то на выходе вы можете получить 4 кнопки на автомате: "Принять монету", "Выдать билет", "Выдать сдачу", "Вернуть деньги". Причём реализованные в железе.

Как инструмент анализа, она, наверное, может быть представлена в таком виде, но только как черновик. Включать её в концепцию или в документ с требованиями нельзя. Потому что если что-то может быть понято неправильно, оно будет понято именно так.

Модель (а не диаграмма) UC должна отвечать на большинство вопросов, поставленных DinamoYA.
(Эта модель не должна отвечать, как устроена система.)

Но диаграмма UC - это только часть модели.

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

Если вы хотите все это представить на одной диаграмме UC, Вам просто не хватит нотаций (два типа сущностей и до пяти типов отношений (вместе со стереотипами!))
Критике такого подхода Коберн посвятил почти половину своей книги.

Но мы уже начали "перепевать" тему по третьему разу. К сожалению, новые участники не читают дискуссию с начала.