Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => IDEF ARIS BPMN и пр. => Тема начата: Ich от 19 Сентября 2007, 10:49:26
-
Как сказано в спецификации, BPMN объединил все лучшее из различных методологий моделирования. И в том числе некоторые моменты, описывающие в этих нотациях одно и то же, но разными средствами.
Например, моделируем простой бизнес-процесс, где есть действие "Поиск документа", который может быть найден или не найден, и в зависимости от этого разворачивается дальнейшее действие. В EPC это бы однозначно моделировалось двумя переключающими событиями "Документ найден" и "Документ не найден" (соответственно в BPMN это будут Intermediary events). В IDEF3 - XOR перекрестком (BPMN - Exclusive databased gateway), в UML Activity Diagram - ветвлением decision и условными переходами (здесь опять же Exclusive databased или Exclusive event-based gateway ). А еще можно просто сделать условные переходы (conditional sequence flow).
Так какой же вариант моделирования будет правильным?
-
Если слово "мама" перевести на несколько языков, изменится ли его смысл?
По-моему любой вариант моделирования будет правильным, если он отражает одно и тоже. Другое дело, что можно делать потом. если на базе этого варианта нужно сформировать имитационную модель, исполняемый код, логику веб-сервиса, то выбор варианта будет определятся возможностями инструмента. Если же будет произведена ручная "настройка", то не все ли равно?
Поскольку результат действия Поиск документа однозначен - найден или не найден, то соответственно имеем исключающее ИЛИ, которое и реализуется разными способами.
-
Поиск документа как БИЗНЕС-ПРОЦЕСС .... как-то не очень укладывается, если это только не архив какой-нить, в котором клерк ищет документы ...
Вот все-таки как-то смешано получается, даже в таком примере ... где бизнес-процесс, а где функции системы?
-
Интересно, обрастет ли когда-нибудь спецификация BPMN методологией, приемами и прочими бэст практис? UML тоже когда-то существовал практически только в виде многостраничной спецификации, давая возможность каждому моделировать в меру своего понимания. Зато сегодня все знают, когда лучше использовать "include", а когда "extend" в use case diagram и что такое "уровень моря" по Коберну.
<<Если слово "мама" перевести на несколько языков, изменится ли его смысл?
Но если в одном языке собираются несколько вариантов слов "мама", значит это зачем-то нужно? Значит есть определенные нюансы звучания в определенных ситуациях. Так и здесь, ну, например, можно предположить, что события можно использовать в моделях только внешние и временнЫе, а "найден/не найден" - это внутреннее событие, поэтому в этом случае лучше использовать другие средства.
<<Поиск документа как БИЗНЕС-ПРОЦЕСС .... как-то не очень укладывается, если это только не архив какой-нить, в котором клерк ищет документы ...
Вообще-то речь шла о поиске документа, как действии в рамках некоего бизнес-процесса. Т.е. есть сервис, который получает сообщение и по полученным параметрам ищет в документоориентированной базе документ и возвращает результат. Но это частности, дело не в том, как смоделировать этот конкретный процесс. Конечно, я могу сделать это так, как считаю нужным, и как мне позволяет инструментарий. Но хотелось бы понять общую методику выбора конкретного варианта моделирования.
-
<<Поиск документа как БИЗНЕС-ПРОЦЕСС .... как-то не очень укладывается, если это только не архив какой-нить, в котором клерк ищет документы ...
Вообще-то речь шла о поиске документа, как действии в рамках некоего бизнес-процесса. Т.е. есть сервис, который получает сообщение и по полученным параметрам ищет в документоориентированной базе документ и возвращает результат. Но это частности, дело не в том, как смоделировать этот конкретный процесс. Конечно, я могу сделать это так, как считаю нужным, и как мне позволяет инструментарий. Но хотелось бы понять общую методику выбора конкретного варианта моделирования.
Вот это то и самое интересное .... то что вы описали действие в СИСТЕМЕ ... это функция поиска в системе. Является ли "поиск по базе данных" бизнес-процессом?
-
Вот это то и самое интересное .... то что вы описали действие в СИСТЕМЕ ... это функция поиска в системе. Является ли "поиск по базе данных" бизнес-процессом?
Кто ж спорит-то. Поиск - это сервис, ну или функция в системе. Входит в описание некоего бизнес-процесса "Обслуживание клиента", например, который собственно и моделируется. Кроме этой функции в процессе участвуют и другие. И вопрос в том, как их правильно связать. Честно говоря, мне сложно понять, как обсуждение темы бизнес-процессы vs функции приближает нас к сути поставленного вопроса. Вы хотите сказать, что функции системы не могут входить в описание бизнес-процесса? Или что они не могут связываться логикой событий и ветвлений?
-
Честно говоря, мне сложно понять, как обсуждение темы бизнес-процессы vs функции приближает нас к сути поставленного вопроса. Вы хотите сказать, что функции системы не могут входить в описание бизнес-процесса? Или что они не могут связываться логикой событий и ветвлений?
Как раз более сложно понять в данном случае что понимается под бизнес-процессом, и являются ли все функции системы частью какого-либо бизнес-процесса, или же нет ...
А почитав ваш вопрос "Так какой же вариант моделирования будет правильным?" я так и не понял что вы таки хотите спросить ... толи какую нотацию лучше использовать при моделировании БП, толи ветвление vs events... проблема-то в чем? и "лучше" это по какому критерию?