Перспективы развития средств разработки для управления тех. процессами

Мне хотелось бы продолжить единственное конструктивное обсуждение, которое началось в соседней ветке.

Первоначально опубликовано Дмитрий Теркель   Собственно, мое исходное предложение по поводу "агрегатных" или "множественных" связей и было таким предложением. Пользователь сам создает определенный ТИП СВЯЗИ, соединяющий определенные ТИПЫ БЛОКОВ. Затем он может протянуть одну единственную агрегатную связь (это как жгут проводов, если хотите), содержащую некоторое множество элементарных. Тогда агрегация самих данных в структуры или массивы ДЛЯ ЭТОЙ ЦЕЛИ будет не нужна.

В принципе, эта мысль мне представляется весьма интересной. Она не противоречит принципам графического представления алгоритмов и структуризации программ, и в то же время предлагает решение для повышения производительности труда программиста, путем введения абстракций и методов их взаимодействия, чего в МЭКовских языках действительно нет. У меня, правда, не хватает уверенности в том, что это не приведет к запутыванию связей между блоками.

Первоначально опубликовано Дмитрий Теркель Имелось ввиду ситуация, когда разработчику алгоритма по смыслу неважно, берется значение переменной с текущего шага или с прошлого, достаточно, чтобы это значение было достаточно "актуально", то есть относилось к моменту, не очень древнему. Собственно, очень многие управляющие алгоритмы на самом деле нечувствительны к замене некоторых прямых связей на "неважно какие". В принципе коммуникации между разными задачами и коммуникации между узлами сети в мэке предствляются именно такими связями Их только не изображают линиями на "единой диаграмме сетевой системы", но, наверное, изображали бы, если бы в мэке (61131, я не имею ввиду 499) такая диаграмма была возможна. Но это уже другая история - о представлении распределенного алгоритма имено как алгоритма, без обязательной привязки к узлам, ресурсам и т.п. ...

Представление алгоритма без привязки к ресурсам - это, конечно, хорошо, но работать такой алгоритм не будет. При создании МЭКовских языков принималась во внимание необходимость простой идентификации каждого из ресурсов, используемых в алгоритме. Формально, алгоритм без привязки к ресурсам с точки зрения IEC-61131 есть не что иное, как функциональный блок. Но мысль о сколько-нибудь сложном алгоритме с соответствующим количеством входов и выходов приводит в ужас... Определенные задатки для решения проблемы есть в виде пользовательских типов данных, но, как Вами было показано, это не всегда удобно. Более простым способом могли бы быть средства привязки и перепривязки, реализованные в некоторых системах, но они имеют свои ограничения.

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