[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 порядка сложней алгоритмов генерации поведения контролов.
Впрочем, редактирование лэйаута дело не хлопотное, а наоборот, увлекательное. Медитативное, как говорит моя коллега :))