Форум Сообщества Аналитиков

×


UC. Жизенный цикл заказа(Прочитано 9154 раз)
UC. Жизенный цикл заказа : 12 Октября 2011, 23:46:18
Здравствуйте.
Попробовал описать бизнес-процесс формирования и получения заказа.
- Клиент заполняет анкету заказа
- Передает анкету оператору
- Оператор проверяет заказ. Если всё ок - выпускает на склад, иначе просит клиента исправить заказ.
- Сотрудник склада получает заказ, собирает, проверяет и т.д.
- Затем заказ отправляется по почте или отдается лично клиенту
- При этом клиент проверяет наличие товара в заказе, если чего-то не хватает, недостача компенсируется. Чтобы исключить обман при выдаче заказа он взвешивается, и вес сличается при приемке заказа по претензии.

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

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




Re: UC. Жизенный цикл заказа Ответ #1 : 13 Октября 2011, 08:33:39
Ваша ссылка на рисунок некорректна и выдает ошибку 404 - потому в сообщении она не отображается. Или прикрепите ее (нажмите изменить и используя Дополнительно прикрепите файл графики) или ссылайтесь на существующий ресурс



Re: UC. Жизенный цикл заказа Ответ #2 : 13 Октября 2011, 12:39:27
Прошу прощения, опубликовал изображение на закрытом сервере...
Вот собственно схема...

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

Спасибо!



Re: UC. Жизенный цикл заказа Ответ #3 : 13 Октября 2011, 13:43:02
Судя по всему я её излишне детализировал? Если так, то можете дать рекомендацию, до какого уровня детализировать и как например показать, что данный ЮсКейс можно рассмотреть подробнее на другой диаграме (как декомпозиция в DFD например) ?
Уровень детализации определяется вашей целью, для чего вы выполняете моделирование процесса или деятельности.
Для отражения того что вы нарисовали, обычно, используют диаграммы activity.
Вы ваш пример начали совсем не с того с чего нужно.
Сначала выделите всех акторов и сделайте краткое описание какая у них цель, и что они делают.
Диаграмма UC необходима для представления о процессе или системе на концептуальном уровне, там не должно тех деталей которые у вас на диаграмме.

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



Re: UC. Жизенный цикл заказа Ответ #4 : 13 Октября 2011, 14:22:17
Спасибо, таким образом я мог на UC показать только общие действия?, например:
  • Клиент - (Оформление заказа), (Получение заказа), (Проверка заказа)
  • Оператор - (Прием заказа), (Ввод заказа в систему), (Отправка заказа на склад)
  • Сотрудник склада - (Формирование заказа), (Выдача заказа), (Компенсация недовложение)
и затем по каждому кейсу составить более подробную диаграмму, например activity?

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

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

Спасибо!



Re: UC. Жизенный цикл заказа Ответ #5 : 13 Октября 2011, 14:35:49
Спасибо, таким образом я мог на UC показать только общие действия?, например:
  • Клиент - (Оформление заказа), (Получение заказа), (Проверка заказа)
  • Оператор - (Прием заказа), (Ввод заказа в систему), (Отправка заказа на склад)
  • Сотрудник склада - (Формирование заказа), (Выдача заказа), (Компенсация недовложение)
и затем по каждому кейсу составить более подробную диаграмму, например activity?

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

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

Спасибо!

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

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



Re: UC. Жизенный цикл заказа Ответ #6 : 13 Октября 2011, 14:52:39
p_safin, спасибо!

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

Спасибо.
« Последнее редактирование: 13 Октября 2011, 14:58:32 от el-niko »



Re: UC. Жизенный цикл заказа Ответ #7 : 13 Октября 2011, 17:50:47
el-niko. Хочу вас предостеречь от заблуждения. UC - это не действие, функция, часть системы или некая сущность.
Это соглашение об использовании системы, это описания способа использования системы для достижения значимой цели для пользователя в одном сеансе такого взаимодействия.

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



Re: UC. Жизенный цикл заказа Ответ #8 : 13 Октября 2011, 17:58:41
Galogen, великолепное пояснение, спасибо. Понял часть своих ошибок.

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



Re: UC. Жизенный цикл заказа Ответ #9 : 13 Октября 2011, 20:02:31
Уважаемые участники сообщества.
Посмотрите пожалуйста вторую версию UC-диаграммы.
Теперь каждый кейс - это отдельный сервис будущей системы без раскрытия деталей. Т.е. я выделил роли пользователей будущей системы и изобразил сервисы системы с которыми эти пользователи будут работать.

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

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

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

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

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

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

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



Re: UC. Жизенный цикл заказа Ответ #10 : 13 Октября 2011, 21:03:47
1. Я правильно понимаю, что контролер начинает работать только если есть претензии клиента.
2. Зачем нужно выделять в отдельный кейс Подтверждение сборки?
3. Возможно кейс Формирования недовложения лишний.
4. ...

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



Re: UC. Жизенный цикл заказа Ответ #11 : 13 Октября 2011, 21:40:04
1. Я правильно понимаю, что контролер начинает работать только если есть претензии клиента.
Нет, не только, нужно видимо добавить extention point и условие начала работы контроллера после сборки заказа, да? Поисходит так: собирается заказ, если требуется, включается контроллер. Если Контроллер нашел недостачу товара - формирует недовложение.

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

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

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

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


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

Спасибо!



Re: UC. Жизенный цикл заказа Ответ #12 : 13 Октября 2011, 23:07:06
А что касается последнего моего вопроса... можно где-то найти пример подробного описания небольшой системы на UML с коментариями для чего какая диаграмма была сделана и как она делалась?
Одно дело читать теорию, но на практических примерах понимать проще, и удобно было бы посмотреть как описать одну систему комплексом диаграмм.
Идельного примера Вы, пожалуй, нигде не найдете. Но объемные кусочки найти можно. UML обширен и довольно сложен. Простые примеры не требуют полного многообразия описательной силы. Посмотрите книгу Мацяшека, например. Есть неплохие примеры у Джозефа Шмуллера. Ну и в интернет, особенно на англоязычных сайтах.



Re: UC. Жизенный цикл заказа Ответ #13 : 13 Октября 2011, 23:21:14
1. Правильно ли изображены отношения?
Нет неправильно. Пояснения слишком обширны, но ... Вы вновь пытаетесь показать процесс, а не способы использования системы.

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

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

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

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



Re: UC. Жизенный цикл заказа Ответ #14 : 14 Октября 2011, 11:58:34
Цитировать
пример подробного описания небольшой системы на UML
Посмотрите "Телефонная служба приема заявок" http://www.intuit.ru/department/se/vismodtp/3/




 

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