Нашёл немного времени, чтобы прочесть - и, как обычно, не пожалел...
Понятно, что много общего с "Решением..." для ТП - но есть и новое.
Но прежде всего - снова текст требует корректуры. Всё как обычно - запятые, вопросительные предложения без вопросительного знака, тире. Также - перестроение отдельных фраз и абзацев, восстановление кое-где пропущенных слов. Только сейчас необходимость больше... догадываетесь, почему?.. Правильно
- в силу текущей ситуации Ваши книги почти неизбежно тоже окажутся "под лупой" разных граждан. Ну и предсказуемая реакция - "- И что это за книги? Сплошная безграмотность! На неокрепшие юные головы!! Ужос!!!"...
Так что хорошего Вам редактора, Виталий Валерьевич... и корректора...
Да, насчёт "программистского"... которое и пишется с трудом, и произносится коряво... да и не очень суть дела в Вашем понимании отражает, наверное... не удивительно, что Вы его не жалуете...
Предложил бы "информатическое" - которое охватывает и "алгоритмическое" и "программное". Если не боитесь разных "верховных судий", которые чегой-то весьма
поверхностно критикуют автора за это понятие... Правда, надо ещё объяснять... ну вон есть ещё "формально-информационное" в ВП:Инфомодель... в общем, Вам смотреть...
Что сказать по сути? Вижу, есть формулировочка мышлений в русле "умотип-теории" Фёдора Васильевича... рулез... Тут соображения по тексту уже высказали... я также по книге в целом, как её можно представить...
Важно, что Вы развёртываете весь
процесс моделирования/формализации, по сути, впервые после Леонтьева и Фридланда/Вентцель. И простыми словами, на конкретике получения программно строгого решения ("отслаивания знаний" (С) Леонтьев) - до "командной модели" (С) Фридланд)). Вот ещё Ляхович отчасти развёртывает (для третьей стадии преимущественно)... да кое-какие посылки можно найти у Симоновича (имею в виду по-прежнему книги из
этого поста)...
Отсюда что важно? Вот Вы пишете: "Возможно психология дает какие-то методы решения подобных задач, но мы психологической наукой не владеем. Из соображений здравого смысла ясно, что необходимо организовать перебор всех возможных вариантов, и выбрать из них вариант с наибольшим значением критерия устойчивости.". Тут бы слегка обобщить в связке со сказанным далее: "Любая работа по устранению неопределенностей, в конечном итоге должна привести, к математически строгой записи." Что психология - это частный случай "предметки", дающий "качественное" (в
этом смысле) понимание задачи. На её месте (или вместе с ней, если задача междисциплинарная) м.б. физика, химия, биология... А "строгая запись" - необходимый результат приложения математики на следующей стадии понимания... которому надо учиться...
Но в математике у нас исполнитель записи ещё не строгий "информатически". Он ещё "потенциально/актуально бесконечен". Отсюда третья стадия - когда переходим к реально конечному (в пространстве - "лент<е|ам> памяти" с конкретным числом ячеек, конечному набору состояний автомата "головки", конкретному "устройству" ячеек; во времени - ограничению продолжительности/числа шагов; в движении - к реальному набору операций/функций над конкретно "устроенными" ячейками). Появляется то, о чём Илья говорил как о "сопротивлении материала", "реализации математики". И тут уточнение того, что вы говорите о "программировании как разделе ПМ" - суть именно в наложении условий конечности на исполнителя и на процесс его функционирования. Тут-то (при нынешних результатах математики) и оказывается, что мы не всегда можем узнать заранее, выполняются ли все или некоторые из этих условий (проблемы остановки, алгоразрешимости, etc). Отсюда и утверждаемый Вами эвристический характер процесса. Сие изложение развивается/логически завершается, конечно, в разделе инженерии - но в общих чертах целостно даётся здесь. Вы начали "простыми словами" - как-то хорошо бы в этом духе и до "командной модели"...
Хорошо, что явно указано на объективность усложнения решения. Тут бы к месту (снова исходя из этапности процесса) сказать, что есть спецификация, и есть программа... и программа как раз нечто "самое" детальное - в расчёте на наиболее точно определённого исполнителя. М.б. к месту будет вспомнить, что фон Нейман
указывал на этот счёт: «…у нас не может быть уверенности в том, что в этой области объект <программа> не является простейшим описанием самого себя, ... и т.д.». Но - при условии, что мы имеем "относительно систематическое представление" (С)
Вирт на с. 48) об исполнителе "объекта" - программы ли, "педантической" инструкции - т.е. о "нашей машине" (С)
Мейер в п. 1.1).
А если без "эйффелевских банальностей", а по существу - о "языковой машине" реальной (архитектуре платформы, включая как программистское представление железа информашины - так и слои ПО, которые использует создаваемая/сопровождаемая программа, если таковые имеются - обычно да, хотя бы БСВВ
) или виртуальной (которая может абстрагировать как одну/ряд платформ, так и наше представление о человеке как алгоритмическом исполнителе, "винтике", "педанте"). Причём указывая, что слои ПО вообще-то и вводятся, чтобы скрывать нижележащие детали (аппаратуру или предыдущий слой) - см. хотя бы у
Рембольда схему на с.47 - или alexus о
языках системы. Но (забыл, как это по латыни - хотя "крылатая фраза" вообще-то
) "чего один человек построил - другой завсегда разобрать сможет" (С) Г. Горин. Формула любви)
- и потому для искусственной "языковой машины" возможен, как правило, обход слоёв. Т.е. хакинг ПО. В меру того, в конечном счёте, что аппаратура позволяет - см.
опыт "Эльбрусов" (ещё у Бабаяна в "Защищенных информационных системах") - ну это так, к слову...
А равно - обход инструкций (в результате которого не обязательно совершаются [право]нарушения - но также и рождаются новые "нормативно полезные" решения). В т.ч. и в программировании...
Во всей полноте это, конечно, инженерия... но начала, IMHO, уже здесь не без пользы были бы...
Насчёт "А или Б" - сам сталкивался с таким выбором не раз. В общем случае иногда полезно браться за "А", иногда за "Б". Выбираешь, действительно, интуитивно - и опыт, видимо, нарабатывается по мере решения.
Чуть-чуть уточнить бы это: "Структурное программирование это парадигма, описывающая технически грамотное построение программы, мы же сейчас обсуждаем не программирование, а процесс поиска решения. Термин «Нисходящее проектирование» несколько ближе. Эта парадигма предписывает разбивать задачу на подзадачи." Примерно так: "Есть поиск идеи решения - как мысленного представления, и есть оформление этой идеи - как записи на языке представления - например, программирования. "Структурное программирование" - парадигма скорее оформления найденного (технически грамотного), тогда как «Нисходящее проектирование» - парадигма в первую очередь поиска (грамотного научно, интеллектуально)." - ну и дальше о его сути. Дабы и классификация была чётче - и в то же время подчёркивалась тесная связь. В общем "догмат нераздельности и неслиянности" - который весьма полезен при подлинно системном подходе... а не только в религии...
Про системы "датаматические" и "автоматические" - лучше переписать на основе того, что у
Карпова,
Поликарповой и Шалыто (про "трансформационные" и "реагирующие" программы в начале каждой из работ; у "автоматчиков" добавляются ещё "интерактивные", но это думать надо)... ещё Илья Ермаков хорошо говорил, очерчивая сферу применения ДРАКОНа... Имею в виду то же, что и Вы - что в одних случаях важна структура данных, в других - алгоритм. Кстати, а Вы предполагаете рассматривать поиск решения и в той, и в другой составляющей?.. Думаю, надо бы... Вот у Ляховича правила, когда типизируем как скаляр, а когда - как массив, IMHO, просты... и правило, когда типизируем как запись, которое сформулировал в рамках
этой задачи (см. о деклар-моделировании), представляется естественным продолжением. Конечно, во всей полноте записевые структуры определяются из довольно сложных критериев (что было видно из некоторых недавних тем здесь)... и развёртывание этого скорее для Вашего замысла по инженерии...
В то же время здесь есть ещё один аспект - как раз алгоритмический. Имею в виду - что реагирование разное бывает. В "условно-реальном времени" - как "алгоритмическая расшифровка" (С) Рэйлвей Каген) модели предопределённого по времени взаимодействия (циклограмма etc). И в "подлинно-реальном" - как "алгорасшифровка" взаимодействия совместно протекающих процессов, предопределить которое по времени сочинитель не может (по принципу "непривязки" к моментам времени, абстрагированию событиями, "интерливы" - линейные порядки чередования во времени - которых образуют базу анализа). Тут трудно сказать, где надо начать разбирать это - здесь или тоже в инженерии - но вспомните, что говорил как раз о сложной задаче на моделирование (
здесь о Гл. 16)... IMHO, можно связать с разомкнутым и замкнутым управлением... но надо подумать (говорил в конце поста о книге Рембольда)... В любом случае терминологию нелишне сразу давать, как она складывается в "предметке".
В общем, удачи!