Обсуждение

Толя, ты стал понятно писать. Это очень хорошо.

Да я всегда понятно пишу, когда не "просто в ЖЖ в порядке журналирования исследований". Этот текст получен переводом с английского моего "текста не в ЖЖ", т.е. даже не "текст", а "статья". :)

т.е. даже не "текст", а "статья". :) - т.е. такой текст, который не ЖЖ-ный постинг, а вне-ЖЖ-шная статья. На самом деле, контраст поразительный. Все-таки, ЖЖ при всех его неоспариваемых и огромных достоинствах не позволяет качественно писать (отчасти, именно вследствие своих достоинств, типа скорости реагирования, связанной с ней непосредственности и "прямости" отклика, возможности уточнить мысль в ответе на комменты, причем "пока не остыл" и т.п.).

Это одна сторона медали. А другая сторона медали -- я пишу в него в десяток раз больше, чем раньше писал в журналы и вообще писал. Я отказался от колонки в Компьютерре (и продолжаю отказываться от всех предложений по авторской колонке), когда понял про ЖЖ. Но если я пишу не в ЖЖ, то пишу совсем по-другому (ибо понимаю, что речь идет не о постинге в контексте других постингов для аудитории из моих френдов и часто заглядывающих сотруников клиента, а об отдельном тексте и совсем другой аудитории). Еще мне забавно, что при переводе этого собственного текста с английского (писал ведь сразу на английском) на русский, я еще и затруднялся время от времени с переводом :)

Мне кажется, я именно об этом и написал.

Моделирование как меняет язык по сравнению с непосредственным программированием (на доступный экспертам-предметникам), так и уменьшает объем кода (а значит и время программирования/отладки) по сравнению с непосредственным программированием. И добавляет еще много чего (например, добавляет повторноиспользуемости). Еще нужно обязательно учесть, что моделирование я рассматриваю не в рамках программной инженерии, а в рамках системной инженерии -- т.е. в том числе моделирование для железных систем (и поэтому пример у меня в этом тексте -- гидравлические процессные модели из насосов, трубопроводов и резервуаров, те самые P&ID диаграммы).

Разработка "языконезависимого интерпретатора/компилятора" и "языконезависимого (в т.ч. графического) редактора" является очень сложной задачей. Зато перспективы очень заманчивы: каждый эксперт-непрограммист может получить собственный кастомизированный (инженерный, финансовый, управленческий и т.д.) DSL, и все эти DSL, адресующие множество различных интересов заинтересованных сторон, будут работать совместно. Заманчиво-то заманчиво, но утопично. Тут не только задача сложная, а и требования совсем другие: в ситуации комплексирования разных языков, софт должен быть на порядок более качественным. Ибо ошибки будут вылезать при стыковке разнородных языков и моделей. И вероятность этого растет пропорционально кол-ву DSL/concerns. Если в обычном проекте, на ошибку в компиляторе можно забить/проигнорировать, то при комплексировании ДСЛей сделать это может оказаться на порядок труднее, потому как автоматизированным тулзам не объяснишь, что надо с этой ошибкой жить. Т.е. надо переписывать тулзы. При этом у них "поедет" (усложнится) ихняя мета-модель. А при следующей ошибке усложнится еще. Ну и т.д. Поэтому вся эта мета-мета- должна базироваться на прочном фундаменте, на качественном софте. Такой сейчас не умеют делать. Сейчас даже простые вещи типа Аспектов трудно применять в программистких проектах, ибо никто не умеет их тестировать. Написать-то можно, а как убедится, что это работает так как надо? Там ведь компилятор такого нагенерит. Вобщем, тут концептуальный затык в мозгах очень серьезный. Но в долгосрочном плане, все конечно в эту примерно сторону будет двигаться. Т.е. как-то будут эти проблемы преодолевать, но это огромная работа. Тут впору Алана Кея вспомнить, о компьютерной революции :).

А Лоусон называет это не "революцией", а rebirth (после винтелевского застоя ;) Заманчиво, и не утопично. С другой стороны -- пока это очень сложно, поэтому в мире в этом направлении пока движутся всего пять-шесть фирм, никакой давки за место под солнцем. Я не приписал тут, чтобы отделить личные предпочтения от описания тренда: я бы сам брал за основу софт COLA для подобной разработки. Это ведь как раз детальки для многоязыкового компилятора-интерпретатора. Правда, пока там не наблюдается деталек для "браузера-редактора", но в эту сторону все движется довольно быстро. А качество софта обеспечивается крайне малым результирующим объемом кода. Там ведь еще и коллаборативная часть развивается в виде Croquet Cobalt, тоже нельзя сбрасывать со счетов, если делать такую работу (ибо за отдельными языками сидят отдельные люди, но все они работают с общей моделью).

Я вот подумал на досуге, и понял, что именно качество софта является принципиальным затыком в системных проектах. Т.е. в плане софта это я знал давно (ибо 60-80% затрат идет на тестирование в софтовых проектах). Но поскольку сейчас в основе всего (инженерного по крайней мере) лежит софт (и железо), то основной затык происходит обычно в обеспечении качества софта. Явно или неявно. А проблема с качеством сводится к тому, что каждый прирост "единицы" качества сопровождается очень быстрым ростом затрат на его обеспечение. Т.е. 90% качество стоит столько, сколько прирост с 90% до 95%, и а прирост с 95% до 98% стоит уже в два раза больше, ну и т.д. При этом Яны Пиумарты не масштабируются :).

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

Дык проблема в том, что эти методы и приемы способны применить только люди вроде Яна Пиумарту :). Коих немного. А рядовой менеджер, мягко говоря, не готов нанимать таких специалистов. Поэтому нет ни спроса, ни предложения. Т.е. это как бы чистое искусство, до (промышленной) практики пока не добравшееся. С подходом Пиумарты касательно качества я согласен полностью, но проблема в том, что таких согласных-то немного. Да и то они готовы согласится на словах, а на деле есть, скажем так, различные обстоятельства. Меня последние много лет интересуют именно промышленные подходы к обеспечению качества. И они как раз и восходят к системной инженерии - типа Model Based Test Generation :). Грубо говоря, задача состоит не в том, чтобы показать всем что я очень умный, а в том, что показать всем, что они придурки :). Т.е. нагенерить тесты, которые найдут кучу багов, и народ побежит их исправлять и повысит качество. Вместо сделать крутой код, который так просто, что его качество очевидно.

Крутой код, конечно, тоже интересует, но это "для души". Кроме того, в области (мета-)*моделирования большой простор для такого кода :).

Спасибо очень познавательно :-) Множество методов описания (viewpoints), Множество групп описаний (views) подскажите пожалуйста это устоявшаяся терминология , и если да то где она зафиксирована ?

Это наши терминологические предложения, которые мне кажутся чрезвычайно удачными. Мы фиксируем их, например, в переводах стандарта ISO42010 (который как раз и определяет эти понятия), а также активно используем в наших работах. А дальше уж -- как будет принято сообществом. Сейчас эти view и viewpoint переводят кто во что горазд, и их содержание зачастую совсем не соотносится с терминологией из ISO 42010 (и далее -- ISO 15288 и многих других стандартов). Мы гармонизировали переводы этих стандартов и старались консистентно это переводить. Переводы эти как раз сейчас активно обсуждаются в сообщесте Русского отделения INCOSE (как раз три дня назад была рассылка пяти переведенных текстов стандартов с активным использованием слов view и viewpoint).

Ясно спасибо большое, я как раз и переводил во что горазд :-) ! Перспектива,разрез очень сюда просятся, но к ним нет хороших дополнений.

Там еще много интересных находок. Так, model -- это "описание", а не "модель". Архитектурное описание (architectural description) состоит из множества групп описаний (views), каждое из которых состоит из [частных, отдельных] описаний (model), а каждая группа описаний порождается (соответствует) одним и ровно одним методом описаний (viewpoint), который может быть или "библиотечным" (и тогда в обязательном порядке дается ссылка на литературу), или специально разработанным для данного проекта (и тогда кроме группы описаний обязательно приводится еще и описание этого метода описаний). Ну, и так далее...

С одной стороны получается красиво и единообразно с другой стороны теряется точность и часть смысла, например : 1. При переводе model - описание , теряется смысл того что модель есть упрощенное представление реальности, и в то же самое время верифицируемое и т.д. 2. При переводе viewpoint как метода описаний , теряется смысл связанный с тем что метод определяется "точкой зрения" заинтересованного лица, а не некий метод описания сферического коня в вакуме Т.е. в конечном итоге мы меняем смысл стандарта, ведь не зря в самом стандарте использована model,view, viewpoint а не много раз description. Аналогия из ООП : description - Родительский класс model,view, viewpoint - потомки. Но замена родительским классом всех потомков далеко не всегда хорошее решение.

Увы, жизнь устроена несколько иначе, и слово "model" потеряло много своих оттенков за период неумеренного употребления. В большинстве случаев его употребления -- это некоторое наукообразие для слова "описание" (типа "афроамериканец" вместо "негра"). Мы предлагаем считать, что перевод model должен быть для тех случаев, когда говорится о формальной модели, и предпочтительно датацентрической. Так, на UML -- это model. А полстранички текста свободного формата "с точки зрения начальника транспортного цеха" -- это просто описание (но все еще попадающее под стандарт, если указан метод, который был использован при составлении этого описания). Есть и еще тонкости. Так, viewpoint является методом, а сам метод в свою очередь может иметь описания (причем разделенные на группы, которые в свою очередь порождаются методами описаний). Так что я бы не так бодро записывал description в родительский класс. В стандарте приведена диаграмма, показывающая связь всех этих понятий. Вступайте в INCOSE, я вам пришлю пяток стандартов со всеми необходимыми картинками ;)