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

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

Согласен, что гораздо проще показать процесс словами или нотациями типа SADT, ARIS, но ведь и диаграмма деятельности - практический аналог IDEF3

2 Galogen,

Все же удобнее описвать ВИ именно в виде текста, а ДД или ДП может дать только немного общего представления, все детали в тесте.

2 AlexTheRaven
А бы выделил два ВИ - Заказать товар на Склад и Предоставить Заказ на полки в Магазин

Если цель -- анализ эффективности БП и реинжениринг, который частично связан с автоматизацией, но это не квинтэссенция, то не факт что UML будет the best для этих целей. Цель определяет средства ее достижения.

А что тогда лучше?

Цитата: Юрий Булуй от Декабря 24, 2006, 02:39:21 pm
Если цель -- анализ эффективности БП и реинжениринг, который частично связан с автоматизацией, но это не квинтэссенция, то не факт что UML будет the best для этих целей. Цель определяет средства ее достижения.
А что тогда лучше?

Я согласен с Юрием. Все-таки UML можно только с некоторой натяжкой позиционировать как полнообъемное средство для описания бизнес-процессов. ARIS для подобных целей лучше подходит

Кто-то может внятно рассказать формальное описание бизнес-процесса?
Читая ветку, а так до конца и не понял чем бизнес-процесс отличается от какого-то другого процесса реальной жизни кроме того, что бизнем-процесс должен приносить прибыль или помогать ее приносить.
Т.е. хотелось бы услышать четкое, позиционированное определение БП, со всеми его входами и выходами, управлениями и ресурсами. + как это согласуется с АРИС.

Далее интересно было бы посмотреть на информационные признаки понятия БП и ВИ, а также на схожие признаки.

UML - это рассширяемая система обозначений - кто мешает расширить ее для описание БП? Таже EA вроде так и сделал?

Да и вообще имеет ли смылс говорить о БП как таковых без привязки их к ИС, ПО и т.п.

Мне интересно у нас клуб аналитиков в чем? В Бизнес-процессах? Системных процессах? Каких? развитие экономики в России?  Как улучший БП обогащения одних и обнищяние других?

Почему ПО обязательно отталкивается от БП? Мы что пытаемся строить и делать? Если вообще пытаемся:-) Устроить свой собственный бизнес?

Помогать народу постигать азы бизнес-экспансии?

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

Далее интересно было бы посмотреть на информационные признаки понятия БП и ВИ, а также на схожие признаки.

Да мне бы тоже хотелось понять в чем приемущество описания, н-р, БП в АРИС по сравнению с БВИ в ЮМЛ?

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

В принципе я создавал такую ветку для БМ на скл.ру, думаю схоже http://www.sql.ru/forum/actualthread.aspx?tid=370422


[/quote]

Да в некоторм смысле - очень похожий вопрос и актуальные ответы.

Но мне хотлеось бы понять бизнес моделирование с одной стороны и модель бизнесу с другой - ведь это не одно и тоже?

БМ в РУП или просто интуитивно - это набор ВИ описывающих модель окружения, с позиций реально действующей бизнес-машины. При этом БВИ - аналог БП, но как утверждают некоторые ораторы этого форума - это совершенно не так.

Потому и задал вопрос.
1. Задайте описание БП формально. Типа БП это некая направленная деятельность, инициируемая событием или набором событий, использующая ресурсы различного типа(информационные, энергетические, физические, химические, людские и т.п.) для преобразования входов в ожидаемый выход=продукт. И может быть небоьшой примерчик такого процесса, с описанием и графической иллюстрацией, а также правиами вывода из этой информации уже основания для моделирования программных составляющих..

2. Увидеть разницы БП и БВИ+диаграмма деятельности

Рекомендую поискать в сети "ARIS vs IDEF", "UML vs IDEF", "ARIS vs UML".

Я например нашёл вот такой интересный документ - "Business Modelling: UML vs. IDEF" (3Мб, 53 стр.). Поскольку ARIS является развитием SADT-идей, то часть наблюдений и выводов применима и к нему.

Я например нашёл вот такой интересный документ - "Business Modelling: UML vs. IDEF" (3Мб, 53 стр.). Поскольку ARIS является развитием SADT-идей, то часть наблюдений и выводов применима и к нему.

Да документ дейстивтельно интересный. Спасибо за помощь

Вообще почему у оператоов в данном контексте цель - спланировать доставку или отгрузку. Может уж тогда инициировать доставку/отгрузку.

Ну рамки системы я такие выбрал для примера - планировать и учитывать. А инициирует взаимодействие что-то другое. Если не планировать использование ресурса - невозможно добиться его эффективного использования.

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

А не важны ещё на этом уровне ни компьютерные системы и подсистемы. Построение АСУ - всего лишь один из способов оптимизации бизнес-процесса. Зачастую - далеко не самый эффективный.
Если в реальном бизнес-процессе есть ветвление, а показать его в ВИ нельзя, то нужно использовать что-то отличное от ВИ. Хотя, кстати, ветвление ВИ реализуется альтернативными последовательностями. 3-4 сложных ветвления (связанных не с обработкой ошибок, а с вариантами логики обработки) превращают ВИ в нечитаемого монстра.

Деталировка происходит на диаграммах последовательности, где упор идет на объъекты и диаграммах дейтельности, где упор идет на операциях, действиях.

В Activity нет важнейших понятий - владелец функции, исполнитель функции, ресурс. Нет разделения перехода на переход
-- контроля
-- физического объекта
-- информации.
Действительно, можно "расширить" Activity посредством введения новых стереотипов. Но не проще ли использовать готовый eEPC?
В Sequence нет ничего, кроме исполнителей функции и переходов непонятно чего.
Ни там, ни здесь нет событийной основы.

Согласен, что гораздо проще показать процесс словами или нотациями типа SADT, ARIS, но ведь и диаграмма деятельности - практический аналог IDEF3

А есть ли вообще цель - использовать UML для всего (не академическая, а практическая)?

А есть ли вообще цель - использовать UML для всего (не академическая, а практическая)?

Да нет, конечно, разве можно человека стеснять рамками. Просто один инструмент на все, от самого зарождения задачи и до ее полного ввода в практику использования. Согласись, что гораздо удобнее, чем разные кусочки делать в разных системах.
Вот сегодня bas жаловался, в одной и тойже конторе используют 5 разных case да еще и разных версий:-))

а eEPC - эриксон - пампкин (ли как его, ну что в ARIS или в EA)?

Если цель -- анализ эффективности БП и реинжениринг, который частично связан с автоматизацией, но это не квинтэссенция, то не факт что UML будет the best для этих целей. Цель определяет средства ее достижения.

А что тогда лучше?

В таком контексте более важно иметь возможность оценки эффективности БП. Описать-то его можно хоть текстом. А вот произвести моделирование (симуляцию) с текстом невозможно, как впрочем и с UML диаграммами (да, я помню про существование ABC который одно время пытались прицепить к UML). Тут нужно либо тот же ARIS либо интсрументарий поддерживающий тот же BPMN. Я помню у IBM есть тула (склероз, а гуглить лень ...), которая поддерживает симуляцию по диаграммам a-la BPMN с переводом в BEPL.
Но если мы описываем БП просто чтобы понять "как устроено", чтобы выйти на требования к ПО, то вполне можно и на UML. Activity диаграммы рулят наряду с collaboration.
Кстати, мелькало на Rational Edge что-то про использования UML для бизнес-моделирования. На самом деле если у кого есть возможность потратить на это время -- можно там поискать.

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

Какова цель бизнес-моделирования, в частности в примере? Реинжениринг и оптимизация процессов, тем более без создания ПО? Эту задачу успешно решают именно инженеты от ИТ или все-таки это не совсем их домен?

В Activity нет важнейших понятий - владелец функции, исполнитель функции, ресурс. Нет разделения перехода на переход
-- контроля
-- физического объекта
-- информации.
Действительно, можно "расширить" Activity посредством введения новых стереотипов. Но не проще ли использовать готовый eEPC?
В Sequence нет ничего, кроме исполнителей функции и переходов непонятно чего.
Ни там, ни здесь нет событийной основы.

Скажем так, что уже до нас эти стереотипы разработали, при желании можно и воспользоваться, другой вопрос ЗАЧЕМ нужно описывать БП. А вот насчет отсутствия событийности ... так есть же понятие Business Event, которое есть в RUP, если мне не изменяет склероз. Да, стереотип, и что это плохо?

А есть ли вообще цель - использовать UML для всего (не академическая, а практическая)?

Вот к целям-то опять и вернулись :-)

Юра, насчет моделирования БП - ты, конечно, прав. Я тоже не слышал об интсрументах, которые используя модели поведения UML, могли бы трансформировать их в имитационные модели.
Для SADT есть. Есть трансформация IDEF3 в систему Арена или BPSimulator в CPN.
В ЕСОiii кажется есть реализация моделей сотояний в код.
Правда можно диаграммы состояний трансформировать в модели Stateflow Simulink Matlab, правда прямой конверации к сожалению из других средств я не встречал, но восможно разработать ToolBox например их XMI

Какова цель бизнес-моделирования, в частности в примере? Реинжениринг и оптимизация процессов, тем более без создания ПО? Эту задачу успешно решают именно инженеты от ИТ или все-таки это не совсем их домен?

Цель бизнес-моделирования в примере - выявление предметной области АСУ склада и написание корректных ВИ для этой АСУ. Эту задачу решают инженеры ИТ. В результате происходит оптимизация бизнес-процесса благодаря ускорению информационных потоков посредством АСУ.
IMHO реинжиниринг бизнес-процесса - это один частный случай оптимизации, а построение АСУ - другой частный случай (оптимизируется использование временнОго ресурса).

А вот насчет отсутствия событийности ... так есть же понятие Business Event, которое есть в RUP, если мне не изменяет склероз. Да, стереотип, и что это плохо?

Такое понятие действительно есть. В UML 1.0-1.1 (RR 2003), в Activity нельзя передавать (неизвестно что) объектам. В UML 2.0 (EA 6.5) действительно можно, причём определять, что передаёшь - контроль или информационный поток. Activity в UML 2.0 действительно можно превратить в ARIS eEPC. Жаль только, что это автоматически не даёт тулзе поддерживающей UML 2.0, возможностей модулей ARIS ABC, BSC и Simulation .