Вот почему, интересно, алгоритмы бизнес-процессов описываются не на нормальных языках типа Java или C#, а на каких-то блок-схемах ? Объявить переменную, организовать цикл или ветвление, перехватить исключение - почему бы для этого не использовать нормальный язык программирования ?

Ну это так была, мысль вслух, скорее.

iscrafmМаксим Гераськин,

если квадратики не устраивают, то можно текстом

http://ru.wikipedia.org/wiki/BPEL
Гипотетический пример. BPEL-последовательность mathProcess принимает переменную $numIn возводит её в квадрат и возвращает результат в переменной $numOut.
...

Не проще ли

?

WJНу Вы тоже, я Вам скажу, выбрали эталон - BPEL

Я не выбрал, а рассмотрел ;)

Так что определитесь уж - картинки или процессы?

Вот насчет этого у меня и появилась мысль - а почему, собственно, генерируют код по картинкам а не картинки по коду.

Ну т.е. взять и описать процесс на нормальном ООП языке, с метаданными, по этому всему делу сгенерировать схему, если надо.

WJСначала программист накодирует нечто, что в его понимании есть бизнес-процесс (если только программист не обладает дипломом MBA и профильным образованием бизнес-аналитика).
Затем генерит из этого нечто квадратики - и тут именно квадратики, поскольку никакой ценности для бизнеса они не представляют. А затем напишет прогу, которая позволит аналитику перерисовывать эти квадратики в соответствии с бизнес-задачами

А зачем программист-то ? Аналитик сразу пишет на высокоуровневом языке схему и тест к ней, там, на JUnit.

WJАаааа, так это я не догоняю )))) Это не программист должен иметь диплом MBA, это бизнес-пользователь должен быть программистом! Так вот оно как, оказца!

Так почему нет ? Ведь все равно вы придумываете, реализуете из тестируете алгоритмы, т.е. выполняете работу программиста.

И еще гендиректор, чтобы управлять полноценно - тоже пусть учится программить!

Ну если он должен придумывать, реализовать и тестировать алгоритмы, то куда ж без программирования ?

АБМаксим,

А вы попробуйте, сходите предложите это СВОЕМУ директору. Потом расскажете что он вам ответит.

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

Во другом месте я сам гендиректор, мне лично было бы проще на Java или C++ написать и оттестировать алгоритм, чем еще одно средство изучать, которое к тому же наверняка хуже подходит для указанных целей.

АБМаксим ГераськинВо другом месте я сам гендиректор, мне лично было бы проще на Java или C++ написать и оттестировать алгоритм, чем еще одно средство изучать, которое к тому же наверняка хуже подходит для указанных целей.
Для понимания обстановки - сколько кроме вас людей там, где вы директор?

Трое

WJПопросите его любым доступным ему способом описать ключевые процессы его компании прямо сходу (дайте карандаш и бумагу).

Так я сам так задумываю алгоритмы - карандаш и бумага. Речь-то про реализацию алгоритмов и их тестирование . У меня что в моем отделе что в моей компании объем тестов превосходит объем собственно исходников.

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

АБМаксим, без обид, но о каких бизнес-процессах вообще может идти речь в компании из четырех человек?

Ну, к примеру, выпуск очередной версии ПО. Скомпилировать - автотесты - собрать дистрибутив-выложить туда - выложить сюда - обновить описание там - обновить описание сям - известить - отослать - разослать - обновить документацию.

Пять простых вопросов, ответив на которые вы узнаете, можно ли ваш бизнес-процесс моделировать и автоматизировать при помощи workflow

Познавательно, спасибо. Однако ж, мне кажется, что статья скорее отвечает на вопрос "нужно ли".

WJэээ... Максим, а вы, собственно, для себя ищете инструмент или хотите кому-то предложить? [quot]

Ну, можно так сказать - я хочу создать инструмент :). Или даже так - я вынужден приступить к созданию такого инструмента.

[quot]Если для себя, то я Вам открою маленький секрет: компании из трех человек не нужны никакие BPMS - поверьте опыту :)

Верю, охотно и сразу.

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

Тут задам вопрос, как опытному человеку - что, часто встречаются гендиректора, которые будут
изучать софт для составления схем бизнес процессов и на них что-то писать ?

Я работал в нескольких софтовых фирмах и в одном банке - нигде генеральному и в голову не пришло бы что-то там формально излагать в виде схем.

WJА вот это как раз скорее исключение, чем правило. Часто директор (или одно из первых лиц компании) в ходе разговора чисто механически берет в руки карандаш и объясняет: вот это у нас так, это хочу так и т.д. И угадайте, что на листочке? Угу, квадратики!

Конечно, я и сам в виде квадратиков и стрелочек делаю наброски.

Например: "добавьте тут еще одно согласование или проверку, а эту стрелочку направьте туда". И тут уж точно вы не предложете Java-код.

Совершенно верно, тут нужна схема. Схему можно сгенерировать по Java-коду, особенно если там есть аннотация.

Собс-но, понятно, что схемы нужны и даже необходимы. Не совсем понятно, почему для написания, а главное, отладки алгоритмов используется не язык ООП. Ведь если человек умеет хорошо алгоритмизировать, то для него язык не проблема, как мне кажется.

К примеру, смотря на ветвистую схему или читая задумчивое описание в первую очередь я думаю о том как ЭТО тестировать. А если речь идет про комплекс взаимодействующих процессов ? Часто случается что тронешь кусок кода, а где-то в другом месте "сыпется". Если система покрыта атоматизированными тестами, то проблема может выявится на общем прогоне. Как в BPM software с тестированием сложных систем из множества взаимодействиющих процессов дело обстоит ?

WJВы действительно не видите противоречий в том, что говорите?

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

Вы соглашаетесь, что для того, чтобы объяснить требования или обсудить бизнес-процесс на уровне бизнеса - нужна схема. Но тут же говорите, что можно сначала написать код на Java. Как писать код того, чего еще нет? Или Вы считаете, что это программист должен диктовать директору, как должен быть устроен его бизнес?

Я вот как считаю:
1)директор каким-то образом излагает некую схему (на бумаге, в устном виде и т.д.)
2)аналитик ее алгоритмизует и пишет тесты на нормальном языке ООП
3)прогоняются общие автоматизированные тесты на все систему, дающие надежду, что система в целом не развалится, если в нее воткнут изменение, порожденное (1)

Т.е. директор излагает идеи а аналитик их алгоритмизует и тестирует. Программист тут как таковой вообще не при делах ибо он не владеет предметной областью.