По пункту 1.
Когда возникает практическая задача, то для нее прежде нужно составить модель. В модели отражаются только существенные для задачи элементы, второстепенные и малозначительные элементы отбрасываются. Поэтому формальное представление задач, прежде всего, связано с моделированием.
Конечно, при построении модели можно пользоваться языком обычной математики. Но более практично для описания задач бизнеса использовать IDEF-модели (бизнес-процессы, потоки работ, потоки данных, модели данных). Для создания программ часто пользуются объектными моделями по стандарту UML. Я и сам им пользуюсь для решения дискретных задач (
http://np-soft.ru/npproject/index.htm ). Еще есть имитационные модели. Часто модели реализуются как "Case-средства" и эти модели могут использоваться внешними (к программе Case-средства) программами.
Бизнес давно мечтает о такой системе, чтобы составить модель - и результатом работы была бы готовая для применения информационная система. К сожалению (а может и к счастью), разработанные модели позволяют построить лишь часть информационной системы (например, структуры баз данных, формы, "болванки" классов и пр.). При этом часто автоматически сделанную работу нужно доделывать руками.
Пункты 2) .. 7) вызывают у меня странные чувства. Есть у меня два знакомых человека, умудренных жизнью. Один оптимист - по его мнению, 90% процентов всех публикаций - это пена, в остальных 10% можно что-то выудить. Второй пессимист - он считает 99% публикаций информационным шумом.
Представим себя коммерсантами, желающих заработать на решении произвольных задач.
1. Первое, что мы можем сделать - это собрать все известные библиотеки решения задач (например, линейное программирование, квадратичное программирование, метод Ньютона и пр.), которые только можно и попытаться их продать.
2. К сожалению, применение библиотек - дело весьма хлопотное, так как для решения конкретной задачи нужно подобрать подходящую библиотеку - а это требует весьма высокой квалификации, прямо не относящейся к предметной области. Поэтому, идя на встречу клиентам, мы можем разработать язык моделирования и предложить составлять условия задачи на этом языке. А сами сделаем экспертную систему, которая подберет нужную библиотек решения задачи, разработанной на языке высокого уровня.
3. Для удобства пользования разработаем интегрированную среду.
4. Весьма вероятна ситуация, когда подходящей библиотеки нет. Для таких случаем можно разработать еще одну экспертную систему, которая с помощью продуктивных правил дозволяет свести некоторые типы ограничений модели к выражениям, подходящих для библиотеки.
5. Если задача не сводится ни к одной из известных, то можно применить универсальные методы (Ветвей и границ, генетический и случайный поиск, локальная оптимизация, перебор с распространениями ограничений и пр.). Если отбрасывание некоторых условий дает возможности применения библиотек, то их можно использовать для построения эвристик и получения оценок и рекордов (здесь могут пригодиться и работы теоретиков, модели которых никогда не встречаются на практики).
Ну и так далее. То есть коммерческая практически полезная система - это сложное инженерное решение, а не супермегавсеобщая теория решения произвольных задач. Метод построения такой системы - последовательное наращивание мощи. Поэтому пункты 2..7 лично для меня кажутся скользкими безденежными направлениями. Западные компании и университеты часто рекламируют именно такие задачи для стран третьего мира (чтобы сэкономить на исследованиях), а про то, что приносит доходы - помалкивают, предпочитая продавать уже готовые решения.