Обсуждение

Это уже проходилось много раз: идеи начинаются в software engineering, а затем с некоторым лагом приходят в системную инженерию. Судя по реалиям софтверного инжениринга, все эти игры с моделями живут отдельно от реальности. Проблема в том, что автоматизация возможна только для банального. На более высоком уровне человек использует интуицию, которая является параллельным нелинейным процессом. Все эти чудесные тулы не помогут тупым инженерам, а у хороших будут путаться под ногами. Другое дело, если бы были эргономичные (то есть удобные и простые) связки с человеческого языка на язык машин. Но это нужно делать очень серьёзный софт распознавания, а не тупые тулы, рисующие прямоугольнички и стрелочки SysML

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

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

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

Судя по реалиям софтверного инжениринга, все эти игры с моделями живут отдельно от реальности. Тут можно и категорически согласиться и категорически не согласиться. Игры с моделями в некотором роде я бы даже сказал мейнстрим нонче, но не в том виде в котором изначально планировалось. Например, в Жабе и других языках активно юзают аннотации, которые фактически превращают класс в модель, из которой потом чего только не генерится. Иногда это даже бывает весьма удобно. Другая модная тема - всеразличные DSL'и. А ведь это тоже игры с моделями по сути. Т.е. используя ДСЛ задается какая-то модель, из нее четта там генериццо. Тоже иногда бывает крайне удобно. Еще один пример - Xtext, который сверху донизу основан на моделях, и на котором создан вполне реальный язык (Xtend) с вполне реальной ИДЕ (ну и еще много проектов, но просто этот самый весомый и нетривиальный). Ну т.е. если порыться можно найти очень немало вполне себе рельных игрищ с моделями. Есессно, они по большей части вне программерского мейнстрима, хотя и это уже не сто процентов верно (аннотации и ДСЛ я бы сказал вполне себе мейнстрим).

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

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

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

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

Просто если модели делают и отлаживают полностью - то это такое же программирование, только более высокоуровневое. Т.е. DSL. Ну или раньше называли 4GL.

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

Тут дело не в этом. Люди на самом деле не тянут работу на абстрактных уровнях.

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

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

ну кагбэ подход кодинг манки и подразумевает что интеллехта особо в программировании не требуется, а точнее он даже вреден (типа если кодинг манки начнет думать, то станет медленнее кодить)

Довольно регулярно сталкиваюсь с проблемой "несквозного" проектирования чего-нибудь инженерного (электроника, строительство), и пытаюсь понять, а удалось ли САПРовщикам вообще продвинуться хоть как-то от уровня PCAD? В нем хоть как-то связывались принципиальная и монтажная схема и, с оговорками, моделирование.

Кое-где это удаётся, но не полностью. Так Autodesk PLANT 3D и P&ID (для process plant) удобно связаны, но без расчётов. Но вот уже Inventor к этому не пришивается ни с какого боку, и поэтому принципиальную схему там "мёртвую" рисуют в AutoCAD, расчёты вообще ведутся где-то сбоку. Собственно, это хорошая задачка для стартапа ;-)

Мой первый "внятный" стартап был как раз по теме моделирования/проектирования топологий микросхем. Там тоже много разных сущностей, причем без итераций, когда из кремния обратно вытягивается реальная схема и опять моделируется, не обойтись. Это так, к слову. Ну да ладно, микроэлектроника наука мутная и трудная :) Как посмотришь на самые банальные задачи типа КД на строительство. Все, пипец. Проект поделен на ОВ, АР и прочие ВК, между ними косячь как хошь. САПР - просто замена кульмана и всё. Недавно читал про страшно-престрашный пакет, который умеет генерить по чертежам деталировку каркасного дома. Задача не то, чтобы примитивная, но и не ядреная физика. Стартапам работы хватит, да. И системным инженеГрам тоже :)

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