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

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Сергей Наумов

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


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

2
Сергей, мне вовсе не хочется вести с Вами спарринг. Я вовсе не хочу навязать Вам свою точку зрения. Вы обратились на форум с вопросом в чем собственно суть 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. Кассир принимает осташиеся денежные средства от клиента.

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

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

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

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


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

4
Про что такое 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. На диаграммах ВИ как эти процессы поддерживаются системой.


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

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

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

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

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

6
если не путаю что-то с чем-то, то admin/admin

Большое спасибо, то что надо!

а какая операционнка?

win xp sp3

и sa sa пробовали?

sa попробовать не догадался, но все равно разгадка лежала в другом месте.

Я ради интереса поискал по документации по слову admin - в installation guide действительно ничего подобного не было. Информация была в Caliber RM Help\Getting started\Procedures\End-user procedures\Logging in to CaliberRM

7
Встала задача ознакомиться с CaliberRM. Скачал триал. Поставил. Но вот незадача не могу понять под каким пользователем осуществляется первый вход  :o. В Installation Guide я ничего похожего не нашел. Сервер указал localhost (пробовал имя компьютера - эффект тот же). Перебрал имена пользователя, которого указал при установке, текущего пользователя винды, Administrator в разных вариантах - не пускает.

P.s. если что, сильно ногами не пинайте

8
Эдуард! Огромное спасибо!
Конец и начало месяца всегда трудное время ;)
Зашел, как только появилось время.

9
IDEF ARIS BPMN и пр. / Re: Вопросы про BPMN
« : 05 Декабря 2008, 10:10:33 »
АБ,

Правильно ли я понял, что на диаграмме мы должны показать в виде ПУЛА внешние сущности и процессы?

10
IDEF ARIS BPMN и пр. / Re: Вопросы про BPMN
« : 04 Декабря 2008, 19:33:32 »

Прокомментируйте пожалуйста - что вы пытались смоделировать этой диаграммой?


Фирма ромашка - производственная фирма. Производит туфли на заказ.
Фирма состоит из трех подразделений:
Продажи
Производство
Закупки.

Общий процесс выглядит так:
Клиент размещает заказ на изготовление туфлей.
Менеджер принимает заказ и передает его в производственный цех.
Считаем что производственный цех обладает неограниченными ресурсами рабочей силы и сразу начинает выполнять заказ.
По мере того, как материалы заканчиваются производство заказывает необходимые материалы у отдела закупок, который в свою очередь заказывает их у поставщиков.

11
IDEF ARIS BPMN и пр. / Re: Вопросы про BPMN
« : 04 Декабря 2008, 16:41:48 »
Посмотрите пжл диаграммку. Сделайте замечания.

12
IDEF ARIS BPMN и пр. / Re: Вопросы про BPMN
« : 03 Декабря 2008, 17:43:34 »
> 4. Правильно ли я построил высокоуровневую модель бизнес процессов? Если нет - то как надо?

Формально правильно, по существу - нет. Процессы столь выскокого уровня не бывают синхронными. Производство не ждет, пока отдел продаж что-то продаст, и не начинает работу после продажи. В реальности отдел продаж формирует производственные заказы и ждет их выполнения. Процесс производства с некоторой периодичностью сканирует заказы и выполняет их. То есть у вас должен быть не один, а несколько асинхронно исполняющихся и обменивающихся между собой сообщениями процессов. Общее правило: Уровень сквозного процесса моделируется не оркестровкой, а хореографией!

Спасибо за ответ.
Я извиняюсь за собственную тупость. Но не могли бы Вы пояснить фразу "Общее правило: Уровень сквозного процесса моделируется не оркестровкой, а хореографией!" ?

13
IDEF ARIS BPMN и пр. / Re: Вопросы про BPMN
« : 03 Декабря 2008, 17:38:48 »
Бас,

>>С другой стороны Продажа, Производство и Закупка - это 3 параллельных БП. Т.о. я бы предпочел их изобразить 3мя группами БП и в них уже расписывать сначала >>верхоуровневую ДБП, а потом уже детализированную Д каждого БП внутри группы БП. Т.е. получаем иерархию:


Ну а почему бы не изобразить все три группы в виде ПУЛОВ ? Мне кажется так получается вполне наглядно. А внутри пулов мы уже можем изображаем процессы.
И еще вопрос. Есть в BPMN какие либо правила, регламентирующие правила переноса входящих потоков на процессы нижнего уровня. Например, если в задачу входит 3 потока сообщений - все три должны быть представлены на процессах, декомпозирующих задачу?

14
IDEF ARIS BPMN и пр. / Re: Вопросы про BPMN
« : 03 Декабря 2008, 16:46:57 »
Еще вопрос:
Если каждый процесс должен иметь начало и конец - тогда
как отобразить на диаграмме процессов верхнего уровня непрервный цикл производства?!

15
IDEF ARIS BPMN и пр. / Re: Вопросы про BPMN
« : 03 Декабря 2008, 16:44:58 »
Спасибо БАС! Как всегда развернуто и подробно:)
Но вот по пункту 4 остались вопросы.

>> От дорожки не может идти message flow.

Я изобразил не дорожку, а ПУЛ и согласно описанию нотации от пула прекрасно могут идти потоки сообщений.

Страницы: 1 2 3 »