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

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

Заранее всем спасибо!

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

Прошу прощения, опубликовал изображение на закрытом сервере...
Вот собственно схема...

Судя по всему я её излишне детализировал? Если так, то можете дать рекомендацию, до какого уровня детализировать и как например показать, что данный ЮсКейс можно рассмотреть подробнее на другой диаграме (как декомпозиция в DFD например) ?

Спасибо!

Судя по всему я её излишне детализировал? Если так, то можете дать рекомендацию, до какого уровня детализировать и как например показать, что данный ЮсКейс можно рассмотреть подробнее на другой диаграме (как декомпозиция в DFD например) ?

Уровень детализации определяется вашей целью, для чего вы выполняете моделирование процесса или деятельности.
Для отражения того что вы нарисовали, обычно, используют диаграммы activity.
Вы ваш пример начали совсем не с того с чего нужно.
Сначала выделите всех акторов и сделайте краткое описание какая у них цель, и что они делают.
Диаграмма UC необходима для представления о процессе или системе на концептуальном уровне, там не должно тех деталей которые у вас на диаграмме.

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

Спасибо, таким образом я мог на UC показать только общие действия?, например:

• Клиент - (Оформление заказа), (Получение заказа), (Проверка заказа)
• Оператор - (Прием заказа), (Ввод заказа в систему), (Отправка заказа на склад)
• Сотрудник склада - (Формирование заказа), (Выдача заказа), (Компенсация недовложение)

и затем по каждому кейсу составить более подробную диаграмму, например activity?

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

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

Спасибо!

Спасибо, таким образом я мог на UC показать только общие действия?, например:

• Клиент - (Оформление заказа), (Получение заказа), (Проверка заказа)
• Оператор - (Прием заказа), (Ввод заказа в систему), (Отправка заказа на склад)
• Сотрудник склада - (Формирование заказа), (Выдача заказа), (Компенсация недовложение)

и затем по каждому кейсу составить более подробную диаграмму, например activity?

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

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

Спасибо!

el-niko, есть понятие бизнес вариантов использования, а есть понятия системных вариантов использования. Отличия см. тут: http://www.uml2.ru/index.php?option=com_content&task=view&id=75&Itemid=51

Декомпозиция вариантов использования на варианты использования - в корне неверный подход (хотя, например, Enterprise Architect позволяет это делать).

p_safin, спасибо!

А можно где-то найти пример подробного описания небольшой системы на UML с коментариями для чего какая диаграмма была сделана и как она делалась?
Одно дело читать теорию, но на практических примерах понимать проще, и удобно было бы посмотреть как описать одну систему комплексом диаграмм.

Спасибо.

el-niko. Хочу вас предостеречь от заблуждения. UC - это не действие, функция, часть системы или некая сущность.
Это соглашение об использовании системы, это описания способа использования системы для достижения значимой цели для пользователя в одном сеансе такого взаимодействия.

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

Galogen, великолепное пояснение, спасибо. Понял часть своих ошибок.

А что касается последнего моего вопроса... можно где-то найти пример подробного описания небольшой системы на UML с коментариями для чего какая диаграмма была сделана и как она делалась?
Одно дело читать теорию, но на практических примерах понимать проще, и удобно было бы посмотреть как описать одну систему комплексом диаграмм.

Уважаемые участники сообщества.
Посмотрите пожалуйста вторую версию UC-диаграммы.
Теперь каждый кейс - это отдельный сервис будущей системы без раскрытия деталей. Т.е. я выделил роли пользователей будущей системы и изобразил сервисы системы с которыми эти пользователи будут работать.

Помогите получить ответы на следующие вопросы:

1. Правильно ли изображены отношения?

2. Достаточно ли информации предоставляет схема, возможно кто-то сможет "прочесть" диаграмму и рассказать, что из неё понятно, а я сопоставлю: что я хотел показать и что мне удалось показать?

3. Такие "сервисы" на схеме как "Формирование заказа", "Получение заказа", "Формирование претензии" осуществляются клиентом без непосредственного взаимодействия с Инф. системой, однако они заполняют руками спец. бланки. Эти функции нужно включать в схему, если они являются частью бизнес-процесса? Ведь можно описывать не только саму ИС, но и способы взаимодействия с ней, или я не заблуждаюсь?

4. Я прочитал ответ в FAQ про отличия ДВИ и БДВИ. Неясен такой момент. Если я хочу изобразить на одной диаграмме участников бизнес процесса и внешних, например, клиентов, то могу ли я изображать их на одной диаграмме или нужно обязательно строить 2 отдельные диаграммы?

5. Объясните пожалуйста другие мои ошибки, это очень эффективно и помогает разобраться.

Заранее спасибо!

1. Я правильно понимаю, что контролер начинает работать только если есть претензии клиента.
2. Зачем нужно выделять в отдельный кейс Подтверждение сборки?
3. Возможно кейс Формирования недовложения лишний.
4. ...

Как вариант:
1. Клиент - кейсы: поиск "чего хочу"; формирование заказа; получение заказа (внутри которого претензии).
2. Контролер - кейс: контроль исполнения заказов.
3. Оператор - кейс: подготовка заказа.
4. Сотрудник склада - кейсы: подготовка заказа, получение заказа.

1. Я правильно понимаю, что контролер начинает работать только если есть претензии клиента.

Нет, не только, нужно видимо добавить extention point и условие начала работы контроллера после сборки заказа, да? Поисходит так: собирается заказ, если требуется, включается контроллер. Если Контроллер нашел недостачу товара - формирует недовложение.

Формирование недовложения происходит в 2 случаях:
- Контроллер заметил недостачу товара в заказе и сформировал недовложение
- Клиент заметил недостачу товара в заказе, сформировал претензию, сотрудник склада сформировал недовложение...

2. Зачем нужно выделять в отдельный кейс Подтверждение сборки?

Подтверждение сборки это отдельная операция, которую может делать второй пользователь с ролью "Сотрудник склада". В этом случае такое изображение допускается?

3. Возможно кейс Формирования недовложения лишний.

Формирование недовложения - это также отдельная "функция/сервис/возможность" - из суммы заказа вычитается стоимость недостающего товара, переделываются документы на заказ и т.д.

Есть ещё пара вопросов:

1. Есть ли в моей диаграмме какие-то фундаментальные ошибки или неправильное применение чего-либо?
2. Какой следующий этап проектирования? Нужно описать каждый сервис с помощью диаграммы деятельности?

Спасибо!

А что касается последнего моего вопроса... можно где-то найти пример подробного описания небольшой системы на UML с коментариями для чего какая диаграмма была сделана и как она делалась?
Одно дело читать теорию, но на практических примерах понимать проще, и удобно было бы посмотреть как описать одну систему комплексом диаграмм.

Идельного примера Вы, пожалуй, нигде не найдете. Но объемные кусочки найти можно. UML обширен и довольно сложен. Простые примеры не требуют полного многообразия описательной силы. Посмотрите книгу Мацяшека, например. Есть неплохие примеры у Джозефа Шмуллера. Ну и в интернет, особенно на англоязычных сайтах.

1. Правильно ли изображены отношения?

Нет неправильно. Пояснения слишком обширны, но ... Вы вновь пытаетесь показать процесс, а не способы использования системы.

2. Достаточно ли информации предоставляет схема, возможно кто-то сможет "прочесть" диаграмму и рассказать, что из неё понятно, а я сопоставлю: что я хотел показать и что мне удалось показать?

В целом достаточно - тематика достаточно прозрачная

3. Такие "сервисы" на схеме как "Формирование заказа", "Получение заказа", "Формирование претензии" осуществляются клиентом без непосредственного взаимодействия с Инф. системой, однако они заполняют руками спец. бланки. Эти функции нужно включать в схему, если они являются частью бизнес-процесса? Ведь можно описывать не только саму ИС, но и способы взаимодействия с ней, или я не заблуждаюсь?

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

4. Я прочитал ответ в FAQ про отличия ДВИ и БДВИ. Неясен такой момент. Если я хочу изобразить на одной диаграмме участников бизнес процесса и внешних, например, клиентов, то могу ли я изображать их на одной диаграмме или нужно обязательно строить 2 отдельные диаграммы?

ДВИ имеет свой синтаксис, семантику и прагматику использования. UML не накладывает на Вас каких-то супер строгих правил, Вы вольны изобретать свои способы графического отображения. Однако в данном случае следует придерживаться общих рекомендаций подобного анализа, т.е. при описании модели придерживаться определенного на нее взгляда, не смешивая их. Лучше и правильнее разделять СДВИ и БДВИ

5. Объясните пожалуйста другие мои ошибки, это очень эффективно и помогает разобраться.

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

пример подробного описания небольшой системы на UML

Посмотрите "Телефонная служба приема заявок" http://www.intuit.ru/department/se/vismodtp/3/