September 7th, 2012

2019

Мета Код

sbobrovsky создал комьюнити metacode_ru, которое описал как "программируем in small в сто раз быстрее и in large в десять тысяч раз эффективнее". Я заинтригован. Первый же содержательный пост http://metacode-ru.livejournal.com/362.html объясняет, почему именно "в сто раз" и "в десять тысяч раз", а второй формулирует (http://metacode-ru.livejournal.com/687.html):
10-е правило Гринспена (предыдущих девяти, естественно, не было)

"Любая достаточно сложная программа на Си или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp".
Потом последовали уточнения и обобщения этого правила:
…в том числе и сам Common Lisp.
Любая достаточно сложная программа на Лиспе наверняка содержит медленную реализацию половины языка Пролог.
Любая достаточно сложная распределённая программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Erlang [подставить по вкусу Haskell, Scheme, ...].
Любая достаточно сложная платформа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины функционального языка.
Интересно.

В нашей маленькой программистской команде середины 80-х годов мы самостоятельно (а не из литературы) обраружили, что в любой выпускаемой нами программе на Паскале мы по факту реализуем какой-то ad hoc спроектированный, глючный, плохоспецифицированный и медленный язык, и этот язык упорно хочет быть полнотьюринговым.

С тех пор я постоянно приглядываю за тем, чтобы в интерфейсе программы была консоль для пользовательского скриптования. Одной из мечт в этом направлении была попытка разобраться в language workbench, в которые меня когда-то ткнул как раз sbobrovsky (http://ailev.livejournal.com/474169.html). Логическим завершением этих попыток стало выведение на переднюю панель онтологического редактора dot15926 питоновской консоли с доступом к DSL онтологического программирования (для онтологии ISO 15926). Спасибо justy_tylor, он не просто реализовал этот DSL, а вписал его в Питон, и идея "каждая программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию крутого языка" для меня успокоилась тем, что этим "крутым языком" оказался выведенный на морду интерфейса REPL полноценного Питона, расширенного специализированным онтологическим языком (internal DSL).

Когда я писал в http://ailev.livejournal.com/976768.html, что летом выпустим версию 1.0 и затем приступим к реализации language workbench, я чуть чуть-ошибся: версию мы выпускаем не летом, а в сентябре, но это и есть language workbench (с точностью до синтаксических ограничений на DSL-языки, возможные в Питоне). Панель онтологического программирования красуется прямо на морде лица софтины, и в этой панели пользователю доступен полноценный язык, в том числе "немножко функциональный" (как это принято говорить о Питоне).

Так что я вписался в metacode_ru, и мне очень интересно, что ещё там появится.
2019

Практики жизненного цикла моделе-ориентированной системной инженерии

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

Дело даже не в изобилии новых непонятных терминов (моделе-ориентированная системная инженерия как опора на формальные описания целевой системы -- http://ailev.livejournal.com/728605.html; мегамодель -- совокупность связанных разнородных моделей -- http://ailev.livejournal.com/829028.html; справочные данные -- http://ailev.livejournal.com/1021613.html; порождающее проектирование http://ailev.livejournal.com/542835.html и производство http://www.vtt.fi/inf/pdf/workingpapers/2009/W129.pdf; и т.д.. Не считайте, что вы что-нибудь поняли, если не знакомились подробно хотя бы с этой терминологией). Дело в изменении сути, в другом мышлении, другом инструментарии, других предметах работы и практиках жизненного цикла. Именно это даёт возможность от технологии "избежать ошибок, но не быстрее и не дешевле" для традиционной системной инженерии перейти к технологии "быстрее, дешевле, и без ошибок" (http://ailev.livejournal.com/832543.html) в моделе-ориентированной системной инженерии.

Есть первые обзорчики мировой практики (http://www.opcat.com/docs/MBSE_Methodology_Survey_RevB.pdf, http://ailev.livejournal.com/825754.html), но интересней попробовать заглянуть в будущее и понять, как это будет в ближайшем будущем, а не как есть сейчас у наших более разворотливых друзей. Чтобы быть на переднем крае, нужно что-то самому делать "впервые в мире", ибо при повторении работ тех, кто на переднем крае, ты сам будешь во вторых рядах, просто по определению "переднего края" и "первых рядов".

Я уже делал первые прикидки к новому набору практик (http://ailev.livejournal.com/820662.html, апрель 2010), тут же попробую развить и конкретизировать этот набор, не особо стремясь к полноте и завершенности, но стремясь к подчёркиванию различий с "традиционной" системной инженерией:

Инженерные практики:
1. Инженерия целей (определение user needs, работа со стейкхолдерами, в том числе стандартизация)
2. Инженерия справочных данных (формализация и обобщение опыта предыдущих и смежных проектов, в том числе требования регуляторов и стандарты в части их формализации)
3. Инженерия системной архитектуры (высокоуровневое моделирование и оптимизация архитектуры)
4. Порождающее проектирование по специальностям (низкоуровневое моделирование и доказательства правильности в рамках разных инженерных специальностей)
5. Порождающее производство (до непосредственное изготовление комплектующих по моделям и сборка комплектующих роботами в изделие)
6. Обеспечение качества (верификация и порождение изменений)
7. Поддержка (ремонт по состояниям)

Операционные практики ("управления"):
1. Управление конфигурацией в ходе жизненного цикла целевой системы
2. Управление кейсами (программами, проектами, процессами, цепочками поставок, изменениями и т.д. -- логистика потока работ и предметов работ по выполнителям)

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

Люди должны намереваться/целеполагать, а компьютеры должны помогать воплощать эти намерения. Мечтать об этом не вредно, но и не полезно. Полезно не только мечтать, но и что-то делать в этом направлении. Мы (TechInvestLab в частности, и члены Русского отделения INCOSE в целом) пытаемся создать какие-то отдельные практики этой новой инженерии, и думаем о том, как эти отдельные практики связать в согласованные цепочки в рамках жизненного цикла моделе-ориентированной системной инженерии. Быть в первых рядах, а не копировать во вторые, третьи и десятые ряды опыт первых рядов...

Продолжение -- в http://ailev.livejournal.com/1026036.html и http://ailev.livejournal.com/1026262.html
2019

Я 10 лет в ЖЖ

Сегодня как раз 10 лет с момента моего первого постинга в ЖЖ (http://ailev.livejournal.com/2002/09/07/). Если бы мне тогда сказали, что это постописание будет весьма активным и затянется на столько лет, я бы сильно удивился.

Ладно, продолжим...