Use Case vs. Use Cases - какая должна быть степень детализации?(Прочитано 111847 раз)
Есть такая задача:
Необходимо сконструировать автомат для продажи билетов. Требования к системе просты. Этот автомат принимает монеты достоинством 1, 2, 3 и 5 руб. и выдает билеты стоимостью 5 руб.

При зрелом рассуждении родились две диаграммы использования. Вопрос знатокам, умницам и умникам, какая из диаграмм правильная? Может правильные обе? Почему?
« Последнее редактирование: 14 Апреля 2011, 01:06:04 от bas »



Re: Use Cases vs. Use Cases Ответ #1 : 13 Апреля 2011, 18:13:54
Это для какой категории читателей тест?
« Последнее редактирование: 13 Апреля 2011, 18:15:44 от lnew »
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



Re: Use Cases vs. Use Cases Ответ #2 : 13 Апреля 2011, 18:45:23
Это для какой категории читателей тест?
Это не тест, это абсолютно взрослый вопрос



Re: Use Cases vs. Use Cases Ответ #3 : 13 Апреля 2011, 19:48:45
Use cases во второй диаграмме не подпадают под определение (пользователь хочет купить билет, а не копейка свои отдать!).

Если хочется подробнее, и процессы (и последующие решения по ним) из второй диаграммы предполагается иметь как авуары многоразового использования, их можно поместить на первую диаграмму с отношениями <<include>> от основного.
« Последнее редактирование: 13 Апреля 2011, 19:50:41 от lnew »
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



Re: Use Cases vs. Use Cases Ответ #4 : 13 Апреля 2011, 22:50:59
А можно прокомпостировать билет и не поехать напихать в автомат монет и уйти, не покупая билета?

Или получить сдачу, не напихав предварительно монет?

Или купить билет без денег?

Если можно, то я за вторую диаграмму. :) Если нет - за первую.
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Re: Use Cases vs. Use Cases Ответ #5 : 13 Апреля 2011, 23:17:32
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 диаграммой системных ВИ?



Re: Use Cases vs. Use Cases Ответ #6 : 13 Апреля 2011, 23:29:43
С другой стороны, не следует ли считать 1 диаграмму диаграммой бизнес ВИ, а 2 диаграммой системных ВИ?

Для меня диаграмма ВИ - это один из первых шагов анализа. Да, наверное, это можно назвать диаграммой бизнес-ВИ, хотя у меня приставка "бизнес" до сих пор вызывает внутренний протест (я всё пытаюсь представить, как будет выглядеть эта формулировка в ТЗ на какую-нибудь военную систему).

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

Вторая диграмма ошибочна в любом случае, потому что Пассажиру все эти кнопки не нужны. Если даже яйца представляют "системные ВИ", мужики должны быть другими.
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Re: Use Cases vs. Use Cases Ответ #7 : 14 Апреля 2011, 00:31:59
Я человек простой. Автор дал определение. Это аксиома. Спорить с этим определением не смысла. Придумай свой термин и дай ему определение и используй, как хочешь!

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

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

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

И конечно же первая диаграмма, даже расширенная предлагаемым способом, не описывает бизнес процесс (принятый синоним BUC).
Бизнес пассажиру не билет предлагает, а услугу по перевозке.
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



Re: Use Cases vs. Use Cases Ответ #8 : 14 Апреля 2011, 01:05:28
ИМХО вторая Д - это детализация первой, и ВИ 2ой Д совсем низкого уровня (если по Коберну). А ВИ "доехать до т. В" - это ВИ уровня облака.
При данном маленьком примере обе Д имеют право на жизнь (если только во 2ом случае называть ВИ от действий пользователя, н-р, "Получить сдачу"), но если разрабатывается большая Система, то второй вариант не приемлем - Д будет в этом случае только мешать.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



У меня вопрос.
Хорошо. Пассажир хочет купить билет и ему систему нужна - нарисовали. Но вот работникам автовокзала (пусть там стоит данный автомат) хочется уменьшить время выдачи билета пассажиру. И по-моему это тоже эффект от использования системы. Надо это показывать или нет? Если надо то как?



Вопрос действительно интересный! Пошел за попкорном :о)))

2 Денис Иванов: IMHO а работник автовокзала (и почему, кстати, "авто-"?)  - actor? Он ведь не использует эти UC, разве что в целях тестирования какого-нибудь.
И потом зачем ему уменьшать время выдачи билета? Можно ведь поставить несколько автоматов (как впрочем и было раньше).
Целесообразнее сократить время обслуживания и увеличить интервалы между обслуживаниями (ну там рулон бумаги для билетов потолще, монетоприемник поглубже и популенепробиваемей, корпус повандалоустойчивее, электричество поменьшеупотреблениестей).

P.S. кстати, вопрос: автомат выдает только один вид билетов? может стоит добавить выбор билета хотя бы по пункту назначения?
Лью воду...



А вставление карты в картопринмник банкомата - это Use Case? Система выполняет обработку. И кому-то это надо!
А заполнение поля идентификатора пользователя в форме ввода - это Use Case? Система выполняет обработку. И кому-то это надо!

Абсурд!

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

Те, кто знаком с RUP (в разработке начальных версий которого участвовали те же авторы) знают, что Use Case - это элемент планирования результатов итераций, каждая из которых, по RUP, предусматривает выпуск системы (внутренней или внешней версии). Один из признаков прецедента, в таком случае: при пошаговой поставке можно выпустить продукт, выполняющий единственный Use Case!

Ну, и нужно различать Use Case от UML и от Коберна. У них разные определения. Но, с некоторыми натяжками, сопоставлять уровни UML и Коберна можно.
Я себе представляю примерно так:

   UML                        Коберн
 Capability UPIA         Облако
 BUC                        Змей
 Основной UC           Море
 Абстрактный UC       Рыба
 нет (Операция?)      Рак
И не надо забывать, что эти уровни имеют своих субъектов:
- если первая диаграмма - бизнес, то субъект - клиент бизнеса, а не пользователь системы! Кто нибудь слышал, чтобы целью бизнеса было приобретение билета? Если только для перепродажи (раньше это называлось "спекуляция", теперь - "посредничество").
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



Относительно степени детализации.

RUP (и "три амигос") рекомендует сначала определять субъектов, а уже потом - use cases.
Если Вы определили и согласовали субъектов, то дальше для определения степени детализации можно спокойно использовать определение. Никаких если уже не будет!

Ну и еще одна идея из RUP, которую я часто использую, если есть несколько уровней моделирования, например, "предприятие", "бизнес", "системы".

Каждый следующий уровень детализирует (и реализует) предыдущий:

- возможности предприятия (capability) -> функциональные области бизнеса -> системы
- операционные задачи -> BUC (бизнес-процессы) -> функциональные области систем
                                     действия диаграммы деятельности -> системные UC
                                                                                          действия диаграммы деятельности -> абстрактные UC (если существенные!)

Не надо на меня ругаться. Это схема размышлений, а не обязательное правило!!!
Но полезно!
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



Друзья, спасибо за интерес к теме и за ваши комментарии и предложения.

Я вижу, что польза от таких дускуссия есть, хотя бы образовательная. И очень хорошо их начинать именно так, как я сделал - с рисунка и общего контекста.

to lnew, вы пишите
Цитировать
Автор дал определение. Это аксиома. Спорить с этим определением не смысла. Придумай свой термин и дай ему определение и используй, как хочешь!
какой автор? какое определение?

Цитировать
Авторы идеи дали очень продуктивное определение, ключевыми элементами которого являются существенность, реализация цели первичного субъекта, видимый результат, имеющий ценность для субъекта.
Какие авторы? какое определение?
"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"
видимый (а что есть видимый?) результат, имеющий НЕКОТОРОЕ значение (ценность) для

разве возврат денег - не НЕКОТОРАЯ ценность для пассажира? (соглашусь по поводу выдачи билета и получения сдачи, хотя, а если получать несколько билетов, а если будет процедура как в банкомате - ожидание следующей операции??)

Цитировать
У меня вопрос.
Хорошо. Пассажир хочет купить билет и ему систему нужна - нарисовали. Но вот работникам автовокзала (пусть там стоит данный автомат) хочется уменьшить время выдачи билета пассажиру. И по-моему это тоже эффект от использования системы. Надо это показывать или нет? Если надо то как?
То есть ты полагаешь, что диаграмма использования должна отражать все эффекты использования системы?



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




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19