Petro123мне кажется все проблемы от незнания "версионирования продуктов".
Я ведь отвечал на этот вопрос
...
- нет столбцов isbn и id_external

== вер. 1.0

- есть только isbn

== вер. 1.1.0

- есть только id_external типа integer

== сфигали? Прыгнули через версию?

- есть только id_external типа varchar

== сфигали? Прыгнули через версию?

- есть isbn и id_external типа integer

== вер. 2.0.0

- есть isbn и id_external типа varchar

== вер. 2.1.0

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

Petro123ну и заодно напиши, какой код на клиенте, у заказиков, веб-сервисах, в хранимках? Наверно тоже с условиями:



Естественно, в клиентском для базы программном коде должна быть соответствующая технология. Внутри SQL-базы как раз препроцессор и выручает. SQL - штука декларативная, причём максимально прямолинейная (писать те же списки полей в операторах select, update и т.п. дюже геморно, без нормального редактора хреново), и у него фиговые средства для абстракций кода, несмотря на всякие процедурные расширения. Технологий вида дженериков, плюсовых шаблонов и прочего параметрического полиморфизма не наблюдается. Препроцессор напоминает разработку на С/С++/Freepascal/Delphi и т.п., где есть крупнейшие проекты, и народ ведь как-то выживает. Пример выше естественно искусственный. Все понимают, что если в одном месте ввели инвариантность, то она может повлечь за собой и другие выкрутасы в иных местах. Заниматься каждым чихом, с реальным основанием или без, весьма проблематично. И на практике я не могу сказать, что весь sql-код становиться исполосован директивами препроцессора или усыпан макросами, вовсе нет. Всё в пределах разумного (конечно, как и в любом программном коде, можно наделать себе граблей, везде нужно понимание и опыт). Для чего-то удобны директивы компиляции, где-то лучше макросы. Причём макросы помогают не только для инвариантности, но и для обобщения кода, к примеру, вокруг какой-то однотипной проверки или обработки данных, и пр. К тому же, препроцессор позволяет уменьшить потребность в "динамическом" SQL, когда в блоках кода вручную формируют строку как текст sql-запроса и запускают его через какой-нибудь "EXECUTE STATEMENT ...". Код с препроцессором как раз остаётся более декларативным, sql-подобным, и чаще более понятным.

Petro123ErWin генерирует код ровно так, как ты захочешь. Т.к. у каждого объекта есть окно - ручной код.
Есть кнопка - сгенерировать код. И т.д.

Не-не-не, спасибо. Я давно отказался от подобного GUI-программирования, и не только в рамках Case-средств. Ничего хорошего, когда целостный взаимосвязанный код размазан чёрт знает где, где-то в GUI-режиме для содержательного кода объекта, что-то где-то раскидано по макросах и формулах в куче GUI-мути, где-то по окошкам для всяких событий, где-то в каких-то формах со сложными структурами (деревья, списки, куча edit-виджетов). Когда начинаются какие-то грабли, то поехали ломать голову, клацаешь кучу режимов туда-сюда, чего-то не можешь найти или вспомнить и т.д. Особенно достаёт, когда какой-то режим реализован модально: открыл, что-то понадобилось иное, закрыл, полез в другое место, вернулся и опять открыл, снова ищешь исходную позицию. С матом плюёшь на это дело, пытаешься сохранить проект в каком-то текстовом экспортном варианте (XML, CSV, json или чего там есть), вручную ищешь чего нужно в тексте, пытаешься понять в какой GUI нужно лезть, или правишь текст сам и пытаешься импортировать обратно.

А Case-средства для меня вообще выглядят как разработка того же java-проекта, но с обратной стороны: первично нужно создавать JavaDoc-документацию, для этого вся среда состоит из Dreamweaver-подобного GUI для создания HTML, где нужно постепенно создавать разделы документации, дополняя каждый раздел соответствующими содержательными элементами. После того, как создали конкретный объект, например, документация для конкретного метода класса, появляется нужная кнопочка, клацаем и открываем окно для ввода непосредственно программного кода, причём только для одного конкретного метода, нужен другой метод - другая кнопочка (где тоже только свой метод). Есть отдельный объект со своим окошком для ввода полей класса, отдельное окно для ввода секции с import-ами. И т.д.

Я понимаю потребность в процессе именно ПРОЕКТИРОВАНИЯ информационной системы, но для этого нужны концептуально иные технологии, и это отдельная офтопная тема.

Petro123опять много букв, но вся логическая цепочка от неверного посыла.
Поэтому, весь пост - в корзину.

Действительно, лучше на этом и закончить.

P.S. Большое спасибо, а то мне показалось, что я опять чего-то не допонимаю в этих GUI/Case-ах.

Petro123методологии проектирования давно стандартизированы. Революции тут не сделать.
http://www.info-system.ru/designing/design.html
Версионированием продукта занимается Руководитель проекта. Ему без версий никуда.
Других подходов к версии я не знаю и не встречал.
Удачи!


Могу поделиться ссылками по соответствующей проблематике:

- рекомендую начать отсюда , это первый отрезвляющий момент. В той теме форума речь идёт о таблицах решений, но это не главное. Там имеются ссылки на древнейшую фидошную переписку с неким товарищем А. Седовым, который изложил концепции своей "машины теорий". Я сохранил эту переписку и у себя и немного подчистил текстовый файл (но не полностью, там есть дублирования), и поделюсь им здесь (см. прикрепление). Также здесь есть небольшое обсуждение этого дела плюс сопутствующие ссылки (и вся тема там по поводу проектирования).

И в целом, на тамошнем сайте есть форум вокруг ДРАКОН-а, это такой графический язык программирования. Там куча реально полезного материала по поводу кривости типовых Case/UML-средств и промышленных стандартов вида IDEF и пр., есть не мало адекватных альтернативных взглядов на всю эту кухню, и полно всякой информации на счёт проектирования, где реально есть чему поучиться;

- как-то выше по постам я говорил о древней, и, фактически, уже редко кому известной, Р-технологии. Здесь собраны все найденные материалы по ней, включая и живых свидетелей тех лет. Сами по себе Р-схемы интересны, и на мой взгляд, это редчайший случай, когда графическая система реально пригодна для практической разработки. Но основное, на что обращаю внимание, это материалы по поводу комплекса "РТК" - система для разработки (кое что есть и в самих постах той темы). О таком концептуальном уровне, именно системной, разработки лично я сегодня в 21 веке могу только мечтать, при этом всё на единой, и именно гармоничной, платформе;

- ты выше хотел понять, как создаются свои "1С". Вот здесь есть отличная тема по этому поводу. Тема большая, но я рекомендую изучить всё, правильно фильтруя мусор, которого там дофига, как обычно. Автор той темы поделился своим проектом, здесь можно скачать (вся инфа по нему в той же теме), это некая своя "1C" на коленке, система концептуально очень мощная, таких ещё нужно поискать. Ключевой момент - это въехать в принцип именно системного подхода, м.б. даже не с первого раза (кстати, здесь есть "первичные" взгляды того автора, и, в целом, на том сайте можно найти не мало толковых его мнений);

- в этой теме форума я как-то давал ссылку на проект Animotron, а также и в другой теме, где тот же Максим Н интересовался альтернативным инструментом. Надеюсь, что модераторы не против, если до кучи я продублирую ссылки и тут: здесь , здесь , здесь .
Это ещё один взгляд на свою "1С", особенно рекомендую обратить внимание на способы обработки данных.


Обсуждать эти материалы я никак не собираюсь, здесь это офтоп, и я не вижу никакого смысла в "велосипед/закопать/уже_всё_стандартизировано/убей_себя/-1" и прочем пескозакидательстве.
t
Вечерками, за бокальчиком коньяку, рекомендую почитать. Что-то в жизни пригодится.


P.S. "Машина теорий" А. Седов:

Совершенно неправильные выводы, совсем не в ту степь. Я не хотел заводить подобный разговор, но вынужден. Сразу извиняюсь за много букв в дальнейшем, ибо будут цитаты.

Мой основной посыл в том, что если действительно (а не просто так, поскольку постольку да как нибудь) интересует проблематика методологий проектирования, и если пока ещё нет собственного чувства ущербности современного ынтырпрайза и прочего мэйнстрима, то рекомендую изучать проблему не только по статьям от производителей мэйнстрим-стандартов и их продающих сторон. А также не только изучать опыт тех, кто эти стандарты использует на уровне корпоративных формальностей, где на самом деле реальная заинтересованность действующих лиц обычно не выше, чем "до лампочки", за исключением руководителей проектов и всякого начальства, и то, только в рамках бурной иллюзии своей деятельности, и согласно своему статусу они беспокоятся о наличии нужных средств и требуют их наполнения (теми же case-моделями). Реальная жёсткая практика у тех, кому стандарты проектирования действительны нужны как воздух, чтобы выжить. И, как правило, выжить на промышленных стандартах они не могут.

Я работаю в маленькой конторке, где все работают сами на себя, как работаешь - так и живёшь, нет корпоративного маразма. А выживаем как можем, и наелись как промышленного ...овна, так и своего (кстати, здесь раньше иронично смеялись над "PHP-SQL", а я час назад был снова благодарен своему велику - после тяжёлых разборов полётов, при котором в ряде мест в коде хранимок и триггеров был прилеплен вывод отладочных данных, мне было достаточно закомментировать одно место в конфигурации модуля и фактически сразу получил конечный код без отладок для эксплуатации). Поэтому я дал ссылки на те места, где рассматриваются проблемы, с которыми я сам нахлебался.

Речь не идёт о всяких оберонах, драконах и прочих разговоров академиков на кухне. Если кому интересны технические проблемы стандартов вида IDEF, UML, eEPC, Amber, всяких Workflow и прочих, то на том же обероновском сайте можно найти реально практичную инфу, включая и альтернативные попытки. Я же, в свою очередь, обращал внимание в целом на смысл применения промышленных стандартов (а точнее, на их БЕССМЫСЛЕННОСТЬ).

Продолжу. В том посте я приводил ссылку на "наколенную 1С". Вот цитата от того автора, где очень чётко подмечена реальная картина на счёт бизнес-моделирования, а точнее "бизнес-описательства" (что на самом деле и есть вся суть этих стандартов):
История длинная, пересказывать её, наверное, нет смысла, оставлю только существенное. ... мы последовательно обходили руководителей/директоров предприятия объясняя/обосновывая им устройство системы/предприятия. Если руководитель понимал и мог представить, как это использовать в текущей деятельности, то "выкатывал белый шар", в противном случае... "шар был чёрный"... он же последний. Мы вполне успешно поговорили с производственниками, снабжением (он нам потом прислал своего сына... устраиваться на работу)... дошла очередь до планирования... Планирование на таком крупном предприятии, как Уралмаш (в хорошие годы там работало 55 000 чел.), занятие... занятное... :)
Мы пришли в плановый отдел чуть раньше времени, нас отвели в комнату, в центре которой стоял большой стол, и рабочие столы по периметру комнаты... штук 10-12... Всё это пространство было завалено листами бумаги... с диаграммами... описаний "бизнес-процессов". Такое обилие макулатуры навевало грустные размышления. Я неосторожно пошутил по поводу "бизнес-процессов", меня привычно не поняли... но когда пришёл руководитель, ему передали "остроту", сопроводив её своими комментариями. Тот покраснел (от крайнего неудовольствия) и сразу перешёл на повышенный тон. Минут тридцать он объяснял, что никто не представляет себе планирования на таком крупном предприятии. Номенклатура собственных деталей - несколько десятков тысяч, покупных - на порядок больше... Если на каком-то этапе на одном из участков не окажется [паршивых] болтов, то процесс встанет... прощай выручка, прибыль, премии и даже зарплаты... Никто [толком] не знает, что в данный момент находится на участках, на сколько хватит складских запасов по той или иной номенклатуре... Вёрстка общего производственного плана [с учётом бесконечных согласований] на следующий месяц может занимать более месяца, а в результате горят сроки исполнения заказов [заказчику нужно быстрее/ещё вчера, а производство очень неповоротливо]... И т.д. и т.п. Если кто-то работал на крупных [машиностроительных] предприятиях, тот, наверное, знает "стандартный" набор проблем, с которыми приходится сталкиваться руководителям. Трудности Уралмаша обусловлены ещё тем, что это мелкосерийное и порой позаказное производство, что выливается в малые размеры производственных партий и, соответственно, их большое количество, что, разумеется, не облегчает жизнь плановикам, производственникам, снабженцам... И без детального описания "бизнес-процессов" [как это сделано во всём цивилизованном мире] планировать не удастся, поэтому... шутки здесь неуместны. Он шумно выдохнул... было видно, что он устал и ему совсем не хочется тратить время на очередную PR-акцию... каких-то очередных автоматизаторов.

Рассказывать о системе, о моделях не имело смысла, поскольку это просто не стали бы слушать (или сделали бы вид, что прослушали). Поэтому я просто продолжил перечислять проблемы планирования, которые ещё не были озвучены, попутно связывая их в цепочку, расставляя их приоритеты и показывая внутренние зависимости/обусловленности и, наконец, возможные причины возникновения. Это подействовало... минут десять я говорил спокойно (стараясь попасть в интонации руководителя), потом стали перебивать вопросами. В какой-то момент говорить стало невозможно и вернулись к началу. Я им нарисовал схему многопередельного/многоцехового производства (всё тот же орграф, где вершинами являются макрооперации выполняемые цехом: литейный цех, кузнечный, штамповочный, мех. обработки и т.д., а ребрами являются межцеховые связи - передачи полуфабрикатов). Естественно, что связи являются слабыми и гибкими, то есть, их можно перестраивать при планировании производства конкретной продукции (например, для какой-то продукции не нужны кузнечные операции или, наоборот... нужны). Когда связи установлены, можно переходить к планированию, то есть, перемещению по связям полуфабрикатов. Если известен норматив времени выполнения какой-то операции, то зная объём партии, можно сказать сколько времени займёт выполнение этой операции над данной партией продукции. При этом планировать можно от конца к началу (от плановой даты выпуска продукции до даты запуска в производство - "тянущая" методика планирования) или от начала к концу (от даты запуска к дате выпуска - "толкающая" методика планирования). Таким образом, добавляем к плану выпуска/запуска всё новые партии продукции, в соответствии с приоритетами (срочные заказы, отстающие, обычные, "фоновые") до тех пор пока на одном из участков/цехов не произойдёт перегрузка. Перегрузка означает, что на участке/в цехе не хватает производственных мощностей для выпуска нужного объёма продукции (с учётом коэффициента загрузки, который в мелкосерийном машиностроении составляет 0,6 - 0,85 [чем выше, тем эффективнее используются производственные мощности], в Японии этот коэффициент держат на уровне 0,45 - 0,6 (двойной запас производственной мощности), в противном случае их пресловутый Канбан не работает, а стоит запас мощностей... дорого... половина оборудования простаивает без дела). Если план работы подходит к пределу (0,85), а сроки выпуска "горят", тогда следует подумать о повышении сменности (ввести дополнительные рабочие смены) и/или организацию и оплату сверхурочных работ. Выполнив планирование на уровне производства в целом, можно перейти к цеховому планированию. Нам уже известны объёмы работ, которые должен выполнить цех в плановом периоде, зная технологию производства в данном цехе, количество и размещение производственных мощностей, можно по той же схеме (теми же алгоритмами) выполнить внутрицеховое планирование.
Отдельно стоит вопрос о горизонте планирования, поскольку от момента запуска в производство до выпуска готовой продукции проходит порой не один месяц, и даже не один год... То есть, планирование работы начальных цехов по выпуску данной продукции происходит задолго до планирования работы сборочных/разборочных (конечных) цехов, в противном случае, сборщики просто останутся без работы. Также необходимо учитывать, что даже при мелкосерийном производстве, часть производственных подразделений могут работать в режиме средней и даже крупной серии (на одной буровой установке может быть несколько тысяч болтов - выпуск болтов - средняя серия, а сами буровые выпускаются мелкой серией).
Потом обсуждались вопросы нормирования, включая нормативы складских запасов, учёта остатков на рабочих местах/участках и пр. пр. ...
Через неделю мне позвонил мой знакомый и сказал, что на совете директоров Уралмаша докладывал руководитель отдела планирования по нашим моделям. Однако не прошло и трёх месяцев, и "москвичи" в очередной раз сменили руководство предприятием... Разруха, увы, продолжается... Но сам факт того, что работу любого предприятия можно выстроить сообразуясь с элементарной логикой, без каких-то анкет, рисования "бизнес-процессов" и прочих глупостей (а-ля ISO 9000:2000 и подобных)... вселяет надежду, что может быть одумаются... ещё...


Иными словами, все эти "бизнес-стандарты" и "case-модели" на самом деле ни разу не модель системы, это лишь некое отражение в каком-то виде (пусть в графическом) какого-то кусочка информационной модели, причём в единственном варианте, отражающем состояние дел на данный момент времени. Завтра поменяются внутренние связи или будет новое внешнее воздействие на предприятие как систему, всё - нужна новая case-модель, все эти case-ы не имеют или никак не отражают причинно-следственных связей. Речь выше шла о зарисовке процессов, всё это касается и их братьев - всяких ER-моделей данных, другой полукусочек модели.

Теперь я обращаю внимание тех, кому действительно интересно. Ссылки на ту наколенную 1С я привёл не просто для примера, как может выглядеть продукт, речь не идёт о какой-то технической реализации как таковой, это не почва для какого-нибудь "Windows Must Die". Продукт интересен концептуально, построен совсем не по типовым принципам. В отличие от 1С, Сапов, Аксаптов и прочих монстров там как раз реализована полноценная модель предприятия, причём именно как система (согласно теории систем и системного подхода). Вот ключевая цитата самой сути:
Вроде бы эти вопросы мы уже обсуждали... и неоднократно. Ничего нового я не скажу. Вы правы, можно исходить из базовой модели жизненного цикла изделия/продукции: моделирование - проектирование/конструирование - планирование - разработка/создание - эксплуатация. Каждая стадия представима своим технологическим процессом. То есть, существует процесс моделирования, существует процесс проектирования и т.д. Любой процесс состоит из отдельных операций (в предельном случае может состоять из одной операции). Собственно, принципиальной разницы между процессом и операцией нет, любой процесс можно считать макрооперацией, а любую операцию можно рассматривать, как микропроцесс. На производстве этим часто пользуются, называя микропроцесс - типовым технологическим процессом, например. Подобная масштабируемость очень удобна, поскольку позволяет использовать одни и те же модели на микро- и макро-уровнях.
Любой технологический процесс представляет собой орграф (направленный граф), где вершины соответствуют технологическим операциям, а рёбра - передачам полуфабрикатов. На микроуровне (уровень предприятия) операции выполняются производственными мощностями данного предприятия, на макроуровне, операции выполняются на отдельных предприятиях (например, операция по выпуску тракторов выполняется тракторостроительным заводом [ЧТЗ, к примеру]). Аналогии по описанию микро- и макро-уровней можно приводить долго... но я их опущу, чтобы не уходить от темы.
Технологическая операция объединяет в себе три элемента (порождается ими): средства труда, предмет труда и, собственно, живой труд. Каждый элемент операции нормируется: нормы износа основных средств, нормы выработки/потребления, и нормы времени работы персонала. Помимо этого, есть нормативы и требования к самой тех. операции, которые не сводятся к её элементам (или сведение не является тривиальным). Нормироваться, например, может время выполнения тех. операции, которое, в общем случае, не равно времени работы оборудования и/или персонала. Требования к операции оформляются технологическим регламентом, где прописывается порядок выполнения операции и контроль выполнения и результатов.
Что мы сейчас имеем...
1. Стадии жизненного цикла, где каждая стадия - процесс, и связи между стадиями;
2. Структуру любого процесса;
3. Элементы, из которых состоит процесс, включая нормативы и требования к ним.
Как видите, всё достаточно строго/формально, единообразно и полиморфично... Всё сказанное можно довольно просто превратить в систему, которая позволяет контролировать жизненный цикл, планировать развитие изделия (вносить изменения, выпускать новые ревизии/версии, переходить к новым изделиям). В общем, даже структура БД для этой системы довольно проста.

Два слова о ролях... Под ролью обычно понимают поименованную совокупность действий. Например, роль технолога подразумевает, что человек умеет делать то-то, то-то и то-то... Роль образуется, исходя из общих/внешних требований, путём выделения в них специфических групп. Если говорить о программировании, то понятие ролей составляет основу для последующей классификации и порождения "иерархии классов/наследования объектов". С другой стороны роль - это группировка интерфейсов с вышестоящим уровнем на основе специфических признаков/свойств/качеств. Таким образом, верхний уровень системы задаёт требования своим подуровням, которые формируют на основании этих требований сущности. Понятие роли в данном контексте является ключевым и формальным.


Иными словами, там нет явного программирования проводок, документов и пр. и прямой их обработки "в лоб" (за рамками функционального ядра), там осуществляется непосредственное моделирование действующих процессов внутри предприятия как системы, со всеми связями и инвариантами. Понимание что такое "система" со стороны автора можно глянуть здесь (это не какой-то пиар, просто когда я писал вчерашний пост я вспомнил об этом человеке, чьи идеи я разделяю, и по памяти нашёл ссылки):
- Предприятие - открытая гибкая система
- Языки системы и система языков
- Программы | Системы
- ну и до кучи: Проблема описания абстракций предметной области

Выше приведенная наколенная 1С - пример результатов именно системного моделирования. Из ссылок выше можно понять, что современные мэйнстрим-ЯП не способны полноценно описать модель системы. А в документике на счёт "машины теорий" это проблема раскрыта более широко, и типовой набор "java-проект плюс HTML-документация плюс возможная wiki плюс ER-модель плюс возможная бизнес-описалка" - ни разу не модель системы. Ну и сама эта "машина" - тоже попытка полноценного, и именно проектирования (кстати, кто не в курсе на счёт таблиц решений (это лишь часть тамошнего моделирования) - книга и современная забава по мотивам).

На счёт умершей Р-технологии. Я специально обращал внимание на комплекс РТК. На мой взгляд, это эталон для полноценного системного проектирования. Нужно понять его сущность, на каких принципах он основан. Там есть (точнее было) всё что нужно, причём на грамотной архитектуре, которая правильно предопределяет процесс именно системной разработки. Нужно посмотреть на его структуру, как там всё разбивается на модули, как там всё взаимосвязано, как процесс проектирования осуществляется через правильный путь - от первоначальных описательных моделей через детализацию на уровне математических моделей и других строгих формальных описаний с верификацией до конкретного программного кода. Причём с наличием инвариантности, с учётом всех причинно-следственных связей (кроме того, что была поддержка вариантов модулей, можно обратить внимание на то, что даже Р-схемы для задания структур данных, описания процессов, графиков работ и пр., т.е. не только для алгоритмов, имели потенциал для указания вариантов). Плюс были прообразы сетевой разработки, контроль доступа, своя СКВ, документация, свои БД и пр.

Т.е. важен сам концептуальный принцип. Современных аналогов просто нет и вряд ли будет (но, я как и все, всего не знаю и всего в глаза не видел). И жаль, что загнулось. И даже, может быть, современный мэйнстрим был бы другим, если бы всё не закончилось вместе с союзом. Тогда у американцев ничего и близко такого не было. И их всякие IDEF-ы начали развиваться совсем не в ту сторону, плюс все их системы зарождались и т.д. в совсем иных условиях, в IBM-подобных конторах с жирными бюджетами на госзаказах со сплошным откатингом и страшной бюрократией. В советское время в оборонке и космичке (где всё зарождалось) работали интеллектуалы высокого уровня, выращенные на советском образовании, на энтузиазме, свойственном русской душе, и на неслабом чувстве патриотизма за свою Родину, особенно при соревнованиях с американцами. Тот же упомянутый дракон тоже не с потолка придумали. Решали сложнейшие задачи, когда в организации, где работает не одна тыща, есть куча инженеров, прекрасно знающие свою предметную область, но не могущие программировать, а есть программисты, которые не в зуб ногой в этой области, причём критически важной, где глюки и кривизна приводят к дорогостоящим катастрофам с возможными человеческими жертвами. Это вам не "мэйнстрим".

Собственно, всё выше сказанное прошу принять как рекомендация к стремлению правильного системного подхода при проектировании, в любой области, не только в ERP-болоте. Большинство, или в большинстве случаев, програмляют как бы не задумываясь, и как бы естественным образом что-то проектируя у себя в голове. На соответствующих проектах может вжарить петух, и начнёшь метаться по сторонам в поисках нужной "машины теорий".

P.S. Сорри, просто тоже зацепила эта тема, как и разговоры вокруг правильной и удобной разработки БД.

Vladimir BaskakovНу и хорошо, пусть в маленьких конторах опробуются новые хорошие подходы, потом люди из них разбредуться и перенесут накопленные знания в мэйнстрим. Это же и есть эволюция путем естественного отбора идей. Если там будет найдена, опробована и отлита пуля из серебра, это же будет счастье для всех.

Думаю, серебряной пули не будет. Человек ленив по своей сути, он в вечном стремлении улучшить свою жизнь, и вечный поиск серебряной пули - двигатель прогресса. И вряд ли мы познаем счастья в некоем глобально условном мэйнстриме. Сейчас это настолько разбухшая махина, причём бабло-политическая, а уж потом какая-то техническая, и чем больше масса, тем больше инерция. Сейчас вроде наблюдается новый виток развития на основе того, чего уже было раньше. Вот в той же ARIS, что на основе eEPC, чувствуется, что люди как-то понимают, что в жизни то оно как-то не так, как все рисуют. Ввели хоть какие-то причинные связи (их принцип "событие -> функция -> событие"), есть намёки на варианты процессов, и т.п., но вроде на счёт моделирования данных прогресса нет. А хорошее старое настолько пылится на каких-то полках, что его фиг и заметишь. Лично я о Р-технологии узнал совершенно случайно. Причём, в ней удивило, что голову ломали не только над тем, как проектировать и разрабатывать системы, но и чтобы технологией можно было реально пользоваться. То, что ввели именно графические схемы - очень даже правильно. Тогда стояла задача дать возможность непрограммистам, инженерам и прикладным специалистам, непосредственно работать с тогдашнем "мэйнстримом", а это С/C++/Паскаль/Форт/Фортран и пр. Причём схемы имеют полноценную структурность (чего нет у всяких блок-схем), специально проектировались так, чтобы не дать возможность в одном месте иметь слишком много кода, всё должно распределяться, подталкивают к обобщению и детализации на более низких уровнях. При этом думали над тем, чтобы эти схемы можно было легко рисовать, на уровне ввода текстовых исходников. Конечно, они имеют свой специфический вид, свои проблемы, но те, кто пользовался, говорят, что было всё очень удобно, даже на тогдашних текстовых терминалах. Сейчас такая инженерная вычурность мало привлекательна для "цветастого" и прочего бизнес-попугайства. Я изредка ломаю голову, как эти схемы задействовать сейчас. Потребность в визуализации изредка имеется. Для технической разработки вокруг БД мы особо ничего не рисуем (в т.ч. мало лазим в GUI-тулзы, для ряда операций проще сгенерить удобный HTML, например, для сравнения таблиц, как здесь или здесь , или для сравнения данных - здесь и здесь , для схем думали задействовать типа что-то Graphviz или PlantUML по мотивам эмаксовой org-mode, но не срослось). А вот разборы полётов с людьми на местах имеются, и общий язык нужен. Кроме того, нам нужна новая платформа, есть мысли связать свой текстовый DSL с Р-схемами, причём инвертировать в одну и обратную форму. Пока всё обдумывается, на реализацию ресурсов ещё нет. Планируется под жабу, но пока дело дойдёт, то возможно уже нужно будет смотреть на новый Rust. JVM, конечно, штука мощная как техническая реализовалка благодаря своему уже имеющемуся широченному потенциалу на каждый чих, но всё-таки как техническая платформа Rust более привлекателен, как некий эрланг на стероидах (к сожалению, пока лишь концептуально, но надежды есть). А если вдруг родится своя полноценная "Р-технология на коленке", то чтобы она вдруг попала в какой-нибудь мэйнстрим, то нужно уж очень заинтересовать мазиловцев, как разработчиков Rust-а, а те, в свою очередь, должны уж очень привлечь гугл, тогда может быть. Это, конечно, гипотетический бред, но другого пути я не вижу. Вон мужики из немерля сколько лет работали со своим проектом и для себя (и тоже не от хорошей жизни), и только через jetbrains немерл сможет попасть в промышленность, если проект всё-таки реализуют.

Таков сегодня мэйнстрим.

Vladimir BaskakovНо сам факт того, что работу любого предприятия можно выстроить сообразуясь с элементарной логикой
А можно показать пример такого предприятия, на котором все так и выстроено? И чтобы оно именно работало.

Тут да, чем крупнее организация, тем больше заболоченная местность. Что касается той "наколенной 1С", то всё-таки там был реализован отличный концептуальный подход. Насколько я помню (на основе того, чего сам читал на форумах), эта система была установлена на нескольких предприятиях, причём промышленных, но относительно не больших. При этом моделированием процессов занимались сами плановики, бухгалтера и пр. спецы (при поддержке, конечно) на тестовых стендах. Деятельность той конторки в России и СНГ как-то не наладилась, вроде их прибрала к себе какая-то монстро-ERP корпорация из Китая или Тайвани или что-то в этом роде, и все их наработки и технологии обитают в тех краях.