DRAKON.SU

Для компьютера, как некоторого универсального инструмента блокнота-калькулятора-будильника для исполнителя.
Или для человека-супервизора бизнес-процессов - автоматическое генерирование, например, регламента контроля.


Для достижения целей бизнес-процесса.


1. Я так и сказал "условно".
2. В схеме кооперации линейный процесс "Согласование договора" присутствует неявно на фоне явной параллельной работы исполнителей (в пределах одного БП). В этом смысле схема кооперации менее линейна, чем условно линейная схема : )

Да че мелочиться -> в чем смысл жизни? На самом деле, зря иронизируете. Программа сконструированная на платформе Дракон аналитиком-предметником (хотя бы потому, что для непрограммиста она гораздо доступнее всех прочих известных мне проектных инструментов), а затем закодированная средним программером, в большинстве случаев будет лучше программы, сработанной классным программером, но слабо понимающим предметную область. Почему? Потому что хорошо работают только такие программы, объектные модели которых адекватны (кратны) объектным моделям соответствующих предметных областей. Поэтому проектировать систему должен специалист-аналитик. Дракон же со своей стороны, довольно жестко препятствует совершению серьезных логических ошибок программистского характера. Закодировать модель затем - действительно в конечном счете лишь дело техники. Сегодня может и нет еще такой совершенной техники, а есть программисты, а завтра ... Бог его знает ... Во всяком случае, очень много достаточно серьезных Акторов в сфере разработки средств производства ПО прилагают к этому большие усилия (т.е., полагают это принципиально реальным). Вполне возможно, что Дракон подпадает под определение "Все гениальное - просто". Мне, по крайней мере кажется, что я, не будучи программером, понимаю принцип механизма кодогенерации, который излагает Паранджанов и мне он представляется действительно практичным. В отличии от механизмов других Case-систем, в которых судя по их форумам, разбираются единицы высококлассных программистов, которые признают их способности к кодогенерации с очень большими оговорками. Я хорошо знаю 1С77-бухию, когда-то полноценно в ней программировал. И мне кажется, что методом Дракона (концептуального) действительно можно было бы получать полноценные конечные 1Cные коды. Не вижу к этому принципиальных препятствий, лишь только чисто функционально-техническую недостаточность существующих редакторов (правда, я немного знаком пока только с одним). Хоть и не программер, но достаточно хорошо знаком со многими средами разработки, и нахожу их, в основном, устроенными подобно, включая 1С. Утверждение, что Дракон может генерировать коды (тексты) для любых сред программирования (почти), лишь укрепляет меня в этом мнении, хотя программисты, как правило, его оспаривают. Лично мне понятно, почему программисты к Дракону относятся предвзято

Чё-то не понял, кто тут иронизировал... у меня обычный вопрос... у Эдуарда тоже вроде рассуждения серьёзные... ну ладно...
На самом деле генерация кода "точно по схеме" - как раз сильная сторона формальных методов. Исходного шампур-метода в том числе. Разумеется, при условии проработанности. ИШМ относительно хорошо подходит для генерации кода в линейно-адресуемое пространство исполнения - т.е. для явно-адресной архитектуры исполнителя. Стало быть, для машины по описанию фон Неймана (и для модели Тьюринга при нумерации ячеек её "ленты памяти"). И для человека, который уподобляет себя такой машине. А вот это уже м.б. эргономически неэффективно (вспомните, какой код получается в ДАЛВЯЗ одной из новых версий - с П-командами, представляющими "межстраничные соединители веток").
Насчёт аналитика - это точно. Но. Тут штука в том, что к маршрутам деятельность как предмет проектирования несводима. Надо оперировать также типами предметов труда... Здесь импер-часть вспомогательна - от неё важно только поддержать грамотную типизацию действий. Например, как описано здесь: viewtopic.php?p=77108#p77108. А типы действий д.б. связаны с типами предметов... так, как мы обычно пишем "математически" для функций (отношений). Имеется в виду это: f : Targ1{ x Targi} -> Trez. Вот мы снова и пришли к "базису трёх абстракций" Кауфмана...
Это к тому, что генерить то, что предлагает Эдуард, можно именно на основе хотя бы такого базиса... а только описания маршрутов и простейших формулировок действий/условий внутри этого описания недостаточно... А есть ещё постановка задачи... формулировки начальных и граничных условий, что можно видеть на примерах с укреплением переплёта книги и разборкой/сборкой Калашникова...
Кстати, даже по модели для второго примера код будет, хотя и вполне семантичным, но синтаксически - в "стиле ЭЛИЗЫ"... попробуйте сами сгенерить (начиная с головной схемы отношений Эксплуатация автомата)...

Видимо, к сказанному Mixail также и это:

Совершенно с Вами согласен.
Моя схема это даже не приближение к решению проблемы...
Больше похоже на рассматривание из под "козырька", а что же там маячит? : )

Да, и именно потому тем или иным такие результаты и оказываются интересны...
Потому, что цель - не "концепции/нотации двигать", а дело делать...
Что и к Дагаеву относится, допустим...
Тут единственная штука - кажется целесообразным такие частные схемы получать прогоном общих (отражающих ту самую "явную параллельную работу" системно)... о чём уже говорил...