Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: Adis от 12 Мая 2009, 16:43:58
-
Здравствуйте, уважаемые специалисты!
Строю use case модель для интернет-магазина, и у меня получается все очень запутанно.
Дело в том, что на каждом шаге можно вызвать ряд use case-ов и если все эти вызовы показывать, то диаграмма будет чрезмерно перегруженной.
Например, есть 3 use case-а:
1. Просмотреть содержимое раздела каталога
2. Выполнить поиск интересующих товаров в каталоге по заданным критериям
3. Просмотреть детальную информацию по интересующему товару
При этом, данные use case-ы могут быть вызваны так (показано схематично, поэтому не судите строго):
(http://adis.fotoplenka.users.photofile.ru/photo/adis.fotoplenka/140402211/xlarge/151884567.jpg?)
Чтобы избежать перегруженности, я «рисую» use case-диаграмму следующим образом:
(http://adis.fotoplenka.users.photofile.ru/photo/adis.fotoplenka/140402211/xlarge/151884569.jpg?)
При этом, use case «Просмотреть каталог товаров» я не «разрисовываю» в виде диаграммы активности, т.к. получается что-то вроде 1-го рисунка.
Но use case-ы следующего уровня детализации («Просмотреть товары в разделе каталога», «Найти товары в каталоге по заданным критериям» и т.д.) я «разрисовываю» в виде диаграммы активности следующим образом:
(http://adis.fotoplenka.users.photofile.ru/photo/adis.fotoplenka/140402211/xlarge/151884570.jpg?)
(http://adis.fotoplenka.users.photofile.ru/photo/adis.fotoplenka/140402211/xlarge/151884566.jpg?)
и т.д.
Вопрос:
Верный ли у меня подход к описанию use case-модели для интернет-магазина?
Есть ли какие-нибудь шаблоны для подобного случая?
Поиск ничего не дал >:(
-
Роман. Подход неверный, хотя некое зерно разумное проглядывается.
Моделирование взаимодействие включает модели вариантов использования и модели взаимоедйствия. Однако первая диаграмма - это диаграмма состояний, а не диаграмма вариантов использования.
Что обозначают зависимости на второй диаграмме?
Ну и самое главное.
Варианты использования -это спецификация, которая пишется на структурированном (и не всегда но лучше) языке с использованием любого шаблона.
Для особо сложных вариантов использования возможно будет необходимость строить диаграммы деятельности.
Модель вариантов использования на 90% текст на 10% картинки
-
Роман. Подход неверный, хотя некое зерно разумное проглядывается.
А как тогда верно?
Однако первая диаграмма - это диаграмма состояний, а не диаграмма вариантов использования.
Да! Это диаграмма, которая нарисована мною "от балды" - ее я просил не судить строго. Это даже не диаграмма состояний!
Что обозначают зависимости на второй диаграмме?
Это что-то типа "расширений", т.е. из ВИ "Просмотреть каталог товаров" ВИ "Просмотреть товары в разделе каталога" может быть как вызван, так и не вызван. Например, Клиент (пользователь) может на главной странице кликнуть не какой-либо раздел, а, например, рекомендуемый товар.
Варианты использования -это спецификация, которая пишется на структурированном (и не всегда но лучше) языке с использованием любого шаблона.
Да, я буду описывать ВИ в виде шаблонов RUP. Но это будет потом, т.к. мне удобнее сначала "накидать" диаграммы activity для обсуждения, а потом только писать спецификации.
Модель вариантов использования на 90% текст на 10% картинки
Это точно
-
А как тогда верно?
UML- это язык, а не методология. Методология может быть разная - придуманная Вами, лучшая практика, что-то стандартное. Чему Вас учат то и будет возможно правильным. Если Вы не совсем знаете, что Вам делать, следует изучить ту или имную методологию и использовать ее.
Да! Это диаграмма, которая нарисована мною "от балды" - ее я просил не судить строго. Это даже не диаграмма состояний!
От балды рисовать ничего не нужно
Это что-то типа "расширений", т.е. из ВИ "Просмотреть каталог товаров" ВИ "Просмотреть товары в разделе каталога" может быть как вызван, так и не вызван. Например, Клиент (пользователь) может на главной странице кликнуть не какой-либо раздел, а, например, рекомендуемый товар.
Это плохой ответ аналитика, что-то типа. Все должно быть корректно, точно и не вызвать двусмысленностей.
Да, я буду описывать ВИ в виде шаблонов RUP. Но это будет потом, т.к. мне удобнее сначала "накидать" диаграммы activity для обсуждения, а потом только писать спецификации.
Это Ваше право, но имхо Вы ошибаетесь
-
Тогда конкретный вопрос:
- есть ли где-нибудь пример модели вариантов использования и модели взаимодействия для интернет-магазина?
-
Тогда конкретный вопрос:
- есть ли где-нибудь пример модели вариантов использования и модели взаимодействия для интернет-магазина?
Например
В книге Use Case Driven Object Modeling with UML: Theory and Practice by Doug Rosenberg and Matt Stephens
Мацяшек. Лешек, А. М36 Анализ требований и проектирование систем. Разработка информационных систем с использованием L'ML.: Пер. с англ. — М.: Издательский дом "Вильям* , 2002. - 481 С: нл. - Парал. тит. англ.
-
Кстати, ИМХО не плохой вариант рисовать ДВИ и отдельно как эти ВИ работают последовательно, что-то типа Д Состояний, но вместо состояний - ВИ.
Особенно должно быть полезно для БВИ.
Но если такой подход применять неправильно, то еще больше путаницы будет ...
-
Вы из этой книги:
Use Case Driven Object Modeling with UML: Theory and Practice by Doug Rosenberg and Matt Stephens
взяли материалы для темы "Пример использования объектного подхода. Интернет-магазин от Розенберга" (см. http://www.uml2.ru/forum/index.php?topic=681.0) ?
Что за use-case'ы "Где мои материалы?" или "Проверить" ??
Мне кажется, предложенное автором - понятнее.
-
Вы из этой книги:
взяли материалы для темы "Пример использования объектного подхода. Интернет-магазин от Розенберга" (см. http://www.uml2.ru/forum/index.php?topic=681.0) ?
А Вы что, своим глазам не верите?
Что за use-case'ы "Где мои материалы?" или "Проверить" ??
Мне кажется, предложенное автором - понятнее.
Понятнее что?
-
Galogen!
Вы пишите:
Подход неверный.
Но вы ж не обосновали, что конкретно неверно!
Я понимаю, что никто никому ничего на форуме не должен, но все же, может в 2-х словах скажете, что не нак?
-
Но вы ж не обосновали, что конкретно неверно!
А почему я должен обосновывать прописные истины? Я дал Вам примеры, у нас много разговоров было на форуме, есть FAQ. Существуют опять же книги, учебник, курсы (на том же intuit.ru)
Я понимаю, что никто никому ничего на форуме не должен, но все же, может в 2-х словах скажете, что не нак?
В 2-х словах звучит так - учите матчасть
-
Роман, а вы читали Коберна?
-
Я бы в случае интернет-магазина выделял бы юзкейсы по Коберну. Т.е. для начала бы подумал о целях пользователя - пользователь пришел на сайт .. каковы его цели? Думаю что самая главная для бизнеса интернет-магазина цель пользователя - это покупка товара. Что пользователь обычно делает для того чтобы положить товар в корзину? ... правильно, он его ищет. Ищет разными способами - через рубрикатор, через поисковый механизм (это кстати "вариации технололгий и данных").
Таким образом имеем один юзкейс уровня облака - "Купить товар". Последовательность действий примерно такова:
1. Поиск товара (результат - нашел или нет - две ветви сценария)
2. Заказ товара(ов)
3. Оплата заказа.
4. Обработка заказа (включая отгрузку - чистой воды бэкофис и черный ящик с т.з. покупателя)
5. Получение товара.
Далее, в реальности мы имеем разрыв по времени, м/у заказом и поставкой - это к вопросу о том, что юзкейс уровня моря будет для Покупателя "Заказать товар" и "Получить товар" (как мнимум накладную подписать должен Покупатель), и для клерка магазина "Обработать заказ".
Теперь юзкейс "Заказать товар" обрастает подробностями как то - пользователь должен для заказа быть залогиненым (тут же понимаем, что нужно заводить юзкейс уровня моря или subfuction (вопрос требует отдельного анализа, лень ;-)) для Пользователя "Получить учетную запись"), пользователь "в любой момент времени может воспользоваться поиском товара" - каким именно образом он будет искать - это вариации технологий и данных ... но можно сделать юзкейсы уровня subfunction, если это для нас важно.
Вот такие мысли ...
пользователь должен оплатить заказ - тут варианты оплаты есть - кредитка или при доставке (или еще какие-то ...)
-
Роман, а вы читали Коберна?
Конечно, читал! А в чем сомнения?
Я бы в случае интернет-магазина выделял бы юзкейсы по Коберну. Т.е. для начала бы подумал о целях пользователя - пользователь пришел на сайт .. каковы его цели? Думаю что самая главная для бизнеса интернет-магазина цель пользователя - это покупка товара. Что пользователь обычно делает для того чтобы положить товар в корзину? ... правильно, он его ищет. Ищет разными способами - через рубрикатор, через поисковый механизм (это кстати "вариации технололгий и данных").
Таким образом имеем один юзкейс уровня облака - "Купить товар". Последовательность действий примерно такова:
1. Поиск товара (результат - нашел или нет - две ветви сценария)
2. Заказ товара(ов)
3. Оплата заказа.
4. Обработка заказа (включая отгрузку - чистой воды бэкофис и черный ящик с т.з. покупателя)
5. Получение товара.
Далее, в реальности мы имеем разрыв по времени, м/у заказом и поставкой - это к вопросу о том, что юзкейс уровня моря будет для Покупателя "Заказать товар" и "Получить товар" (как мнимум накладную подписать должен Покупатель), и для клерка магазина "Обработать заказ".
Теперь юзкейс "Заказать товар" обрастает подробностями как то - пользователь должен для заказа быть залогиненым (тут же понимаем, что нужно заводить юзкейс уровня моря или subfuction (вопрос требует отдельного анализа, лень ;-)) для Пользователя "Получить учетную запись"), пользователь "в любой момент времени может воспользоваться поиском товара" - каким именно образом он будет искать - это вариации технологий и данных ... но можно сделать юзкейсы уровня subfunction, если это для нас важно.
Вот такие мысли ...
пользователь должен оплатить заказ - тут варианты оплаты есть - кредитка или при доставке (или еще какие-то ...)
Можно и так. Я, кстати, сначала так и стал делать.
-
Конечно, читал! А в чем сомнения?
Можно и так. Я, кстати, сначала так и стал делать.
Глава 5.1. Наибольший интерес представляет цель пользователя. Это та цель, которую пре следует основное действующее лицо, пытаясь добиться от системы выполнения определенной работы, либо пользователь, работающий с системой. Она соответствует «элементарному бизнес- процессу» в технолоrии бизнес-процессов.
Цель пользователя характеризуется вопросом: "Уйдет ли основное действующее лицо удовлетворенным, выполнив это?" Для служащеrо этот вопрос звучит так: "За висит ли ваша производительность труда от тоro, сколько вы сеrодня сделаете?"
Цель можно также пропустить через тест "перерыва на кофе": "Коrда это закончу, сделаю перерыв на кофе". В большинстве случаев цель пользователя проходит тест для одноrо клиента за один сеанс (2-20 мин).
Вообще цели "Совершить покупку на онлайновом аукционе" и "Войти в систему" не считаются целями пользователя. Онлайновые аукционы требуют несколько дней и поэтому не проходят односеансовый тест. Вход в систему 42 раза подряд не отвечает (как правило) должностным обязанностям индивидуума или цели использова ния системы. "Зареrистрировать новoro клиента" и "Купить книry" вполне Mоryт быть целями
пользователей. Задача реrистрации 42 новых клиентов не лишена смысла для агента по продажам. Покупку книrи можно совершить за один сеанс.
Где у вас цель пользователя? Почему вы сразу начинаете с целей уровня подфункции?
Серьезно отнеситесь к выявлению вариантов использования уровня моря. Они действительно важны. Напишите несколько предельных вариантов использования, чтобы обеспечить контекст для друrих.
Вариант использования — это текст. Если у вас нет контекста модели, как мы можем помочь вам в прояснении правильности текущей модели?
-
Где у вас цель пользователя? Почему вы сразу начинаете с целей уровня подфункции?
Замечание походу верное.
Я считаю, что целью пользователя для интернет-магазина является "Покупка товара", а вернее - "Заказ товара", т.к. покупка товара может включать и его доставку, а сам сайт его не доставит.
А UC-ы "Управлять корзиной", "Просмотреть каталог" или "Найти товар в каталоге" - цели уровня подфункций.
Наверно, так.