OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 17 Сентябрь, 2019 10:30

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 21 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Схемы в описании программ
СообщениеДобавлено: Суббота, 09 Февраль, 2013 18:46 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Тема предполагается для представления различных подходов к структуризации программ и инструкций к ним, нотаций для получаемых структур.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 27 Февраль, 2013 06:47 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Итак, восстановим сказанное в связи с редактором Ильченко (с уточнениями и исправлениями). Проблематику представления поведения очертил один из участников РСДН:
...
Буквально единицы лет назад в академических кругах научились делать "суперкомпиляторный анализ" императивного кода, до этого вообще был детский сад, представляющий из себя чуть продвинутую бета-редукцию над ФП.
Почему так медленно идёт движение в этой области? Любое ветвление в программе — это лишний множитель комбинаторного кол-ва вариантов исполнения, то бишь сложность анализа от сложности алгоритма — степенная. Современные компиляторы проводят анализ в самых простейших случаях до 10 уровней глубины, в сложных — дай бог 2-3. Исходники gcc открыты, можно посмотреть самому.
Понимаешь, из-за степенной природы происходящего, наблюдаемая вроде бы неплохая геометрическая прогрессия в росте мощщи железа ничего кроме пессимизма не вызывает. Ни ты, ни я не увидим "золотого века IT". Например, gcc в последних версиях медленно но верно догоняет MS VC по эффективности конечного образа. Именно поэтому gcc таки относительно скоро нагонит MSVC, что он его настигнет прямо в точке насыщения возможностей, выжимаемых из машин разработчиков.
Это я всё к тому, что в течении ближайших 10-20 лет никакое самое вылизанное ФП по эффективности не догонит аналогично вылизанный императив даже близко.
На плюсах я сижу неплотно лет 20, плотно более 15 лет. Все их достоинства и недостатки собственной задницей ощущал не раз, так же как знаю как с ними бороться. Я могу выжимать из машины максимум, умею это и люблю. Помимо выжимания, есть определенные способности находить нетривиальные ошибки даже в чужом коде. Считай, у меня в сформировалась некая статистика по причинам всех этих ошибок.
Самые популярные, ес-но, не те ярлыки, которые навешивают на плюсы — типа выхода за границы диапазонов. Самые популярные сегодня — это неверное представление о работе собственных многопоточных программ, иногда откровенные гонки. Причем, эти гонки не из-за непоходимости разработчиков, ес-но, а из-за всего здесь обсуждаемого, из-за скрытого неявного поведения/зависимостей, которое в реальном коде образуется немыслимыми сочетаниями сценариев. Обычный разработчик уже на глубину более 3-х уровней зависимостей смотрят с ооочень большим трудом и не часто. В идеале хотелось бы 1 уровень. И мне/нам обсуждаемые языковые ср-ва помогут заметно сэкономить на отладке. А если брать предлагаемую банальную иммутабельность — наоборот, добавит работы и снизит эффективность решения.
- возможно, на взгляд специалистов в теории деятельности (алгоритмизации, в частности), он не всё существенное учёл, ну пусть специалисты и выскажутся...

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

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

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

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

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

Приложение того или иного подхода к программам требует:
    * выработки понимания программ как систем задания поведения исполнителя;
    * увязки пониманий исполнителя для ЧТО-моделей (управляемого целями, декларативного, интеллектуально[-имитирующе]го) и для КАК-моделей (управляемого способами, императивного, алгоритмического).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 27 Февраль, 2013 06:57 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Ну и теперь безотносительно к семантике - каков м.б. "синтаксический базис" представления? Рассуждая для графовой формы записи, можно предложить такой состав классов структур графит-схем:
    * маршрутная — такая, что схема есть устремлённый (аранжируемый, сводимый) граф, планарный (без пересечений при укладке на плоскости) либо нет;
    * древовидная —такая, что схема есть дерево, каждая ветвь которого м.б. ребром или маршрутной подсхемой с разветвлением/соединением их через ОС-узлы, а также, возможно, «прошивкой» дерева и/или сращением двух и более деревьев;
    * сетевая — такой, что схема есть конечное множество вершин с конечными чис­лами входов и выходов, причём входы и выходы м.б. либо связаны попарно (при­надлежа в паре одной или разным вершинам), либо не связаны (временно присо­единяясь к вершинам-туннелям).
Предполагается, что в этом составе можно представить любые практически тре­буемые схемы. Разумеется, желательны компетентные оценки (от специалистов, прикладывавших теорию графов к представлению программ).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 27 Февраль, 2013 07:20 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
С учётом сказанного здесь, можно конкретизировать. Так, в ДАЛВЯЗ фактически определены "ордер-блок-схемы" как разновидность структур маршрутного класса.
Целесообразные ограничения возможны и для структур древовидного класса.

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

Ну, большинство их предложено не мной... :) и даже не в рамках различных "исчислений графов"... ибо та же ЕСКД сформировалась ещё и до видеоструктур Дейкстры...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 19 Май, 2013 06:21 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
В своё время поток управления (варианты использования, маршруты) алгоритмического процесса (программной процедуры) структурировался у меня так:
Вложение:
Рис A3LS ГрафитМод Схема развёртки-свёртки маршрутов (ИС-процедура).png
Рис A3LS ГрафитМод Схема развёртки-свёртки маршрутов (ИС-процедура).png [ 416.05 КБ | Просмотров: 12514 ]
- можно, конечно, было "допилить" и под дополнительные входы, но показалось достаточным для общего представления (а допвходы всё равно лучше вводить в рамках какого-то принципа "метаструктуризации" алгоритма - "дейкстрального" или "силуэтного").
Здесь, в общем-то, представлены и идеи "упаковки дерева в устремлённый граф", описанные в докладе Ермакова-Жигуненко. Собственно, мысль Ермакова о развёртке в дерево и послужила толчком к такой модели.
Синтаксис развилок отражает в свёрнутом виде ту же семантику, что развёрнута в синтаксисе кейса SFC Editor. Ну или здесь.
В отличие от "дерева юзкейсов" здесь, эта схема построена не как "ставшая", где все маршруты идут из общего корня (и нелинейность множественная, "сразу для всего"), а как "становящаяся", где есть только ветвления, существующие в алгоритме (по тому же принципу, что и структура Крипке). Главный (по крайней мере, физически) маршрут идёт вертикально, поэтому особо не выделен (понятно по аналогии с "исчислением маршрутных слепышей"). Разумеется, логически он быть главным не обязан - по семантике алгопроцесса может вообще оказаться, что два и более маршрутов равнозначны. Поэтому принцип "ставшей" организации тоже рулит (кстати, возможно их сочетание, как там на самом деле и есть).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Схемы в описании программ
СообщениеДобавлено: Четверг, 05 Декабрь, 2013 14:39 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Пока вкратце о новых размышлениях PSV100 как здесь: viewtopic.php?p=84205#p84205 (и далее), так и в Карантине... :)

Выделено у Усова о лексике хорошо, и в своих решениях по "системе языков" стремлюсь учитывать. Цель именно поддержка массового производства данных... но с учётом не только опыта этой сферы, но и производства материального... например, переданного Грабиным: http://forum.oberoncore.ru/viewtopic.php?p=54622#p54622... Где схемы - не самоцель, а средство "проектного производства"...

От граф-схем можно для "компактификации" переходить к структурным скобкам, как в этом примере, допустим. Трактую их как своего рода таблицы.

Существенна в контексте сказанного новая дискуссия на сайте communicay вот отсюда:
http://compiler.su/programmirovanie-bez-programmistov-eto-meditsina-bez-vrachej.php, коммент от 2013/11/16 11:24, автор: Noname писал(а):
Дракон относится к средствам помогающим понять возможную последовательность действий работы (преобразования) базовой информации, но наличие фреймворков с низкоуровневыми библиотеками реализации некоторых действий позволит приблизить к использованию его в прагматической деятельности, а наличие или отсутсвие в визуальном представлениии явно блок схем (пример конструктор программ Hiasm) не сильно принципиально.
- и дальше там спорят о роли схем. И важные сопоставления делают с материальной инженерией... только надо... системнее...

И ещё: быть может, чтобы не городить зависимости элементов, надо с самого начала следовать единому подходу к системе? и может, это и есть главный результат развития Р-технологии (благодаря чему им удалось создать среду, поддерживающую не только "единую методологию разработки" - что очень правильно, думаю! :) - но и оргсистему разработки)?.. Это уже и к вопросам, затронутым здесь: http://forum.oberoncore.ru/viewtopic.php?p=84240#p84240 (и в следующем посте).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Схемы взаимодействия процедур
СообщениеДобавлено: Среда, 18 Декабрь, 2013 17:53 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Недавно сказал не совсем точно - схемы взаимосвязей типа желаемых Прохоренко и igor, в принципе определил давно. Пример для частного случая можно было найти здесь: http://forum.oberoncore.ru/download/file.php?id=1791. Но нужно сказать вот что.

А. Синтаксис в примере старый, "силуэтно-ограниченный", он не позволяет выразить всё оптимально. Уже давно использую другой, основанный на лио-расширении. Там получается не устремлённая топология, а сетевая в пределе, что не проблема - выводится графит-методом с соответствующей спецификой. Ну и графит-сеть здесь м.б. двумерной, что позволяет на одном уровне расположить те процедуры, которые только вызываются вышестоящими в иерархии реализации и/или сами вызывают нижестоящие (но не друг друга и не на несмежных уровнях при строгой иерархии). Т.е. решается задача:
igor в viewtopic.php?p=28837#p28837 писал(а):
... чтобы обрести ясность что делает та или иная процедура, и как она используется в самом модуле. ... понять какие из них являются ключевыми, а какие служат лишь для того, чтобы обеспечить реализацию этих ключевых процедур.
...
- т.е. программа представляется как "решётка" из процедур.

Правда, есть одно "но" - зависимости надо прослеживать по "разъёмам", как обычно в ЕСКД-сетях. Решений, чтобы "наглядный рисунок скрывал" ((С) П. Алмазов) как можно меньше, два:
    * выполнять снятие кросса (разгруппировку его линий на отдельные связи) - при этом пересечения, если они есть, будут явными;
    * показывать зависимости над кроссом (например, как в табличных процессорах) - но тоже организованной сетью связей, а не "по кратчайшим", как у Рейсса в FIELD, что Тышов воспроизвёл.
В любом случае получится на плоскости, как у Вирта в "Проекте Оберон" примерно (допустим, на Рис. 2.2, 12.6). Классика она и есть классика... :) Ну а как в пространстве - возможное решение недавно Дмитрий_ВБ предложил: http://forum.oberoncore.ru/viewtopic.php?p=83913#p83913.
Только подробнее структурно, потому что даются и вызовы, и возвраты.
Расширение позволяет показывать, кроме обычного вызова/возврата, также внешний, порождение/снятие, конструкцию/деструкцию. Знай только символику изобретай... :)

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

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

А вообще штука полезная... получается "графический инспектор кода" в части структур управления. Например, можно быстрее получать ответ на вопрос вида: "Вот я ставлю палец в эту точку <на каком-то маршруте - В.Ж.> и спрашиваю: Какой последовательности событий <при дальнейшем следовании - В.Ж.> я могу ожидать?" ((C) И. Ермаков)
Только в составе продуманной системы представлений кода... ибо есть ещё части структур данных и исполнителя... и нужно системировать. Некоторые замечания здесь: http://forum.oberoncore.ru/viewtopic.php?p=84856#p84856.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Схемы в описании программ
СообщениеДобавлено: Четверг, 19 Декабрь, 2013 19:45 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 368
igor писал(а):
... чтобы обрести ясность что делает та или иная процедура, и как она используется в самом модуле. ... понять какие из них являются ключевыми, а какие служат лишь для того, чтобы обеспечить реализацию этих ключевых процедур.
...

Прежде всего, это значит, что формализм самого языка программирования такого соответствующего качества, если он не может обеспечить порядок. В некоторых языках воюют до последнего, оставляя даже для комментариев потенциал структурности, как окончательный рубеж фронта. Пример для Хаскеля (отсюда):
Код:
-- | Little example
module Hello(
    -- * Introduction
    -- | Here is the little example to show you
    -- how to make docs with Haddock
   
    -- * Types
    -- | The types.
    T(..),
    -- * Classes
    -- | The classes.
    C(..),
    -- * Functions
    helloWorld
    -- ** Subfunctions1
    -- ** Subfunctions2   
) where

...

Цитата:
...
Комментарии со звёздочкой создают раздел, а с двумя звёздочками – подраздел. Те определения, которые экспортируются за комментариями со звёздочкой попадут в один раздел или подраздел. Если сразу за комментарием со звёздочкой идёт комментарий со знаком “или”, то он будет помещён в самое начало раздела. В нём мы можем пояснить по какому принципу группируются определения в данном разделе.
...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Схемы в описании программ
СообщениеДобавлено: Четверг, 19 Декабрь, 2013 19:49 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 368
Владислав Жаринов писал(а):
...
Там получается не устремлённая топология, а сетевая в пределе, что не проблема - выводится графит-методом с соответствующей спецификой.
...
- т.е. программа представляется как "решётка" из процедур.
...
* выполнять снятие кросса ... - при этом пересечения, если они есть, будут явными
* показывать зависимости над кроссом ... - но тоже организованной сетью связей, а не "по кратчайшим"
...
В любом случае получится на плоскости... Ну а как в пространстве - возможное решение недавно Дмитрий_ВБ предложил
...
Выводить-то можно, но вручную... столько надо заполнять для небольшой, в общем-то, программы
...
Автоматизировали. И тогда упрёмся в то, что схема всех аспектов взаимодействия процедур будет весьма объёмной. Так что надо реализовать прежде всего составление выборочное
...
Только подробнее структурно, потому что даются и вызовы, и возвраты.
Расширение позволяет показывать, кроме обычного вызова/возврата, также внешний, порождение/снятие, конструкцию/деструкцию. Знай только символику изобретай...

И плюс не забыть, что на функции также нужно смотреть и как на редукционные подстановки. В результате, вместо программирования, вынуждены рисовать "структуры Крипке", даже с автоматизмом нужные лишь бюрократическим субъектам для формальностей, или для презентаций со спецэффектами.
Владислав Жаринов писал(а):
... получается "графический инспектор кода" в части структур управления. Например, можно быстрее получать ответ на вопрос вида: "Вот я ставлю палец в эту точку <на каком-то маршруте - В.Ж.> и спрашиваю: Какой последовательности событий <при дальнейшем следовании - В.Ж.> я могу ожидать?"...

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Схемы в описании программ
СообщениеДобавлено: Четверг, 19 Декабрь, 2013 19:55 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 368
Владислав Жаринов писал(а):
...
И ещё: быть может, чтобы не городить зависимости элементов, надо с самого начала следовать единому подходу к системе?
...

Связи между элементами не исчезнут, а вот единый подход в организации управления этими связями, имхо, самое главное. Например, проблемы ER-диаграмм, затронутые здесь, решаются кардинально - отказом от ER-схем (как способ первичного создания структуры БД) и "программированием БД", также как программируется всё остальное в проекте. Когда объектов в БД далеко не одна сотня, они требуют модульного разделения и объединения по логическим связям, которые не всегда выражаются только лишь через "master-foreign key", к тому же прямых технических связей внутри БД может и не быть, и отношения между элементами образуются через прикладное приложение, использующее БД. И до сих пор для программирования БД нет адекватных инструментов. Лично я предпочёл бы удобный текстовый редактор, где бы была реализована поддержка SQL-кода на одних и тех же принципах как и для остального не-SQL кода, например, как здесь (скриншот редактора из проекта Light Table). Для интерактивной работы куда удобнее не наблюдать кучу квадратиков с лесом линий, а, скажем, быстро просмотреть структуру конкретного модуля (обобщённо, в виде списка содержащихся объектов), открыть исходник, например, таблицы (в виде текста DDL-оператора "create table ..."), при необходимости открыть рядом документацию по таблице, связанный исходник "домена" выбранного столбца, тексты операторов "create index ...", список объектов, которые определяет данная таблица (индексы, триггеры и т.д.), список объектов, которые используют данную таблицу (зависимые таблицы, хранимые процедуры) и т.д. и т.п. Общий анализ БД можно выполнять (кроме DB-IDE, а качественных IDE для БД нет) на основе HTML-документации в стиле javadoc и т.п. (например, как pldoc), где все связи, фактически, сведены к табличному представлению. А некоторые, ощущая потребность в системности, пытаются продвинуться дальше, и делают попытки отражать связи не только внутри БД, но и между БД и внешним прикладным кодом, оперирующим СУБД (например, как в HyperSQL).

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

Отсюда:

- важен единый однородный подход;

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Схемы в описании программ
СообщениеДобавлено: Четверг, 19 Декабрь, 2013 20:19 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 368
Владислав Жаринов писал(а):
...и может, это и есть главный результат развития Р-технологии (благодаря чему им удалось создать среду, поддерживающую не только "единую методологию разработки" - что очень правильно, думаю! :) - но и оргсистему разработки)?..

Насчёт Р-схем. Вспомним про человеческие "чанки" (отсюда - Графика или текст: какой язык нужен программисту? Владимир Зюбин):
Цитата:
...
Психология запоминания и критерии оценки языка

Давно подмечено, что для успешной разработки языковых средств и определения критериев их оценки требуются определенные познания в области психологии. Эта мысль присутствует в трудах А. Ершова, У. Дала, Э. Дейкстры, К. Хоора. Исследования в области психологии программирования [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
mental-bazis_html_m541b40a6.gif [ 118.6 КБ | Просмотров: 12124 ]

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Схемы в описании программ
СообщениеДобавлено: Четверг, 19 Декабрь, 2013 20:38 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 368
И если позволить здесь продолжить речь по поводу Р-схем, то не помешает обобщить принципы возможной Р-технологии на сегодня. Ибо сейчас мы можем наблюдать лишь отдельные, в определенных частных аспектах попытки подойти к процессу разработки информационных систем полиморфно.

Опять же, для начала вспомним Седова. Его ключевые тезисы:

- использование формализма, близкого к терминам решаемой прикладной задачи. Роль машинного ЯП общего назначения должна быть максимально приближена или сужена до задач непосредственного управления этой машиной и служить в качестве мостика между прикладным формализмом и "низкоуровневым" стэком данных и алгоритмов. Выражаясь по-современному: основная прикладная разработка - через DSL (domain specific language);

- задействование автоматизма для формирования DSL -> ЯП (имхо, самое главное);

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

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

В принципе, сегодня тоже не мало разговоров вокруг DSL, но единого системного подхода для его реализации пока не наблюдается (наиболее "продвинутый" в попытках DSL-строения, имхо, проект Nemerle, в основном представленный на RSDN). Если для стартового скачка взять идеологию Р-комплексов, то в современных условиях Р-технология должна иметь:

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

А ЯП на сегодня имеют реальную тенденцию для качественного развития, в т.ч. и в плане прикладного формализма. Даже небольшой шаг в сторону более привычных математических выражений - тоже качественный скачок. Например, ниже записи на языке Julia, который хоть и позиционирует себя как средство для инженерного программирования, но это вполне ЯП общего назначения (в примере: операции сравнения, функциональная запись (где "2x" => "2*x"), использование комплексных и рациональных чисел, а также пример "встроенного" DSL: r"a+.*b+.*?d$"ism - это регулярное выражение с опциями в соответствии с уже "прикладным" perl-стандартом):
Код:
1 < 2 <= 2 < 3 == 3 > 2 >= 1 == 1 < 3 != 5

map(x -> x^2 + 2x - 1, [1,3,-1])

(1 + 2im)*(2 - 3im)

2//3 == 6//9

match(r"a+.*b+.*?d$"ism, "Goodbye,\nOh, angry,\nBad world\n")

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


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

И, кстати, "три колонки" в Р-технологии определяются на разных уровнях моделирования и объединяются в соответствующие "контуры", а организация интерактивного рабочего места напоминает современные попытки "сode bubbles" и подобных семантических редакторов, где по требованию контекстно можно вытащить необходимую часть модели и расположить рядышком. Имхо, так практичнее.


- кроме схем необходимы стандарты или спецификации для всего текстового, более того, всё должно быть "текстовым". На эту роль, например, подходит Pandoc’s markdown - упрощённо, язык для документации, который позволяет конвертировать результаты в различные форматы, в т.ч. и представлять программный код (или иное) как "литературное программирование". На сегодня, как правило, разброд и шатание даже в базовых составляющих, таких как оформление текста в комментариях для генерации HTML-документации по коду, в системах багтрекера, управления проектами, вики и т.д. Здесь ещё пригодятся наработки эмакса (фактически, ставшие "стандартами") для работы с таблицами, задачами, в т.ч. и создание графических диаграмм (здесь пример), ведь и Р-технология, и Седов предполагают использование DSL-моделей не только в виде Р-схем/таблиц. Также нужны общие спецификации для визуального форматирования, как, например, в проекте EditorConfig - попытка организовать общие правила для форматирования программного текста для разных редакторов/IDE (которые д.б. расширены, и, кстати, ещё одно "просветление").

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

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

И такой подход позволяет реализовать как и удобный текстовый редактор, так и GUI-режим, включая и вэб, плюс имеется возможность в любой момент сформировать требуемый комплект документации (нужной версии, полный или частичный, со всеми программами, таблицами и схемами) в любом распространённом формате - HTML, pdf и т.д., или в промежуточный docbook, latex и т.п.;


- необходимы сами Р-схемы. Они более-менее представимы в виде текста, причём, повторюсь, схема может быть в любом месте, как модульная модель, так и часть какого-то комментария. Для схем возможны удобные методы построения по мотивам эмаксовых таблиц, ну и нет никаких ограничений для реализации типовой работы через мышь или сенсорный экран;

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

Думаю, что сочетание Р-схем и схематических таблиц не вызывает чувства "полиинструментальности". Они схожи внешне, через сами Р-схемы неплохо отображаются табличные данные, могут иметь схожие методы построения, имеют ряд общих свойств, к примеру, и в таблицах (не только "схематических"), и в Р-схемах есть возможность выражать предикаты через линию/дугу (что, кстати, хороший плюс для возможности представления условий не только в алгоритмах), и т.д. Во всяком случае, нет чувства uml-зоопарка. Р-схемы применимы на разных уровнях проектирования, код на ряде языков действительно нагляднее в виде схем (причём это С/Pascal-подобные или а-ля asm, ФЯП лучше читаются в виде текста, а некоторые языки сами имеют возможность для двумерного представления, как Epigram). А также и Седов утверждал то, что такая агрегатная модель как таблицы решений служит основой не только для сведения всех данных, но и для вычленения конкретных связей и их анализа. И здесь Р-схемы м.б. помощником для выражения варианта моделирования.
Да и в любом случае, рядом со схемами будут распространены таблицы, в том или ином виде. И набор -- Р-схемы, таблицы, схематические таблицы -- необходимый и достаточный, в качестве универсального, и при этом однородного;


- ну и самое главное, нужен формализм для построения схем и таблиц. Наличие удобной возможности для ручного их формирования является обязательным, но недостаточным для полного автоматизма "DSL -> ЯП", цель которого не только упрощение и ускорение, но и контроль.

В какой-то степени, необходимо дальнейшее развитие идей Nemerle. Приведу пример из этой области (конкретно, отсюда):
Вложение:
statechart.PNG
statechart.PNG [ 28.67 КБ | Просмотров: 12122 ]

Здесь в качестве атрибута/аннотации для класса указан прикладной DSL -- код в скобках "<#...#>", что есть "инородная инъекция" для базового ЯП, где в виде прикладного формализма описан некий простой автомат (рядом представлена соответствующая ему UML-диаграмма). Во время компиляции программы будет обработана эта инъекция, выполнятся все проверки, и класс автоматически дополнится недостающими данными и методами, реализующими автомат. Ребята из Nemerle идут дальше, пытаются организовать поддержку DSL и в IDE, также, как и для основного ЯП (подсветка синтаксиса, автодополнение, динамический контроль ошибок и т.д.). И нужен ещё один подобный шаг в сторону поддержки и "визуального". Для этого нужны строгие формализмы. Например, для разбора произвольного текста (в т.ч. и для DSL) имеются наработанные решения, как EBNF/PEG-грамматика, с возможностью разделения на модули/классы с обобщением и повторным использованием. Техники программного формирования кода на самом же ЯП тоже отлажены (лисповое квазицитирование применимо и для языков а-ля мэйнстрим тоже, пример на Scala). А вот для формирования "визуального" у меня пока нет чёткого понимания.
В частности, Р-схемы и таблицы (в т.ч. и "схемные") имеют много чего генетического общего. Р-схемы вменяемо выражаются в виде табличного представления (в т.ч. и отцы-основатели сами приводили примеры). Но это не основная сложность. Желателен формализм, который выражает не только то, что необходимо показать, но и отражающий связь между источником (базовый программный код, код DSL, бинарные или другие данные модели, если прикладная модель не в виде текста) и визуальной моделью (схемой, таблицей). Такой формализм должен упрощать и дать возможность наладить, фактически, оперативную двустороннюю связь: код/DSL <-> схемы/таблицы. Как вариант, я сейчас анализирую возможность применения Datalog (пример его использования для задач анализа программного кода, здесь презентация).
Короче говоря, над этим вопросом ещё нужно поработать.

Здесь ещё нужно уточнить. Источником для визуальных моделей может быть что угодно (DSL, в виде текста и нет, код на ЯП). Нужна и обратная связь, из схем и таблиц необходимо формировать целеуказания для формирования кода на ЯП, или другой DSL. Причём, к примеру, те же таблицы м.б. "внешними", подготовленными в каком-нибудь экселе. При этом может существовать эффект обобщённости, например, в теме про схематические таблицы продемонстрировано, что алгоритм можно выразить через Р-схему, алгоритмическую таблицу (или через несколько связанных таблиц), схематическую таблицу, плюс может быть "прикладная" таблица решений, в типовом или в каком-то специальном варианте, а также и Р-дерево решений.
Всё это желательно учитывать в потенциальном формализме для выражения "табло-схем", причём он должен упрощать, как BNF/PEG для разбора сложного текста, и быть применимым на уровне регулярных выражений или SQL-запросов.

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


Итого:

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Схемы в описании программ
СообщениеДобавлено: Четверг, 19 Декабрь, 2013 20:46 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 368
Владислав Жаринов писал(а):
...
Цель именно поддержка массового производства данных... но с учётом не только опыта этой сферы, но и производства материального... например, переданного Грабиным: ... Где схемы - не самоцель, а средство "проектного производства"...

Кстати, вопрос, более чем актуальный. Прежде всего, нужно учесть, что в реальной жизни есть существенные предопределяющие нагибалки, такие, как стандартизация, сертификация, и прочая бюрократия. Пример: разработка ПО авионики, где имеется и обратная сторона медали -- "Отладка самолета? Это очень просто!" --
Цитата:
...
P.S. Спрашиваете, ну а что дальше, как летать? А все очень просто – в FAQ появилась очередная строчка, которая советует не допускать свободного вращения колес после взлета дольше минимально необходимого времени, а в случае возникновения ошибки TR – сбросить потом ошибку после приземления, и спокойно летать дальше.

P.P.S. А производитель двигателей сказал, что они, конечно, немедленно выпустят обновленную версию ПО, только займет это год – полтора, так как такое ПО проходит через строгие и длительные процессы разработки и сертификации (и это не шутка).

Однако, есть и другая реальность: Как у нас пишут ПО для космических аппаратов, подобные реалии подтверждают и ряд комментариев к статье насчёт разработки ПО авионики.

В общем, стоит учитывать ряд внешних определяющих факторов, к тому же есть уже исторически устоявшиеся модели и методологии в той же инженерной области. И поэтому сегодня, в отсутствие Р-технологии, вынуждены лепить её суррогатные "подменители", типа FUSED - Formal United System Engineering Development (анонс, сайт, презентация). Насколько я понял, это клей для манипулирования разными техническими моделями. Возник проект где-то под боком NASA (вроде как). Есть базовые спецификационные модели, в частности, в виде таблиц Excel-я, используются 3D-модели в каком-нибудь CAD, далее применяются модели для проверки лётных характеристик (тестовая эмуляция), и т.п. Решается важная и сложная задача - автоматизм преобразования между моделями. Для этого применяются некие мета-модели, где определяются форматы технических моделей и правила построения одних моделей из других. Используется какая-то графика, квадратики с содержимым и со связями, что из чего возникает. В распоряжении имеется некий свой функциональный ЯП, со специализированной системой типизации, чего-то можно програмлять, плюс внутри мета-моделей прикладные специалисты задают функциональные выражения (формулы). Мета-модели сохраняются в XML-простынях, и есть набор инструментов, который выполняет верификацию технических моделей и генерацию новых на базе существующих. Инструментарий расширяемый, т.е. задумывается открытая адаптация под широкий набор инженерных сред.

Стоит отметить, что разрабы заявили:

- они отвергли попытку применить единый мега-мета-супер формализм, через который проектировать всё. Пошли по пути адаптации к существующим;
- они отвергли попытку использовать уже имеющиеся стандартные методологии, такие как UML (что не удивительно).

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Схемы в описании программ
СообщениеДобавлено: Понедельник, 23 Декабрь, 2013 15:54 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9139
Откуда: Россия, Орёл
PSV100 писал(а):
Однако, есть и другая реальность: Как у нас пишут ПО для космических аппаратов, подобные реалии подтверждают и ряд комментариев к статье насчёт разработки ПО авионики.


Касательно этой статьи: плохой эффект от неё в том, что читатель сразу делает вывод обо всей нашей косм. отрасли. И автор ни одним словом не развеивает этого впечатления.

Специфика нашей косм. отрасли - очень много совершенно независимых предприятий (хотя это сейчас меняется в сторону интеграции, как известно; возможно, что дойдёт и до некоторой унификации технологий программирования. Попытки работы экспертных групп в этом направлении уже были: http://i.ermakov.pw/pubs.php#space).

Культура программирования у этих разнороных предприятий тоже совершенно различная. А автор статьи побывал только в одном из них (может быть, НПО Лавочкина, ИМХО) - и даёт своим "мемуарам" такое громкое название. Всякие желчно настроенные субъекты эту его статью уже затаскали по форумам, в том числе политического характера.

Возьмите НПО Решетнева с их технологией полного цикла, где внизу лежит Модула-2 (http://www.inr.ac.ru/~info21/pdf/AAKpaper2006.pdf и http://www.inr.ac.ru/~info21/info/koltashev.jpg).

Возьмите РКК "Энергия", где за ПО отвечают команда академика Микрина (у них базовые кафедры в МГТУ им. Баумана).
У них хорошо поставленный техпроцесс на базе современных инструментов (UNIX-экосистема GCC, системы контроля версий.. ОС на МКС используются QNX и Windows), своя архитектура на основе изолированных процессов и протоколов обмена сообщениями и т.п.

Возьмите НПЦ АП с их Графит-Флоксом, с которым они имеют техпроцесс надёжной разработки сложных СУ на железе уровня не самого сильного микроконтроллера.

Возьмите НПОА Семихатова, где люди разрабатывают свои DSL на базе конечноавтоматных формализмов.

.....


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Схемы в описании программ
СообщениеДобавлено: Понедельник, 23 Декабрь, 2013 15:56 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9139
Откуда: Россия, Орёл
В остальном: спасибо за много интересных мыслей. Лично я читаю внимательно всё, что Вы пишете.
Дискутировать и развивать беседу, к сожалению, не имею возможности.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Схемы в описании программ
СообщениеДобавлено: Вторник, 24 Декабрь, 2013 08:38 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Почти аналогично. :) С привязкой к космической и конкретно борто-управляющей тематике изложил здесь: viewtopic.php?p=84912#p84912 (и в следующем посте). Тут кратко о том, что по существу вытекает из сказанного PSV100 с учётом естественной системологии и теоретической информатики (как их на сегодня понимаю в ограничениях квалификации "представителя заказчика информатизации" :wink: ). Предварительное замечание: далее рассмотрение именно и только с позиций теории систем, просьба не разводить дискуссий по личным предпочтениям тех или иных из представляемых вариантов объектов, процессов, явлений (полагаю, предел можно считать обозначенным здесь; поэтому вообще и обсуждаю тут). Итак:

А. В основе представления о деятельности как предмете труда (построения, проектирования) - всегда экономика. В определении по схеме Винера для кибернетики - т.е. как наука о труде живом и машинном. :) Иначе говоря, допущение, что для "искусственной среды" реализации экономические категории перестают действовать, мягко говоря... слишком сильное... :wink: :|
Имеется в виду - не для процесса производства этой среды (разработки железа/ПО в частности) - это-то само собой. А именно внутри самой искусственной среды (например, программно-аппаратной платформы... включённой, между прочим, в "методический комплекс" наряду с документацией для применения людьми... хотя бы и опосредованного/ограниченного, как в случае с РН и тем более - с системами для применения по типу "выстрелил и забыл").
    Что отсюда самое важное? У исполнителя деятельности всегда есть надсистема в составе: институциональная среда; механизм баланса потребностей/наличия ресурсов; субъекты владения. Ну, как наглядный пример - в соцэкономическом смысле Усов говорит "государство-рынок-собственники" для конкретной организации общества. Его определениями общими и можно пользоваться.
Конкретика нужна прежде всего для второго. Типов балансировки два: планирование спроса/предложения на ресурсы и согласование между потребителями/производителями. Рынок есть вариант второго типа механизма. Это действует и в искусственной среде (например, реализуется в управляющей программе). Развитая среда представляется иерархической моделью (пример у Овчинникова в Гл.8). Как в ней организовать согласование? Опыт социальной реализации подсказывает, что чисто плановые и согласующие решения "не работают". Вникая в типизацию АИС Овчинниковым, можно предположить, что он склоняется к какому-то сочетанию типов. Усов же предлагал логичный вариант - чем ниже по иерархии, тем меньше планирования и больше согласования. Это можно считать за одно из базовых условий моделирования системы деятельности (независимо от исполнителя).
Далее, деятельность ведь реализует какое-то назначение (системотехнически - {целевое/функциональное; главное/вспомогательное}). А откуда оно берётся? Если опять же не игнорировать логику и историю, определяемую полным ЖЦ системы, то от таких типов субъектов: создатель; владелец; система.
    Тут нагляден пример от Заде: "если некто имеет молоток, то ему везде видится гвоздь". :) Однако создатель молотка мог не предвидеть, что владелец будет его применять не только к гвоздям и не только для забивания... а сам "молоток", ежели он система достаточно высокого уровня развития (в 7-уровневой иерархии), может, как в "Мойдодыре" или "Федорином горе" Чуковского, и сбежать от владельца... или заняться "социальной инженерией"... или ещё чего... :wink: И, между прочим, если учитывать и понятие метасистемы, то и система низкого уровня развития может примениться "по-своему"... и это в рамках мета-назначения не будет "отступлением от ТЗ"... :) тут уже как литературный пример годится... правильно, "Умные вещи" Маршака...
Прежде всего, системно можно выделить типы назначения деятельности: исследовательская, практическая, образовательная. Разумеется, конкретная система-исполнитель может их сочетать в своей деятельности как целостной системе.

Б. Теперь к представлению деятельности. Сначала договоримся применительно к топику. Схема - это форма представления некоей структуризации содержания. И д.б. эквивалентные формы текстового и табличного родов. Т.е. не "чертёж есть абстракция более высокого уровня", а есть абстракции разных уровней, и есть разные формы записи одной и той же абстракции (равно как и конкретики). Системно, по-моему, так. Именно тогда можно задать: "... стандартный универсальный способ их расширения (развития), алгебру конструирования ... из простейших элементов как базовых, так и полученных в результате их расширения,..."
    Илья говорил в своём докладе из Судака, что нужно уметь переходить между базисами. Понимаю это - как в пределах рода, так и между родами. Ну и PSV100 подтверждает сие, записав некую модель, данную как Р-схема, на текстовом языке в этом посте.
А что это за структура?
Экономические категории определяют модельную структуризацию деятельности на: предмет труда; средство (субъект + орудие) труда; собственно труд. Как представлять третье, определяет подход к образовательной деятельности. Если принять деятельностный, то имеем архитектурную модель Гальперина, описанную современно, допустим, Атановой и Пустынниковым в п. 1.2. Это для "живого труда". А так, чтобы можно было и для машинного? Тут, полагаю, годится "базис трёх абстракций" Кауфмана: данные; связывание; операции. Для меня его применение в таком соотнесении с экономикой (когда связывание идёт через средство труда, исполнителя) было изначально плодотворным. Но. По мере осмысления появилось интуитивное ощущение. Что в общем случае связующей будет выступать любая из категорий. И определяться это может уровнем моделирования...
Далее. Какие возможны подходы к раскрытию структуры деятельности в базисе категорий? Ведь надо, чтобы и целостность сохранялась... Есть мнение, что такие: процедурный; функциональный; объектный. Так и на уровне "математической алгоритмизации", так и на уровне "технологической" (где "парадигмы моделирования" переходят в "парадигмы программирования": <императивно|"собственно">-процедурная; процедурно-функциональная; процедурно-методная).
Как выбрать? Объектная кажется наиболее естественной. Но есть один момент. Парадигмы создаются (и принимаются) людьми, мышление которых определяется... правильно, экономическими условиями. И если создатели Симулы в 1967-м мыслили назначение объектности одним образом, то предложения гражданина Буча и др. - скорее всего, продукт экономики "после золотого стандарта" (особо это относится к "агентной" подпарадигме). Что имеется в виду в системном смысле? То самое, что в А - представление о сочетании планирования и согласования... Вот тут хорошо сказано, думаю:
PSV100 в viewtopic.php?p=84877#p84877 писал(а):
...
Теперь подход мэйнстрима, скажем, Java. Конечно, всё должно быть в классах, никаких там "алгоритмов". Тот же тип "Результат" будет выстроен в цепочку наследования, введены "свойства", сплошные методы "Get"/"Set" и т.д. Сразу же написаны "тесты" и успешно "пройдены". Более того, должен же быть полиморфизм (!!!, мы же современны !), срочно нужны ещё "интерфейсы" и их "реализации" (написаны "тесты" и успешно "пройдены"). А как же Dependency injection ? Срочно ваяем "фабрики", ваяем XML-конфигурации (матерясь на этот XML) или втыкаем "аннотации" в код, и т.д. и т.п. (нужны или нет здесь "фабрики" - думать нельзя, так промстандарты постановили, обо всём уже подумали за тебя ...)
В результате, "уравнение" размазывается на кучу методов и классов, и на разные файлы, в коде технических слов (сплошной мусор, "организованный" далеко не самым оптимальным образом) больше, чем "решения".
...
- кстати, ООП не зря названо "идеологией"... :) Ну, в Яве возможно, это ещё и от того, о чём Лаптев говорил - модуль отождествляется с классом...
    И то, что Усов предлагает по "техноалгоритмизации объектности" - результат осознания необходимости сочетания закономерного. Во всяком случае, понимаю это так. Дело в том, что процесс тоже имеет полный ЖЦ. Он в какой-то момент порождается по модели, "шаблону возможных процессов" ((С) Ермаков, Жигуненко) как экземпляр шаблонированного типа (раз уж объектность считаем естественной, будем рассуждать в её категориях). Затем изменяет свои состояния в заданном базисе (например, как у Рембольда на Рис. 8.7) и в некоторый момент снимается. Изменения состояния - тоже техоперации.
А про общую, инвариантную-то структуру деятельности за лесом вызовов у одних, редукций у других, наследований у третьих мы не забыли?.. :wink: А она такая по-прежнему, полагаю... и никакая парадигматика отменить этого не может... :) Или как?

В. И собственно о моделировании деятельности. Это, думаю, очень связано с родом инвариантного структурирования. Что имеется в виду? Да, рода сетей техопераций тоже можно понимать как "эквивалентные базисы". И надо уметь переходить от одного к другому. Но. Есть смысл подумать, зачем (а отсюда и когда). И вот какие мысли.
Сеть 2-го рода представляет взгляд на деятельность как в идеале ("завершённой производством" модели) планируемую. Ну должен ты, если состыковал техоперации-связи через элементы-"события", прописать условия наступления... Отсюда в ОПУП это широко использовалось. И сам считал планы именно в такой модели (для "сетевых графиков"). И вот что получается, если надо нетиповые вещи посчитать - приходится "наворачивать" порой... Какова возможная причина? События требуют "алгорасшифровки". Т.е. и связи сети - процессы-техоперации, и содержание элементов - тоже. Причём реально в элементах должны выполняться и операции над связями по изменению состояния процессов (что обсуждалось, например, для узлов "независимых параллельных действий" (НПД) языка блок-схем алгоритмов, РК- и МШ-языков). Это нужно специально оговаривать. Иначе такая роль элементов сети 2-го рода становится неочевидной (особенно для предметника). Заранее построенные соотношения можно вычислять (как, например, планы прохождения предметов труда по сетевому графику в ОПУП), а чтобы построить новые, иногда рациональный путь сразу не определишь. И так же в сетях Петри, например...
Тогда как сеть 1-го рода представляет деятельность как согласуемую. И предлагает прописывать не условия - а процессы (техоперации) согласования. В которых только и разрешено употреблять операции изменения состояния процессов. Планирование же можно учесть через порядок техпроцессов (4-уровневую иерархию исполнения, которую можно понимать и как состав типов процессов в контуре управления). Есть и математика планирования (тот же Афанасьев).
Что получилось в Р-схемах? Верно подмечено, что с однородными на разных уровнях структурами работать удобнее. В Р-модели принят 2-й род. Отсюда и структура управления процедур... приведена к сетевым графикам (операторы-связи, а элементы - грубо говоря, те же события). Что не всегда удобно.
Далее. В системе документации можно изображать структуру предмета документирования совмещённо, а можно разнесённо. И снова однородность облегчает восприятие при совмещении. А сеть 1-го рода оказывается совместимой с обычной структурой управления (оператор-элемент, связь-переход).
По отношениям. Модель "сущность-отношение" - это общий язык реляционного R-базиса. Разница между типами связей там в общем случае - только имя отношения, задаваемое построителем модели. Поэтому в таком языке вообще не нужно выделять типы связей для схемной записи. :) А нужно - реализовать в редакторе моделей показ только выбранных отношений (по именам).
Тут важно ещё что понимать? Общий FSR-базис - это не для "технологической" конкретики. Это математическая семантика. А для программирования/инструктирования уже задаём конкретные отношения. Которые надо различать по-разному в зависимости от модели. В Р-схемах различие представляется, как можно понять, определением узла (события).

По ОС-узлам. Они вообще имеют назначение прежде всего "над-модельное" - представить графически варианты организации модели. Ну и могут употребляться для той же однородности как представления ветвлений в структуре управления любого рода (ОС-ИЛИ) или "независимых параллельных действий" в сети 2-го рода (ОС-И/ИЛИ).

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

Ну и насчёт неопределённости и аппарата её формализации. В инженерной теме интересно вспомнили Никанорова. В то же время у теории множеств были проблемы в изначальных формулировках. Это обсуждалось у Успенского. А Зверев даёт иерархическую теорию множеств. По впечатлению, Никаноров со своими категориями двигался туда же... но неясно, насколько он учитывал математическую семантику... ИТМ же даёт возможность непосредственно отобразить множества и как графы (и по-своему определить классы топологий структур). Возможно, здесь и системность математики... и резерв для учёта психологии в образовании... И за счёт эквивалентного графового представления тоже. Кроме того, неопределённость формализуется и в логике. Предлагаемые три- и тетралогика прямо предназначены для этого. И здесь опять же надо с одной стороны найти наглядные представления, с другой - приложить к моделированию деятельности... Есть ли у квалифицированных аналитиков готовность?..


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Схемы в описании программ
СообщениеДобавлено: Вторник, 24 Декабрь, 2013 20:05 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 368
Илья Ермаков писал(а):
Касательно этой статьи: плохой эффект от неё в том, что читатель сразу делает вывод обо всей нашей косм. отрасли. И автор ни одним словом не развеивает этого впечатления.
...

Да, конечно, и в космической отрасли, и в авионике, да везде хватает и бардака, и гармонии. Собственно, я на этом и не акцентировал внимание. Основное, что хотел выразить:

- есть внешние предопределяющие факторы, как стандартизация;
- есть ограниченная применимость: 3D-CAD модель ("однородный" спец-DSL) заменить блок-схемой -- нецелесообразно, а вот склеивать инженерные модели программаторскими (но для человеков) -- то, что доктор прописал...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Схемы в описании программ
СообщениеДобавлено: Вторник, 24 Декабрь, 2013 20:11 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 368
PSV100 писал(а):
...В результате, вместо программирования, вынуждены рисовать "структуры Крипке", даже с автоматизмом нужные лишь бюрократическим субъектам для формальностей, или для презентаций со спецэффектами...

To Владислав Жаринов. Спасибо за очередной философский подборчик...


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

Действительно, необходимы представления и в предельной сетевой модели, и в "структуре Крипке" и т.д., есть и острая необходимость в зарисовке, прежде всего, выражая сущность семантики. Но для оперативной работы лучше подобные модели свести к аксиомам, и действовать производными теоремами.

Поэтому важно:

- диаграмма должна выражать только само существо дела (в прочем, это не только диаграмм касается);

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

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

Недавно смотрел фильм по "дискавери": "есть ли у нас свобода выбора ?" (что-то в этом роде). Был любопытный "технический" момент. Я немного пытался найти связанных материалов (пока неуспешно), наткнулся на статейку:
Цитата:
...
Да, нейробиологи показали, что работа мозга подчиняется определенным законам. Ясно, что ее результаты (мысли, эмоции и поступки) в принципе можно предсказать, если знать предыдущее состояние мозга и характер входящих сигналов. Выяснилось также, что некоторые решения, которые нам кажутся осознанными, на самом деле принимаются (или по крайней мере подготавливаются) бессознательно. Мы лишь после осознаём, что решение принято, и рационализируем его «задним числом», искренне полагая, что весь процесс шёл под сознательным контролем. В ряде экспериментов ученым по томограмме мозга удавалось предугадывать (хоть и далеко не со 100-процентной точностью) решения испытуемых за несколько секунд до того, как эти решения были осознаны самими испытуемыми. По-видимому, мозг вполне детерминистичен на макроуровне.
...

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Схемы в описании программ
СообщениеДобавлено: Среда, 25 Декабрь, 2013 18:59 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Черниговская, по-моему, говорит о тридцати... Кстати, она как раз исследует эти особенности мышления. Вот теоретическая информатика, как понимаю, тоже исходит из того, что надо детерминировать исполнителя, включая естественно-интеллектуального... только начиная с его архитектуры...

Вот с Вашими замечаниями что принципиальное связано, как мне кажется? Во-первых, решения за счёт чего могут получаться? Если в терминах генетиков, то механизмы подготовки м.б. "врождёнными" и/или "благоприобретёнными". Если для машины, то первые - это реализация в схемах и в ПЗУ, при подготовке используется и изменяемая командами (основная) память - регистры и ОЗУ. Вторые - это то, что позволяет взять данные из сенсорных/технических каналов связи, из ВЗУ в Рг/ОЗУ, там использовать/изменить и положить обратно. Во-вторых, откуда могут браться сведения для решений в принципе? Тут важно предположение Черниговской, что сознание всегда распределённо. И вот очень интересно - она пришла к этому в результате длительных экспериментов. А теперь вспомним этимологию слова: со-знание. Выходит, наши предки, творцы родного языка, понимали это?.. :wink: И может, надо о "детерминизме на макроуровне" рассуждать в том смысле, что взять человека как материально-информационную систему и подумать, какие у него сенсоры, эффекторы?.. Может, он в каких-то ситуациях берёт решение "прямым постижением" ((С) Усов) из метасистемы?.. Может, под-со-знание для этих целей и "врождённо-реализовано"?..

Это к чему? Любое сообщение (схема в частном случае) служит лишь актуализации "ментального опыта" ((С) М.А. Холодная) данного субъекта как со-знательного, т.е. если можно соотнести с уже образованными "ментальными структурами" (Анохин говорит "когнитомами", имея в виду, как понимаю, то же самое) - то субъект "понимает на уровне сознания" (распознаёт образ), если нет - то "на уровне подсознания", т.е. запрашивает у со-знающих... :) Отсюда критерии лёгкости будут субъективными - причём к обычным условиям вроде гипотезы "двойного кодирования" Солсо (соответствие формы сообщения удобной адресату для восприятия и оперирования в уме, а содержания - сложившимся у него смыслам) добавится ещё влияние формы и содержания сообщения на качество построения по нему "запроса к распределённой БД" такого, чтобы ответ было опять же удобно использовать (и не забудем, что она не в каждом случае откликается одинаково "охотно"... пожалуй, и замечание Евгения к этому имеет прямое отношение)...
Отсюда рациональность использования пространства - это не только (и не столько) физическая компатификация (миниатюризация предложений языка на носителе). Это прежде всего соответствие организации сообщений у адресата.
Кстати, именно поэтому "всякий текст нуждается в редактировании" получателем...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Схемы в описании программ
СообщениеДобавлено: Среда, 25 Декабрь, 2013 20:40 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 368
Владислав Жаринов писал(а):
...
А про общую, инвариантную-то структуру деятельности за лесом вызовов у одних, редукций у других, наследований у третьих мы не забыли?.. :wink: А она такая по-прежнему, полагаю... и никакая парадигматика отменить этого не может... :) Или как?
...

Если речь об имеющейся там цитате, то это типовой пример кривого "планирования" и "согласования". Примеры адекватных были в посте выше ("fork/join" и "конвейер").

Владислав Жаринов писал(а):
...Сеть 2-го рода представляет взгляд на деятельность как в идеале ("завершённой производством" модели) планируемую...
...Тогда как сеть 1-го рода представляет деятельность как согласуемую...
...
Что получилось в Р-схемах? Верно подмечено, что с однородными на разных уровнях структурами работать удобнее. В Р-модели принят 2-й род. Отсюда и структура управления процедур... приведена к сетевым графикам (операторы-связи, а элементы - грубо говоря, те же события). Что не всегда удобно.
...

Непонятно, каким образом впихнут в Р-схемы только "2-й род", особенно с учётом:
Владислав Жаринов писал(а):
...
Опыт социальной реализации подсказывает, что чисто плановые и согласующие решения "не работают". Вникая в типизацию АИС Овчинниковым, можно предположить, что он склоняется к какому-то сочетанию типов. Усов же предлагал логичный вариант - чем ниже по иерархии, тем меньше планирования и больше согласования. Это можно считать за одно из базовых условий моделирования системы деятельности (независимо от исполнителя).
...

Пример в "схематических таблицах" отражает такую модель "забивания гвоздей":
Вложение:
вбивание_гвоздей.PNG
вбивание_гвоздей.PNG [ 45.7 КБ | Просмотров: 11937 ]

где предусматривается в т.ч. и "согласование" - "удар по пальцам". В алгоритме рядом с обработкой сигнала есть и "assert" - "доска пробита насквозь". В примере вызова "закупки" выполняются параллельно (из-за кривого Р-редактора нет подсказок в виде спецвершины).

Особенности Р-схем:

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

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

Если взять базис:

- объекты, или лучше как в "базах": сущности, со свойствами;

- связи, или отношения, с атрибутами (отношения не существуют, поэтому они не сущности, это лишь семантическая окраска для понимания и представления);

- функции, или операции.

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

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

Ещё раз не забыть, что любая категория выражается через функцию...

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


P.S. Заметил, есть ещё вопросы в "схем-таблицах", но пока нет времени уделить внимание...


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 21 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB