Добрый день всем!
Увлекаюсь генерацией программного кода по концептуальной модели предметной области.
На днях запустил микросервис http://gendoc.ru/cgi-bin/GenCode.htm .
Не знаю, куда дальше двигаться.
Буду всем признателен за любые предложения, замечания комментарии, идеи.

rbc5, спасибо за подсказку про XAF!
Смотрю, изучаю..

Спасибо за ответы!

А эти ваши системы смогут сгенерить код по формулировкам вида, например:



Мое приложение сможет.

rbc5 , scaffolding ,
спасибо, посмотрел, интересно, буду учитывать эти идеи и подходы к реализации в своих разработках.

На странице http://gendoc.ru/cgi-bin/GenCode.htm в разделе Ссылки буду размещать интересные ссылки по теме.

В WEB сервис генерации исходных кодов добавил генерацию по шаблонам: ASP, Java-таблица и различных вариантов комментариев.

Ссылка на сервис: http://gendoc.ru/cgi-bin/GenCode.htm

Интересно узнать мнение участников форума.

Alexander A. Sak,

В своем сообщении от 14 ноября я указал направление движения данной разработки.
На данный момент, реализации еще нет, появится месяца через три.
На данном этапе в приоритете - формирование онтологии (описание сущностей, их атрибутов и отношений между ними) и доработка шаблонов для генерации программного кода.

Как планируется обрабатывать постановку вида:

Alexander A. SakТребуется учет пациентов.
Отчет по выявленным заболеваниям

1) Анализ предложений на ограниченном естественном языке (ЕЯ) позволяет выделить из текста сущности ПАЦИЕНТ и ЗАБОЛЕВАНИЕ.
На сайте GENDOC.RU есть информация о имеющихся наработках по обработке ЕЯ (морфология, синтаксис, извлечение понятий)

2) В онтологии эти понятия должны быть предопределены с типовыми (наиболее распространенными атрибутами) и отношением многие ко многим. По сути UML диаграмма классов или ER диаграмма. Можно OWL.

3) Результаты отображения исходной постановки п.1 (ограниченный ЕЯ) в модель п.2 (фрагмент онтологии) достаточно информации для запуска шаблонов генерации исходного программного кода для целевой системы.
Можно будет просматривать, фильтровать, редактировать списки пациентов и заболеваний.

Здесь не вижу проблем.

А вот с фразой обстоят дела иначе:

Alexander A. SakФорма 30.


Ясно, что без формального описания данной сущности, ничего автоматически сгенерировано быть не может.
Даже опытному программисту, не встречавшемуся ранее с такой формой 30, перед началом работы ее нужно будет добыть и хорошенько изучить.

Коллеги, правда, у меня много недостатков.
НО Я НЕ СУМАСШЕДШИЙ!!!

fsharp_fsharp,
какой реакции на свои комментарии Вы от меня ждете?

Вы не верите в возможность реализации данной идеи.
И ничего конструктивного по теме мне не подскажете.
У нас с Вами разные дороги.

А проект я буду продолжать.

Добрый день всем!

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

Сразу сообщу, что проект развивается и актуальная версия WEB сервиса
доступна в разделе "Генерация программного кода" на сайте www.gendoc.ru

Генерация программного кода позволяет:
1) Сократить рутину в программировании, чтобы освободившееся время программисты могли использовать
для творчества, экспериментов, обучения новым технологиям и решения более интеллектуальных и нестандартных задач.
2) Ускорить, упростить и исключить ошибки и опечатки при составлении типового программного кода.
3) Упорядочить и стандартизовать исходный код программ, разрабатываемых коллективом программистов.
4) Быстро создавать прототипы приложений даже для тех систем и платформ, с которыми у разработчика раннее не было опрыта работы.
5) Упростить и ускорить процесс перевода программ с одного языка программирования на другой.
6) Более глубоко вовлечь аналитиков в процесс создания программ,
сократить коммуникационный разрыв между аналитиками и программистами.
7) Упростить обучение новым языкам программирования и технологиям,
путем сравнения сгенерированного кода на знакомом и незнакомом для пользователя зыках программирования
(аналог сравнения параллельных текстов при изучении иностранных языков).
8) Автоматизировать процесс разработки сопроводительной документации для программного орбеспечения.

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

Ниже приведены принципы, в соответствии с которыми будет осуществляться дальнейшее развитие сервиса:
1) Постепенное наращивание сложности (функциональности) шаблонов генерации от простых к сложным.
2) Максимальный охват шаблонами популярных и хорошо зарекомендовавших себя языков программирования,
программных систем и технологий.
3)"Осторожное" использование в шаблонах и результах генерации фреймворков и библиотек третьих (по отношению к базовой технологии) лиц.
4) Автоматическая генерация не только программ, но и документации к ней
(справочники (хэлпы) для разработчиков и пользователей,
описание API, шаблоны пользовательских инструкций и т.д.)
5) Простота использования WEB сервиса.

Также остается неизменным принцип:
отсутствие каких-либо ограничений на использование сгенерированного WEB сервисом программного кода.

Буду признателен за любые идеи и комментарии.

С уважением к форумчанам.

Версия 0.41 от 28.02.2017
1.Добавлен шаблон для генерации WEB приложения на PHP+MySQL для работы с таблицами.
2.Добавлен шаблон для генерации SQL-команд в синтаксисе SQLite и MySQL.
3.Добавлена возможность генерации в формат JSON.

Vladimir Baskakov,
спасибо!

В части развития направления генерации кода на PHP я подумывал о Yii 2.
Какого Вы мнения об этом фреймворке?

dma_caviar,
у Вас хорошая платформа.
Всегда мечтал нечто подобное сделать, но не сложилось.

Вы правы, гоняться за технологиями - неблагодарное занятие.
Особенной за фреймворками и библиотеками - на них еще быстрее мода проходит.

Именно по этотой причине хочется хоть в некоторой части обрести независимость
(или возможность перехода) не только от ОС, но и от языка/среды программирования.

Моя работа не носит коммерческий результат.
Мне интересно найти общее в подходах и технологиях пограммирования.
Этакое метапрограммирование.

Пример:
20 лет назад было 3 SQL-лидера: Sybase (потом MS SQL), Oracle, Informix.
И общее мнение было, что так и останется.
Сегодня, следуя моде, мне пришлось в WEB сервисе генерации
реализовать синтаксис SQL запросов для MySQL, PostgreSQL, SQLite.
Все, в общем, одинаково.
Но у каждого из них свои особенности в синтаксисе, иначе работать не будет или будет работать криво.
А ведь есть стандарты SQL92 и SQL2000.
Кто мог предположить такое развитие событий 20 лет назад?

А C-подобный синтакцис у C++, Java, JavaScript, того же PHP.
20 лет назад любой, кто хотел разработать свой язык программирования, был чудаком
и "изобретателем велосипеда". А сколько с тех пор появилось новых языков?

Еще можно спорить, что лучше: XML (для серьезных) или JSON (попса).

ИТОГ, к которому я пришел.
Очень хочется вынести "за скобку" программирования:
1.Особенности синтаксиса по-сути одинаковых языков программирования, библиотек и ИТ-технологий.
2.Общую модель (онтологию) данных. Чтобы в каждом проекте, например, не нужно было изобретать
таличку физических лиц (будь то клиент, работник или пациент) с одними и теми же полями.

Понимаю, что это не монетизируется, но это мой путь.
Буду продолжать идти, пока есть интерес и силы :)

kealon(Ruslan)Дмитрий Concept,

сегодня только наткнулся
ИИ научили писать код

Спасибо за ссылку, но смущает (привожу цитату из заметки) "В данный момент он может работать примерно с ПЯТЬЮ строками кодами. "

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

Этот подход мне кажется более реалистичным, иначе такой ИИ (как в приведенной заметке) так и будет формировать абстрактные синтаксически правильные программы из 5-10 строк с неясной семантикой (для кого и чего такие программы будут нужны).

dma_caviarДмитрий Concept,

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

Т.е. ядро ваше, а реализация провайдеров через api.
Причем я бы сфокусировался сначала например на sql языках. Потому как у ЯП и у реляционных языков ведь совмем разные принципы. В одном базовом провайдере не учесть и то и другое.

Реально спасибо Вам за подсказанную идею. Не сразу, но Ваши слова до меня дошли.

По-сути внутри у меня именно такая архитектура (провайдер+api+классы генерации конструкций для различных ЯП) и используется.
Только нет четкого разделения на указанные компоненты. Т.е. где-то есть, а где-то еще все перемешано (каша).
У меня сейчас выделено три мета шаблона приложений:
1.Простая последовательность команд, включая циклические обработки (например цикл по полям сущности)
2.Приложение в архитектуре "десктоп" (основанное на создании и манипулировании классами компилируемых форм)
3.Приложение с архитектурой тонкого веб-клиента

В рамках одного мета шаблона настройка на конкретный ЯП вполне может быть вынесена в классы занимает около 10-20% от общего
объема команд шаблона.

Возможности интерпретатора дают невероятную гибкость:
1.Можно в рантайме в любой момент перегружать классы и методы
2.Можно по строковому шаблону сформировать имя функции и тут же вызвать ее, если она существует, а если нет - вызвать функцию по умолчанию или просто пропустить данный шаг генерации
3.Вплоть до того, что можно в рантайме сгенерить фрагмент шаблона, загрузить его и выполнить на его основе генерацию

Еще раз спасибо за идею и конструктив!

Vladimir Baskakovdma_caviar .... Чтобы те кому нужно , смогли за вас ....

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

4 - на примере ближаеших аналогов (рельс например) рассмотреть, как по мере развития продукта росла сложность того, что должно было упрощать жизнь.

Владимир, я с Вам согласен.
Но Вы обрисовали конечный продукт.
Я еще в начале пути к нему, думаю, где-то 20% только прошел.
И не могу гарантировать, что смогу дойти до конца (промышленной реализации).
Да и нужно ли?

Одно из применений сервиса - обучение ЯП. Особенно 2-му, 3-му и т.д. Например, я знал ASP. Сгенерировав параллельный код на PHP и сравнив его с аналогичным на ASP, не залезая в документацию, я сразу вижу принципиальные отличия.
<?php вместо <%
$sql = 'create ' . $id вместо sql='create '+id
echo '<tr>' вместо Response.Write('<tr>')

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

alex55555Дмитрий ConceptОчень хочется вынести "за скобку" программирования:
1.Особенности синтаксиса по-сути одинаковых языков программирования, библиотек и ИТ-технологий.
2.Общую модель (онтологию) данных. Чтобы в каждом проекте, например, не нужно было изобретать
таличку физических лиц (будь то клиент, работник или пациент) с одними и теми же полями.
А что мешает? Строим единую расширяемую модель и дорисовываем к ней "особенности синтаксиса языков" и "клиентов, работников и пациентов"..

Размерность задачи. ЯП много и предметных областей тоже. Онтология большая.

alex55555Дмитрий ConceptПонимаю, что это не монетизируется, но это мой путь.
Не смешно. Не монетезируется, это когда с открытым кодом (да и то не всегда). А так вы всегда оставляете себе ядро, а наружу только сервисы торчат (потенциально платные). Ну и идейки у народа за одно собираете, мол не для бабла, а чисто для души - помогите кто чем может, расскажите как вы там всё делаете (забесплатно, ведь для души!).

Хотя бывают и исключения.

Но конечный итог один - ещё лет 15 и будет вам ИИ, поувольняют не только кассиров да бухгалтеров, но и кодеров. Хотя опять же - ну какой дурак так далеко смотрит? Нам бы ипотеку выплатить, да унитаз подороже приобрести.

"Ну и идейки у народа за одно собираете, мол не для бабла, а чисто для души'.
Да и не скрываю, за идеи буду признателен. К тому же, это в обе стороны.
Кто-то посмотрит на WEB сервис генерации кода, подумает "а вон значит как можно" и сделает лучше, учтя мои ошибки.
Ну и хорошо.

kolobok0, спасибо!

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

kolobok0предложить некие правила объединяющих различные модули по генерации в единую платформу.

ЭТА ИДЕЯ НУ ОЧЕНЬ НРАВИТСЯ. Готов присоединиться к такому обсуждению, если кто-нибудь возьмет модерацию темы на себя.

kolobok02) (немного дёгтя наверное) с точки зрения рынка - это не удачный вектор. более удачный рядом - в пол шажке от Вас. На рынке требуются (как тут уже прозвучало) продукты для конечного потребителя. Ваш же подход - без раскрутки имени = имхо тупиковая ветка.

Понимаю. Но я стараюсь реально смотреть на вещи. Себя я давно знаю. Я технарь и вырос из системного программирования.
Маркетинг, продвижение, сегмент B2C - не умею я. Пробовал, но не умею.
Вот фреймворки, библиотеки, шаблоны - это мое. Но это сегмент B2B. А в нем в каждой софтверной компании свои программисты-технологи, технологии, внутренние стандарты и т.д.

kolobok03) выше Вы писали, что столкнулись с заточкой под те или иные БД. Это действительно так. Универсальность либо фичи. как более гибкий подход - создать адаптирующий слой под тот или иной движок. не все фичи вынуть сможете, но думаю для большинства задач подойдёт. Тут правда для адаптирующего слоя требуется опыт общения с различными БД и практическое применение наработок при той или иной модели классов обслуживающих БД.

С этим согласен. Общение с различными БД и практическое применение наработок необходимо.
Иначе не получить объективную оценку и обратную связь.

kolobok04) ваш сервис предлагает некий интерфейс общение с человеком в рамках ваших знаний и понимания, далее идёт готовое решение в рамках ваших знаний и понимания. Системе как воздух требуется гибкость. И в плане интерфейса и в плане генерации. Может имеет смысл рассмотреть промежуточный слой строения классов?

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

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

Интуиция мне подсказывает (могу ошибаться, конечно), что именно в плоскости автоматизации программирования и документирования (CASE-технологии) находится решение.
Сейчас современные CASE средства дороги, тяжеловесны, сложны в применении и ориентированы на специализированные (ограниченный набор) языки моделирования, программирования, технологии и стандарты.

Вот если сделать CASE технологию, которая бы была:
1.Простой в изучении и использовании.
2.Дешевой.
3.Гибкой (настраивалась на выходные языки программирования и среды, Фреймворки, интерфейсы и т.д.)
4.Использовала на входе описание модели информационной системы/ПО в популярных нотациях (UML, ER, XML)
5.Поддерживала автоматическое документирование для всех этапов жизненного цикла ПО.

Собственно, это и есть цели разработки WEB сервиса генерации ПО.
Если удастся 50-70% программного кода на НАЧАЛЬНОМ ЭТАПЕ РАЗОРАБОТКИ ПО (или на этапе миграции на другую платформу/стек разработки ПО) сгенерировать автоматически, заложив прочный скелет приложения - это будет хороший результат,
который позволит вписаться в тенденции (указаны в начале данного сообщения) и позволит командам разработчиков
обеспечить необходимую мобильность, снизить зависимость от платформы, вписываться в сжатые сроки разработки и бюджеты.

Остальные 30%-50% программного кода - удел высокопрофессиональных разработчиков, допиливающих приложение под специфику задачи. От этого никогда и никуда не деться. Да и не нужно - это нормально.