Хочу поднять теоритическую тему "что есть use case".

Кратко представлюсь: занимаюсь внедрением АС на платформе 1С:Предприятие 8. UML использую для описания БП и моделирования.

USE CASE диаграммы я использую следующим образом:
1. составляю описание БП с помощью UML по известному методическому пособию.
2. от БП переходим к ВИ. ВИ я использовал для описания "цепочек документов". Т.е. ВИ, описывающий именно вариант в котором система может использоваться. ВИ в моем случае практически готовый тест-кейс.

Примеры диаграмм я привел.

Хотелось бы услышать мнение сообщества о правильности такого примения ВИ с точки зрения RUP. Правильно ли я понимаю суть ВИ?

Про что такое use case на форуме не мало было тем - поищите - use case, вариант использования.
К тому же книг не мало.

Диаграммы в общем случае могут быть любые. Важен контекст и уровень. Если Вы таким образом хотите описать системные варианты использования, то как мне кажется не выполняются некоторые условия элементарности.
Та же продажа с предоплатой предполагает целый набор функциональности. Т.е. сама продажа - конечно бизнес-процесс, но все-таки не ВИ в классическом смысле - т.е. цель пользователя.

Исходя из описания процесса я вижу как минимум трех пользователей - участников процесса: кассир, кладовщик и менеджер.

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

Возможно это будет нечто вроде Подготовить коммерческое предложение - т.е. некоторое относительно атомарное (элементарное) действие, нечто что в течение рабочего дня менеджер делает многократно, начав и закончив. - Вариант Создать коммерческое предложение, Разместить коммерческое предложение....

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

Кладовщик Оформить отгрузку товара (результатом которой будет документ ТОРГ-12, и некоторые изменения в БД)

USE CASE диаграммы я использую следующим образом:
1. составляю описание БП с помощью UML по известному методическому пособию.
2. от БП переходим к ВИ. ВИ я использовал для описания "цепочек документов". Т.е. ВИ, описывающий именно вариант в котором система может использоваться. ВИ в моем случае практически готовый тест-кейс.

Примеры диаграмм я привел.

1. Если в примерах из первой диаграммы получается вторая, то не могли бы объяснить каким образом?
2. А какая смысловая нагрузка второй диаграммы? Кстати, если её привести к удобочитаемому виду, то вообще непонятно зачем она.
3. ВИ - это то, что предоставляет проектируемая/моделируемая система пользователю по его запросу, это то, что делает система.
Ссылка на ВИ в разделе FAQ: http://www.uml2.ru/index.php?option=com_content&task=category&sectionid=3&id=31&Itemid=47
Может в Вашем случает ВИ не нужны вовсе? Не получается ли забивание гвоздей микроскопом?

ИМХО.

Про что такое use case на форуме не мало было тем - поищите - use case, вариант использования.
К тому же книг не мало.

Диаграммы в общем случае могут быть любые. Важен контекст и уровень. Если Вы таким образом хотите описать системные варианты использования, то как мне кажется не выполняются некоторые условия элементарности.
Та же продажа с предоплатой предполагает целый набор функциональности. Т.е. сама продажа - конечно бизнес-процесс, но все-таки не ВИ в классическом смысле - т.е. цель пользователя.

Исходя из описания процесса я вижу как минимум трех пользователей - участников процесса: кассир, кладовщик и менеджер.

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

Возможно это будет нечто вроде Подготовить коммерческое предложение - т.е. некоторое относительно атомарное (элементарное) действие, нечто что в течение рабочего дня менеджер делает многократно, начав и закончив. - Вариант Создать коммерческое предложение, Разместить коммерческое предложение....

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

Кладовщик Оформить отгрузку товара (результатом которой будет документ ТОРГ-12, и некоторые изменения в БД)

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

1. Если в примерах из первой диаграммы получается вторая, то не могли бы объяснить каким образом?
2. А какая смысловая нагрузка второй диаграммы? Кстати, если её привести к удобочитаемому виду, то вообще непонятно зачем она.
3. ВИ - это то, что предоставляет проектируемая/моделируемая система пользователю по его запросу, это то, что делает система.
Ссылка на ВИ в разделе FAQ: http://www.uml2.ru/index.php?option=com_content&task=category&sectionid=3&id=31&Itemid=47
Может в Вашем случает ВИ не нужны вовсе? Не получается ли забивание гвоздей микроскопом?

ИМХО.

1. По сути вторая диаграмма - это различные варианты БП "Продажа". Т.е. варианты БП в которых может быть использована программа.
2. В данном упрощенном примере возможно не так очевидна ее польза. Но когда таких "цепочек" около 8 и возможны различные комбинации - то такая диаграмма просто незаменима. Например: "Отражение продажи услуг российского поставщика", "Отражение продажи услуг зарубежного поставщика", "Отражение продажи услуг с отложенной оплатой агентом" и т.д. (речь о туристическом бизнесе). Каждый из таки сценариев продажи сильно отличался от других (но и конечно имел общие моменты).
3. Совершенно верно. ВИ - то что предоставляет система. В моем случае она предоставляет возможность отражать хозяйственные операции по продаже товаров с предоплатой или без предоплаты.

Если взять определение из FAQ

Вариант Использования (ВИ, прецедент или Use Case) - это последовательность некоторых событий, показывающих как Система должна взаимодействовать с Пользователями (называющимися актером или actor) для достижения какой-то цели. Различают два вида ВИ – это бизнес ВИ (БВИ) и системный ВИ (СВИ).

То диаграмма прецедентов посути показывает взаимосвязи сценариев работы программы. Или взаимосвязь последовательностей действий. Не вижу концептуального противоречия с той диаграммой, которую привел я. Не факт, что их нет - если бы не сомневался, то не стал бы поднимать ветку

Я немного расширил пример. Возможно так более понятна будет технология работ.

В идеале я себе представляю так:
1. На диаграммах БП мы изображаем как в компании выполняются те или иные процессы;
2. На диаграммах ВИ как эти процессы поддерживаются системой.

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

ну это как Вам нравится, Сергей. Только тогда не называйте это вариантом использования системы. Раз Вы интересуетесь сутью, то суть в том, что ВИ  есть цель пользователя, но не совокупности пользователей.

Продать товар с предоплатой - чья в данном случае цель? Менеджера ? Кассира? Кладовщика?

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

Может ли некий одиночный пользователь продать товар с предоплатой? Очевидно, нет. Поскольку в процессе задействованы различные персоны, которые осуществляют свои действия асинхронно в разное время. Очевидно же, что пока не будет коммерческого предложения, пока не будет осуществлена предоплата и т.п. процесс не будет завершен. Он может быть растянут во времени, он связан и с поведением некой внешней сущности, которая  у Вас вообще осталась за кадром (та сущность котоая вносит предоплату и доплату тоже)

Это тянет на бизнес-вариант использования, но в этом случае все действующие лица, которые у Вас обозначены - это business workers - т.е. исполнители процесса, сидят внутри процесса, но не снаружи. А весь БВИ описан как прозрачный ящик, в то время как СВИ пишется как черный ящик: действия пользователя и реплика системы.

Потому возможно не следует называть это ВИ.

Продать товар с предоплатой - чья в данном случае цель? Менеджера ? Кассира? Кладовщика?

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

Может ли некий одиночный пользователь продать товар с предоплатой? Очевидно, нет. Поскольку в процессе задействованы различные персоны, которые осуществляют свои действия асинхронно в разное время. Очевидно же, что пока не будет коммерческого предложения, пока не будет осуществлена предоплата и т.п. процесс не будет завершен. Он может быть растянут во времени, он связан и с поведением некой внешней сущности, которая  у Вас вообще осталась за кадром (та сущность котоая вносит предоплату и доплату тоже)

В определении ВИ явным образом сказано про "Пользователей". В определенном смысле Вы правы, когда говорите про неконкретность постановки цели в моем случае, но это лишь вопрос игры слов. Если перефразировать в "Отражение хозяйственных операций при продаже товаров с предоплатой" - то это явным образом цель группы пользователей. Замечу, что актором может быть и система - в таком случае наличие двух акторов в одном ВИ практически неизбежно. Например, пользователь инициирует выгрузку данных, а АС выгружает данные во вторую систему.

В определении ВИ явным образом сказано про "Пользователей". В определенном смысле Вы правы, когда говорите про неконкретность постановки цели в моем случае, но это лишь вопрос игры слов. Если перефразировать в "Отражение хозяйственных операций при продаже товаров с предоплатой" - то это явным образом цель группы пользователей. Замечу, что актором может быть и система - в таком случае наличие двух акторов в одном ВИ практически неизбежно. Например, пользователь инициирует выгрузку данных, а АС выгружает данные во вторую систему.

Сергей, мне вовсе не хочется вести с Вами спарринг. Я вовсе не хочу навязать Вам свою точку зрения. Вы обратились на форум с вопросом в чем собственно суть use case. На мой взгляд, возможно кто-то меня тоже поддержит, Вы не правильно понимаете суть вариантов использования.

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

Группа пользователей <> внешняя система. А приведенный Вами пример вовсе не подтверждает Вашу логику.

Вариант использования - это сборник сценариев, главным образом описанных текстом, может быть отражен в виде диаграмм видов деятельности и диаграмм последовательности.

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

Сергей, мне вовсе не хочется вести с Вами спарринг. Я вовсе не хочу навязать Вам свою точку зрения. Вы обратились на форум с вопросом в чем собственно суть use case. На мой взгляд, возможно кто-то меня тоже поддержит, Вы не правильно понимаете суть вариантов использования.

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

Группа пользователей <> внешняя система. А приведенный Вами пример вовсе не подтверждает Вашу логику.

Вариант использования - это сборник сценариев, главным образом описанных текстом, может быть отражен в виде диаграмм видов деятельности и диаграмм последовательности.

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

Я не пытаюсь настоять на своей точке зрения, т.к. являюсь топик стартером. Я излагаю свою точку зрения, что бы получилась дискуссия, в ходе которой я возможно лучше пойму суть use case диаграмм. Пока я не понял, почему то, что я делаю нельзя называть ВИ. С теоритической точки зрения я ознакомился с работами Коберна, прошел курсы по UML на Intuit. Остались вопросы практического применения.

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

Например на http://www.intuit.ru/department/se/intuml/2/ дано следующее определение use case диаграмм от Буча:

Прецедент (use-case) - описание отдельного аспекта поведения системы с точки зрения пользователя (Буч).

И приведены примеры, которые лежат в том же уровне, что и процесс продажи. Например, обратите внимание на Рис 2.4.

Zicom Mentor Actor-а определяет так:
Эктор (actor) - это множество логически связанных ролей, исполняемых при взаимодействии с прецедентами или сущностями (система, подсистема или класс). Эктором может быть человек или другая система, подсистема или класс, которые представляют нечто вне сущности.

Участники процесса "продажа" при выполнении "сценария взаимодействия с системой" "продажа с предоплатой" как раз подходят под это определение. Разве нет?

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

1. Менеджер вводит КП
2. Система регистрирует КП в журнале КП
3. Менеджер печатает КП
4. Система формирует печатную форму ххх
5. Кассир отражает прием предоплаты
6. Кладовщик регистрирует отгрузку товаров со склада
7. Система уменьшает количество  товаров на складе, снимает резервы по КП (глупость конечно по КП товар резервировать, но для упрощения считаем что резервы именно КП образованы)
8. Кладовщик печатет ТОРГ 12
9. Система формирует на основании данных документа печатную форму ххх
10. Кассир принимает осташиеся денежные средства от клиента.

Цель достигнута - все хозяйственные операции по продаже товаров зафиксированы.

1. По сути вторая диаграмма - это различные варианты БП "Продажа". Т.е. варианты БП в которых может быть использована программа.

Различные варианты БП и ДВИ - это разные вещи, я не понимаю зачем и как их можно смешивать?

2. В данном упрощенном примере возможно не так очевидна ее польза. Но когда таких "цепочек" около 8 и возможны различные комбинации - то такая диаграмма просто незаменима. Например: "Отражение продажи услуг российского поставщика", "Отражение продажи услуг зарубежного поставщика", "Отражение продажи услуг с отложенной оплатой агентом" и т.д. (речь о туристическом бизнесе). Каждый из таки сценариев продажи сильно отличался от других (но и конечно имел общие моменты).

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

3. Совершенно верно. ВИ - то что предоставляет система. В моем случае она предоставляет возможность отражать хозяйственные операции по продаже товаров с предоплатой или без предоплаты.

Не вижу. У Вас на ДВИ "продажа с/без предоплаты", где же ВИ "отражать хозоперации"?

Различные варианты БП и ДВИ - это разные вещи, я не понимаю зачем и как их можно смешивать?
Ну хорошо, пускай графическое изображение Ваших цепочек сильно упрощает жизнь, но что заставляет использовать именно ДВИ? В конце концов, можно красиво и понятно всё это нарисовать в Visio, зачем использовать конкретную нотацию и пытаться скоррелировать её семантику и свои нужды?
 Не вижу. У Вас на ДВИ "продажа с/без предоплаты", где же ВИ "отражать хозоперации"?

1. Не совсем понимаю, почему разные? под вариантами БП "Продажа" - я подразумевал варианты отражения хоз.операций по продаже в системе
2. Потому что считаю, что это в чистом виде ВИ
3. Я написал чуть выше, что это игра слов. Если перефразировать в "Отражение хозяйственных операций при продаже товаров с предоплатой" - то это явным образом цель группы пользователей. Суть сценария от названия по-моему не изменяется.

1. Не совсем понимаю, почему разные? под вариантами БП "Продажа" - я подразумевал варианты отражения хоз.операций по продаже в системе

Ну хотябы потому, что это БП и ВИ - по определению разные понятия. А "варианты отражения хоз.операций по продаже в системе" - это не есть ВИ. Мне кажется, мы не понимаем друг друга... или я Вас. Вот "отразить хоз. операции" - это будет ВИ для данной системы.

2. Потому что считаю, что это в чистом виде ВИ

ок =)

3. Я написал чуть выше, что это игра слов. Если перефразировать в "Отражение хозяйственных операций при продаже товаров с предоплатой" - то это явным образом цель группы пользователей. Суть сценария от названия по-моему не изменяется.

Изменяетя понимание диаграммы. Можно конечно рисовать одно, понимать под этим совсем другое. Но зачем?

1. Менеджер вводит КП
2. Система регистрирует КП в журнале КП
3. Менеджер печатает КП
4. Система формирует печатную форму ххх
5. Кассир отражает прием предоплаты
6. Кладовщик регистрирует отгрузку товаров со склада
7. Система уменьшает количество  товаров на складе, снимает резервы по КП (глупость конечно по КП товар резервировать, но для упрощения считаем что резервы именно КП образованы)
8. Кладовщик печатет ТОРГ 12
9. Система формирует на основании данных документа печатную форму ххх
10. Кассир принимает осташиеся денежные средства от клиента.

Цель достигнута - все хозяйственные операции по продаже товаров зафиксированы.

Вы описали бизнес вариант использования. Но не указана точка зрения, т.е. основное действующее лицо, которое цель достигает. В интересах кого Вы описываете данный ВИ?

Менеджер, Кассир, Кладовщик , Система - это исполнители процесса продажи, они внутри некой общей системы - назовем ее склад оптовой продажи

Zicom Mentor Actor-а определяет так:
Эктор (actor) - это множество логически связанных ролей, исполняемых при взаимодействии с прецедентами или сущностями (система, подсистема или класс). Эктором может быть человек или другая система, подсистема или класс, которые представляют нечто вне сущности.

Но эктор - это все-таки одна роль, у Вас же их несколько Менеджер Кассир Кладовщик - какова логика объединения их и каково название этого эктора

Хочу поднять теоритическую тему "что есть use case".

Кратко представлюсь: занимаюсь внедрением АС на платформе 1С:Предприятие 8. UML использую для описания БП и моделирования.

USE CASE диаграммы я использую следующим образом:
1. составляю описание БП с помощью UML по известному методическому пособию.
2. от БП переходим к ВИ. ВИ я использовал для описания "цепочек документов". Т.е. ВИ, описывающий именно вариант в котором система может использоваться. ВИ в моем случае практически готовый тест-кейс.

Примеры диаграмм я привел.

Хотелось бы услышать мнение сообщества о правильности такого примения ВИ с точки зрения RUP. Правильно ли я понимаю суть ВИ?

1. Я бы не стал описывать activity диаграмму в таком виде, как это сделано у вас (видимо по пособию Золотухиной). Т.к. семантика activity диаграмм позволяет использовать те же swimlane более эффективно, показывая в них подразделения организации или тех же экторов. Кроме этого можно со спокойной совестью использовать object flows в activity диаграммах, и не заниматься самодеятельностью с "Выходной информацией" в отдельном swimlane. У object flow есть даже одно преимущество - в них после определенной activity можно указать в каком состоянии находится наш объект (или бизнес-сущность).
2. Очень рекомендую начинать использование юзкейсов не как диаграмм, а именно как текстовых описаний. Причем читать не столько Буча по этой теме (все-таки Буч больше программер, нежели аналитик) а либо Якобсона, а еще лучше - Коберна.
3. У вас не верно, со всех точек зрения именованы юзкейсы ... они у вас отражают некую функцию, а не цель пользователя по отношению к системе. А юзкейсы как известно не есть функции системы. Кроме этого - не понятно кто есть primary actor у ваших юзкейсов. Из диаграммы это никак не следует. Если вы хотите сказать, что данный юзкейс это цель пользователя для обеих экторов, то семантически более правильно ввести абстрактного эктора, объединяющего Кассира и Менеджера, и к нему уже пристыковывать юзкейс.
4. Отвечая на ваш вопрос относительно правильности с т.з. RUP - то RUP это процессный фреймворк, а не стандарт описания юзкейсов или UML диаграмм. Другой вопрос, что он дает некие общие рекомендации, как это делать, но не более того! Кроме этого, интерпретация RUP-а Золотухиной является ее авторской разработкой, отличающейся определенной, э-э ... своеобразностью что ли. Я бы не стал опираться только на ее интерпретацию.