Итак, восстановим сказанное в связи с редактором Ильченко (с уточнениями и исправлениями). Проблематику представления поведения очертил один из участников РСДН:> -- vdimas в http://www.rsdn.ru/forum/philosophy/484 ... ?tree=tree писал(а):
> ...Буквально единицы лет назад в академических кругах научились делать "суперкомпиляторный анализ" императивного кода, до этого вообще был детский сад, представляющий из себя чуть продвинутую бета-редукцию над ФП. Почему так медленно идёт движение в этой области? Любое ветвление в программе — это лишний множитель комбинаторного кол-ва вариантов исполнения, то бишь сложность анализа от сложности алгоритма — степенная. Современные компиляторы проводят анализ в самых простейших случаях до 10 уровней глубины, в сложных — дай бог 2-3. Исходники gcc открыты, можно посмотреть самому. Понимаешь, из-за степенной природы происходящего, наблюдаемая вроде бы неплохая геометрическая прогрессия в росте мощщи железа ничего кроме пессимизма не вызывает. Ни ты, ни я не увидим "золотого века IT". Например, gcc в последних версиях медленно но верно догоняет MS VC по эффективности конечного образа. Именно поэтому gcc таки относительно скоро нагонит MSVC, что он его настигнет прямо в точке насыщения возможностей, выжимаемых из машин разработчиков. Это я всё к тому, что в течении ближайших 10-20 лет никакое самое вылизанное ФП по эффективности не догонит аналогично вылизанный императив даже близко. На плюсах я сижу неплотно лет 20, плотно более 15 лет. Все их достоинства и недостатки собственной задницей ощущал не раз, так же как знаю как с ними бороться. Я могу выжимать из машины максимум, умею это и люблю. Помимо выжимания, есть определенные способности находить нетривиальные ошибки даже в чужом коде. Считай, у меня в сформировалась некая статистика по причинам всех этих ошибок. Самые популярные, ес-но, не те ярлыки, которые навешивают на плюсы — типа выхода за границы диапазонов. . Причем, эти гонки не из-за непоходимости разработчиков, ес-но, а из-за всего здесь обсуждаемого, . Обычный разработчик уже на глубину более 3-х уровней зависимостей смотрят с ооочень большим трудом и не часто. . И мне/нам . А если брать предлагаемую банальную иммутабельность — наоборот, добавит работы и снизит эффективность решения.- возможно, на взгляд специалистов в теории деятельности (алгоритмизации, в частности), он не всё существенное учёл, ну пусть специалисты и выскажутся...

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

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

1. Работа-элемент - в схемной форме м.б. представлен такой вьюшкой (отсюда):Вложение:
Соболев-ОптимСтройПроц-извл(Рис7).png [ 116.41 КБ | Просмотров: 24772 ]
- заметим, что страницей раньше Соболев даёт вьюшку табличную, а от неё уже переходит к размеченному графу.
В этом случае связь имеет смысл передачи предметов труда ("веполей" для производства материального - предметов/сред/энергии или информатического - знаков/сигналов). Передачи в пространстве системы (транспорт) и/или во времени (хранение). А элемент (вершина графа) - преобразования предметов труда.Совместное протекание процессов (в т.ч. одновременное) естественное - "рабочая точка" как артефакт моделирования связана с наполнением связи. Процессы управляются предметами.

2. Работа-связь - в схемной форме м.б. представлен такой вьюшкой (отсюда):Вложение:
Соболев-ОптимСтройПроц-извл(Рис46-49).png [ 87.82 КБ | Просмотров: 24772 ]
- разумеется, формы записи тоже м.б. любыми.
В таком случае элемент (вершина) имеет, по литературе, несколько размытый смысл. Как правило, его определяют как событие достижения цели деятельности, представляемой сетью. Связь же - это любая работа.Совместное протекание процессов искусственное, должно представляться соединениями через события "не один к одному", имеющими специальную интерпретацию в модели - как "перекрёстков рабочих точек". Т.е. процессы (поведение системы) управляются артефактами моделирования.

Подход 2 исторически применяется, по-видимому, шире. Для него разработан ряд вариантов. Существенным различием между ними можно считать отношение к цикличности структуры. Есть сети работ-связей с циклами и ациклические. Вторые требуют топосортировки работ и размыкания циклов фиктивными связями-работами.
Сравнение подходов, возможно, проводилось крайне редко. Мне известна только одна работа с ограниченным сравнительным анализом...Подход 1 применяется в некоторых современных методологиях организации деятельности. Есть методы проектирования и реализации деятельности (Афанасьев, Соболев, Усов).
Возможно, существуют теории деятельности, независимые от подхода к системированию. В частности, следует изучить в этом аспекте[ПР]АЛУ-подход Закревского.
Приложение того или иного подхода к программам требует:
* выработки понимания программ как систем задания поведения исполнителя;
* увязки пониманий исполнителя для ЧТО-моделей (управляемого целями, декларативного, интеллектуально[-имитирующе]го) и для КАК-моделей (управляемого способами, императивного, алгоритмического).