Это можна еще назвать "Формальные методы програмирования".

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

Попытка решения:
Потрачено много времени на поиск решения этой общей проблемы, на поиск какой либо информации по этому поводу, вот теперь и у вас спрашиваю.

1. Что такое программа.
Если называть программой то что у нас стоит на компе, как например WinRar, FireFox и т.д. То это нечто для решения какой нибудь задачи. То есть WinRar берет на входе контент файла, грубо говоря, и выдает сжатый контент. FireFox как интерактивная программа, имеет на входе бесконечный поток(список) дествий от пользователя, и выдает бесконечный поток графических картинок.
Из всего этого четко видется что любая программа это ничто иное как алгоритм.

2. Что такое алгоритм.
Ну как было сказано, отражает входные данные на выходные. То есть как бы обычная функция (аргумент — значение).
Существует множество известных алгоритмов. Как бы сказать алгоритмов для решения самый распостраненных задач. (Сортировка, поиск, и т.д.).
Программа это сложный алгоритм который состоит из множества других алгоритмов. Основная задача построения программы это композиция алгоритмов, то есть найти способ правильно соеденить эти алгоритмы для того чтобы програама работала правильно.

3. Что такое создание программы.
Создание программы это как ни странно тоже алгоритм)). Такой алгоритм берет на входе "постановку задачи" или скажем уже растолкованные человеком структуры данных, и дает на выходе работающую программу.

4. Как представить программу.
Ну написать ее например на языке С (Императивный подход). Или на Haskell (Функциональный). Программы на функциональном языке ближе к математике, и представить на них программы и алгоритмы проще и нагляднее чем на императивном языке. С другой стороны наши компьютеры это автоматы с переходом состояний, памятью, и работают по императивному принципу. Банальный trade-off.
В универе мы изучали как синтезировать автомат из какой нибудь булевой функции. Но я никак не могу найти доступный способ применять такие принципы для синтеза больших программ на С.
Другая проблема это построение самой функции программы (помним что программа это большая функция, или автомат). Имея набор общих алгоритмов я не знаю как
А. Представить постановку задачи как некую запись в виде функций, формул или чего то там еще.
Б. Синтезировать программу из пункта А.

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

ЗЫ. Блок схемы это просто графическое представление императивной программы. Эта штука разве что показывает условные переходы и последовательность операторов (statement ов). Так что это дает очень большую картину даже для небольшой программы, и эта визуализация бесполезна для понимания.
UML диаграммы, чисто для ООП программирования. Такое абстрактное описание системы тоже бесполезно так как подразумевает программу как взаимодействие обьектов. Что собственно не является лучшим представлением программы.

Спасибо всем.

посмотри в сторону IDEF

Здравствуйте, osupka, Вы писали:




O>ЗЫ. Блок схемы это просто графическое представление императивной программы. Эта штука разве что показывает условные переходы и последовательность операторов (statement ов). Так что это дает очень большую картину даже для небольшой программы, и эта визуализация бесполезна для понимания.
O>UML диаграммы, чисто для ООП программирования. Такое абстрактное описание системы тоже бесполезно так как подразумевает программу как взаимодействие обьектов. Что собственно не является лучшим представлением программы.

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

Если уж говорить об UML, то UML и не предназначался для программ, он для программных систем. И программную систему UML помогает описать довольно таки не плохо. К тому же, в UML есть инструменты которые вовсе не завязаны только на ООП, например диаграмма прецедентов, диаграмма состояний, диаграмма активности. Хотя и одного UML не достаточно, т.к. в нем отсутствует понятие требования. Для этого можно добавить SysML.

Здравствуйте, osupka, Вы писали:

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

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

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

O>Попытка решения:
O>Потрачено много времени на поиск решения этой общей проблемы, на поиск какой либо информации по этому поводу, вот теперь и у вас спрашиваю.

Не верю. Качество твоих определений говорит, что ты потратил время лишь на написание своего поста и ни на что более. Даже существующие определения алгорима в википедии не посмотрел. С ТАКИМ подходом к ТАКОЙ проблеме ты далеко не уедешь.

O>1. Что такое программа.
O>Из всего этого четко видется что любая программа это ничто иное как алгоритм.

Это бессмысленное сведение одного термина к другому. Где Вася? На скамье. Где скамья? Под Васей.

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

Эта проблема давно уже решена использованием framework, которые абстрагируют весь нижний уровень, позволяя тебе заниматься исключительно "функциональным наполнением". Посмотри, как делают "программы" на rails. Захватывающее зрелище .

Величие картины лечится написанием "use cases" и из последовательной реализации. Как уже отметили выше, слана необходимо есть маленькими кусочками.

Здравствуйте, osupka, Вы писали:

O>3. Что такое создание программы.
O>Создание программы это как ни странно тоже алгоритм)). Такой алгоритм берет на входе "постановку задачи" или скажем уже растолкованные человеком структуры данных, и дает на выходе работающую программу.

Заметим, что "постановка задачи" в идеальном мире сама по себе является программой. Просто описанной на гораздо более высокоуровневом языке, чем Си или Хаскель.

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

А в чем вопрос заключается?

Полностью формализовать постановку задачи и синтезировать программу? Такого не существует.

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

Если я правильно понял.

Здравствуйте, osupka, Вы писали:

O>Это можна еще назвать "Формальные методы програмирования".
O>Здеся немного попахивает автоматической кодо генерацией.. Ну вообщем я не против бы получить хоть какую нибудь информация, как человек не опираясь слишком на интуицию и придержаваясь формальных способов может написать программу.
O>ЗЫ. Блок схемы это просто графическое представление императивной программы. Эта штука разве что показывает условные переходы и последовательность операторов (statement ов). Так что это дает очень большую картину даже для небольшой программы, и эта визуализация бесполезна для понимания.
O>UML диаграммы, чисто для ООП программирования. Такое абстрактное описание системы тоже бесполезно так как подразумевает программу как взаимодействие обьектов. Что собственно не является лучшим представлением программы.
Есть еще такой графический язык как ДРАКОН. Погугли по еще по нику Драконограф — много найдешь интересного.
Дракон родился в недрах нашей советской космической индустрии для реализации алгоритмов бортовых ЭВМ проектировщиками-непрограммистами — и сейчас выплыл наружу.
Автор Владимир Паранджанов — есть у него несколько книжек на эту тему. Весьма интересных.

Здравствуйте, osupka, Вы писали:

O>3. Что такое создание программы.
O>Создание программы это как ни странно тоже алгоритм)). Такой алгоритм берет на входе "постановку задачи" или скажем уже растолкованные человеком структуры данных, и дает на выходе работающую программу.

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

Здравствуйте, osupka, Вы писали:

O>Из всего этого четко видется что любая программа это ничто иное как алгоритм.

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

O>UML диаграммы, чисто для ООП программирования. Такое абстрактное описание системы тоже бесполезно так как подразумевает программу как взаимодействие обьектов. Что собственно не является лучшим представлением программы.

ОО-программа это и есть сеть взаимодействующих объектов. И динамические диаграммы UML (Collaboration (Communication), Sequence) — неплохое представление таких программ (в отличае от Class diagram).

Здравствуйте, osupka, Вы писали:

O>UML диаграммы, чисто для ООП программирования. Такое абстрактное описание системы тоже бесполезно так как подразумевает программу как взаимодействие обьектов. Что собственно не является лучшим представлением программы.

Хм, и какое же тогда представление является лучшим? Почему тогда не пользуешся этим самым "лучшим" представлением для решения указанной проблемы?

По сути ты спрашиваешь какие существуют методы и парадигмы для борьбы с существенной сложностью программного обеспечения и моделируемых систем. И как формализовать эти методы, что бы их мог легко использовать начинающий программист.
И при этом игнорируешь полувековой опыт развития этих самых методов выраженный в парадигме объектно-ориентированного проектирования и её ответвлений и обощений. Не стоит изобретать велосипед и плясать от базовых терминов вроде алгоритма.
Изучить, доработать и формализовать современные методы OOD, так что бы их можно было применять на лету без UML и схем на бумаге, это интересная и полезная задача.

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