OberonCore

С ООП огромная путаница.

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

Но в Симуле были апробированы несколько эффективных механизмов.
С инженерной точки зрения сразу было увидены преимущества этих механизмов: расширения типа данных, полиморфизма, виртуализации. В Смоллтоке их преимущества были подтверждены беспримерной на тот момент расширяемостью системы. Тут всё ясно. По этой линии мы имеем на сегодняшний день подход Оберона, ряд компонентных паттернов, т.е. некий инженерный инструмент, позволяющий хорошо разделять при разработке и гибко соединять при выполнении разные компоненты системы.

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

Кроме своего опыта. Те примеры крупных сложных комплексов из оборонки и проч., которые попадались лично мне в классике по программной инженерии, сделаны именно в таком стиле. Архитектуры комплексов ПО на Ada (а, видимо, именно на ней более 50% самой крупной критической распределёнки в мире) заточены именно на структурное проектирование.

Ещё раз: ООП - механизм разделения системы на компоненты и их коммутации, преимущественно. Остальное - от лукавого, преимущественно.

"Распределённые объекты" - вообще дурь. Давайте задумаемся: расширение типа, полиморфизм и виртуализация - это ПО СУТИ своей механизмы внутрипрограммные. Способ расширяемо выполнять вызовы, передавать параметры, с сохранением предельной эффективности.
Удалённый вызов - любой - по определению виртуален. Передача сообщения по определению полиморфна. Замена реализации удалённого сервиса вообще прозрачна изначально. Какое ООП, господа? Просто хочется не передавать параметром ID удалённой сущности, а имитировать объектное обращение к ней? Дурь.

Пардон за эмоции

Ну да, напр. в Обероне объектные принципы, если я верно понимаю спецификацию у Свердлова, можно проследить в следующих элементах:

* инкапсуляция - в управляемой видимости именуемых элементов (за счёт экспорта/импорта идентификаторов);
* наследование - в объявлении расширений типа запись (в т.ч. процедурных);
* полиморфизм - в логике работы оператора WITH - выбирается нужное течение процесса для динамического типа (фактически получившегося в предыдущих вычислениях).

Кстати, есть мысль - хотя над переводом работали не просто так люди - не трактовать ли "type guard" как "установление типа" - в смысле как действие (аналогично "установлению подлинности")?

А "методность объектов" вижу в реализации процедурных типов, в т.ч. как связанных с типом запись. Возможно, именно это я подразумевал (ещё не зная того), когда при МШ-записи процесса варки кофе Эдуарда в этом сообщении ввёл переменную-действие Наполнить в силуэты 2 и 3 и во вставку Напиться. Правда, сделано не по-программному, а "в лоб", через присваивание этой переменной той или иной формулировки действия , но если принцип в Обероне подобен - этот стиль в любом случае мне нравится больше, чем прятать код в объекты с конструкторами/деструкторами.
А можно было, как я вижу, и по другому - выбирать разные формулировки прямо в Напиться переключателем по установленному в силуэте значению переменной выбора... но меня интересовало получить более компактный алгоритм Напиться

И всё это без упоминания объектов... и более логично.
И вот хотелось бы ещё наложить на текстовые объявления графический язык визуализации, что начал продумывать Ярослав в связи с ДРОНом... чтобы можно было ввести его в дракон-среду и тем самым получить полноценную дракон-систему - и алгоритм, и его структура данных прорисовываются, а далее из схемы данных (у Романченко - "дерево таблиц", а конкретно - граф-схема записи, узлы которой атрибутируются в табличной форме) получается деклар-текст на Обероне (все объявления и список импорта модуля), а из схемы алгоритма - импер-текст (фактически остальная часть модуля). Прослеживая употребление объявленных имён в импер-тексте (командах икон) можно контролировать правильность сочинения, я так понимаю, сразу при визуализации (поскольку типизация статическая).
Вспомним у Вирта: "данная книга начинается главой о структурах данных, и тому есть две причины. Во-первых, интуитивно ощущается, что данные предшествуют алгоритмам; нужно иметь какие-то объекты прежде, чем что-то с ними делать." (Алгоритмы и структуры данных, 2010. - с.11). То же у Гегечкори в статье, помещённой в этом сообщении (хотя он, скорее всего, сам опирался на Вирта).
Целостная визуализация "программа = алгоритмы + структуры данных", IMHO, послужит и наведению порядка в мозгах прикладников. Как ДРАКОН м.б. учебным импер-языком, позволяющим наглядно представить исполнение программ (систем программ), так ДРАКОН+деклар-язык позволит представить информатизацию деятельности в целом и многое объяснить неспециалисту... но сам стандарт деклар-языка, наверно, должны выработать прежде всего программисты.

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

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

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

Хотелось бы отметить, что виртуализация - ака полиморфизм. Операция "сложить", применяемая к разным типам данных, является совершенно разной операцией. Операция "сложить" виртуальным образом привязана к встроенному типу данных.

Еще, конечно, надо назвать базовый принцип - абстрагирование. Для, собственно, выделения классов.

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

А, ну да, это моя ошибка. Озаглавил список как "принципы". Не принципы, а средства всё-таки перечислил.

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

Кстати, свойства языков довольно подробно обсуждаются и в /Девятов, Мартиросьян, Гл.9/.

И такой пример на тему как семиотики, так и соотношения художественного и научного познания. Наш "Поэт Революции" (Маяковский) был одним из основоположников футуризма в поэзии. Стремясь построить теорию этого нового направления в искусстве, он размышлял в своих сочинениях над свойствами языка. В 1914 году он написал следующее:
«Каковы же изменения, происходящие в законах слов?
1. Изменение отношения слова к предмету, от слова как цифры, как точного обозначения предмета, к слову-символу и слову-самоцели.
2. Изменение отношения слова к слову. Быстреющий темп жизни провел дорогу от главного периода до растрёпанного синтаксиса.
3. Изменение отношения <человека> к слову. Увеличение словаря новыми словами.»
Видно, что Маяковский фактически дал краткие определения уровней значения информации: семантики, синтаксиса и прагматики.
В 1938 г. американский логик и философ Уильям Моррис, давая определения трёх основных разделов науки о знаках, сам того не ведая повторил эти формулировки, определив семантику как «отношения знаков к объектам» (т.е. «слова к предмету»), синтактику как «отношения знаков к знакам» («слова к слову»), прагматику – как «отношения знаков к интерпретаторам» («отношение <человека> к слову»).
Эти определения были положены в основу семиотики – науки о знаковых системах, которая тесно связана с информатикой. Т.о., Маяковский предвосхитил ее и был одним из первопроходцев научного изучения информации. Также он наметил и некоторые проблемы культуры и технологии общения («самоцельные» слова, чересчур растрёпанный синтаксис, произвольное увеличение словаря), которые сейчас очевидны.

Также появился сайт, посвящённый Вячеславу Иванову.

Упоминаемая концепция "трёх схем" (точнее, классов ЯПЗ, соответствующих разным т.зр. на предмет формализации) была определена для датаматики в стандарте IDEF1X (см. выдержка):

Далее начинается собственно описание МФЗ IDEF1X; по крайней мере одно определение оттуда представляется общезначимым: "Сущность является ...независимой, если каждый экземпляр сущности м.б. однозначно идентифицирован без определения его отношений с другими сущностями." (с.13). Полагаю, перекликается с понятием независимости процессов в алгоритмике. Этот же принцип использовал в определении независимости для МШ-метода - процесс независим, если не использует (статически, т.е. в текстуальном определении) те же объекты, что и любой другой процесс, возможный в данной системе; то же относится и к коду, который в случае повторной используемости надо дублировать для каждого использующего процесса (о чём уже говорил Илья, обсуждая "развёртку силуэта") - причём явно (как я понимаю, тоже текстуально).

Уже говорил, что считаю эту концепцию приложимой к любому роду частного отчуждённого знания;.

Вот ещё выдержка:

Обзор языков спецификации программ как способа организации понятийных средств, описанных в предыдущих главах книги.

Отражает ещё один взгляд на вопрос, рассмотренный здесь. Отличие, IMHO,
прежде всего в том, что автор выявляет максимально широкий круг средств представления знаний на стадии математической формализации, чтобы предоставить сочинителю-спецификатору поле выбора ЯПЗ для конкретной задачи (класса задач). В то же время среди классификаций средств нет такой, которая введена в Драконографике - для организации языкового базиса практической формализации.

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

Несколько иная классификация, чем у Герасименко.

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

И ещё одно название:
Симонович С.В. Общая информатика: новое издание. - СПб.:Питер, 2007
Здесь всё хорошо, включая когнитивный стиль как иллюстраций, так и текста. Но одно, видимо, требует уточнения - определение способов адресации. Принимая за основу принципы, изложенные на этой странице, мы должны трактовать "числовую" и "символьную" адресации по Симоновичу не как альтернативы, а как два из многих частных случаев в расширенном пространстве индексации (соответственно: исторически-порядково-числовой и функционально-иерархически-символьный); очевидно, это требует и переработки определений этих способов. У Макаровой ближе к сути - классификация и кодирование сущностей разделены.

оть здесь и проскальзывало ироническое отношение к названной методологии, но вот такой современный источник, тесно связанный с практикой:

Как обычно, в соответствии с действующим законодательством выдержка даётся "в объёме, оправданном целью цитирования - научного, полемического или иного". Из цитированных разделов не взято большинство примеров - все они относятся к материальным системам, а оставшегося вкупе с источниками достаточно, чтобы видеть - ТРИЗ в современном виде работает и завоёвывает популярность.
Что здесь интересно? Прежде всего, автор рассматривает ТРИЗ (в современной версии, выработанной, как видно, и его усилиями) как методологию формализованного проектирования искусственных систем-решателей проблем. Из материала очевидно, что ТРИЗ самая что ни на есть информатическая методология. С одной стороны, общий содержательный анализ существующих изобретений в рамках теории стал основанием для общего формального анализа полученных решений, выявившего инвариантные законы изобретательского творчества; установлена общая методика выработки изобретательского решения. С другой стороны, одновременно постулирована конечность множества элементов, используемых на каждом шаге методики (моделей, приёмов, эффектов). Наконец, как один из принципов введено единство формы представления решения.

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

В Гл. 6...9 сущность методики раскрывается. Существенно, что вводится три уровня рассмотрения проблемы - административный, технический и физический - это перекликается со взглядами теории безопасности. В частности, если ограничиться источниками, данными в этом сообщении, то первые два уровня можно отождествить с неформальным и формальным метауровнями СЗИ у /Герасименко В.А., Рис. 7.1/ (если вспомнить ЭМВОС по стандарту ИСО7498, то легко находится место и для физического - нужно добавить к СЗИ физическую среду как основание), а по /Диев, Шаваев, Гл.3/ - все три уровня со сферами ОТМ, НСД, ПДТР.
Поскольку модели деятельности есть тоже технические системы, то наверное можно, основываясь и на доказательной формализации, формировать постепенно "каталог логических эффектов", обеспечивающий рациональное проектирование решений по информатизации на техническом уровне; системотехнический же уровень (подробно раскрытый в Гл. 14-15) инвариантен к природе объекта проектирования (материальная или информатическая система).

В начале п. 7.2 (с. 92-95) автор обосновывает свою т. зр. на определение алгоритма. охватывающее человеческую деятельность. Видимо, это подлежит осмыслению и проверке на корректность (а м.б. и нет - всё-таки автор "проф.д-р.д-р.т.н." и потому знает, что говорит? ).

В Гл. 8 рассматривается правильное в общем смысле построение машин (по Фридланду - "устройств"); инвариантная модель машины формулируется на с. 113-114.

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

В Гл.14 сформулирован, по сути, пожицикл системы на основе системотехнического представления о её назначении (главное/вспомогательное, целевое/функциональное). Важна целостная формулировка на с. 255-256 показателя эффективности искусственных систем, не "выносящая за скобки" эффекты, не видимые (и/или допускающие сиюминутное игнорирование) решателем/заказчиком решения.
Данная концепция системного анализа, IMHO, весьма отличается от первоначальной "бизнес-технократической", известной, напр., в следующей формулировке: "Операция <по достижению заданной цели> м.б. представлена как обмен, в результате которого So-система за приобретённый эффект q расплачивается некоторым количеством ресурсов C в течение времени проведения операции T." (Надёжность и эффективность в технике: Справочник. Т.3. - М:Машиностроение, 1988. - Гл.1). О чём речь, станет более понятно, если вспомнить. что ещё лет полтораста назад наш А.Н. Островский по существу вскрыл (сам того не ведая ) её суть одной фразой "Я буду грешить и каяться, грешить и каяться." (вроде вложена в уста Турусиной из "На всякого мудреца довольно простоты", но не уверен). Отсюда в т.ч. положенная в социально-экономическую практику "цивилизованных народов" концепция благотоворительности "активных" (сначала неважно как приобрёл эффект, затем увидел некоторые побочные результаты своей и/или чужой деятельности и кинул "долю малую" на то, чтобы кто-то за тебя их попытался устранить - причём часто не из искреннего желания сделать "по-божески", а просто чтоб глаза не кололо ) - вместо нормального комплексного просчёта последствий принятого решения и соответствующей корректировки не только деятельности, но и поставленных себе (и другим) целей.


Принципиальны законы развития искусственных систем, сформулированные в Гл.15. Интересны и метамодели развития, следующие далее в этом разделе.

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

В Гл.16 напоминается, что методологии управления качеством сегодня широко применяются и главное, работают - очевидно, если их правильно формулировать и применять.

В Гл.18 по существу вводится принцип смены т. зр. на культурное наследие - рассматривать элементы художественной сферы как источник научно-технических принципов (в своё время нечто подобное в обратном смысле предлагал Марк Твен: "Я провёл много увлекательных часов ...за чтением свода законов или Толкового словаря, с волнением следя за судьбой героев." ) (Налегке. - Гл.III)).
Введённое в п. 18.2 РВС-моделирование, IMHO, непосредственно следует из диаматических категорий действительного, где оценка движения как частный случай сведена к стоимостной.

Сказанное в гл.19 о целостном освоении ТРИЗ и тренировке в её применении, IMHO, перекликается с интенсификацией интеллекта по Паронджанову. В преодолении ошибок, перечисленных в п. 19.3, может помочь комплексная постановка задачи.

В п.20.1 Орлов фактически соглашается с /Фридланд А.Я., 2005, Гл.3/, что интеллект до конца неформализуем, хотя и возлагает надежды на "ряд математических моделей". О неформализуемости социальных аспектов информатизации, кстати, говорил ещё в 1980-е Игорь Бестужев-Лада. Рассуждения о прогрессе и творчестве, конечно, "с головой выдают" европейский образ мыслей - линейность прогресса и утопизация человека и социума - в реальности при ведущем частноиндивидуалистическом в человеке само по себе внедрение творческого стиля жизни ничего не решит (но может стать импульсом для подъёма "спирали истории"). Расширение же "ТРИЗ-трансфера в сферы искусства, менеджмента, воспитания" при этих условиях может привести и к "отрицательному творчеству", напр. в виде наработки более совершенных приёмов "выбивания/вбивания" установок сознания, выгодных ТРИЗ-кающему и/или его заказчику в полном соответствии с /Почепцов, Гл.1/.
В п. 20.2 важнейшим является формулирование "принципа включения", интеграции альтернатив на базе нового понимания. Здесь на рис. 20.4 снова "западное" понимание истории как "уходящего будущего" - в отличие от описанного в /Девятов, Мартиросьян, Гл.2, п. Порядок времён/ китайского понимания как "приходящего будущего".

В организации ТРИЗ-софта по Гл. 21, думаю, можно почерпнуть идеи и для систем визуализации знаний. Принципиально, что для одной ТРИЗ-технологии у Орлова существуют реализации как автоматизированная, так и ручная - что вполне естественно и должно считаться нормой.

Ну и наконец, любое предметное решение, подлежащее автоматизации, м.б. получено ТРИЗ-методами - и ИТ-специалисту, наверное, полезно представлять себе логику, приведшую предметника к результату, если даже он не пользуется ею в своей работе.

О больших системах Поспелова
http://gen.lib.rus.ec/search?req=%D0%9F%D0%BE%D1%81%D0%BF%D0%B5%D0%BB%D0%BE%D0%B2
Там еще для начинающих есть Шилейко "Микропроцессоры"
И другие книжки интересные есть. Все ссылки прямые

Торрентино на Грaфы в пр0граммир0вании Касьян0ва Евстuгнеева 2003 г. 1104 страниц 18 мег
ТОЛЬКО ДЛЯ ОЗНАКОМЛЕНИЯ! НЕ НАРУШАЕМ ТОВАРИСЧИ ПРАВ АВТОРОВ И ИЗДАТЕЛЬСТВ

Модератор: Удалена невалидная ссылка на Касьянов В. Н., Евстигнеев В. А. - Графы в программировании: обработка, визуализация и применение [2003, DJVU]

Полные тексты для двух МФЗ, пока сохраняющих актуальность:


Сравнивая документы, можно увидеть в них компоненты структуры МФЗ, введённой в этом подпункте - реализация показывается как ручная ИСП, на базе натурального документа "IDEF-папки", соответственно и ТФЗ задана как процесс документооборота - "цикл IDEF-папки".

И ещё обзор, по своему представляющий содержание взаимосвязь распространённых МФЗ:

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

По ошибке это сообщение (новое) заменило собой старое, расположенное теперь по этому адресу: viewtopic.php?p=52313#p52313

Тут высказывалось пожелание выложить машобраз книги /Паронджанов, 2000/:
Очевидно, это так никто и не сделал, т.к. при обсуждении подобных пожеланий справедливо указывалось, что произвольно выкладывать "для ознакомления" копии книг, на которые не истёк срок исключительных прав - значит входить в конфликт с правообладателями. В то же время закон нас не полностью ограничивает - см. в этом сообщении о Ст.1274 ГКРФ08.
Познакомился с этой книжкой (в издании 2007 года) и возникли некоторые соображения. В результате публикую большую часть её содержания со своими комментариями
Итак, пойдём по темам (машобраз разбил по главам - иначе обработка цветного усложняется):

§1. Ну, тут всё понятно... только можно ввести понятие задачи как тройки <Дано, Надо, Решение> явно

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

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

§4. В запоминателях допущена "перетасовка" определений... это так задумано или редакционная ошибка?

§5. Быть может, стоит включить в состав исполнителей и человека... уточнив, что дракон-схема помогает ему выполнять какую-то работу "педантично" (всё к тому же, что для §2)?

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

§11...12. Можно упомянуть, что содержимое комментариев в данном случае - это основная часть состояния алгоритма. А состояние - это все данные, которые нужны исполнителю, чтобы правильно исполнить следующий оператор.

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

§§14...16. Различие между линейными и нелинейными алгоритмами я бы пояснил так. Линейный получается, если сочинитель представляет исполнителя без обратной связи с окружающим миром (см. также Рис.53 из §26; в этом свете стоит его дать пораньше) - что бы ни получилось в результате исполнения очередного действия, мы всё считаем правильным для решения задачи. Нелинейный - это когда исполнитель должен при следующих действиях учитывать результат предыдущих; для этого он имеет обратную связь ("глаз"), и поступающие по ней (равно как и сформированные предыдущими преобразованиями по маршруту) данные используются для выбора маршрута. При этом стоит ввести понятие алгоритмической обстановки (представления сочинителя об исполнителе и окружающей его среде через набор свойств, каждое из которых может принимать одно из конкретных значений) и данных - этих самых значений, возникающих при конкретном исполнении алгоритма. По сути, в терминах кибернетики речь идёт о разомкнутом или замкнутом управлении.

Кстати, кибернетический подход проводится и в "Общей информатике" Симоновича (см. в этом сообщении)... тоже школьный учебник.

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

А лучше пойти путём гарантоспособных прогязыков и фиксировать как операторные инварианты - см. макровиопы 30Д...34Д здесь.

§20. Возможно, стоит уточнить (как в /Паронджанов, 2001/), что одинаковым текстам (однотипных вершин) на схеме соответствуют одинаковые буквы?

§22. Возможно, для старших школьников стоит сказать и о допвходах?

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

То, что с самого начала решение задачи описывается на алгоязыке, само по себе не проясняет его смысла - ведь обстановка изначально остаётся такой же неопределённой - не показать ли, что выбор точной формы описания упрощает диалог сочинителя с исполнителем (и/или человеком-экспертом в решении данной задачи) и выявление сути?

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

§33. Можно и об эквивалентных алгоритмах рассказать... здесь или при обсуждении подстановки. В частности, о том, что можно заполнять вершины текстом на разных языках и получать алгоритм решения той же задачи на языке, понятном исполнителю (я имею в виду гибридизацию техноязыка).
Далее (до следующей откомментированной темы) всё описано в /Паронджанов, 2001, с. 105-110/.

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

§§41...42. Иной раз при программировании мы нуждаемся и в разъединении (об общем правиле развёртки нелинейного алгоритма в командную модель говорил Илья Ермаков в этом сообщении.)... не знаю только, нужно ли это школьникам (вне программистских "профильных классов")?

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

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

При таком взгляде и Рис.91 будет другим. Возможно, он должен учитывать сказанное о БП с возвратом здесь - а для "совсем старших школьников" также и здесь.

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

§48. Даже не знаю... м.б. стоит при раскрытии этой темы рассказать о предусловии, постусловии и инварианте цикла... конечно, подбирая слова? И вообще об инварианте алгоритма (который мы в Обероне или Promela можем проверять по assert при переходе к любому оператору) - ведь и в "школьной" алгонотации assert имеется (в виде НАЧ/УТВ/КОН)...

Дальнейшее описано в /Паронджанов, 2001, с. 126-129/

§§55...56. На конференции неоднократно указывалось (напр. Ильёй в этом сообщении), что нужно уметь выводить цикл, а не подбирать его логику досрочными выходами/возвратами. Думаю, что учить этому хорошо бы со школы; посему не показать ли алгоритмизацию описанных задач с выводом условий циклической структуры?

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

§§57...58. Цикл в цикле также полагал бы возможным представить как цикл Дейкстры; имеет смысл дать преобразование в ЦД приведённых примеров.

Конечно, без формул-"лягушек" здесь не обойдёшься в то же время, возможно, удастся показать логический вывод частично посредством "развилочной логики" техноязыка - так наглядней. А в целом стоило бы показывать связь с математикой - тем более здесь всё вроде оказывается в рамках школьного её курса и даже может в чём-то иллюстрировать его положения - быть может, это неплохой способ внедрять "когнитивную письменность" в математику, о чём говорилось в /Паронджанов, 2001, Гл.19/?

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

§64. Здесь разбирается силуэт только с одним ВЦ. Неплохо было бы указать, что веточных циклов м.б. и два и больше, и соответственно дать иной синтаксис пометки ВЦ - напр., предложенный в /Паронджанов, 2001, Рис.105-107/ и развитый, напр., в этом подпункте Д2М-определения техноязыка. См. также замечания по концептуализации дракон-моделей в этом сообщении.
И уместны примеры, иллюстрирующие разные случаи вложения (без совпадения границ; с совпадением по начальной ветке; по конечной; по обеим - уже говорил в этом сообщении) - это скорее для старших школьников, конечно...

Далее описано в /Паронджанов, 2001, с. 86-95/

§69. Здесь у нас снова описаны состояния и инварианты алгоритма. Наверное, хороший повод вернуться к этому "для закрепления".

§70. Здесь мы по сути разбили основное содержание алгоритма на ряд веток (в данном случае на две) для удобства компоновки дракон-силуэта на диосцене (критерий эрговыделения веток, или "правило Я. Романченко"). Хорошо бы остановить внимание читателя на этом как на допустимом приёме сочинения (наряду с подстановками в тела веток).

§71. Неплохо было бы перед обсуждением этой темы ввести цикл ДЛЯ; тогда здесь показать, что такой цикл в дракон-силуэте можно располагать только целиком внутри одной ветки, иначе также возникают "сиамские близнецы", только "против шампура" - из ветки с концом цикла ДЛЯ в ветку с его началом (предшествующую по правилу "чем правее, тем позже").

См. также замечания по визуальному синтаксису цикла ДЛЯ в этом примере.

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

§74-75. Пожалуй, смысл "застывшего условия" шире - это "риторический вопрос", обсуждавшийся, в частности, в этом подпункте. И было бы уместно, считаю (если не для 5-х, то для 9-х классов наверняка), показать переход от "риторического вопроса" к зацикливанию алгоритма - и визуализацию этого зацикливания посредством силуэтных БП (удалением конечной ветки). Объяснить, что это необходимо для реагирующих систем (в смысле теории взаимодействующих процессов), т.е. для любой программы, поддерживающей диалог со внешней средой (объектом управления).

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

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

Ну и "вкратце об остальном" (без машобразов). Насчёт того, должны ли "быть иконы не только в церкви" применительно к нашей культуре, некоторое замечание высказал Дмитрий_ВБ; в этом сообщении замечание обсуждалось и учтено (предварительно) в Д2М-редакции стандарта техноязыка.
Ежели говорить о продолжении, которое я понимаю как расширенное и углублённое изложение визуализации деятельности "для отроков" (уж не знаю, планируется оно или нет ), то, IMHO, имело бы смысл положить в основу гибрид с конкретным прогязыком, и лучше РВ... хорошо бы для начала Оберон взять, а потом перейти к чему-то вроде Promela/AO.

Так говорю, поскольку разделяю:
* и мысли Ильи в Разд.5 этого доклада о нетенденциозном выборе прогязыка;
* и предложение Info21 о необходимости единого языка как сквозного при обучении программированию (в предисловии к АиСД-Оберон);
* и идеи о явном выделении состояний процесса для последующей верификации (у тех же Карпова и Шалыто).
Кстати, связь графит-метода с автоматным программированием использована в этом примере. А выдержки из новой книги по этой методологии теперь вложены в это сообщение.

При этом, пожалуй, следует проводить единый подход для материальных и датаматических процессов ("техпроцессов" и "алгоритмов"), подчёркивая, что отличие только в объектах предметной области - реальные или виртуальные - а информатическая модель строится по единым принципам, включая представление объектов типизированными структурами данных. И межпредметные связи наводить - на обсуждении постановок и алгообстановок для конкретных задач из разных "предметок".
В то же время в подобной книжке не стоит обходить уже и дискуссионные вопросы. В первую очередь это как раз упомянутая точность указаний - здесь интересным представляется мнение М.А. Орлова в связи с мета-АРИЗ, приведённое в п. 2 этого сообщения. У меня готовых ответов здесь нет; но хороший математик, думаю, сформирует мнение, которое можно высказать для "старшеклассников и младшекурсников". Далее, сказанное Фридландом о сущности и значении информатики (напр. в п/р 8.4 из учебника, вложенного в это сообщение) - здесь я бы скорректировал определение информатики, о чём говорил в этом пункте. И переопределение данных и знаний, введённое Фридландом в п/р 3.4, с чем согласен.

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

В алгоритмике можно рассмотреть и "гвардейские команды" Дейкстры, и "роботы в стране Задач", т.е. алгоритмические обстановки. В датаматике - раскрыть и "герметизацию типов", и типизацию воообще. Если говорить об актив-знаниях - то стоит донести до читателя и реализацию алгопроцессов (структуры времени выполнения), и их взаимодействие (с основными механизмами синхронизации), и представление деятельности как программы в "клеточной стране Тьюрингии", т.е. внутри адресного исполнителя, другие базовые вещи ) - в общем, что-то вроде исполнителеориентированной части из Звенигородского, только на достойной "дракон-обероновской" основе

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

Такие вот мысли...

P.S. Также в продолжение имеет смысл включать передовые результаты, имеющие значение для инженерной формализации - такие, как существование погранично-корректного класса математических формализаций (см. работы Ю.П. Петрова, упоминавшиеся, скажем, здесь: viewtopic.php?f=75&t=2219&start=20#p63721) и вопросы ограничения типов для автоматической верификации (отказ от нецелых чисел и соответственно от приближённых вычислений, от текстуально не конечных структурных типов - см. критику Оберона от Патрика Реали, которую упоминал здесь: viewtopic.php?p=50800#p50800, работы по model checking).

P.P.S. §47. Когда обобщаем операторы в теле цикла - нужно сохранять в величинах обобщённое состояние алгопроцесса. Конкретно для данного примера действие формулируется так: "Отрубить очередную голову Змея Горыныча". Тем самым сохраняются данные о том, что на каждой итерации имеем дело с новой алгообстановкой - возможно, отличной от предыдущей (здесь - новая голова, очевидно, расположена в пространстве иначе, чем предыдущая; за время после отрубания следующей Змей Горыныч мог переместиться; и т.д.) - и по необходимости сочинитель может детализировать состояние для учёта в алгоритме. Это, кстати, и к вопросу о детерминации точности указаний свойствами исполнителя - человеку-исполнителю указания "очередную" вполне достаточно

Подробности об автоматном программировании можно прочитать в монографии Шалыто "SWITCH-технологии", которая вышла еще в 98 или 99 году.

Да-да, спасибо. Я имел в виду именно перспективы связи с верификацией, в этой книжке лишь упомянуто о такой возможности, а появилось, если посмотреть Карпова, уже после 1999-го (новые результаты по model checking)... впрочем, из того, что отражено Карповым, уже многое можно понять...

По ошибке новым сообщением было заменено это.
Новое сообщение по этому адресу: viewtopic.php?p=51403#p51403

Вышла в свет книга:
Поликарпова Н., Шалыто А. Автоматное программирование. - СПб.:Питер, 2010. - 176 с. - библ.156 назв.
Основы формализации деятельности системами переходов между явно выделенными состояниями предметной области. Принципы и методы приложения в процедурно- и объектно-ориентированной парадигмах с примерами программ (на Си/Си++). Проблемы и перспективы автоматного подхода.

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

Добавлена выдержка из работы:
Определения типов реагирующих систем на с. 10 коррелируют с уровнями реализма информоделирования деятельности, введёнными в начале этого подпункта. Важен проводимый подход к проектированию деятельности от качественного описания через математические автоматные спецификации к информоделям с увязкой компонентов частного отчуждённого знания, выделенных в начале этого подпункта. Прежде всего это касается импер- и актив-знания; деклар-компонента, как видим, глубоко не рассматривается (и её увязка уже д.б. результатом работы читателей - если Шалыто не предлагает стройного решения в других своих работах).
Интересно, что Поликарпова работает в Цюрихе... по соседству, можно сказать, с Виртом При этом имеются определённые различия в подходах - см. на с. 162 в следующей выдержке: Т.к. образы разворотами, то последнюю страницу (164-ю) см. в предыдущей выдержке.

В связи с использованием материала в ряде сообщений сюда помещаю машобраз выдержки из Фридланда.

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

Взгляд на инфоркультуру, изложенный на с. 248-249, весьма актуален; приведённые там правила касательно информативности учёл при определении формата РДП-документов в этом сообщении.

В п. 7.3.2 среди ресурсов определён и языковой как "совокупность языков анализа и проектирования, в т.ч. языков программирования" (с.216) - это также соответствует представлению о разработке и документировании как о двуедином интеллектуальном процессе. В целом классификацию средств, видимо, можно уточнить (используя положения системотехники о видах обеспечения искусственных систем). В частности, я бы объединял методы, методики, модели, алгоритмы (понимая их как символические импер-модели), символическое обеспечение косавтов (в основном определённое как signware в /Паронджанов, 2001, Рис.142/) в вид когнитивного обеспечения орг[тех]систем, к которому как раз и предъявляется требование когнитивной эргономичности как ведущий показатель качества наряду с показателями качества для достижения целей применения.

В п. 5.3.5 хорошо определен процесс информатизации (в узком смысле) и его результат (информодель и инфорсима). Только, как и в п/р 6.1 (в частности, на Рис.20) нужно уточнить, что конечным результатом даже сейчас не всегда будет именно компьютерная модель (переработки данных на информашине); существенной (а если косавт для решения задачи не предусмотрен - возможно, временно - то и единственной) частью будет модель для человека (инструкция), имеющая "педантическую" формальность. Соответственно заключительный уровень формализации по Фридланду и получаемые на нём модели я назвал командными; коррективы внесены на этой странице.

Ну и конечно даты в п/р 1.2 уточнил бы. Транзистор изобрели (как мы помним, Шокли, Бардин и Браттейн) в 1948-м; даже у нас первый транзистор появился, по-моему, пораньше 1956-го Считается, что ИМС создана практически в 1958-м (Килби и Нойс; идея высказана Д. Даммером в 1952). Если говорить о работающей информашине независимо от принципа действия - то первой можно считать как релейные из Z-серии Конрада Цузе (первую рабочую модель относят к 1940; тогда же он создал для неё первый прогязык Планкалкюль), так и "интерполятор" Дж. Атанасова (1939-41); если о дискретной автоматической программируемой - то это британский "Колосс" (1943). Микропроцессор всё-таки был сделан в 1971-м. Телевидение в 1939-м появилось в СССР; за рубежом пораньше (электронное - ок. 1935 в Германии; кстати, доктор Геббельс был "отцом" концепции "информационно-развлекательного ТВ", перенятой всеми коммерческими телевещателями в мире (или переоткрытой, исходя из общности взглядов) - ему и его сотрудникам принадлежит обоснование содержания программы, разбивки его по составу передач, их "сетки").

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

Кое-что также обсудил в конце этого сообщения.

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