Бест регардс, Михаил Федотов!
Похоже, я тоже ваш единомышленник. Как бы мне к вашей группе примкнуть? :)
А если серьёзно, то я на Постгре+Тикль создаю RAD-CASE платформу разработки учётных приложений. С перспективой выхода на PLM, а для ВПК эта тема ОЙ как интересна.
Идея в том, чтоб описать предметную область и требования заказчика в диаграммах разных нотаций - расширенной ER, BP, описания распределения прав доступа и т.д. вплоть до описания GUI.
Причём по предшествующим диаграммам можно генерировать прототипы для последующих - из расширенной ER-диаграммы можно породить диаграмму некого шаблонного GUI, на который потом можно наводить лоск в терминах GUI-нотации.
Сейчас мной реализован универсальный диаграммер ComDiag, который позволяет создавать диаграммы в заранее описанных нотациях. Внешне функциональность напоминает Visio, но редактируются не изображения диаграмм, а модели, которые диаграммами визуализируются.
Реализован генератор GUI по диаграммам GUI-нотации. Пока на Tcl/Tk, но руки дойдут - можно будет на JS переписать, чтоб порождать браузерного клиента. Пока не реализовал TreeView и вообще контролы навигации по иерархическим и сетевым структурам. Но это на ближайшей очереди.
Реализовал генерацию схемы БД по расширенной ER-нотации. Вместо обобщенных сущностей предлагаю использовать вполне специализированные - статические справочники, объекты учёта, события, периоды и т.д. Вот "и т.д." пока не реализовал :))
Подробней об идеях, лёгших в основу этого проекта, можно прочитать в статьях о проблемах моделирования бизнес-процессов и об учётных системах на сайте www.rad-erp.ru
Если станет интересно - давайте посотрудничаем.
Одно маленькое замечание - не стоит заглядывать в будущее, его надо создавать самим!

>Двадцать лет назад эта гениальная идея называлась Designer/2000. Аж ностальгия пробила.

Точно! Удивляет, почему начиная с Oracle8 об этом ни слуху, ни духу?
Кстати, есть радикальные отличия от Designer/2000.
1) Набор нотаций для диаграмм открыт для дополнения.
2) Есть нотация GUI, которая в отличие от Oracle-Forms делает процесс генерации форм гораздо более управляемым
3) Есть нотация управления правами доступа, в том числе на уровне записи.
4) ER-нотация расширена и специализирована.
Ну и многое другое...
Я действительно затеивал этот проект под впечателением от Oracle-Designer/2000, но привнёс в него свой опыт разработки учётных приложений.

превед!Идея в том, чтоб описать предметную область и требования заказчика в диаграммах разных нотацийЭто утопия и маниловщина. Сгодится только для простых случаев.
На чём основано столь радикальное мнение?
На собственном опыте? Каком? Или просто на природном скепсисе?
Любая, сколь угодно сложная система декомпозируется на простые подсистемы.
Главное, дать разработчику инструмент декомпозирования.
Особое место в учётных системах занимает GUI. У разработчика на его реализацию уходит от 70 до 95 процентов трудозатрат. Причём все решения не простые, а очень простые. И проблема лишь в том, что их много, и в голове все взаимосвязи не удержишь. А если предоставить возможность эти взаимосвязи учитывать (всё равно в ЧТЗ кодерам их приходится специфицировать), то оказывается, что алгоритмы их реализации в код клиентской части просто тиривиальные.
В принципе то же можно сказать и о генерации схемы БД, и о генерации процедур, вычисляющих права доступа по соответствующим диаграммам.
Тестируюсь я пока на действительно простых случаях - полтора-два десятка таблиц, соответсвенно под пол-сотни форм, включая формы фильтрации и агрегации.
Хинт - чтобы сделать сложное простым надо перейти на другой уровень абстракции представления.
В этом была суть перехода с ассемблера на языки высокого уровня, например.

[quot постоянный мембер]На собственном опыте? Каком? Или просто на природном скепсисе?
Любая, сколь угодно сложная система декомпозируется на простые подсистемы.
Главное, дать разработчику инструмент декомпозирования.> Таки на собственном.
> Веду среднесложную корпоративную систему.
> Очень много нюансов и в ГУИ и бизнес-логике.
Так собственно опыт в создании сложной системы "в лоб", "ручками" или всё же в неудачных попытках автоматизировать рутину?
> Масса проверок.
Как правило проверки сводятся к вычислению статуса объекта учёта. Важно адекватно описать состав статусов и правила их изменений.

> Сотни файлов SQL-я. Более тысячи для ГУЯ.

Ну это может быть показатель не сложности, а другого :)) Например, бессистемности архитектуры.

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

Возможно, Вы "кубиками на диаграмке" называете блок-схемы алгоритмов? :))
Ну так я и не претендую на описание и генерацию уникальных алгоритмов бизнес-логики.
Их проще прямо на языке программирования в хранимую процедуру записать.
Но вот все люди проектируют схемы баз данных с помощью ER-диаграммеров, и никому в голову не приходит сказануть, что ER-диаграмму разработать сложнее, чем в лоб описать схему на DDL.

> Сложность такого "инструмента декомпозирования" будет зашкаливать

По факту не зашкаливает :))

> и создавать жуткие неоптимальности.

Уточните - неоптимальности ЧЕГО???

> Одна строчка SQL может повлечь полсотни галочек в этом гипотетическом шедевре.

Вот это не понял совсем. Строчка SQL не может влечь галочки (во всяком случае в "моём шедевре").
Наоборот, галочка (точнее проперти) влечёт за собой строки SQL.

> Именно поэтому такого инструмента нет.

Уже есть :))

> Как нет ИИ.

И ИИ есть. Вы просто не в курсе :))
Я написал в разгар "ускорения" САПР для тел вращения с экспертной системой принимавшей ВСЕ технологические решения от выбора заготовки до генерации программ ЧПУ.
Этот САПР оказался умней (в части оптимизации технологии) не только меня, но и всех моих коллег по техотделу. А это было, между прочим, на "Корол1вской фирме", флагмане советских технологий.

> Насколько я могу судить, драйвером развития и СУБД, и инструментов разработки долго являлся OeBS

Странное суждение... Или Вы имеете в виду драйвером конкретно в компании Оракл?

ShiraЛюбая, сколь угодно сложная система декомпозируется на простые подсистемы.
Главное, дать разработчику инструмент декомпозирования.

> Нет, это совершенно не главное. Здесь уместна следующая аналогия.

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


ShiraОсобое место в учётных системах занимает GUI. У разработчика на его реализацию уходит от 70 до 95 процентов трудозатрат.
да Вы что??

Ну да. У меня математическое образование. Реализовать какую-нибудь навороченную модификацию методов линейного или динамического программирования для меня не вопрос.
Да и редко они встречаются в учётных системах. Самое навороченное, с чем я сталкивался в них - разнесение затрат на себестоимость. Ну и ещё расчёт KPI, если у заказчика больное воображение.
Всё остальное - отфильтровать список, подставить в форму значения по умолчанию, ну ещё проверить права доступа на объект учёта. Короче select,insert,update,delete.

постоянный мембери никому в голову не приходит сказануть, что ER-диаграмму разработать сложнее, чем в лоб описать схему на DDLА я как раз и утверждал, что диаграмму (н-р на ВИЖИО) можно нарисовать. Но нельзя рисуя мышкой диаграмму в некоем волшебном продукте, физически реализовать сложную бизнес-логику.
Что значит "сложную"? Нетривиальный численный метод? Таки да. И не надо его представлять диаграммой.
Сложную зависимость поведения GUI от состояния визуализируемых объектов? Достаточно адекватно описать пространство состояний и приписать переходам стандартное поведение контролов GUI и повесить на триггеры какие-то дополнительные манипуляции с данными. И эту "бизнес-логику" назвать "сложной" язык не повернётся!
Другое дело, когда проектированием архитектуры (и описанием пространства состояний) никто не занимался. Тогда каждая фича в поведении GUI становится левой заплаткой. И продукт рано или поздно рухнет под слоями таких лоскутных одеял.
Кстати, мои инструментарий позволяет не только быстро создавать приложения, но и гибко привносить в него результаты бизнес-реинжиниринга. Чтоб прикладной проект никогда не становился лоскутным одеялом.
> Именно поэтому такого инструмента нет.
Уже есть :))Я обычно в таких случаях говорю: "Есть в попе шерсть" (с) :)
зы: Вы обычный непризнанный гений (без обид).
1) Вы невнимательно читали моё исходное сообщение. Мой инструментарий УЖЕ работает!
2) Не такой уж непризнанный :))
3) Какие обидки! Наоборот, спасибо за высокую оценку! :))

ViPRosShira,
покажи пару рож
Сгодится? Или такая лучше?
На www.rad-erp.ru есть ряд статей, посвящённых этой проблеме.
В частности в статье "Учётные системы..." есть пара иллюстраций. Немного устаревшие, но передающие суть.
Или какие рожи ты имел в виду???
Кстати, а почему это ты интересуешься? Ты, случайно, не в милиции работаешь? (С) Кот Матроскин

dma_caviarShiraМой инструментарий УЖЕ работает!
По сложившейся традиции, скриншоты в студию)

Да я бы с радостью, но не знаю как их встроить в ответ.
На www.rad-erp.ru в статье "Учётные системы..." есть скриншоты, но немного устаревшие и низкого качества.
Уж извините, я скриншоты делать не умею. Жму Ctrl-PrintScreen а там уж что получится...

dma_caviarShira,

Да вроде все просто, кнопка "Выберите файл".

Получилось?

dma_caviarShira,
Да вроде все просто, кнопка "Выберите файл".

Ага! Получилось!
Приведённая форма в том виде, в каком она автосгенерилась. То есть над лэйаутом следует чуть-чуть поколдовать ручками, чтоб эстетику навести.
А вот исходная диаграмма.
В ней две ветви - клиенты и контрагенты. На форме представлена только одна ветвь - клиенты.
Поскольку каждая ветвь порождает свой собственный GUI.

dma_caviarShiraПриведённая форма в том виде, в каком она автосгенерилась. То есть над лэйаутом следует чуть-чуть поколдовать ручками, чтоб эстетику навести.
Вы бы скинули что-нибудь из готового, с эстетикой. А то, так сказать, картинка несколько обескураживает)

Интересно, чем обескураживает? Хаотичностью размещения контролов?
Да, алгоритм эстетичного размещения контролов на 2 порядка сложней алгоритмов генерации поведения контролов.
Впрочем, редактирование лэйаута дело не хлопотное, а наоборот, увлекательное. Медитативное, как говорит моя коллега :))

постоянный мемберrad-erp.ru Прикольный ресурс. Статьи в неформальном, живом стиле. Даже чуть с юмором.
Никакой крамолы или ахинеи.
Спасибо на добром слове.
Тем не менее не вижу конкретики.
Есть некий продукт ? Есть к нему описание ? Что реально он умеет (доходчиво, "на пальцах") ?
Как пощупать ? Где видеознакомство (как в iscra, галактике, террасофте) ?
Продукта нет. Есть рабочий прототип. Описание пока только для меня и моих коллег - не доходят руки сделать нормальный user_guide. Говорить о том, что он умеет пока рано. Сначала нужно определиться с тем, что он должен уметь. А это вопрос к инвесторам. Пощупать - это конструктивно. Но пока сервер проекта хостится по подворотням, доступ к локальным песочницам - очень интимный вопрос. Ну а видеознакомство - вообще вопрос №16. Я точно знаю, что мой инструментарий до стадии продукта мне самому не довести. Пока расчитываю на то, что с этим инструментарием (в стадии рабочего прототипа) мне удастся составить очень серьёзную конкуренцию на рынке заказных учётных систем. Хватит денег (и интереса) на доведение инструментария до продукта - займусь. Нет - до лучших времён.
ERP-отрасли вовсе не нужны меганавороченные, ультрамодные системы с ИИ.
Графы, множества, эволюционное моделирование, ООП ......
Это маркетинговая шелуха, кот. быстро забывается и мало кому интересна.
Да что ж Вы всё в одну кучу! Графы и множества - это очень практичные теории. Точно не ульта- и даже вообще не модные, а непреходящие. С ИИ у Вас просто конфликт или недопонимание. Я, кстати, предполагал в дальнейшем компоновку прототипа прикладной системы из библиотеки типовых решений именно с помощью ИИ, а точнее экспертной системы проектирующего типа. И этой "моде" уже более 40 лет
Про эволюционное моделирование я вообще не слышал. Не просветите?
ООП сама по себе вещь не (очень) плохая, если не рассматривать это как панацею и не совать во все щели.
Но в целом к маркетинговой шелухе я отношусь так же, если не с ещё большим (нецензурным) негодованием.
Нужные простые и удобные решения, пусть даже с недостатками (а-ля 1С).
Да я-то как раз и надеялся, что смогу предложить такое решение. Ну пока с качеством сервиса увы. Все силы пока бросил на функциональную полноту. Дойдут руки - подзаточу сервис.
Были уже гении вроде мадам Хохловой с её гениальным "Эталоном". И где они ??? :)
Что-то вроде слышал... Это не из ЦИТИСа ли ноги растут? Или я путаю... Нет, точно! Я даже знакомился с их доками в 2008, но там всё было очень-очень сыро, судя по всему, шумиху подняли заранее, гранты распилили, а потом и интерес угас. Или тоже заметили концептуальные противоречия, которые заметил я. Жаль, что не помню какие Думаю, что и шумиху подняла не сама Хохлова, а неуё...(м)ные деятели из ЦИТИСа. Они там хронически паразитируют на чужих продуктах. Свои создать не могут, а оправдать существование такого угробищного паноптикума как-то надо.

dma_caviarShiraДа, алгоритм эстетичного размещения контролов на 2 порядка сложней алгоритмов генерации поведения контролов.
Впрочем, редактирование лэйаута дело не хлопотное, а наоборот, увлекательное. Медитативное, как говорит моя коллега :))
Если накидать поля друг под другом (имея метаинформацию о максимальной длине поля, например даты и числа 120) + большие контролы, такие как гриды, раскидать по страницам табконтрола + мемо поля (как правило оно если есть, то одно) кинуть последним, перед таб контролм (если он есть), то уже будет сносно выглядеть и можно даже руками не править.
Я всё это проходил, правда в другом проекте. Во-первых всё это не так просто, недею минимум на это потратить прийдётся. Во-вторых кроме собственно контролов придётся распихивать ещё много чего (вложенные фреймы, например) размеры которых заранее не оценить. В-третьих "сносно" у заказчика может не прокатить и руками всё же править придётся.
Оно может быть и медитативное, но медиативность эта будет от настроения зависеть. Сегодня кривизна формы одна, завтра другая, в итоге все не презентабельно. Да и, медиативность эту, заказчику придется оплачивать.Я в эстетике не эксперт Моя коллега с этим всем лучше справляется, я не лезу. Оплачивать заказчику придётся не эстетику, а продукт под ключ. Так что эстетика это моя (точнее, мой коллеги ) головная боль.
В принципе я согласен, что кое-что можно и нужно подкрутить, но я сейчас занят фичами в генерации схемы БД. Вот сегодня отладил создание полииерархических (сетевых) структур. В отличие от деревьев, каждая вершина может иметь более одного родителя. Например, в оргштатной структуре есть административная иерархия, территориальная (по филиалам), проектная (по проектам) и т.д. И по разным вопросам подчинение происходит по разным иерархиям. Для адекватного управления бизнес-процессами такая такая фича может быть очень полезной. Например, по какому вопросу начальник по какой иерархии даёт "добро" (визу) на принятое на уровне исполнителя решение.
Так что мне пока не до эстетики

ViPRosShiraпропущено...
Получилось?
неа
надо что то типа
Что-то не понял я... Это что было? Разглашение Гос.Тайны?
А если серьёзно, то действительно, что это?