от себя могу сказать, что в начале девяностых (боже как давно и недавно всё это было) участвовал в разработке подобной системы (описанной в исходном посте), и более того "система" у нас была готовая и работающая, что несколько отличается от термина "прототип", а в кавычках потому как не внедренная - так уж получилось...
тогда правда технологии были другие, сейчас многое можно даже назвать смешным, но как минимум уровни базы данных, обработки и презентейшн левел были разделены. Если говорить кратко, то уровни БД и интерфейса были проработаны до состояния компонентов. Оставалось "запроектировать" уровень обработки, т.е. решить нужную задачу в терминах предметной области. По сути в основе лежала формализованная модель, корректность которой проверялась стандартным компилятором. Фактически, при этом программирование переводилось с системного на прикладной уровень - не надо было программировать БД и уровень представления, достаточно было корректно определить объекты предметной области и их связи, и засунуть полученное описание (она же модель) в обработчик. А от задания их поведения куда ж денешься?
Сама система планировалась для автоматизации банковской деятельности и была реализована менее чем за 1 месяц (прикладная часть разумеется). Базовый софт потребовал где-то до 6 месяцев (за счет использования интерфейсных наработок ТурбоВижн), при практически готовой постановке. Команда была 4 человека, из них 2 прикладника, да два программиста.
Переносимостью особой, правда, эта штука не обладала, но используемый подход, кстати, позволил относительно просто мигрировать на платформу windows (ибо интерфейс был событийно управляемый и использовал близкие к стандартным компоненты), что для дос-приложений было невсегда просто. А чем дальше, тем больше появлялось программ и систем, использующих какие-то из воплощенных нами принципов. По состоянию на сейчас дело, ясное дело, заглохло.
Причем однажды мы этот конплехт показывали на выставке (да после того, как я ушел, показывали). И даже известные на тот момент деятели информационных технологий обратили внимание. С одним из них даже состоялась дискуссия на тему "Ах как хорошо, что программировать не надо!" По окончании дискуссии, когда было продемонстрировано создание простенькой, но работающей системки (типа приведенной выше обработки заказа) за 1 час параллельно неспешной беседе. Был сделан вывод: все-таки программировать надо, причем нужен специалист в двух разных областях: в предметной и в разработке (где-то здесь я это уже писал)
Насколько помню основной идеей лежащей в основе того фрейворка было: сократить цикл и время разработки (читай отлить серебряную пулю), в какой-то момент показалось что это удалось, но в исторической перспективе сказал бы что нет. При этом продолжаю идеалистически считать, что можно существенно продвинуться на этом тернистом пути, хотя сам по нему не иду.
Так к чему это я?
1) Не надо изобретать велосипед. Многое уже придумано и реализовано. Хотя...
2) Нужно хорошо прорабатывать интерфейсы (есть даже такие специальные слова: SOAP и иже с ними)
3) Нужно по максимуму использовать стандартные, т.е. готовые компоненты.
4) Уровень программирования (в том или другом виде) никуда не девается, но может видоизменяться и сильно упрощаться. При этом желательно добавление специализации в предметной области
А вообще нужно в первую очередь решать задачу и не увлекаться чрезмерно созданием инструмента (если конечно не он сам является продуктом.
P.S. Про фастбейс ничего сказать не могу, но с задачей генерации кода сталкивался неоднократно. Без напильника там не обойтись, взять тот же дельфи. А ввод значений в окошки свойств по сути мало отличается от текстового редактора, но это уже лирика
UML в качестве редактора универсального браузера