Обсуждение

По-моему, после точки пропущено 14.

А ведь и вправду! И после шестёрки пятёрку вполне можно было бы ещё дописать!

Мне казалось, что все давно знают. :)

Знать-то знают, но раз в пару лет забывают -- и так приятно вспомнить!

В чем отличие упомянутого в исторической справке онтологического САПР от экспертной системы, обучаемой теми же пользователями САПР?

Экспертные системы в те далёкие времена не обучались пользователями, а программировались. Контекст описан в пункте 4 http://ailev.livejournal.com/542835.html Программисты отдела главного сварщика опрашивали специалистов-технологов и строили при помощи Аквизитора правильную семантическую сетку. Потом на эту сетку они запускали уже свой ризонер, который на выходе выдавал готовые технологические карты. Меня тогда мало волновала часть с ризонером (собственно САПР), моя задача была сделать этот самый аквизитор -- инструмент для стадии knowledge aquisition. Тут нужно было учесть, что ризонер и генератор отчётов писать было тогда относительно легко и понятно как. А вот экранные интерфейсы в 1985-1986 году, когда всё это начиналось, были в диковинку. Софтинка, объединяющая командный интерпретатор чего-то тьюринг-полного, семантическую сетку и экранное (псевдографикой! пиксельной графики тогда не было!) её редактирование -- это очень хитрая штука была, хотя и немного менее хитрая, чем .15926 Editor.

Извините, ЭС не может программироваться в принципе, это живая активная база знаний, но я не настаиваю, не в этом суть (книжка "Designing and programming personal expert systems" выпущена в 1986, на русский переведена в 1990). В дискуссии по ссылке задавали вопрос о практическом примере в софтостроении. Я прошел далее, но ничего конкретного не обнаружил. Сам знамаюсь темой Model Driven уже лет 10 с разными системами, включая собтсвенную, вывод однозначный: с трудом внедряются элементы автоматизации технологических операций, управление моделью практически всегда натыкается на недостаток квалификации разработчиков.

Мы это неоднократно с Анной Елашкиной обсуждали: любая супер-пупер автоматизация оказывается сильно дорогая (требует "настройки на предметную область" с супер-дорогими разработчиками), но легко заменяется бригадой специально обученных девушков. Ситуация начинает меняться только в последнюю пару лет, когда deep learning оказывается способным научить компьютер мимо "настройщиков" -- то там свои грабли и свои дорогие специалисты, плюс дикий недостаток данных для обучения.

Даже не выходя за рамки собственно технологий софтостроения, использование model driven встречает препятствия, связанные с недостаточными компетенциями разработчиков и неумением работать с абстракциями выше, чем линейный код и его структурированные отображения в инструментальных средах. Поднимаясь на уровень моделей ПрОбл дело принимает совсем уж обреченный характер, упираясь уже в компетенции заказчиков. Собсно, я целую главу в книге этому вопросу посвятил, ответов на него не вижу, наоборот, ситуация в отрасли в среднем ухудшается, число работников без профильного образования растет.

То, что вы пишете, в целом совпадает с моими наблюдениями: раньше была возможность врабатываться в технологию лет пять, а теперь через пять лет технология вся целиком меняется и можно врабатываться снова с нуля. А поскольку "быстрых гениев" мало, и учиться нужно долго, то меняющиеся каждые пять лет model driven технологии не взлетают, есть такое дело. Ещё одна проблема, это долгая подготовка моделей -- и дальше невозможность отбить затраты на единственном проекте. А многих однотипных проектов нет, для проектов другого типа нужно опять затраты на подготовку моделей -- и та же засада. Так что model-driven обычно оказывается более затратен (надежды "окупиться" на многократном использовании моделей не сбываются). У меня есть хитрые ходы, как моделирование привносить в фирмы. Например, Modelica привносится сначала только через нестандартный для неё notebook (Dr.Modelica), и только потом идёт нормальное моделирование с диаграммами. Сразу диаграммы никто не понимает, проект моделирования не взлетает. Уже в нескольких фирмах этот трюк прошёл: "мы внедряем не моделирование, а расчёты" -- вот это хорошо идёт как первый шаг!

Не совсем так. Model driven как раз и призвана уберечь от затрат на обучение технологиям, которые изменятся (сейчас чаще просто будут выкинуты на свалку) через 3-5 лет. Разработка концентрируется вокруг моделей, сменилась технология - заменили кодогенераторы, все опять заработало. Но для работы на таком уровне абстракции большинство разработчиков не готово ни морально, ни интеллектуально.

А чьто требуется для моральной и интеллектульной подготовки разработчика? Помимо желания, какие необходимы навыки, курсы пройти, книжи почитать?

Образования с лихвой хватит профильного (АСУ, системотехника ЭВМ), нужны навыки работы с CASE, понимание сути и роли моделей и метаданных. Морально: не сомневаться, что "картинки и стрелочки" могут генерировать работающий код хорошего качества.

я генерацией чего-нить из описаний занимаюсь с самой первой своей работы в 96-97 году ну и выявил две основные проблемы: 1 коммуникация с остальными (менеджерами, заказчиками) 2 тестирование нагенеренного Т.е. если ты чего-нить много нагенерил то у тебя два геморроя: это все протестировать и объяснить менеджерам/заказчикам. Поскольку я тестировать умею, у меня лично всего один геморрой :). Решается он тем что не надо без нужды афишировать кодогенерацию.

Ну да, ну да. Из того, что я вижу, обучать, точнее отучать от попыток думать на уровне пола приходится месяцев 6. При этом многие "наши уважаемые эксперты" нифига не могут освоить, потому что просто думать не способны. Видимо, инженеры отсеивают таких во время обучения, а в ИТ они доходят до выпуска.