Обсуждение

Мои пять копеек: Сейчас вижу тот ужас, в который может вызвать использование новых технологий вроде SysML в индустриальном проекте. А, ведь, напишут "Удачное внедрение" и всех собак свалят на программистов-реализаторов... Насчёт же OPENPROD и подобных начинаний у меня скепсис после давнего знакомства с xtUML aka Шлейер-Меллор и опыт провала такого проекта по нетехническим причинам. Нескольких людей из перечисленных организаций видел. IMVHO докторанды просто изобретают велосипед. Онтологии одна местная фирма моделирует на Visio. Сказали, что проще и удобнее, чем самим разрабатывать оболочку.

Мое собственное чутьё почему-то сильно опасается SysML, но положительно относится к оригинальной идее Modelica. А вот с онтологиями все может быть ОК, ежели речь идет о промышленных (а не исследовательских) системах с ISO 15926. Я пока выводов никаких не делаю, но отсутствие хоть какого-то configuration management (или integrated modeling environment) в этом моделирующем зоопарке сильно бросается в глаза.

При близком знакомстве в SysML обнаружил много загадочных особенностей. Особенно эротичны Requirement Diagrams. На Modelica, пообщавшись с инженерами, надежд тоже не возлагаю. Потому как "полёт фантазии" ограничивает. Похоже, наиболее правильное решение DXL (в смысле Domain Specific Language) под каждый класс задач делать. Благо при минимальной стандартизации словаря и формы записи поднять информацию можно даже из Excel.

Насколько я понял, Modelica позволяет делать DSL (в том числе путем программирования нестандартных алгоритмов внутри своих блоков, если очень нужно). Меня больше заботит другая задача: как комплексировать весь этот зоопарк DSL. Пока они подключают Modelica либо к Simulink, либо к Matematica, либо к Maple -- и юзают тамошние notebooks/workbooks. Насчет подъема информации из Exel, так именно этого я и хочу избегать: как вы обеспечите учет информации (configuration management -- иерархический на все данные, а не только управление версиями одного набора данных). Инженеров я бы слушал с большой осторожностью. Они обычно рассказывают про ситуацию десятилетней давности (когда та же Modelica только-только появилась).

Requirements Diagram -- это как раз сильная сторона. Ведь до сих пор нет способа фиксировать требования общего вида, которые можно потом трассировать к принятым решениям. Пока для управления требованиями применяют такие монстрообразные системы, как DOORS, но это не значит, что проблема решена. У меня к SysML другие вопросы: прежде всего онтологические (мне почему-то не нравятся атрибутивные языки, поэтому я так тяготею к онтологиям. Но и онтологии сейчас пришли к атрибутивному OWL, хрен оказался по факту не слаще редьки).

Я как-то видел у вас в посте (не нешел, в каком) упоминание об устройствах сохранения/акуумулирования электроэнергии? Не помните ссылку? Интересует современное состояние этой сферы (коммерческое применение таких устройств)...

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

Уже нашел примерно похожее: http://www.proatom.ru/modules.php?name=News&file=print&sid=811 Инерционные аккумуляторы и маховики...

Информация поднимается или в XML, или в базу данных, или в тул типа DOORS. С иерархией ещё прикольнее. Она строится на основе семантического анализа. Благо, уровней как правило достаточно мало. Проблема только в том, как запихнуть в офисные форматы идентификаторы или как их генерить при импорте так, чтоб обновления шли к нужным объектам, а не писались как новые в базу. В принципе, все мои задачи сводились в последнем проекте к построению системы однозначных идентификаторов к информационным объектам, разбросанным по разным местам. После этого всё дело техники, связка XML/XSLT - великая сила. Хотя, конечно, с Лиспом было бы удобнее. С инженерами трабл не в том, что старые знания используют, а в том, что на уровне своего соображения пытаются создавать новые методики. Причём, каждый свою.

Requirements Diagram -- это как раз сильная сторона Это в реальном проекте дурь полная. Приличные тулы или не поддерживают представление сети требований, или используют его как игрушку. Уже десятка четыре квадратиков на листе вызывает перегрузку, а в современных требованиях на безопасность тысячи объектов с тысячами связей. Практически, только программно можно получить статистику или протрассировать теми же скриптами. Вместо монструозного древнего DOORS можно применять IRqA. Другие тулы или не интегрируются нормально в средства разработки или не тянут большие проекты. Вместо OWL мне все советовали применять TopicMaps, как более полезный для практики вариант. А языки сейчас подстраиваются под тулы. Если б было не так, вместо дурного UML все бы пользовались наследником более эргономичного OPEN.

У меня было много таких постов в разное время -- технологии сильно различаются в зависимости от мощности. Буквально недавно вот встречал (не помню, давал ли ссылку в блоге) про изобретение жидкосолевой батарейки из трех слоев несмешивающихся жидкостей и химической реакции, переводящих эти соли из одного состояния в другие с поглощением и выделением электроэнергии -- там речь идет о мегаватных характеристиках (типа как для сглаживания пиков в сетях), причем еще до коммерции дело не дошло, только недавно изобрели. Ежели более умеренные по мощности и объему характеристики, то вот свежайший обзорчик: http://techon.nikkeibp.co.jp/english/NEWS_EN/20090310/166951/

Синхрония! Мы с vvagr как раз с одним из этих авторов вечерком встречались и беседовали у нас в офисе :)) Правда, не про маховики :))) Впрочем, и другого автора мы знаем, но сегодня не общались.

TopicMaps неадекватны, ибо они больше про сильно раздутые в возможностях каталоги, а не семантическую сеть. Ежели вам интересны онтологии, то поглядите обязательно Gellish (нужные ссылки в профайле gellish_ru). Мне безатрибутные вещи более симпатичны. С другой стороны, команда ISO 15926 сопротивлялась до последнего, но затем перешла на смесь из Gellish+OWL (от представления онтологии в EXPRESS, как они рассчитывали). Я писал на эти темы полгода-год назад очень часто. Вместо дурного UML есть много более интересный ORM -- тоже более эргономичный своей безатрибутностью. А вот IRqA погляжу более внимательно, еще не глядел в эту сторону. У нас проблема в том, что разработка не софта, а всего на свете (в том числе и софта) -- системная инженерия в самом общем случае, и объекты очень большие.

Как вы это описываете, все ваши задачи сводились к созданию "системы учета изменений состояния набора описаний" (так я перевожу в случае информации configuration management -- это version management, только взятый не в варианте ведения версий каждого информационного объекта, а с учетом иерархий "часть-целое"). Вопрос очень сложный, ибо число отношений "часть-целое" довольно велико, это дело изучает специальный раздел онтологии-как-дисциплины -- мереология. Инженеры создают не новые методики, а вариации старых. Новые методики им приходится рассказывать. Мы как раз этим занимаемся по жизни, а айтишников мы не любим -- именно за то не любим, что они консервируют (автоматизируют и облегчают) старые неэффективные методики.

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

В принципе мне в основном нужны простые быстрые решения для определённых проблем. Подозреваю, полновесные онтологии для таких целей немного тяжеловаты. За Gellish спасибо. Пока что я смотрел в основном на развиваемый местными умельцами http://www.neon-toolkit.org/ С тулами получился анекдот. Все подразделения кроме софтверного взяли на вооружение DOORS, а вот айтишный отдел пытается требования запихнуть в SysRS тул. Сейчас у них много-много диаграммок, копирование ручками и полное отсутствие связей по разным уровням. Хотя, собираются к тулу прикрутить надстройки. Но сомнительно, что даже проверку смогут сделать. Ну и в формуле V&V одно из "V" по дороге потеряли. Судя по разговорам со знакомыми, это общая тенденция. IRqA хорош хотя бы тем, что там не DXL, который заставил меня вспоминать среды программирования студенческих времён. (Или, даже, начала студенческих времён, потому как курсе на третьем был уже TurboC). Людей, перешедших на IRqA с DOORS знаю. Обратно по доброй воле никто не возвращался. Но тут DOORS стандарт с львиной долей рынка. Особенно в таких областях как автомотив. С большими объектами не сталкивался. Всё или разбивалось на удобоваримые иерархии, или же вешалось в более адекватном формате как внешние ссылки.

Ну, ежели про названия -- это точно онтологии и мэппинг. В этом плане наиболее продвинут сейчас оказался ISO 15926 и тамошний проект Camelot (пилот для архитектуры iRING) -- http://ailev.livejournal.com/661468.html. Но это (пока) явно решение не наколеночное.

Насколько я понимаю, автомобиль -- это порядка 10тыс. уникальных деталей. Самолет -- это миллион, нефтяная платформа -- десять миллионов. Поэтому и задачи различаются. В одном случае нужно мэппить творения пары десятков поставщиков, в другом -- пары сотен, в третьем -- пары тысяч. Отсюда и монструозность решений, и необходимость иметь upper ontology кроме собственно мэппера, и необходимость общего протокола обмена данными в фиксированной онтологии между вычислительными системами разных организаций (и продолжение обменов в предметных онтологиях внутри одного подразделения, чтобы люди не путались). Не удивлюсь, ежели Gellish как онтологию и обменный синтаксис объединить с Neon как просмотровщиком и мэппером, то как раз будет подмножество ISO 15926, только без фасадов.

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

Собственно, вопрос - почему заказывают делать всякую фигню? И тщательно сопротивляются когда предлагают сделать поэффективнее?