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

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

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

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

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

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

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

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

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

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