Здравствуйте, уважаемые специалисты!

Строю use case модель для интернет-магазина, и у меня получается все очень запутанно.
Дело в том, что на каждом шаге можно вызвать ряд use case-ов и если все эти вызовы показывать, то диаграмма будет чрезмерно перегруженной.

Например, есть 3 use case-а:
1.   Просмотреть содержимое раздела каталога
2.   Выполнить поиск интересующих товаров в каталоге по заданным критериям
3.   Просмотреть детальную информацию по интересующему товару
При этом, данные use case-ы могут быть вызваны так (показано схематично, поэтому не судите строго):



Чтобы избежать перегруженности, я «рисую» use case-диаграмму следующим образом:



При этом, use case «Просмотреть каталог товаров» я не «разрисовываю» в виде диаграммы активности, т.к. получается что-то вроде 1-го рисунка.
Но use case-ы следующего уровня детализации («Просмотреть товары в разделе каталога», «Найти товары в каталоге по заданным критериям» и т.д.) я «разрисовываю» в виде диаграммы активности следующим образом:





и т.д.

Вопрос:
Верный ли у меня подход к описанию 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их.

Вариант использования — это текст. Если у вас нет контекста модели, как мы можем помочь вам в прояснении правильности текущей модели?