Use Case vs. Use Cases - какая должна быть степень детализации?(Прочитано 70629 раз)
Соглашусь с Леонидом и Гришей.
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 имеют архитектурную существенность.
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



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

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

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

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

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



Да!...

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

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

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

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

Наверное, мы о разном UML-е речь ведем!
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



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

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



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

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

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

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

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

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



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

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

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

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



Уважаемый 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, что такое бизнес (и бизнес процесс).
Но если Вы можете точно сформулировать, что Вы под этим понимаете, это делает Вам честь!
Только другие могут Вас не понять!
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



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

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

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

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

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


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



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

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

Коберн диаграмм не рисует вообще, но суть та же (за исключением расширения на пять уровней и черный (объектный подход) и прозрачный ящик)
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



1. Нарисуйте, будет понятнее
А вот "конкуренты" похожую тему обсуждают http://forum.uml3.ru/viewtopic.php?f=18&t=51
« Последнее редактирование: 15 Апреля 2011, 17:24:03 от DinamoYA »



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


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

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

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

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



А вот "конкуренты" похожую тему обсуждают http://forum.uml3.ru/viewtopic.php?f=18&t=51
Почему же конкуренты - это наши друзья )

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

ИМХО дальше не имеет смысла обсуждать, поэтому откланиваюсь ...
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.




 

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