> -- Владислав Жаринов писал(а):
> ...Цель именно поддержка массового производства данных... но с учётом не только опыта этой сферы, но и производства материального... например, переданного Грабиным: ... Где схемы - не самоцель, а средство "проектного производства"...
Кстати, вопрос, более чем актуальный. Прежде всего, нужно учесть, что в реальной жизни есть существенные предопределяющие нагибалки, такие, как стандартизация, сертификация, и прочая бюрократия. Пример:разработка ПО авионики, где имеется и обратная сторона медали --"Отладка самолета? Это очень просто!"--
> -- Цитата:
> ...P.S. Спрашиваете, ну а что дальше, как летать? А все очень просто – в FAQ появилась очередная строчка, которая советует не допускать свободного вращения колес после взлета дольше минимально необходимого времени, а в случае возникновения ошибки TR – сбросить потом ошибку после приземления, и спокойно летать дальше.P.P.S. А производитель двигателей сказал, что они, конечно, немедленно выпустят обновленную версию ПО, только займет это год – полтора, так как такое ПО проходит через строгие и длительные процессы разработки и сертификации (и это не шутка).
Однако, есть и другая реальность:Как у нас пишут ПО для космических аппаратов, подобные реалии подтверждают и ряд комментариев к статье насчёт разработки ПО авионики.

В общем, стоит учитывать ряд внешних определяющих факторов, к тому же есть уже исторически устоявшиеся модели и методологии в той же инженерной области. И поэтому сегодня, в отсутствие Р-технологии, вынуждены лепить её суррогатные "подменители", типа FUSED - Formal United System Engineering Development (анонс,сайт,презентация). Насколько я понял, это клей для манипулирования разными техническими моделями. Возник проект где-то под боком NASA (вроде как). Есть базовые спецификационные модели, в частности, в виде таблиц Excel-я, используются 3D-модели в каком-нибудь CAD, далее применяются модели для проверки лётных характеристик (тестовая эмуляция), и т.п. Решается важная и сложная задача - автоматизм преобразования между моделями. Для этого применяются некие мета-модели, где определяются форматы технических моделей и правила построения одних моделей из других. Используется какая-то графика, квадратики с содержимым и со связями, что из чего возникает. В распоряжении имеется некий свой функциональный ЯП, со специализированной системой типизации, чего-то можно програмлять, плюс внутри мета-моделей прикладные специалисты задают функциональные выражения (формулы). Мета-модели сохраняются в XML-простынях, и есть набор инструментов, который выполняет верификацию технических моделей и генерацию новых на базе существующих. Инструментарий расширяемый, т.е. задумывается открытая адаптация под широкий набор инженерных сред.

Стоит отметить, что разрабы заявили:

- они отвергли попытку применить единый мега-мета-супер формализм, через который проектировать всё. Пошли по пути адаптации к существующим;
- они отвергли попытку использовать уже имеющиеся стандартные методологии, такие как UML (что не удивительно).

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