> -- Владислав Жаринов писал(а):
> ...и может, это и есть главный результат развития Р-технологии (благодаря чему им удалось создать среду, поддерживающую не только "единую методологию разработки" - что очень правильно, думаю!  - но и оргсистему разработки)?..
Насчёт Р-схем. Вспомним про человеческие "чанки" (отсюда- Графика или текст: какой язык нужен программисту? Владимир Зюбин):
> -- Цитата:
> ...Психология запоминания и критерии оценки языкаДавно подмечено, что для успешной разработки языковых средств и определения критериев их оценки требуются определенные познания в области психологии. Эта мысль присутствует в трудах А. Ершова, У. Дала, Э. Дейкстры, К. Хоора. Исследования в области психологии программирования [2] показывают, что использование имеющихся в психологии методов позволяет повысить качественный уровень программирования, освободившись от вредных заблуждений. Действительно, программирование не может быть сведено к математическим формализмам: обоснование для существования идентификаторов, структуризации, языков высокого уровня следует искать в первую очередь в человеческой природе. К сожалению, рассматривая свойства языков, «человеческий фактор» либо просто игнорируют, либо проводят на непрофессиональном уровне. Между тем, даже поверхностное знание того, как функционирует человеческая память, позволяет более качественно оценить выразительные средства.В соответствии с используемой в психологии моделью, «запоминающий ресурс» состоит из трех основных элементов: рабочая, кратковременная и долговременная память. Рабочая память предназначена для хранения сенсорной информации («мгновенный снимок»); время хранения — десятые доли секунды. Кратковременная память позволяет хранить небольшое число семантических сущностей и оперировать ими, загружается быстро и без особого напряжения; время хранения — до 30 секунд. Долговременная память представляется постоянной, практически неисчерпаемой емкостью, с длительным временем хранения, однако ее загрузка требует серьезных усилий и времени.Наибольший интерес с точки зрения понимания когнитивных механизмов представляет кратковременная память, обеспечивающая динамическую работу с информативными сущностями. Кратковременная память впервые была описана в классической работе Дж. Миллера «Магическое число семь — плюс или минус два: предел человеческих способностей обрабатывать информацию». Основной вывод работы — в ее названии: кратковременная память накладывает жесткие ограничения на возможность человека обрабатывать данные. Однако Миллер допускает возможность преодоления психологических ограничений за счет разбиения информации на независимые части, выделения независимых признаков: «Лучше знать немногое о многом, чем многое о немногом». Помимо этого ограничения, человеческая память обнаруживает и еще одно неприятное свойство: использование кратковременной памяти требует от человека заметного напряжения. Вот мы и стараемся «выгрузить» информацию, давая себе отдых. Эта особенность работы с кратковременной памятью называется в психологии проблемой закрытия [2].Таким образом, для человека принципиально невозможны операции, предполагающие динамическое манипулирование с большим числом однородных информационных компонентов. Динамические операции с достаточно сложной сущностью требуют построения модели, при работе с которой ограничение Миллера не нарушается. Методами преодоления данного ограничения таковы: устранение несущественных деталей, выделение «ортогональных» ракурсов рассмотрения и создание моделей объекта в виде иерархической структуры, когда для работы с любой из областей такой структуры достаточно лишь нескольких информационных компонентов. Следует отметить, что приведенные рассуждения напрямую связаны с понятием сложности, которую можно трактовать как степень нагрузки на кратковременную память. Однако широко распространенные методики оценки сложности программ (в частности, мера сложности Маккейба) не учитывают ни ограничений Миллера, ни существование проблемы закрытия....
Вроде, всё логично, в т.ч. и ключевые плюсы графики:
> -- Цитата:
> ...Для начала нужно отметить, что графика не является самодостаточным выразительным средством; в языках спецификаций она всегда служит лишь дополнением к тексту. В первую очередь это связано с иероглифичностью графики, с неформализуемостью создания новых идентификаторов-пиктограмм. Вообще говоря, это обстоятельство показывает натянутость любого вопроса, подразумевающего противопоставление графики и текста. Правильнее ставить вопрос так: насколько графика может улучшить воспринимаемость текста и повысить эксплуатационные свойства языкового средства?Среди неоспоримых плюсов графики — обилие признаков (цвет, оттенок, насыщенность, размер, форма, текстура, позиция, ориентация, масштабирование и пр.). С точки зрения кратковременной памяти («проще знать немного о многом») это, несомненно, позволяет создавать сущности большей информативности. Даже с учетом того, что существуют ограничения на использование этих признаков (скажем, текстура вызывает утомление), некоторые признаки слабо подходят для отображения количественных значений, другие — качественных.Графика позволяет использовать метафору, то есть представление новых или необычных для пользователя явлений через другие явления, хорошо ему известные из повседневной жизни [3]. Механизм работы метафоры с точки зрения психологии заключается в использовании уже существующих у пользователя знаний — долговременной памяти. Это чрезвычайно упрощает освоение нового продукта для новичков в программировании. Классическим примером такого подхода при создании языкового средства служит язык релейных схем (ladder diagram) из состава международного стандарта МЭК 61131....
Да и насчёт некоторых минусов согласен:
> -- Цитата:
> ...Однако кажущаяся простота такого подхода таит в себе «подводные камни»; даже для относительно простых случаев очень трудно подобрать подходящую метафору, выразительная сила метафорического языка крайне низка, существует опасность возникновения «метафорических артефактов», побочных аналогий в сознании пользователя [3]. Построение действительно полезной графики является скорее искусством, чем операцией, доступной любому пользователю....
И многие творцы, действительно, в этом плане "продвинулись", когда на огромной схеме не только нет никакой упорядоченности, но и глаза разбегаются от сплошных иероглифов, построенных по принципу: "так..., все квадратики с ромбиками и овалами разобрали, э..., ага, вот ещё свободные эти пузырьки, берём, ...так, блин, уже ничего не осталось, значит... э..., берём эту трапецию и соединяем с этой улиткой...".

А вот в ключевом выводе автор статьи (который, фактически, цитирует научные работы других UML-продвигателей) противоречит сам себе:
> -- Цитата:
> ...Таким образом, при создании сложных программ значительно повысить эффективность можно за счет совместного использования графических средств разработки, например, набора языков UML, и текстовых средств кодирования, например, Си++. К выводу о возможности применения нескольких языков при создании программы приходят и другие авторы. Например, в [7] говорится: «На каждом шаге имеется свой уровень абстрактного представления программного продукта. Для каждого уровня программистом используются свои, наиболее целесообразные языковые средства, которые при переходе к следующему уровню абстракции подвергаются усложняющим их преобразованиям до тех пор, пока не будет получено требуемое представление программы (например, на языке Фортран)». Не следует смешивать способ создания программ с мультиязыковым программированием — использованием разных языков на одном уровне абстракции (кодировании), что крайне негативно сказывается на надежности создаваемого программного обеспечения [2, 5]. Например, одновременное использование Фортрана и Си, как правило, приводит к «классическим» ошибкам, обусловленным разными принципами индексации массивов. ...
...что нарушает принцип "лучше знать немногое о многом", ведь это "многое о немногом". И вспомним Седова:
> -- А. Седов писал(а):
> ...Человеческая способность одновременного оперирования понятиямиограничена в среднем 4-7 чанками (до 12 чанков -- у наиболее выдающихсяособей Homo sapiens). Для простоты положим, что чанк - это ровно однопонятие с минимальным контекстом, в котором оно используется. Понятно,откуда родились призывы (наиболее знакомые "обычным" программистам поязыку С): разбивайте программу на множество МАЛЕНЬКИХ подпрограмм --из стихийного осознания того физиологического факта, что человек не всостоянии воспринять КАК ЦЕЛОСТНОСТЬ текст объемом более половиныобычной книжной страницы....Сложность есть МЕРА НЕОДНОРОДНОСТИ. Чем более разнообразны составляющиенечто части, чем более разнообразны образуемые между частями связи - темвыше сложность этого нечто. Сложность вселенной, состоящей из одинаковымобразом сложенных одинаковых кирпичей равна сложности одного кирпича иобразуемых им с соседями связей (теорема редукции сложности). Таким образом,сложность выражает не масс-энергетические характеристики мира (см.E=m*c**2), а СТРУКТУРНЫЕ его свойства, причем весьма емкО и общО....А существо дело крайне просто сформулировать: основная проблемапрограммирования -- это проблема управления сложностью программы; этопроблема "размазывания" сложности вдоль текста программы "ровным слоем"(не слишком толстым, но и не очень тонким - как масло на бутерброде);не допускать "сгущений" сложности важно просто потому, что именно втаких местах сложность легко "перепрыгивает" ограниченные человеческиеспособности к одновременному восприятию множества взаимосвязанных вещейи в программе появляются не описки, а настоящие ошибки (ограниченностьНА ЛЮБОМ УРОВНЕ ПОЗНАНИЯ понимания задачи НЕЛЬЗЯ считать ошибкой - этопросто ИМАНЕНТНАЯ особенность познания, процесс которого, как известно,бесконечен)....
Видимо, Вельбицкий, Глушков и др. тоже изначально понимали суть проблем, отсюда и ключевые принципыР-схем:
> -- И.В. Вельбицкий писал(а):
> ...Во-первых, Р-схемы, не уступая в наглядности блок-схемам (так кратко и обобщенно будем называть изображения, использующие граф, нагруженный по вершинам), более компактны (в среднем в 3-4 раза при пересчете на алфавитно-цифровое представление). Однако блок-схемы более привычны.Во-вторых, Р-схемы, имеющие только горизонтальные и вертикальные линии, лучше (проще, технологичнее) реализуются на современных технических (растровых и алфавитно-цифровых) устройствах ввода-вывода ЭВМ.В-третьих, ГОСТ 19.005-85 (ISO 8631Н) благодаря особой информационной компактности положенных в его основу Р-схем не только задает графический образ и профессиональную символику основных рекомендуемых обозначений для единого описания и алгоритмов, и программ, и данных, и процессов, но и задает стандартный универсальный способ их расширения (развития), алгебру конструирования Р-схем из простейших элементов как базовых, так и полученных в результате их расширения, а также вводит в программирование понятие чертежа как следующий, более высокий уровень абстракции структуры. ...
Т.е. единственные кирпичики, формирующие однообразные связи, уменьшают "неоднородность" а, следовательно, и сложность. Следуя принципам декомпозиции и обобщения, они соответствуют требованию "лучше знать немногое о многом". И как аналогия, на сегодня уже можно провести исторический анализ на базе языков программирования - кто был более последователен в таких моментах, тот и оказался практичнее. В качестве примера, язык Rust - новый, императивный С-подобный, с надеждой в т.ч. и для системного программирования, где уже учитывают практику (как мэйнстрима, так и ФЯП). В результате там нет ООП-наследования, полная декомпозиция, не только функциональная, но и структурная (данные от функций максимально разделены, нет деклараций данных вместе с функциями (в стиле типовых ООП-классов), обобщённые функции не должны зависеть от структуры оперируемых данных, достаточно требования, чтобы были реализованы применяемые операции над ними, и т.д.), и полный полиморфизм (как функций, так и типов данных, и даже переменных - т.е. можно "перегружать" и переменные, к примеру, ввести коэффициент как значение по Цельсию, так и по Фаренгейту, и оперировать одной переменной, при этом есть контроль случайной модификации переменной, и два раза значение одного типа не укажешь (просто так)). Одним словом, те же базовые (необходимые и достаточные) кирпичики с однородными связями.

Причём, в Р-схемах нет информационной перегруженности, и все связи подчёркнуто и равномерно определены, при этом задействован необходимый и достаточный минимум элементов: дуги со стрелками (в т.ч., и в разные стороны), спецдуга, явно выделяются структурные блоки, плюс спецвершина, ну и структурные переходы как самый крайний случай, а также и имя структуры. При этом принцип построения схем не даст слепить слишком огромную схему, или вместить слишком много информации над/под дугой.

Для сравнения - IDEF (отсюда):
Вложение:
mental-bazis_html_m541b40a6.gif [ 118.6 КБ | Просмотров: 24216 ]

В такой схеме, как, например,здесь(отсюда) разница между типами связей, задаваемая такой формой, фактически, не будет заметна.

А "спец-иероглифы" для "метафор" не чужды и Р-схемам:
Вложение:
r_sdl.PNG [ 60.59 КБ | Просмотров: 24216 ]

Здесь спец-иконы "флажок" и "указатель" заменены на ">>"/"<<". При необходимости, "девочки" могут применять гламурные картинки, а суровые программисты - символы юникода, да плюс подсветка синтаксиса.

Или ещё пример. Активизировалась темаПараллельные процессы в языке Дракон (Глава 14). Что ещё раз подчёркивает факт того, что удобного решения до сих пор нет. Прежде всего, необходимо отметить то, что подобные попытки отразить параллельные процессы в программировании применимы к определенным парадигмам организации этих процессов. Например, принцип "fork-join" - запуск некоторого количества процедур и ожидание их завершения, на сегодня в большинстве случаев применяется для реализации одной большой задачи с рекурсивным разделением на малые составляющие, исполняемые одновременно, с последующей сборкой их результатов (примерна java). Или для той же java есть такая штучка -Disruptor(сампроект) - реализация кольцевой очереди обработки сообщений: один или несколько процессов-производителей кидают в очередь сообщения, и потребители-процессы их разгребают, работая параллельно, причём некоторые потребители ожидают завершение обработки сообщений другими, т.е. некий конвейер. Поэтому в схемах может возникнуть потребность указывать кроме признака параллельности, какздесь, в виде "параллельных линий", и сущность разделения/слияния процессов. Попытки чуть детального целеуказания, как в"мульти-шампуре", не вписываются в эргономику диаграммы. И в то же время "краткие" и компактные узлы, как "ОС-атомы" (отсюда):
Вложение:
os_atom.PNG [ 50.58 КБ | Просмотров: 24216 ]

тоже выпадают из общего ритма диаграммы. В Р-схемах спецвершины вида:
Вложение:
r_spec.PNG [ 7.02 КБ | Просмотров: 24216 ]

не нарушают ритмику чтения. Через них можем просто акцентировать внимание на последующую в диаграмме параллельность, или указать конкретно "fork...join", "конвейер...". Или же обойтись без спецвершин, если, к примеру, вся диаграмма задаёт схему конвейера процессов, где в каждом структурном блоке все действия параллельны, и они ожидают завершения обработки данных процессами из предыдущего структурного блока.

Кстати, фактически, в подобном случае Р-схемы будут отражать тот же сетевой график, в ациклической форме. Вот примерчик из "disruptor"-а:
Вложение:
input-activity.png [ 23.52 КБ | Просмотров: 24216 ]

Представить Р-схему-аналог несложно. Здесь один производитель сообщений и один прикладной их обработчик, но прежде чем он начнёт свою обработку данных, сначала сообщения должны быть сохранены и подготовлены, что возложено на ряд вспомогательных процессов, работающих параллельно. В качестве предиката м.б. показана вспомогательная информация, к примеру, номер процессора/ядра, к которому "привязан" процесс. Или же конкретные условия, например, показывающие какие именно сообщения из потока будет обрабатывать процесс, и т.п. Причём подобная схема может отражать лишь часть общего конвейера, к примеру, после прикладной обработки сообщения могут быть переданы дальше на вход другого конвейера. Отсюда важное свойство Р-схем - их структурность, что позволяет отразить как общую колбасу, так и порезать её на части.
И пример самого производственного сетевого графика:
Вложение:
r_set.PNG [ 40.04 КБ | Просмотров: 24216 ]

Насколько применимы частные методики из проектного производства для организации исполнения программных процессов как в примере выше, типа определения критического пути, понимание фиктивной работы и т.д., методики для оптимизации и т.п. - однозначно сказать непросто. Всё решает семантика реализации очереди сообщений (в данном случае), в программных процессах проблемы со своими особенностями, но схожесть с производственными циклами имеется, в т.ч. и, в целом, с пониманием деятельности (это на счёт "...не только опыта этой сферы, но и производства материального...").

Или параллельные процессы мы можем выразить как-то так:
Вложение:
r_proc.PNG [ 2.29 КБ | Просмотров: 24216 ]

Что м.б. отражает некий применяемый текстовый формализм для декларирования процессов.


Как итог: Р-схемы определяют минимальный возможный и достаточный формализм, следуют принципам декомпозиции и полиморфизма, задавая максимальную однородность (уменьшая сложность) и навязывают "знать немногое о многом". При этом используется минимум технических элементов, не воруют драгоценные "чанки" и оставляют больше потенциала для освоения содержательной прикладной информации.

Моя симпатия к Р-схемам напоминает наблюдаемый виток спирали: когда начал бурно развиваться GUI-интерфейс в IT, была "3D-мания" его оформления: из-за "вау!" всё было объемным, выпячивалось и подчёркивалось, утолщённые линии, затемнения и тени. Сейчас возвращаемся во "flat": всё плоское, сдержанное, ненавязчивое, стильное, равномерное и однородное... Всё то же и в вэб-дизайне. Или когда пришло понимание того, почему в аскетичных вим/эмаксе на порядок удобнее работать, чем в монстрах-IDE, с их дурацкими тулбарами на пол-экрана, сплошными "деревянными" (в смысле в виде деревьев) всякими вьюверами, не говоря уже об остальной эргономике управления средой, хотелось монстро-строителей бить ногами. Сейчас можно наблюдать, что и до них инерционно докатывается осознание...

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

P.S. И, конечно, без соответствующего оргподхода к проектированию и разработке Р-схемы сами по себе мало значимы в общей технологии.