Category: дизайн

2019

AMA со мной в CreativeRussia

Опубликовано видео AMA (формат ask me anything) со мной в CreativeRussia, стримилось это live через Hangout на несколько десятков человек 27 апреля 2016г. (https://youtu.be/ey4RNOQEOuk):

Спрашивали о всяком разном, но главным образом про машиноинтеллектуальное творчество. Оно и понятно, Creative Russia ведь как раз сообщество "криэйторов" ("вся соль дизайна, технологий, медиа и стартапов" -- http://creativerussia.co/), а у кого что болит, тот о том и говорит.

Я уж старался "криэйторам" всё "на пальцах" объяснять, даже темп речи у меня медленней обычного получился. Это вполне поправимо: плеер youtube позволяет смотреть это и с удвоенной скоростью.
2019

Нужны ли виртуальные персональные и групповые ассистенты? Не факт!

Вот обратите внимание, как непросто подбирать задачи для Cortana, Google Now, Siri. Для поиска задачек к M городят целый огород с настоящими людьми.

Казалось бы, что на этот интерфейс "помощника" любые утилитки-аппы сядут! Ан нет, аппы продолжают юзаться отдельно, а все эти "умные интерфейсы" продолжают бытовать с вмонтированными в них возможностями отдельно.

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

Ассистент должен сам уметь делать что-то гениальное, а не просто разговаривать. Если есть аппка, то проще этой аппкой воспользоваться самому на голосовом интерфейсе, безо всякого посредника. Аппы сами будут разговаривать, аки люди-эксперты. Секретари для общения с ними могут оказаться не нужны. Посадить пяток аппов, и беседовать с ними. А персональный ассистент? Что он сам должен мочь? "Позови мне Васю и Петю?" Так в виртуальном мире можно просто сказать "ОК, Вася и Петя" вместо "ОК, Гугль, позови Васю и Петю" -- всего-то делов.

К коллективным ассистентам это тоже относится. Или они фасилитаторы/модераторы/менеджеры (то есть приложения, которые что-то умеют, т.е. не "ассистенты-разнорабочие"), или их быстренько дисинтемедиируют. Всё как с людьми.

Платформы, которые дадут вашему гениальному приложению разговаривать без посредников, уже есть:
-- https://api.ai/ (эта платформа и персональных ассистентов поддержит, это же тоже "приложение", например https://assistant.ai/),
-- https://mindmeld.com/
-- Alexa Voice Service, https://developer.amazon.com/public/solutions/alexa/alexa-voice-service
-- https://www.houndify.com/
-- http://viv.ai/ -- viv radically simplifies the world by providing an intelligent interface to everithing
-- ...тысячи их, дальше просто лень смотреть.

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

UPDATE: дискуссия в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10206694169046923
2019

Картинки с текстами vs. тексты с картинками

Что-то щёлкнуло у меня в мозгу, и я таки начал читать мангу. Раньше никогда не получалось: этот жанр был для меня недоступен, я никак не понимал, как можно сравнивать черно-белые картинки с пометками типа "бац" и "жамк" с полноценным текстом или полноценным аниме. Раз в год я делал попытку -- и через двадцать страниц все эти попытки заканчивались, ибо бросал в недоумении. Но в этом году у меня получилось! Я прочёл несколько полномасштабных (размер в 3тыс. страниц картинок -- это не такая уж редкость) манг -- и оказалось, что "послевкусие" от них у меня примерно такое же, как от аниме (и совсем не такое, как от книг). Да, несмотря на отсутствие в манге цвета, звука и движения.

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

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

Про инфографику я подробно писать не буду, там тоже картинки с вкраплениями текста.

LMS (learning management systems) в плане создания контента выродились в слайдовые презентации на стероидах -- учитывая тот факт, что звук и видеоролики в эти слайдовые презентации тоже вставляются элементарно (http://ru.wikipedia.org/wiki/SCORM).

Active essay (www.vpri.org/pdf/tr2009002_active_essays.pdf) сегодня в точных науках делаются довольно легко -- во многих вычислительных системах реализованы notebooks, позволяющие перемежать текст, картинки, фрагменты исполнимого компьютерного кода и области вывода результатов выполнения этих фрагментов кода. Эту идею легко можно распространить и дальше: на все эти "сложные тренажёры" и "моделеры предметных областей".

Да, это всё очень разные жанры донесения содержания:
-- книжка с картинками (текст с картинками)
-- комикс/манга (картинки с текстом)
-- инфографика (сложные картинки с поясняющим текстом)
-- классический "слайдомент" из powerpoint (к которому не предполагается устного выступления)
-- SCORM-пакет в LMS
-- видео (то же аниме, но можно равным образом представить "учебный кинофильм". Меньше всего имею тут ввиду видео говорящей головы лектора -- но и это важно, ибо наблюдение за невербальными акцентами, которые делает лектор, крайне полезно)
-- active essays

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

Что даёт графика в приложении к тексту? Если это художественный текст, то компактную передачу эмоций и дополнительную красоту ("беллетристический аспект"). Если научный -- "беллетрестический аспект", aka "дизайн" в его художественном смысле слова. И уж через этот "дизайн" и об эмоциях в сухом материале тоже можно думать. Также графика может быть ключом к резкому снижению образовательного ценза для восприятия сложного материала: графика задействует иные зоны мозга, нежели требующиеся при чисто текстовой работе с одной стороны, но она может задавать нотацию, в терминах которой легко объяснять сложные явления (струнные диаграммы, фейнмановские диаграммы и т.д.). "Один раз увидеть, чем сто раз прочесть" -- как то так.

У самого меня с картинками отношения сложные. С одной стороны, у меня в аттестате восьмого класса все пятёрки, кроме тройки за рисование (не потому, что плохо рисовал, а потому что всегда забывал принести цветные карандаши), с другой стороны -- по черчению у меня была пятёрка-автомат (ибо я сумел договориться с учителем в первую же неделю принести для какой-то сложной детали два чертежа: в изометрической и диаметрической проекциях -- на спор. Чертежи я принёс, и учитель честно выполнил своё обещание не трогать меня до конца года). А потом всю жизнь я просто никогда не рисовал, ну просто нулевая практика. Я даже писал не ручкой или карандашом, а цокал на клавиатуре.

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

Тут всё очень и очень неоднозначно. Так, я не верю в графические языки для разработки: большие системы нельзя написать на графических языках, для этого пригодны только текстовые языки. Графические языки нужны только для того, чтобы вынести какую-то проблемную диаграммку на суд не слишком разбирающихся в текстовой нотации экспертов, которые будут обсуждать какой-то крошечный аспект проблемы. Но данный пост не про графические языки, он про картинки -- схемы ad hoc, из головы. Он больше про то, что-то сложное рассказывать людям хорошо бы как в манге (см., например, http://www.mangapark.com/manga/molester-man -- обратите внимание, сколько там текста!), а не как в романе Л.Н.Толстого "Война и мир" (можете даже взять иллюстрированное издание). Да, это шапкозакидательное заявление, и можно спорить: тратить ли пару часов на придумывание правильной картинки-схемы, или на полировку текста. Мне почему-то кажется, что создание правильной картинки-схемы в плане отношения затрат времени к количеству переданных из головы авторов в головы читателей ("рассматривателей", ага) знаний более продуктивно. Так, я мог бы долго полировать предыдущую фразу. А мог бы нарисовать картинку (статичную. Вря ли тут бы помог мультик, вряд ли было бы уместно активное эссе).

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

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

Детские визитки

Из серии "куда полезно сходить с дитёнком": сделайте ему визитку. Дитятко вдруг заявил, что ему тяжело писать на всяких бумажках для одноклассников свои номера телефона и адрес блога, а он точно знает, что взрослые для этого имеют заранее распечатанные заготовки. И предложил немедленно распечатать на принтере пачечку визиток.

Я ответствовал, что лучше бы это делать в типографии -- и мы сходили в http://www.a-cifra.ru/contacts/ (это десять минут пешком от нашей двери, и три минуты от "Третьяковской" или "Новокузнецкой". Работают с 10 до 21 без выходных).

Через десять минут диалога дизайнера и клиента получился любимый зелёный фон, шрифты с засечками (как в книжках! объяснить, что это не слишком хорошо в визитках, не удалось), вместо названия фирмы класс и номер школы, телефон, адрес электронной почты и адрес блога. С помощью гугла.картинок был найден правильный зомби из Plants and Zombies, ибо без него требовательный клиент дизайна визитки не принимал. Макет был тут же отправлен клиенту по электронной почте, взятой из самой визитки.

Висеть (при любых других способах не получалось) на рычаге резака было доверено самому дитёнку, а самым трудным и долгим было потом увести дитятку из типографии (ибо там ведь ещё много было вокруг интересного, то есть неподёрганного и непокрученного).

Сделали на "полудизайнерской" бумаге (чуть-чуть тиснёной) аж сто штук односторонних, обошлось вместе с дизайном в 620 рублей.

Сводите своих дитяток, пусть им будет счастье и польза.
2019

4D система и ее жизненный цикл

Вчера на 27 заседании INCOSE рассматривался порождающий дизайн (видео, слайды и картинки -- http://community.livejournal.com/incose_ru/16172.html), докладывал Вячеслав Петухов, а я давал комментарии. Утром я еще некоторое время подумал над высказанными соображениями, и пришел к следующим выводам:

1. Мегамодель системы -- это темпоральная часть системы. Система "в железе" -- это темпоральная часть системы. Трансформации мегамодели и системы нужно отражать в терминах 4D онтологии (например, ISO 15926).

2. Порождения (generation) в мегамодели -- это жизненнй цикл мегамодели. Это generative design. А когда мы порождаем трансформации "в железе" -- это generative manufacturing. Ключевое тут -- это акты порождения, трансформации. Поэтому жизненные циклы нужно показывать как цепочки порождений, а не просто нарастающее количество артефактов/рабочих продуктов. Нужно помнить, что "код на языке высокого уровня", "код на языке машины" -- это две темпоральных части "кода" (причем в ходе трансформации код на языке высокого уровня не исчезает, превращаясь в код на языке машины -- ведь это информационные объекты. А вот прямая труба, выданная в монтаж, превращается в гнутый отрезок трубы, и исчезает при этом -- но это все та же труба, только в разных состояниях. А еще до этого код существовал в виде модели (из которой был порожден кодогенерацией, а потом сгенерированный код был отредактирован, а затем компилирован -- не становясь от этого другим кодом!), а труба существовала в виде чертежей (из которых была порождена в ходе сооружения).



На всех этих картинках не хватает главного: показа трансформаций "одного и того же объекта". Система -- она и в голове система, и в железе, только у нее в жизненном цикле много-много было трансформаций. Мыслить в терминах жизненного цикла -- это как раз мыслить одну и ту же систему с темпоральными частями, которые существуют не всё время. Кодируют "по старинке" только темпоральные части. А ведь нужно еще кодировать и трансформации/морфизмы!
Осторожно выскажу гипотезу: возможно, для записи жизненных циклов нужно использовать моноидальные диаграммы.

3. Поэтому языки из списочка http://ailev.livejournal.com/840977.html должны проверяться на то, соответствуют ли они 4D онтологии или 3D онтологии: разные ли в них объекты до и после трансформации, или же это идут трансформации одного объекта, только в нем меняются темпоральные части в ходе трансформации.
Четко видно, что в одних системах главным является одиночный акт, у которого есть вход и выход -- входят одни объекты, выходят другие. А в других системах цепочка операций происходит над одним и тем же объектом, который проходит через ряд преобразований, оставаясь самим собой в разных состояниях.

4. Понятно, что переход к 4D онтологии породит дикие противоречия "бытового языка" (у нас таки 3D "народная" онтология, т.е. объекты существуют в определенные моменты/срезы времени, а что происходит с ними между этими моментами -- загадка) и 4D языка. Тем не менее, онтологическая шизофрения по поводу попыток описания изменений в языке, в котором нет изменений, а есть средства описания только рядов дискретных состояний, будет меньше. Я начинаю понимать, почему в команде ISO 15926, которая пыталась заниматься жизненным циклом, а не только "проектированием" (когда будущее системы представляется "точкой", а не периодом, в котором система постоянно изменяется), победили сторонники 4D онтологии. Контроль конфигурации (системы, мегамодели, версий кода и т.д.) должен делаться в 4D языке, а в 3D языке это делать не так удобно (хотя и привычней).
Особо отмечу, что для всех "внешних" пользователей ISO 15926 именно 4D "навороты" представляются излишествами и критикуются наиболее сильно как "ненужные для большинства применений". Вот-вот: пока "большинство применений" не связано с жизненным циклом и системным мышлением, 4D не нужно. Если вам не нужно "удерживать целое", то вам не нужно 4D. Если вы не системный инженер, вам не нужно 4D.

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

Литература для начала копаний в 4D-онтологии: http://www.matthew-west.org.uk/publications.html
2019

Из разговора с Rob Hamann

Позавтракали сейчас с Rob Hamann из Дельфтского университета, в прошлом системного инженера по проектам аэрокосмических роботов. На EuSEC2010 он был сопредседателем academic (образовательной? исследовательской? и не переведешь...) секции. Просто, чтобы не забыть некоторые мысли из разговора:

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

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

Выяснилось, что огромное количество системных инженеров не любят INCOSE Handbook (я уже писал, что Мартон Форкош хвастается, что аналогичный NASA Handbook лучше). Rob Hamann использует какую-то древнюю версию середины 90-х, потому как в ней еще сохранились следы обсуждения структуры (продукта) и инструментов (акторов). В текущей версии 3.2 не осталось ничего, кроме процессов -- а это только часть метода! И действительно, текущая версия -- это переписанный ISO 15288, в котором намеренно выкошено все про акторов (роли и инструменты) и продукты (софт, железо и в том числе модели). То есть не учебник, а одна треть учебника. Тем не менее, Роб не пользуется понятием "метод", когда приводит такое рассуждение, "целое" изо всех этих частей у него безымянно и не слишком структурированно. Поэтому он в разговоре пропускает роли, но выпячивает инструменты, а про продукт говорит только "структура" (в оппозицию процессу).

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

Конвергенция: моделецентрическая программная, системная и контрольная инженерия

Продолжим пересказ презентации Janos Sztipanovits "Convergence: Model-Based Software, Systems And Control Engineering" (http://www.infoq.com/presentations/Model-Based-Design-Janos-Sztipanovits). Начало -- http://ailev.livejournal.com/673824.html.

Понятие "платформ" -- не интеграционных, как в MDA и ООП, а для выражения разных свойств динамизма, разных взаимосвязей во времени. "Платформы" -- это слои абстракции в моделецентричном дизайне (model-based design). Например, платформа архитектурных описаний софта, или она же -- платформа описания вычислений (computations). Мы двигаемся от одного слоя абстракции к другому слою, используя разные техники -- преобразования (transformations), синтез, уточнения (refinement). Это и есть моделецентрический дизайн (model-based design). [намеренно не использую тут слово "проектирование" -- как потому, что оно не "конструирование", так и потому, что оно в значении пересекается с проектом-project. Эта переводческая проблема еще ждет своего решения].



Проблемы при использовании моделецентрического дизайна в киберфизических системах:
-- инструменты автоматизации негибки в их design flow, а киберфизические системы весьма гетерогенны, да еще и быстро меняются -- так, что инструментарий их моделирования постоянно отстает. Тут нужно переходить от монолитных закрытых инструментальных сред к каким-то настраиваемым цепочкам открытых инструментов. Возможные решения: предметноспецифические языки моделирования (domain specific modeling languages, DSML), интеграция и трансляция DSML, метапрограммируемая инструментальная инфраструктура, интеграционные фреймворки (в их программистском значении -- не библиотеки, а наоборт, вызывающие структуры) для инструментов дизайна, генерация кода из моделей.
-- системная интеграция весьма гетерогенна и сложна. Тут нужно переходить к полномасштабному (end-to-end) моделированию, быстрому виртуальному прототипированию, специфичным для предметной области абстракциям. Возможные решения: предметноспецифические языки моделирования, интеграция и трансляция DSML, управление моделями (учет изменений состояния моделей, в том числе очень больших моделей и моделей, возникающих в ходе "параллельной разработки" concurrent engineering), DSML и эволюция моделей, архитектурные исследования и имитационное моделирование (simulation).
-- нужна высокая уверенность в дизайне, безопасность (safety, security) и возможность дешевого и быстрого лицензирования (certifiability) сейчас главная забота. Тут нужны специфичные для предметной области (а иногда и для отдельных проблем) интегральные абстракции, не теряющие семантической точности в их определении, чтобы можно было при интеграции как-то соотносить эти абстракции между собой. Возможное решение: явная (explicit), практичная и способствующая объединению (composable) семантика DSML.

Далее из всех этих проблем обсуждаются настраиваемые открытые цепочки инструментов моделирования, опирающиеся на общее семантическое основание. Вот три слоя инструментальной структуры модельно-интегрированных вычислений (model intergated computing, MIC):



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

Пример: general modeling environment GME8 -- http://www.isis.vanderbilt.edu/projects/gme/, базирующаяся на нотации UML диаграмм классов и ограничений OCL. Folders, FCOs (first class objects -- Models, Atoms, Sets, References, Connections), Roles,Constraints and Aspects are the main concepts that are used to define a modeling paradigm. Для этой среды расширения пишутся на традиционных языках программирования с использованием MS COM.

Вся механика модельно-интегрированных вычислений опирается на преобразования моделей: во время вычисления входные модели преобразуются в выходные модели, и это описывается в GME8 на семантике преобразования графов -- тройки метамоделей: метамодель Входа, метамодель Выхода, и метамодель Преобразования. Из результирующего метамодельного графа генерируется исполняющий код. Создать моделер для DSML -- это описать соответствующие предметной области метамодели на UML+OCL, а затем получить готовый код моделера (редактора моделей). Что часто недооценивается, так это наличие структурной (математической структуры) семантики самих метамоделей.

Структура (математический формализм) модели не статична, она эволюционирует в динамике (например, в сетевых встроенных системах, networked embedded systems). И ограничения (constraints) тоже появляются в динамике, во времени. Как работать с этой поведенческой семантикой (behavioral semantics) -- дно из направлений исследований. Не только системы изменяются во времени, но и их модели. Поэтому должны появляться языки моделирования с поведенческой семантикой. Сейчас метамодели определяются с неформально статической семантикой, поведенческая семантика неявно определяется кодом симулятора, кодогенератором, пользовательским комьюнити. Поведенческая семантика определяется примерами и неформальными выражениями намерения (intent). Для некоторых языков моделирования такая формальная семантика разработана с огромными усилиями, нет "устаканившейся" методологии или формализма.

Все поведенческие модели должны быть как-то совместимыми друг с другом: если не знать, как свойства в разных моделях соотносятся друг с другом, нельзя быть уверенным, соотносятся ли друг с другом результаты моделирования. В автомобильной промышленности часто одни средства моделирования показывают, что дизайн безопасный, а другие -- что небезопасный. Это связано с тем, что нет средств семантического сопоставления результатов моделирования.

Эксплицитные методы получения поведенческой семантики: от AST (abstract syntax tree) переходим либо:
-- к коду на языке программирования (например, С++), затем получая либо модуль-модель, либо выполнимый код со спрятанной внутри поведенческой семантикой,
-- либо к правилам переписки графов с явно выражаемой динамикой, а уже от них к выполнимому коду или выполняемой спецификации. Это формальный метод, тут можно использовать формальный вывод.

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

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

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

DSML типа SysML (системная инженерия), AADL (avionics architecture description language) и другие предметно-ориентированные языки, которые развиваются путем распухания, это тупик для комплексирования моделей. Для комплексирования моделей требуется специальное изучение проблемы и создание специальных "внепредметных" языков общего назначания, опирающихся на математические формализмы. Эти языки будут довольно компактными, и помогут бороться с гигантскими и необъятными в своем стремлении ко всеохватности стандартами. Инициативы типа SysML и AADL хороши, но отражают сегодняшнее, а не завтрашнее мышление в моделировании.

Комплексирование моделей сводится не просто к сопоставлению свойств разных моделей, которые имеют там разные наименования. Это вопрос сущностной картины мира (онтологии в ее классическом философском значении). Например, при комплексировании непрерывных моделей (дифуры) и дискретных моделей (конечные автоматы) вообще непонятно, как из связывать друг с другом на уровне языка. Если хочется сделать имитационное моделирование такой системы, описываемой двумя такими моделями, немедленно придется понимать, что означает "связывать модели". Такая интеграция моделей порождает новые семантические предметные области (new semantic domains).

Future combat systems является примером использования моделирования для разработки требований. Требования для такой системы систем (Systems-of-Systems) всегда недостаточны. При обнаружении каждой новой проблемы группа Janosh Sztipanovits быстро определяет новый DSML, разрабатывает соответствующую проблеме модель, и затем выполняет комплексное моделирование уже совместно с этой моделью. Затем проводится анализ результатов, определяется новая проблема, и так требования появляются постепенно по ходу возникающей большой модели. Не было бы моделей, не было бы понимания требований.
2019

Требования, верификация, дизайн

Стоимость верификации софта в Boeing -- 50% от общей его стоимости (http://shemesh.larc.nasa.gov/LFM2008/slides/Session4/Manolios.pdf). Для дизайна интегральных схем -- 30%-70% (http://www.ccs.neu.edu/home/pete/courses/Decision-Procedures/2007-Fall/lectures/Lecture0.pdf). Современный инжиниринг, по идее, должен включать формальную верификацию (http://https://dashlink.arc.nasa.gov/static/dashlink/media/group/Manolios-2008-10-Nasa-Panel.pdf). С другой стороны, верификация и сам дизайн связаны много теснее, чем можно подумать (http://www.cs.cofc.edu/~bowring/classes/csis%20602/docs/ManoliosISSTA.pdf -- тут работали с реальной авионикой Boeing 787, сокращение времени верификации было с нескольких человеко-лет до нескольких человеко-недель, что дало возможность попробовать в дизайне другие архитектуры).

Я ровно месяц назад обсуждал вопрос, что произошло (или вот-вот произойдет) с традиционными проблемами AI в последние несколько лет, когда компьютеры стали весьма мощны (http://ailev.livejournal.com). Вот это и произойдет: использование формальной верификации, сначала в дизайне софта, а затем и любом другом дизайне.

Тем самым к системам работы с требованиями возникают не просто вопросы по а) ее связи с верификацией и валидацией в варианте assurance case (http://ailev.livejournal.com/646290.html), но и б) возможность формулировки требований в виде, доступном для формальной проверки.

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

Тем самым рассматривать какой-нибудь CAD вне связи с полным Vee циклом стадии дизайна (это мы еще исключаем concurrent engineering!) "сбор требований -- анализ требований -- (архитектурный, детальный) дизайн -- верификация -- валидация" сейчас нельзя. Это must.
* * *
Все руки не доходят вернуться к "серой бумаге" (http://ailev.livejournal.com/545386.html). Комменты в том постинге пошли в сторону формы -- "языкоориентированности". А нужно разворачиваться в сторону содержания -- какие языки (сиречь "методы описания") нам нужны, как их структурировать, как сделать так, чтобы сделанные на этих языках описания попадали к нуждающимся в них стейкхолдерам. Собственно, это одна из постановок задачи "управления информацией".

Но пока нужно выполнить план по постам (http://ailev.livejournal.com/647552.html). После этого язык изложения (да и в значительной мере то, что этим языком излагается) будет совсем другим, нежели в годичной давности "серой бумаге".
2019

Об "управление требованиями"

Очень много разговоров про требования в эти предновогодние дни. Запишу кратенько, чтобы потом вернуться к этому вопросу подробнее:

1. Требования, нормы, проект (и в смысле project, и в смысле design), интересы стейкхолдеров и даже сами процессы и их практики -- все это "требования", и с этим нужно еще разобраться.

2. Нет процесса "управление требованиями" в ISO 15288. Там есть два разных процесса -- "сбор требований" и "анализ требований".

3. Согласно Vee-диаграмме, требования потребуются в процессах архитектурного дизайна, а также верификации и валидации (впрочем, и во всех других), поэтому они должны храниться в форме, удобной для этого использования: должна быть предусмотрена трассировка дизайн-решений к требованиям (возможно, по типу assurance case, т.е. через arguments), а для целей верификации и валидации уж точно должна быть предусмотрена форма assurance case, где к claims (соответствующих требованиям) идут связи от evidence (результаты измерений, симуляционного моделирования и других расчетов, актов испытаний и т.д.), причем через agruments -- и нужно понимать, где именно эти arguments, evidence и связи между ними (включая связи к claims) хранятся. Поэтому "IT-система управления требованиями" не должна просто учитывать требования и позволять их быстро искать. Большой вопрос о функциях этой системы, а также о хранимой в ней информации и способах с ней работать -- эти функции и способы работы должны соответствовать не только и не столько процессам "сбор требований" и "анализ требований", сколько другим процессам, в которых требования используются.
2019

Понятийный минимум подхода системной инженерии к управлению жизненным циклом

Если ваша организация вдруг решила заняться системной инженерией, и вы даже раздобыли текст стандарта ISO 15288:2008, то сразу выяснится:
а) о вычитанном в стандарте невозможно говорить по-русски;
б) этого стандарта недостаточно, чтобы понять, о чем идет речь: он упоминает еще пару десятков основных стандартов в самых интересных местах, и нужно также разбираться с этими другими стандартами (архитектурных описаний, процессного подхода и т.д.);
в) центральное понятие (жизненный цикл) непонятно -- достаточно задуматься о том, чем отличаются слова "жизненный цикл" и "управление жизненным циклом" (не говоря уже о "системе управления жизненным циклом системы"). Или попробовать отличить стадии жизненного цикла от процессов жизненного цикла (например, стадию "архитектурный дизайн" от процесса "архитектурный дизайн"). Или понять, почему дизайн всенепременно "архитектурный"?
г) стандарт документоцентричен, и непонятно как его стыковать с датацентричными стандартами типа ISO 15926;
д) совершенно непонятно, с чего начать использование этого стандарта на практике так, чтобы как можно быстрее получить от него пользу.

TechInvestLab.ru в рамках работ над практической организационной системой PraxOS предлагает некоторые ответы на эти вопросы:
а) разработан понятийный минимум подхода системной инженерии к управлению жизненным циклом, причем не только на базе ISO 15288, но и на базе ряда других стандартов;
б) философские основания стандарта сделаны явными;
в) не просто предложены переводы для трудных английских терминов, но и даны их обоснования. Для этих же терминах приведены определения, позволяющие судить об их типах (то есть устроенные по принципу "X -- это специализация Y": "тигр -- это животное, которое большое и хищное").
г) предложено решение, как говорить о документоцентрических и датацентрических системах управления информацией в одном языке, но различать их, когда необходимо;
д) начинать использование стандарта нужно с подготовки "Концепции управления жизненным циклом", в которой перечислить основные целевые системы вашей организации и дать нормативные архитектурные описания процессов управления жизненным циклом для этих систем.

Отныне ответы на подобные вопросы доступны всем не только в форме семинаров, но и в письменном виде. Опубликованы наши свежие разработки по PraxOS:

1. Понятийный минимум подхода системной инженерии к управлению жизненным циклом -- http://www.techinvestlab.ru/495344

2. Требования к "Концепции управления жизненным циклом" -- http://www.techinvestlab.ru/495347

3. Обновленный подстрочник к семинару (слайды) "Подход системной инженерии к управлению жизненным циклом" -- http://www.techinvestlab.ru/486759