Visio поддерживает UML, что уже позволяет осуществлять базовое моделирование. Но это не отменяет конечно его основного предназначения как инструмента построения и визуализации.
Странное замечание, мы же не на филфаке, без обид)) грамотно писать надо, слова, пунктуации. но это это уже мне кажется дело автора и есть термины и для БА и СА английские. В разных компаниях, по разному принято обозначения, где-то на родном, где-то как за границей.
Так, начнём вот с чего. 486 был моим первым процессором. Это было мажорство, но я не возражал. 100 мегагерц было достаточно всему. Игры шли вообще без каких либо тормозов. Тогда вообще мало что тормозило.
моя история, "плюсую" :) машина по тем временам отличная
все так, я помню ток линейки 386 и 486 с DX, были бодрые машины того времени)) у меня первый новый комп появился как раз 486DX-100. с кнопкой Turbo конечно :) на первый пенек P-75 у родителей денег не хватало
Статья крутая. Автору спасибо за труд, в закладки. Согласен с @Spellingчто баланс не менее важен, т.к. все в природе построено на этом. Но это видимо еще сложнее, чем контрдвижение.
"бабушки" это да, допускаю, что с ними бывает не просто :)
инструменты и нотации выбираются под конкретную ситуацию и необходимость в них: нужны Заказчику, РП, команде.. а схемы ради схем, это уже действительно про ЧСВ :)
Вот это я коротко описал подход в парадигме многоуровневой архитектуры. Любопытно как может выглядеть другой. Жду новую статью ;)
Спасибо за участие в обсуждение и развернутые комментарии) Все конструктивные и объективные замечания, постараюсь учесть в работе при проектировании и описании БП, а также при написании в будущем статьи, возможно более развернутой или еще более компактной ;)
Про аннотации я писал к задачам, не ко всей диаграмме. Диаграмма-то как раз может быть в идеале самоописана.
Это возможно и в каих-то случая нужно. Но диаграмма не идет в отрыве от описания бизнес-процессов, а иначе она представляет собой только логику выполнения БП, а не комплекс диаграмма-описание.
"Событие используется для нескольких целей. Во-первых, чтобы указать моменты времени, когда выполняется работа. Например, начать выполнение очередной операции через 1 час, после завершения предыдущей. Во-вторых, чтобы ограничить длительность операций. Например, прервать исполнение операции через 30 минут после начала. В-третьих, они описывают реакцию на изменение состояния внешних, по отношению к процессу объектов." - Моделирование бизнес-процессов в нотации BPMN2.0, И.Г. Федоров
Сообщение же - это вид событий
в статье приведена классификация по типу события
Еще бывают события старта/конца, таймера, ошибок, отмены, сигнала, условия и, конечно, ссылки на другой процесс
"Для описания бизнес-процессов из опыта в большинстве случаев достаточно элементов нотации, описанных здесь" - туториал не имеет своей целью охватить все элементы и аспекты нотации BPMN, для этого есть специализированные издания.
Привет и спасибо за комментарий) Я бы не назвал BPMN сложной, она хорошо подходит для описания именно бизнес-процессов.
EPC да, относительно легко читается, из-за небольшого кол-ва элементов и цветовой типизации, но мне кажется она больше подходит для описания относительно простых БП или процессов нижнего уровня, а также шагов, но выбор нотации в конечно счете зависит от конкретного случая и того, что именно будет описываться с её помощью.
Спасибо за ваш отзыв и за то, что уделили время на его написание. Понимаю и допускаю, что могут быть различные подходы для отражения элементов на схеме. В своей статье я стремился сделать BPMN более доступным для широкой аудитории и возможно, допустил некоторые упрощения. Я обязательно еще раз просмотрю указанные вами моменты и постараюсь улучшить материал. Возможно, в будущем для другой статьи добавлю более детальные пояснения и примеры. Спасибо за ваш вклад в улучшение контента и дело Хабра. Комментарии как положительные, так и отрицательные помогают всем нам становиться лучше.
Базовые - задачи должны быть в терминах предметной области, а не технических терминов вроде "сохранение", БД и элементы данных не могут выступать в качестве задач.
В нотации не запрещено использование технических терминов. Элементы не могут, но задача/действие над данными могут.
Путаница в нотации между сообщениями (вид событий) и событиями.
Событие - элемент управления потоком, который указывает на состояние, влияющее на выполнение процесса. События могут запускать действия в процессе или быть их результатом. Сообщение в свою очередь является одним из типов такого события.
пояснения задач процесса вместо некорректных представлений связей между элементами данных и БД
Ко всем создаваемым диаграммам в обязательном порядке идет аннотация с описанием каждого бизнес-процесса, отраженного на схеме. Связи элементов важная составляющая диаграмм и понимания схемы пользователями.
Процесс с событиями таймеров ожидания между параллельными шлюзами - вообще иллюстрация как делать не надо никогда
Разрешение выше физической матрицы монитора.. что происходит?🙈
Спасибо автору за рекомендации и подборку💫
Плюсую за развернутый комментарий-рассуждение и цитату Форда
Иван, хорошая статья. Уверен, она многим будет полезна и интересна.
Visio поддерживает UML, что уже позволяет осуществлять базовое моделирование. Но это не отменяет конечно его основного предназначения как инструмента построения и визуализации.
Странное замечание, мы же не на филфаке, без обид)) грамотно писать надо, слова, пунктуации. но это это уже мне кажется дело автора и есть термины и для БА и СА английские. В разных компаниях, по разному принято обозначения, где-то на родном, где-то как за границей.
моя история, "плюсую" :) машина по тем временам отличная
все так, я помню ток линейки 386 и 486 с DX, были бодрые машины того времени)) у меня первый новый комп появился как раз 486DX-100. с кнопкой Turbo конечно :) на первый пенек P-75 у родителей денег не хватало
Спасибо, что обратили внимание
Капитальный лонгрид)🤝
Статья крутая. Автору спасибо за труд, в закладки. Согласен с @Spellingчто баланс не менее важен, т.к. все в природе построено на этом. Но это видимо еще сложнее, чем контрдвижение.
"бабушки" это да, допускаю, что с ними бывает не просто :)
инструменты и нотации выбираются под конкретную ситуацию и необходимость в них: нужны Заказчику, РП, команде.. а схемы ради схем, это уже действительно про ЧСВ :)
Спасибо за участие в обсуждение и развернутые комментарии) Все конструктивные и объективные замечания, постараюсь учесть в работе при проектировании и описании БП, а также при написании в будущем статьи, возможно более развернутой или еще более компактной ;)
Это возможно и в каих-то случая нужно. Но диаграмма не идет в отрыве от описания бизнес-процессов, а иначе она представляет собой только логику выполнения БП, а не комплекс диаграмма-описание.
"Событие используется для нескольких целей. Во-первых, чтобы указать моменты времени, когда выполняется работа. Например, начать выполнение очередной операции через 1 час, после завершения предыдущей. Во-вторых, чтобы ограничить длительность операций. Например, прервать исполнение операции через 30 минут после начала. В-третьих, они описывают реакцию на изменение состояния внешних, по отношению к процессу объектов." - Моделирование бизнес-процессов в нотации BPMN2.0, И.Г. Федоров
в статье приведена классификация по типу события
"Для описания бизнес-процессов из опыта в большинстве случаев достаточно элементов нотации, описанных здесь" - туториал не имеет своей целью охватить все элементы и аспекты нотации BPMN, для этого есть специализированные издания.
Привет и спасибо за комментарий) Я бы не назвал BPMN сложной, она хорошо подходит для описания именно бизнес-процессов.
EPC да, относительно легко читается, из-за небольшого кол-ва элементов и цветовой типизации, но мне кажется она больше подходит для описания относительно простых БП или процессов нижнего уровня, а также шагов, но выбор нотации в конечно счете зависит от конкретного случая и того, что именно будет описываться с её помощью.
Константин, спасибо. Полезный и удобный материал. Добавил ссылку в статью на ресурс и от меня благодарность с упоминанием)
спасибо за обратную связь) добавил в статью пример описания маршрутизации пациента, с краткой аннотацией
Спасибо за ваш отзыв и за то, что уделили время на его написание. Понимаю и допускаю, что могут быть различные подходы для отражения элементов на схеме. В своей статье я стремился сделать BPMN более доступным для широкой аудитории и возможно, допустил некоторые упрощения. Я обязательно еще раз просмотрю указанные вами моменты и постараюсь улучшить материал. Возможно, в будущем для другой статьи добавлю более детальные пояснения и примеры. Спасибо за ваш вклад в улучшение контента и дело Хабра. Комментарии как положительные, так и отрицательные помогают всем нам становиться лучше.
В нотации не запрещено использование технических терминов. Элементы не могут, но задача/действие над данными могут.
Событие - элемент управления потоком, который указывает на состояние, влияющее на выполнение процесса. События могут запускать действия в процессе или быть их результатом. Сообщение в свою очередь является одним из типов такого события.
Ко всем создаваемым диаграммам в обязательном порядке идет аннотация с описанием каждого бизнес-процесса, отраженного на схеме. Связи элементов важная составляющая диаграмм и понимания схемы пользователями.
Спасибо за замечание, не обратил внимание