SysMoLan (system modeling language): зачем мы это делаем и почему у нас это получится
Зачем нужен ещё один системноинженерный язык, когда у нас есть SysML, Modelica, AADL, P&ID диаграммы, ArchiMate, GSN и множество других чудесных инструментов моделирования для инженера по требованиям и системного архитектора?
Да и перечисленные чудесные инструменты сегодня используются отнюдь не всеми, и явно не распространяются как пожар ("Заметки по трудностям верхнеуровневого моделирования", 2013, http://ailev.livejournal.com/1056723.html -- в качестве причин медленного перехода к MBSE приводятся неочевидность полезности моделирования, отрыв моделирования от принятого в инженерии системного подхода, отсутствие дешёвых и удобных моделеров, непонятность создаваемых моделей ключевым участникам моделирования, модели не учитывают нужды коллективной разработки, модели не рассчитаны на накопление знаний).
Какие плюшки мы должны предложить инженерам, чтобы они выбрали моделирование на Сисмолане? Вот несколько из них (и мы постараемся собрать этих плюшек побольше -- мы честно выучили несколько уроков за прошедших несколько лет):
1. Разные инженеры привыкли работать в различных САПР, в различных моделерах. Дальше проблема не столько в отсутствии мэппинга между моделерами (это не проблема обычно), сколько в невозможности устроить полноценную коммуникацию между людьми, работающими с разными моделями. ISO 42010 предложил различать
-- синтетический подход, при котором отдельные модели-документы независимы и готовятся в разных САПР (authoring tool), а потом мы их объединяем, как-то указывая на соответствие элементов моделей друг другу и храня эти соответствия где-нибудь ещё (например, система registry позволяет обозначить компонент, а потом мы этот компонент указываем в самых разных документах, используя именно это обозначение и добавляя разную информацию про этот компонент -- скажем, глядя глазами на одну диаграмму, и вбивая нужное имя в нужную табличку другого документа).
-- прожекторный подход (у театрального прожектора белая лампочка, но мы можем получить любой цвет, поставив светофильтр), когда есть одна база данных описания системы, а отдельные модели мы получаем фильтрацией этой базы данных -- читая или записывая только элементы, нужные для этой модели.
Исторически, конечно, развивался синтетический подход: много разных САПР поддерживали много разных моделирований. Все эти САПРы втыкались в какую-то PLM. В части PLM мы уже понимаем, куда идёт развитие: в сторону прожекторного подхода (подробней рассказано в "Четыре поколения информационных систем для инженерных проектов", 2011, http://ailev.livejournal.com/965124.html -- там мы это называли датацентричными системами в противовес документоцентричным).
В реалии языков моделирования именно такой "датацентрический" (прожекторный) подход показал Архимейт: дизайн-цель там была обеспечить коммуникацию между разработчиками моделей деятельности (какими-нибудь службами качества), моделями софта (какими-нибудь "службами САПР" или "службами ERP") и моделями оборудования и связи (какими-нибудь "службами IT). Решение было простым: иметь возможность нарисовать одну диаграмму с элементами разных моделей, нужных этим разным службам. А если эти службы хотят увидеть информацию только для них -- фильтровать, механизм view (тематических для каких-то стейкхолдеров групп описания). Но можно фильтровать и так, что диаграммки будут отражать именно связи между обычно разными моделями, позволяя разным группам отмоделировать и обсудить эти связи.
Это был успех, Архимейт достиг заявленных целей и стал одним из самых быстро развивающихся архитектурных языков (сейчас интерес к нему, определяемый по Google Trends уже догнал появившиеся чуть пораньше SysML и Modelica и обогнал ISO 15926, хотя некоторое время и был на одном уровне: http://www.google.com/trends/explore#q=archimate%2C%20sysml%2C%20ISO%2015926%2C%20modelica&cmpt=q
Сисмолан -- это прожекторный язык. Он позволяет отмоделировать всё, и ещё чуть-чуть, а затем каждому стейкхолдеру показать только то, что ему нужно.
Зачем мы делаем проективный язык? Почему бы не продолжать использовать букет из сегодняшних языков системного моделирования -- SysML+AADL+Modelica+Essence+ArchiMate? Все эти языки (хотя и каждый по-своему) описывают какой-то кусочек проблемы, остаётся лишь собрать воедино все описания, плюс из бонусов никого не нужно переучивать и весь инструментарий уже есть. Зачем нам нужен новый язык?
Непрерывно пухнущее и разбухающее знание системноинженерного мышления, практик системной инженерии и системноинженерного менеджмента нужно время от времени компактифицировать, а иногда и со сменой репрезентаций. Так прирастает человеческое знание в любой сфере. SysMoLan делает именно это: компактифицирует сегодняшнее знание о системноинженерном мышлении (см. подробней пункт 6 в "Компактификация методического знания и сопутствующие гносеологические проблемы", 2010, http://ailev.livejournal.com/872954.html, а в других пунктах аргументы в пользу работы по компактификации).
SysMoLan экономит мышление, компактифицирует знание. Не нужно изучать пять языков, чтобы утрясти информацию по какому-то инженерному объекту, отражённому в моделях на этих пяти языках. Нужно изучить один. Кто уже выучил пять языков, тому есть что терять. Кто не выучил ещё ни одного, может задуматься, учить ли ему их или один SysMoLan.
2. Но есть ещё одна тонкость, которая позволила Архимейту справиться с задачей объединения разных моделей, но представляет огромную проблему для современных PLM. Это реляционная или объект-ориентированная (объект-атрибутная) природа хранилищ данных в PLM. Каждый новый САПР удаётся прицепить большой кровью, ибо "что в одном САПР объект, то в другом атрибут, и наоборот". Если тебе дают "атрибут", считают его "объектом" и требуют добавить атрибутов к этому атрибуту, то нужно существенно перерабатывать схему базы данных! И так каждый раз при добавлении очередного САПР.
Ещё один кошмар -- это справочные данные для проектных САПР (для машиностроения это не так важным оказалось), в которых нужно описывать оборудование. 10 тысяч классов оборудования (насосы, задвижки, моторы) набегают легко, описание каждого из них требует своей таблицы в реляционной базе данных. Работа с десятками тысяч таблиц (а не записей в таблицах) становится невозможной очень быстро, не хватает ни средств ведения схемы базы данных, ни скорострельности запросов в базе данных с такой сложной схемой.
Выходом из этого является переход к факт-ориентированному от объект-ориентированного описания (и не будем называть это "семантикой", это слово сейчас чаще всего означает Semantic Web, а нам это лишнее). Всё больше и больше людей хочет держать данные в "графовых базах данных" (трипл-сторах, "безсхемных базах данных"), подробней в "Про ECM и PLM, а также пятое поколение инженерных информационных систем", 2011, http://ailev.livejournal.com/965564.html
Про факт-ориентированность (достоинства графовых баз данных, семантической обработки данных) написаны горы литературы, семантик-вебовцы постарались. Но нам не нужен семантик веб, мы за модой не гонимся. Рекомендую первую половину книжки Chris Partridge “Business Objects: Re-Engineering for Re-Use” http://www.borosolutions.co.uk/research/content/files/books/BusObj-Printed-20050531-with-watermark.pdf/at_download/file, я называю это "антиаристотелевщина" (Витгенштейн сказал, что мир дан нам не в объектах со свойствами первичными и вторичными, как говорил Аристотель, а в фактах о том, как относятся между собой объекты. Мы про объекты можем сказать только то, как они относятся к другим объектам, и ничего -- никаких атрибутов -- про сам объект).
Если говорить про базы данных, то переход к трипл-сторам (трипл это тройка: объект1-отношение-объект2) сдерживался только тем, что они были поначалу помедленней, чем реляционные базы данных. Сейчас факт-ориентированные базы данных сравнялись по скорости с реляционными базами данных, а на сложных запросах могут и опережать их.
Как с этим справился Архимейт? Он сразу был факт-ориентированным: в нём есть сущности и отношения, а атрибутов нет. Это позволяет легко и непринуждённо развивать язык, добавлять новые и новые предметные описания к уже имеющимся (например, ArchiMate 2.0 не столько поменял сам язык Архимейт, сколько добавил в него новые элементы и отношения для моделирования требований и поддержки самой архитектурной работы -- ничего существенного перепланировать не потребовалось. Новые элементы и отношения просто добавляются, это и есть достоинство факт-ориентированного описания).
Sysmolan -- это факт-ориентированный язык. Когда необходимо его расширять (то есть он не позволяет что-то отмоделировать, и нужно добавить эту возможность), он легко позволяет это сделать, просто добавьте новые виды объектов и отношений.
Это серьёзное конкурентное преимущество перед объект-ориентированным SysML, который рассматривается сейчас как один из главных кандидатов на язык системного моделирования (про то, что же в нём системного, мы пока умолчим).
3. Люди, которые были недовольны объект-ориентированной природой стандартов STEP (ISO 10303) для инженерной информации, поняли, что стандарт не решит поставленной задачи: не позволит создавать "интеллектуальную модель изделия", "цифровой макет", "информационную модель сложного инженерного объекта" и т.д., причём не только потому что STEP был объект-ориентированным, и не получилось складывать вместе в одну базу данных проектные данные, созданные в соответствии с его разными схемами данных. Нет, факт-ориентированного описания для сборки нескольких разных моделей в одно связное описание системы оказалось мало. Нужно было понять, как сопоставлять разные объекты на разных моделях -- и для этого пришлось обратиться к онтологии.
Онтология (по Тому Груберу) это формализованная концептуализация, общая для многих (shared). Онтология отвечает на вопрос "какие концепты -- т.е. объекты и отношения между ними -- есть в этом мире (включая воображаемые, прошлые, будущие, потенциально возможные, информационные, физические и т.д.)?". Ответ при этом требуется формальный и согласованный с каким-то сообществом, солипсизм какого-то отдельного человека в качестве онтологии не подходит -- онтология выполняет коммуникационную функцию тоже. Онтология оказалась нужна инженерам для формальной записи информации различных моделей системы, в которой как-то бы гарантировалось, что эти модели описывают одно и то же устройство мира -- и обмена информацией между моделями. Если грубо, то есть много разных способов записать смену насоса на насосной станции (на принципиальной схеме остаётся один и тот же насос, но вот насос с серийным номером меняется -- иногда на насос совсем другой модели другого производителя), и нужно договориться как объединить модели закупщиков и проектантов (часто разрабатываемые разными людьми в разном софте) так, чтобы компьютер не запутался при их объединении. Многие из этих способов плохи, некоторые хороши. Нужно было договориться так описать мир, поделенный на объекты и отношения, чтобы компьютер не запутался, и можно было бы выражать такие типовые ситуации инженерной работы. И инженеры договорились, создав справочные данных ISO 15926 -- инженерную онтологию.
В ISO 15926 за основу взяли идеи философской логики, позволяющие выразить модель мира, согласованную с системным подходом, принятым в инженерии. Например, 4D экстенсионализм позволил отождествлять объекты разных моделей в общее описание системы (отождествлять в одной системе разные её ипостаси -- функциональную, модульную, пространственную). Конструкция класса классов позволила использовать различные классификаторы, не выделяя из них "главный" -- ибо для разных профессий (тех же проектантов и закупщиков) удобны разные "главные" классификации, и они никогда не договорятся.
К примерно таким же онтологическим выводам пришли и многие другие стандарты:
-- ISO 42010 рассказал, что не бывает одного описания системы, но только множество этих описаний, ибо есть много разных стейкхолдеров. Для каждого тематического вида описаний -- view (состоящего из моделей) стандарт потребовал указать метод описаний -- viewpoint (дисциплину, раскрывающую часть онтологии: какие виды объектов записывать)
-- ISO 81346 указал, как обозначать элементы системы, существующие во многих ипостасях -- и декларировал минимальное число этих ипостасей. Плюс он рассказал, как "разбирать систему на части" с учётом различных ипостасей.
-- ISO 42010 и OMG Essence указали на различие дисциплины (как думаем о системе в терминах идеальных объектов), позволяющей определять систему, и практики, позволяющей описывать систему (документировать систему в виде рабочих продуктов)
-- ISO 15288, OMG Essence показали важность описания системы деятельности (обеспечивающей системы, enabling system в ISO 15288, client и endeavour domain of interest в OMG Essence), обеспечивающей жизненный цикл целевой системы. Нужно уметь описывать не только саму систему, но и практики её жизненного цикла, и вид жизненного цикла.
SysMoLan гармонизирует находки всех этих стандартов, предлагая совместимый с этими инженерными стандартами способ документирования определения системы. Это означает, что SysMoLan реализует онтологию системного подхода в своей основе: в нём можно выражать различные ипостаси системы на разном уровне разбиения системы на подсистемы и элементы.
Слово "системный" в словосочетаниях system thinking, system approach, systems engineering означает мышление в рамках онтологии систем. SysMoLan -- System Modeling Language, язык системного моделирования -- содержит слово System именно в этом смысле, он поддерживает онтологию систем, системный подход, системное мышление, системное моделирования прямо "из коробки". Заметим, что в SysML и Modelica это не присутствует.
Как и ArchiMate оказывается не только архитектурным языком, но и архитектурным подходом (framework: он диктует не только как записывать архитектуру, но и как думать об архитектуре и как делать архитектурные описания), так и SysMoLan более полно можно назвать -- язык и подход системного моделирования. SysMoLan служит не только для записей различных моделей системы, но и воплощает в себе системный подход (в данном случае не только aproach, но и framework).
4. ISO 15926 не только предложил онтологические решения (идеи о том, как устроен мир с точки зрения системного подхода -- прежде всего 201 тип сущности, которые позволяют описать невероятно большое количество инженерных моделей), но и способ документирования моделей системы. Но в этом месте разработчики сделали ошибку: они пошли вслед за модой семантического веба и создали чересчур сложный формат записи этой онтологии. Мало того, что этот формат вообще не был приспособлен для чтения человеком (а только для чтения программами), так он оказался крайне сложен для освоения любыми программистами. Конкретно, в этом стандарте в основе лежат нечитабельные URI (программисты давно забыли, как выглядят адреса в оперативной памяти -- но спокойно пишут свои программы. А ведь эти URI имеют именно такой смысл! Почему кто-то должен смотреть на эти адреса без крайней на это необходимости?!). Также они реифицировали отношения (показали, что само отношение состоит из нескольких объектов), что само по себе хорошо. Но это оказалось и очень плохо: вместо желаемого инженером отношения нужно каждый раз придумывать и записывать множество разных объектов со своими именами, это огромный накладной расход. Реификация должна быть только тогда, когда она действительно уместна.
Сообщество за последнюю пару лет придумало новый способ "поднять уровень языка" ISO 15926 -- это так называемые паттерны данных. Но по факту это оказалось только "нахлобучкой" сверху уже очень большого и сложного стека технологий. И шанса, что кто-то освоит эту технологию "подъема уровня языка" нет, слишком мало будет тех людей, которым под силу будет заняться этим "подъемом уровня".
John Sowa сформулировал свой "закон стандартизации", аргументирующий важность недоспецификации предметной области: если и разработан какой-то стандарт, то результатом будет распространение упрощённой версии этого стандарта (http://en.wikipedia.org/wiki/John_F._Sowa#Sowa.27s_law_of_standards).
SysMoLan не будет отражать всё то, что в состоянии отразить все перечисленные стандарты, в особенности ISO 15926. Нет, он отразит только самое важное и намеренно будет простым (как и Архимейт, который "опишет 20% ситуаций, встречающихся в 80% случаев"). С другой стороны, SyMoLan будет снабжён достаточными средствами для расширения языка.
Что же будет отражать SysMoLan? В Shell были исследования, показавшие, что в ходе всего жизненного цикла для какого-то сложно устроенного насоса нужно хранить лишь 20 единиц данных, хотя в ходе разработки о нём используется до 1500 данных. Мы постараемся сделать так, чтобы в SysMoLan попали все эти 20 единиц "из коробки" (а остальные 1500 единиц данных можно было бы представить расширениями языка -- "профилями" как в UML, "библиотеками справочных данных" как в ISO 15926, дополнениями как в Archimate и т.д.).
SysMoLan не будет использовать идеи семантического веба, но обопрётся на аналогичные идеи моделирования данных, хорошо отработанные в мире традиционного программирования (даже не в мире баз данных!). Это позволит в разы и разы упростить работу с языком. Никакого OWL/RDF/XML стека, онтологии всегда можно было записывать по-другому. Это не значит, что моделям системы и их элементам нельзя будет давать адреса в интернете! Но их никто не увидит, как никто не увидит в текстах программ адресов оперативной памяти. Забота о URL должна лечь на что-то типа "компилятора" и "линкера/мейкера", сам язык в этих URL не нуждается (хотя они и могут быть из него доступны).
5. Логические языки представления факт-ориентированной информации не получили большого распространения, ибо в них трудно соединить ход вычислений с внешним миром -- что-то запросить у пользователя в ходе обработки или подождать ответа от далёкого сервера. Совсем недаром про успешный Prolog шутят, что у него половина от фортрана! В этом плане функциональные языки оказались лучше (в том числе для связи функционального и логического миров всегда можно вспомнить о Curry-Howard, или подключить логический ризонер в виде внешней "библиотеки" -- по специально организованному запросу).
SysMoLan, конечно, будет мультипарадигмальным в своих "запросных" и "трансформационых" аспектах, но прежде всего он будет функциональным, и только потом "логическим" языком. В этом изюминка: факт-ориентированный функциональный (а не традиционный логический) язык. Никаких требований к гарантированной decidability тем самым в SysMoLan нет, приоритет отдаётся не "вычислимости", а выразительности.
В основе SysMoLan является представление онтологической информации в виде паттернов данных. Паттерн данных с одной стороны представляется чисто программистским объектом (данные в отличие от информации не имеют значения и смысла, они обрабатываются по определенным алгоритмам, и только), а с другой стороны они наделяются онтологическим смыслом. Работа с паттернами больше похожа на работу с грамматиками, поэтому паттернированное выражение мира обычно чрезвычайно компактно и достаточно строго.
Паттернирование даёт систематический способ расширять язык, охватывать новые и новые предметные области. По сути дела, это концепция встроенных в базовый SysMoLan DSL (подробней на эту тему, а также объяснение почему это невозможно сделать в SysML: http://levenchuk.com/2009/12/08/sysml-is-the-point-of-departure-for-mbse-not-the-destination/).
Тем самым SysMoLan представляет собой нечно среднее между "псевдокодом" (записями моделей, не имеющими документированную в формальном логическом языке семантику -- то есть не подлежащими компьютерной обработке иной, нежели хранение и выдача хранимых единиц по запросу, таким языком является, например ArchiMate) и "кодом" (записями моделей, имеющими формальную семантику -- то есть такими моделями, на который можно напустить солвер, таким языком является опирающийся на MOF SysML и Modelica). Это будет и язык представления моделей/данных, и язык запросов к моделям/данным, и язык трансляции/конверсии/трансформации данных.
Но в SysMoLan (как и в Архимейте с его derivative relations) делаются попытки формализации важнейших аспектов описания систем. Более того, моделер будет пытаться помогать в этой формализации (разбор полнотекстовых описаний с возможными запросами к пользователю на их уточнение, привлечение внешних справочных данных для снятия неопределённостей, использование логического вывода и контекста для верификации/нахождении противоречий и ошибок в моделях и т.д.). Так что один из лозунгов SysMoLan -- это "от псевдокода к коду, при помощи компьютера".
6. Опыт любых языков описания показывает, что к этим описаниям нужны язык запросов и язык конверсии в другие представления (трансформации, мэппинга). Для каждого OWL нужно договориться о его SPARQL, для каждого XML нужно договориться о его XSLT.
SysMoLan позволит не только выражать данные, он позволит их запрашивать! Это означает, что можно говорить о серверах системной информации, поддерживающих запросы.
Эти сервера будут работать сразу не в программистских терминах, а в терминах системного подхода. Вся "программистская часть" будет спрятана в них "под капотом". SysMoLan это не только язык системного моделирования, это и язык запросов к системным моделям (типа SQL, SPARQL), и язык преобразования (мэппинга) системных моделей (типа XSLT, QVT, ATL).
В отличие от ISO 15926, в котором до сих пор не нашлось места для описания ограничений (хотя и предложено делать это на Plan9) и SysML, в котором ограничения можно описывать на отдельном языке OCL, SysMoLan будет поддерживать ограничения "из коробки", так что вполне можно думать и о contract-based design.
7. Современные языки описания систем имеют сразу два представления: текстовое и графическое. Текстовое представление позволяет легко программно генерировать записи на этих языках, а также читать их не только человеку, но и компьютеру. Текстовое представление в разы и разы удобней, когда описания на этом языке большие по объему (помним, как вымерли блок-схемы компьютерных программ и до сих пор не могут прижиться визуальные языки программирования: просто программы стали большие!). Графические описания важны, когда человеку нужно представить наглядно топологию: что там с чем связано в небольшом описании. Два вида представления моделей имеет OMG Essence, два вида представления моделей имеет Modelica.
SysMoLan тоже имеет два вида конкретного синтаксиса представлений (кроме неминуемого "абстрактного синтаксиса"), хотя разработку мы начнём с текстового (и не только потому что это проще, но и для того, чтобы отработать SysMoLan как язык запросов и как язык преобразований).
В инженерии это общепринято: например, так устроена Modelica.
8. Современная инженерия невозможна без описаний на естественных языках. В SysML пришлось добавить текстовые описания для требований по сравнению с UML. SysMoLan обобщает это: в него можно включать полнотекстовые описания на равных правах с модельными описаниями, а не только требования. Плюс из этих описаний всегда можно "вытащить" структурированную информацию и выразить её на самом SysMoLan (язык запросов это поддерживает). Интеграция со всякими DOORS становится вполне возможна.
Лозунг: SysMoLan не воюет с естественным языком, он вместе с ним!
Вообще, SysMoLan по возможности ориентирован на гибридные вычисления:
-- логический (функциональный) вывод/reasoninc для информации о структуре, контрактах модулей (contract design)
-- численные вычисления для мультифизики (как в Modelica)
-- текстовые вычисления (a la IBM Watson -- ответы на вопросы. Или извлечение информации, "понимани", a la CYC)
-- в принципе, сюда же может быть добавлена и геометрическая информация, для геометрических солверов
В этом смысле SysMoLan нацеливается поучаствовать в движении поиск-ориентированной системной инженерии и другой пост-моделеориентированной жизни: http://ailev.livejournal.com/1122876.html
9. Предполагается, что SysMoLan в какой-то момент будет стандартизован. Стандартизация обычно предполагает:
-- коллективное обсуждение и открытость спецификации, понятную процедуру изменения спецификации
-- наличие модельной реализации (доказывающей реализуемость на практики), т.е. сервера и моделера
-- иногда (но не всегда) наличие нескольких реализаций, демонстрирующих совместимость (в консорциуме OASYS стандарт публикуется только после того, как минимум три члена этого консорциума реализовали стандарт. "Неудачный стандарт стандартом не назовёшь").
Наша цель тут -- чтобы SysMoLan стал не менее популярным языком MBSE инициативы INCOSE, чем SysML, AADL, Modelica. Так что вокруг SysMoLan мы планируем некоторую формальную организацию стандартизации (и для поддержки этой организации мы зарегистрировали http://sysmolan.org). Но, как водится в этой стандартизации, на вход стандартизации должен поступить какой-то проект стандарта, коллективная разработка "с белого листа" оказывается неэффективной, проще обсуждать "по тексту" и модельной реализации, если они есть.
Вспомним также закон John Sowa, что при слишком детальной стандартизации-переспецификации в жизнь выйдет не SyMoLan, а более простой вариант для того же самого, так что и со стандартизацией нужно не переусердствовать: удовлетворяющий всех стандарт по факту не удовлетворит никого.
10. SysMoLan служит для накопления знаний. Это означает, что на нём легко подготовить:
-- типовые требования (например, содержащиеся в стандартах)
-- типовые высокоуровневые архитектуры (например, содержащиеся в учебниках)
-- типовые запросы для какого-то сорта комбинированных моделей
Эти знания будут накапливаться в библиотеках справочных системных моделей (по аналогии с библиотеками справочных данных ISO 15926 и библиотеками Modelica).
В этом плане SysMoLan -- это язык представления и накопления инженерных знаний.
11. Какие области применения SysMoLan будут первоочередными?
11.1. Инженерия: "ранние стадии жизненного цикла" (несмотря на то, что эти практики выполняются в ходе всего жизненного цикла, а часто их и вовсе называют "системная инженерия") -- инженерия архитектурных требований и системной архитектуры. "Архитектурный" тут -- это те самые 20% требований и отвечающих им инженерных решений, которые определяют 80% устройства системы. То есть в этом плане SysMoLan -- это язык целеориентированной инженерии требований (типа GSN или i*) и системной архитектуры (типа SysML, AADL, Modelica -- да, мы считаем Modelica и архитектурным языком, а не только языком мультифизического моделирования), а также описания вида жизненного цикла (типа OMG SPEM 2.0 и OMG Essence) и даже организации разработки (ArchiMate) -- и дикий зоопарк продуктов.
11.2. Образование: поскольку SysMoLan поддерживает "из коробки" основные инженерные концепты в рамках системного подхода, он становится идеальным для обучения студентов видеть мир в терминах систем, начальная стадия обучения системного инженера. Это означает, что в дополнение к языку должен быть разработан курс системноинженерного мышления. По факту, такой курс уже разработан, но он пока никак не использует язык моделирования -- http://techinvestlab.ru/files/systems_engineering_thinking/systems_engineering_thinking--TechInvestLab_2014.pdf. После появления хотя бы первых версий языка и моделера этот курс будет существенно переработан не столько в части его содержания, сколько в части упражнений: понимание будет тренироваться и проверяться на решении задач системного моделирования. Для моделе-ориентированной (model-based, model-driven) системной инженерии нужно моделеориентированное системное мышление.
11.3. Интеграция данных (федерирование инженерных информационных систем): поскольку SysMoLan является наследником ISO 15926, то все его достижения и наработки по федерированию данных жизненного цикла, находящихся в разных инженерных системах, вполне приложимы к SysMoLan. Это будет даже лучше, ибо язык стандартизует не только онтологию ("справочные данные") и средства её пополнения, но и как запрашивать данные жизненного цикла, и как преобразовывать их в/из альтернативных представлений в разных инженерных информационных системах. Редактор/моделер SysMoLan должен быть дополнен сервером (поддерживающим язык запросов) и адаптором (обеспечивающим экспорт-импорт в/из разных форматов данных). В этом плане SysMoLan поддерживает пункт 13 из http://ailev.livejournal.com/872954.html -- он предлагает компактное представление нового знания, а для уже имеющегося знания в старых форматах он предлагает мэппинг.
* * *
Этот текст представляет собой обновление и расширение предыдущих двух текстов с постановкой задачи: февральского http://ailev.livejournal.com/1061167.html и июньского http://ailev.livejournal.com/1122497.html. Он рассчитан на тех, кто знаком с упомянутыми в нём языками, стандартами и идеями (сейчас ситуация чуть полегче: для начального знакомства теперь можно прочитать книжку "Системноинженерное мышление в управлении жизненным циклом", 306 страниц по-русски -- . Теперь "для маркетинга" нужно бы переписать его "на чистых идеях", чтобы не поминать ненужных имён стандартов, но я бы перед этим хотя бы чуть-чуть спрототипировал язык. нулевая версия могла бы использовать паттернированую запись триплов для архимейт-подобных диаграмм, плюс многоипостасийные структурные имена, почёрпнутые из ISO 81346. Для детекторного приёмника запись выбора оборудования при этом может быть чем-то вроде =детектор1((реализован((-диод Д 161-320-18 ((имеет((ударный прямой ток((7500@А
На конкретный синтаксис в деталях (обработка пробелов и т.д.) пока внимания не обращаем, а вот как компактненько показать паттерн из нескольких триплов про одно и то же -- вот это да, этим как раз и занимаемся. Так, префикс = из ISO 81346 для =детектор1 означает для , что детектор1((тип((компонент, т.е. функциональный объект с принципиальной схемы. Префикс - в -диод Д 161-320-18 по ISO 81346 означает, что диод Д 161-320-18((типа((модуль, то есть "продукт" из каталога. Всё это "дизайн в классах", что делать с классификаторами и индивидами придумаем чуть позже. А когда отмоделируем детекторный приёмник, то начнём работать с подуровнями системы. Потом добавим описания (ибо на SysMoLan нужно описавать не только саму систему, но и её модели -- это язык мегамоделирования!).
Вместо скобок я бы предпочёл лесенки (не люблю закрывать скобки). Так, чтобы выдать ещё какую характеристику для диода этого детекторного приёмника, я бы писал:
=детектор1((реализован((-диод Д 161-320-18 ((имеет((
ударный прямой ток((7500@А
частота максимальная((500@Гц
* * *
Проблемы для постепенного решения:
-- киберфизические системы (попытки решения в AADL: стык оборудования и софта)
-- какая-то более-менее развитая онтология информатики (software engineering)
-- акаузальное мультифизическое моделирование (Modelica)
-- требования и motivation (хотя бы как в i* или лучше)
-- модуляризация
-- графический синтаксис
-- обоснования по ISO 15026 и так далее (http://ailev.livejournal.com/811715.html)
-- как делать model cheсking (верификация)
* * *
Отдельный вопрос -- это прототипная реализация (сервер, моделер, адаптеры). К этому уже приступили. Не забываем про чеклист для современного моделера -- http://ailev.livejournal.com/1041274.html
Да и перечисленные чудесные инструменты сегодня используются отнюдь не всеми, и явно не распространяются как пожар ("Заметки по трудностям верхнеуровневого моделирования", 2013, http://ailev.livejournal.com/1056723.html -- в качестве причин медленного перехода к MBSE приводятся неочевидность полезности моделирования, отрыв моделирования от принятого в инженерии системного подхода, отсутствие дешёвых и удобных моделеров, непонятность создаваемых моделей ключевым участникам моделирования, модели не учитывают нужды коллективной разработки, модели не рассчитаны на накопление знаний).
Какие плюшки мы должны предложить инженерам, чтобы они выбрали моделирование на Сисмолане? Вот несколько из них (и мы постараемся собрать этих плюшек побольше -- мы честно выучили несколько уроков за прошедших несколько лет):
1. Разные инженеры привыкли работать в различных САПР, в различных моделерах. Дальше проблема не столько в отсутствии мэппинга между моделерами (это не проблема обычно), сколько в невозможности устроить полноценную коммуникацию между людьми, работающими с разными моделями. ISO 42010 предложил различать
-- синтетический подход, при котором отдельные модели-документы независимы и готовятся в разных САПР (authoring tool), а потом мы их объединяем, как-то указывая на соответствие элементов моделей друг другу и храня эти соответствия где-нибудь ещё (например, система registry позволяет обозначить компонент, а потом мы этот компонент указываем в самых разных документах, используя именно это обозначение и добавляя разную информацию про этот компонент -- скажем, глядя глазами на одну диаграмму, и вбивая нужное имя в нужную табличку другого документа).
-- прожекторный подход (у театрального прожектора белая лампочка, но мы можем получить любой цвет, поставив светофильтр), когда есть одна база данных описания системы, а отдельные модели мы получаем фильтрацией этой базы данных -- читая или записывая только элементы, нужные для этой модели.
Исторически, конечно, развивался синтетический подход: много разных САПР поддерживали много разных моделирований. Все эти САПРы втыкались в какую-то PLM. В части PLM мы уже понимаем, куда идёт развитие: в сторону прожекторного подхода (подробней рассказано в "Четыре поколения информационных систем для инженерных проектов", 2011, http://ailev.livejournal.com/965124.html -- там мы это называли датацентричными системами в противовес документоцентричным).
В реалии языков моделирования именно такой "датацентрический" (прожекторный) подход показал Архимейт: дизайн-цель там была обеспечить коммуникацию между разработчиками моделей деятельности (какими-нибудь службами качества), моделями софта (какими-нибудь "службами САПР" или "службами ERP") и моделями оборудования и связи (какими-нибудь "службами IT). Решение было простым: иметь возможность нарисовать одну диаграмму с элементами разных моделей, нужных этим разным службам. А если эти службы хотят увидеть информацию только для них -- фильтровать, механизм view (тематических для каких-то стейкхолдеров групп описания). Но можно фильтровать и так, что диаграммки будут отражать именно связи между обычно разными моделями, позволяя разным группам отмоделировать и обсудить эти связи.
Это был успех, Архимейт достиг заявленных целей и стал одним из самых быстро развивающихся архитектурных языков (сейчас интерес к нему, определяемый по Google Trends уже догнал появившиеся чуть пораньше SysML и Modelica и обогнал ISO 15926, хотя некоторое время и был на одном уровне: http://www.google.com/trends/explore#q=archimate%2C%20sysml%2C%20ISO%2015926%2C%20modelica&cmpt=q
Сисмолан -- это прожекторный язык. Он позволяет отмоделировать всё, и ещё чуть-чуть, а затем каждому стейкхолдеру показать только то, что ему нужно.
Зачем мы делаем проективный язык? Почему бы не продолжать использовать букет из сегодняшних языков системного моделирования -- SysML+AADL+Modelica+Essence+ArchiMate? Все эти языки (хотя и каждый по-своему) описывают какой-то кусочек проблемы, остаётся лишь собрать воедино все описания, плюс из бонусов никого не нужно переучивать и весь инструментарий уже есть. Зачем нам нужен новый язык?
Непрерывно пухнущее и разбухающее знание системноинженерного мышления, практик системной инженерии и системноинженерного менеджмента нужно время от времени компактифицировать, а иногда и со сменой репрезентаций. Так прирастает человеческое знание в любой сфере. SysMoLan делает именно это: компактифицирует сегодняшнее знание о системноинженерном мышлении (см. подробней пункт 6 в "Компактификация методического знания и сопутствующие гносеологические проблемы", 2010, http://ailev.livejournal.com/872954.html, а в других пунктах аргументы в пользу работы по компактификации).
SysMoLan экономит мышление, компактифицирует знание. Не нужно изучать пять языков, чтобы утрясти информацию по какому-то инженерному объекту, отражённому в моделях на этих пяти языках. Нужно изучить один. Кто уже выучил пять языков, тому есть что терять. Кто не выучил ещё ни одного, может задуматься, учить ли ему их или один SysMoLan.
2. Но есть ещё одна тонкость, которая позволила Архимейту справиться с задачей объединения разных моделей, но представляет огромную проблему для современных PLM. Это реляционная или объект-ориентированная (объект-атрибутная) природа хранилищ данных в PLM. Каждый новый САПР удаётся прицепить большой кровью, ибо "что в одном САПР объект, то в другом атрибут, и наоборот". Если тебе дают "атрибут", считают его "объектом" и требуют добавить атрибутов к этому атрибуту, то нужно существенно перерабатывать схему базы данных! И так каждый раз при добавлении очередного САПР.
Ещё один кошмар -- это справочные данные для проектных САПР (для машиностроения это не так важным оказалось), в которых нужно описывать оборудование. 10 тысяч классов оборудования (насосы, задвижки, моторы) набегают легко, описание каждого из них требует своей таблицы в реляционной базе данных. Работа с десятками тысяч таблиц (а не записей в таблицах) становится невозможной очень быстро, не хватает ни средств ведения схемы базы данных, ни скорострельности запросов в базе данных с такой сложной схемой.
Выходом из этого является переход к факт-ориентированному от объект-ориентированного описания (и не будем называть это "семантикой", это слово сейчас чаще всего означает Semantic Web, а нам это лишнее). Всё больше и больше людей хочет держать данные в "графовых базах данных" (трипл-сторах, "безсхемных базах данных"), подробней в "Про ECM и PLM, а также пятое поколение инженерных информационных систем", 2011, http://ailev.livejournal.com/965564.html
Про факт-ориентированность (достоинства графовых баз данных, семантической обработки данных) написаны горы литературы, семантик-вебовцы постарались. Но нам не нужен семантик веб, мы за модой не гонимся. Рекомендую первую половину книжки Chris Partridge “Business Objects: Re-Engineering for Re-Use” http://www.borosolutions.co.uk/research/content/files/books/BusObj-Printed-20050531-with-watermark.pdf/at_download/file, я называю это "антиаристотелевщина" (Витгенштейн сказал, что мир дан нам не в объектах со свойствами первичными и вторичными, как говорил Аристотель, а в фактах о том, как относятся между собой объекты. Мы про объекты можем сказать только то, как они относятся к другим объектам, и ничего -- никаких атрибутов -- про сам объект).
Если говорить про базы данных, то переход к трипл-сторам (трипл это тройка: объект1-отношение-объект2) сдерживался только тем, что они были поначалу помедленней, чем реляционные базы данных. Сейчас факт-ориентированные базы данных сравнялись по скорости с реляционными базами данных, а на сложных запросах могут и опережать их.
Как с этим справился Архимейт? Он сразу был факт-ориентированным: в нём есть сущности и отношения, а атрибутов нет. Это позволяет легко и непринуждённо развивать язык, добавлять новые и новые предметные описания к уже имеющимся (например, ArchiMate 2.0 не столько поменял сам язык Архимейт, сколько добавил в него новые элементы и отношения для моделирования требований и поддержки самой архитектурной работы -- ничего существенного перепланировать не потребовалось. Новые элементы и отношения просто добавляются, это и есть достоинство факт-ориентированного описания).
Sysmolan -- это факт-ориентированный язык. Когда необходимо его расширять (то есть он не позволяет что-то отмоделировать, и нужно добавить эту возможность), он легко позволяет это сделать, просто добавьте новые виды объектов и отношений.
Это серьёзное конкурентное преимущество перед объект-ориентированным SysML, который рассматривается сейчас как один из главных кандидатов на язык системного моделирования (про то, что же в нём системного, мы пока умолчим).
3. Люди, которые были недовольны объект-ориентированной природой стандартов STEP (ISO 10303) для инженерной информации, поняли, что стандарт не решит поставленной задачи: не позволит создавать "интеллектуальную модель изделия", "цифровой макет", "информационную модель сложного инженерного объекта" и т.д., причём не только потому что STEP был объект-ориентированным, и не получилось складывать вместе в одну базу данных проектные данные, созданные в соответствии с его разными схемами данных. Нет, факт-ориентированного описания для сборки нескольких разных моделей в одно связное описание системы оказалось мало. Нужно было понять, как сопоставлять разные объекты на разных моделях -- и для этого пришлось обратиться к онтологии.
Онтология (по Тому Груберу) это формализованная концептуализация, общая для многих (shared). Онтология отвечает на вопрос "какие концепты -- т.е. объекты и отношения между ними -- есть в этом мире (включая воображаемые, прошлые, будущие, потенциально возможные, информационные, физические и т.д.)?". Ответ при этом требуется формальный и согласованный с каким-то сообществом, солипсизм какого-то отдельного человека в качестве онтологии не подходит -- онтология выполняет коммуникационную функцию тоже. Онтология оказалась нужна инженерам для формальной записи информации различных моделей системы, в которой как-то бы гарантировалось, что эти модели описывают одно и то же устройство мира -- и обмена информацией между моделями. Если грубо, то есть много разных способов записать смену насоса на насосной станции (на принципиальной схеме остаётся один и тот же насос, но вот насос с серийным номером меняется -- иногда на насос совсем другой модели другого производителя), и нужно договориться как объединить модели закупщиков и проектантов (часто разрабатываемые разными людьми в разном софте) так, чтобы компьютер не запутался при их объединении. Многие из этих способов плохи, некоторые хороши. Нужно было договориться так описать мир, поделенный на объекты и отношения, чтобы компьютер не запутался, и можно было бы выражать такие типовые ситуации инженерной работы. И инженеры договорились, создав справочные данных ISO 15926 -- инженерную онтологию.
В ISO 15926 за основу взяли идеи философской логики, позволяющие выразить модель мира, согласованную с системным подходом, принятым в инженерии. Например, 4D экстенсионализм позволил отождествлять объекты разных моделей в общее описание системы (отождествлять в одной системе разные её ипостаси -- функциональную, модульную, пространственную). Конструкция класса классов позволила использовать различные классификаторы, не выделяя из них "главный" -- ибо для разных профессий (тех же проектантов и закупщиков) удобны разные "главные" классификации, и они никогда не договорятся.
К примерно таким же онтологическим выводам пришли и многие другие стандарты:
-- ISO 42010 рассказал, что не бывает одного описания системы, но только множество этих описаний, ибо есть много разных стейкхолдеров. Для каждого тематического вида описаний -- view (состоящего из моделей) стандарт потребовал указать метод описаний -- viewpoint (дисциплину, раскрывающую часть онтологии: какие виды объектов записывать)
-- ISO 81346 указал, как обозначать элементы системы, существующие во многих ипостасях -- и декларировал минимальное число этих ипостасей. Плюс он рассказал, как "разбирать систему на части" с учётом различных ипостасей.
-- ISO 42010 и OMG Essence указали на различие дисциплины (как думаем о системе в терминах идеальных объектов), позволяющей определять систему, и практики, позволяющей описывать систему (документировать систему в виде рабочих продуктов)
-- ISO 15288, OMG Essence показали важность описания системы деятельности (обеспечивающей системы, enabling system в ISO 15288, client и endeavour domain of interest в OMG Essence), обеспечивающей жизненный цикл целевой системы. Нужно уметь описывать не только саму систему, но и практики её жизненного цикла, и вид жизненного цикла.
SysMoLan гармонизирует находки всех этих стандартов, предлагая совместимый с этими инженерными стандартами способ документирования определения системы. Это означает, что SysMoLan реализует онтологию системного подхода в своей основе: в нём можно выражать различные ипостаси системы на разном уровне разбиения системы на подсистемы и элементы.
Слово "системный" в словосочетаниях system thinking, system approach, systems engineering означает мышление в рамках онтологии систем. SysMoLan -- System Modeling Language, язык системного моделирования -- содержит слово System именно в этом смысле, он поддерживает онтологию систем, системный подход, системное мышление, системное моделирования прямо "из коробки". Заметим, что в SysML и Modelica это не присутствует.
Как и ArchiMate оказывается не только архитектурным языком, но и архитектурным подходом (framework: он диктует не только как записывать архитектуру, но и как думать об архитектуре и как делать архитектурные описания), так и SysMoLan более полно можно назвать -- язык и подход системного моделирования. SysMoLan служит не только для записей различных моделей системы, но и воплощает в себе системный подход (в данном случае не только aproach, но и framework).
4. ISO 15926 не только предложил онтологические решения (идеи о том, как устроен мир с точки зрения системного подхода -- прежде всего 201 тип сущности, которые позволяют описать невероятно большое количество инженерных моделей), но и способ документирования моделей системы. Но в этом месте разработчики сделали ошибку: они пошли вслед за модой семантического веба и создали чересчур сложный формат записи этой онтологии. Мало того, что этот формат вообще не был приспособлен для чтения человеком (а только для чтения программами), так он оказался крайне сложен для освоения любыми программистами. Конкретно, в этом стандарте в основе лежат нечитабельные URI (программисты давно забыли, как выглядят адреса в оперативной памяти -- но спокойно пишут свои программы. А ведь эти URI имеют именно такой смысл! Почему кто-то должен смотреть на эти адреса без крайней на это необходимости?!). Также они реифицировали отношения (показали, что само отношение состоит из нескольких объектов), что само по себе хорошо. Но это оказалось и очень плохо: вместо желаемого инженером отношения нужно каждый раз придумывать и записывать множество разных объектов со своими именами, это огромный накладной расход. Реификация должна быть только тогда, когда она действительно уместна.
Сообщество за последнюю пару лет придумало новый способ "поднять уровень языка" ISO 15926 -- это так называемые паттерны данных. Но по факту это оказалось только "нахлобучкой" сверху уже очень большого и сложного стека технологий. И шанса, что кто-то освоит эту технологию "подъема уровня языка" нет, слишком мало будет тех людей, которым под силу будет заняться этим "подъемом уровня".
John Sowa сформулировал свой "закон стандартизации", аргументирующий важность недоспецификации предметной области: если и разработан какой-то стандарт, то результатом будет распространение упрощённой версии этого стандарта (http://en.wikipedia.org/wiki/John_F._Sowa#Sowa.27s_law_of_standards).
SysMoLan не будет отражать всё то, что в состоянии отразить все перечисленные стандарты, в особенности ISO 15926. Нет, он отразит только самое важное и намеренно будет простым (как и Архимейт, который "опишет 20% ситуаций, встречающихся в 80% случаев"). С другой стороны, SyMoLan будет снабжён достаточными средствами для расширения языка.
Что же будет отражать SysMoLan? В Shell были исследования, показавшие, что в ходе всего жизненного цикла для какого-то сложно устроенного насоса нужно хранить лишь 20 единиц данных, хотя в ходе разработки о нём используется до 1500 данных. Мы постараемся сделать так, чтобы в SysMoLan попали все эти 20 единиц "из коробки" (а остальные 1500 единиц данных можно было бы представить расширениями языка -- "профилями" как в UML, "библиотеками справочных данных" как в ISO 15926, дополнениями как в Archimate и т.д.).
SysMoLan не будет использовать идеи семантического веба, но обопрётся на аналогичные идеи моделирования данных, хорошо отработанные в мире традиционного программирования (даже не в мире баз данных!). Это позволит в разы и разы упростить работу с языком. Никакого OWL/RDF/XML стека, онтологии всегда можно было записывать по-другому. Это не значит, что моделям системы и их элементам нельзя будет давать адреса в интернете! Но их никто не увидит, как никто не увидит в текстах программ адресов оперативной памяти. Забота о URL должна лечь на что-то типа "компилятора" и "линкера/мейкера", сам язык в этих URL не нуждается (хотя они и могут быть из него доступны).
5. Логические языки представления факт-ориентированной информации не получили большого распространения, ибо в них трудно соединить ход вычислений с внешним миром -- что-то запросить у пользователя в ходе обработки или подождать ответа от далёкого сервера. Совсем недаром про успешный Prolog шутят, что у него половина от фортрана! В этом плане функциональные языки оказались лучше (в том числе для связи функционального и логического миров всегда можно вспомнить о Curry-Howard, или подключить логический ризонер в виде внешней "библиотеки" -- по специально организованному запросу).
SysMoLan, конечно, будет мультипарадигмальным в своих "запросных" и "трансформационых" аспектах, но прежде всего он будет функциональным, и только потом "логическим" языком. В этом изюминка: факт-ориентированный функциональный (а не традиционный логический) язык. Никаких требований к гарантированной decidability тем самым в SysMoLan нет, приоритет отдаётся не "вычислимости", а выразительности.
В основе SysMoLan является представление онтологической информации в виде паттернов данных. Паттерн данных с одной стороны представляется чисто программистским объектом (данные в отличие от информации не имеют значения и смысла, они обрабатываются по определенным алгоритмам, и только), а с другой стороны они наделяются онтологическим смыслом. Работа с паттернами больше похожа на работу с грамматиками, поэтому паттернированное выражение мира обычно чрезвычайно компактно и достаточно строго.
Паттернирование даёт систематический способ расширять язык, охватывать новые и новые предметные области. По сути дела, это концепция встроенных в базовый SysMoLan DSL (подробней на эту тему, а также объяснение почему это невозможно сделать в SysML: http://levenchuk.com/2009/12/08/sysml-is-the-point-of-departure-for-mbse-not-the-destination/).
Тем самым SysMoLan представляет собой нечно среднее между "псевдокодом" (записями моделей, не имеющими документированную в формальном логическом языке семантику -- то есть не подлежащими компьютерной обработке иной, нежели хранение и выдача хранимых единиц по запросу, таким языком является, например ArchiMate) и "кодом" (записями моделей, имеющими формальную семантику -- то есть такими моделями, на который можно напустить солвер, таким языком является опирающийся на MOF SysML и Modelica). Это будет и язык представления моделей/данных, и язык запросов к моделям/данным, и язык трансляции/конверсии/трансформации данных.
Но в SysMoLan (как и в Архимейте с его derivative relations) делаются попытки формализации важнейших аспектов описания систем. Более того, моделер будет пытаться помогать в этой формализации (разбор полнотекстовых описаний с возможными запросами к пользователю на их уточнение, привлечение внешних справочных данных для снятия неопределённостей, использование логического вывода и контекста для верификации/нахождении противоречий и ошибок в моделях и т.д.). Так что один из лозунгов SysMoLan -- это "от псевдокода к коду, при помощи компьютера".
6. Опыт любых языков описания показывает, что к этим описаниям нужны язык запросов и язык конверсии в другие представления (трансформации, мэппинга). Для каждого OWL нужно договориться о его SPARQL, для каждого XML нужно договориться о его XSLT.
SysMoLan позволит не только выражать данные, он позволит их запрашивать! Это означает, что можно говорить о серверах системной информации, поддерживающих запросы.
Эти сервера будут работать сразу не в программистских терминах, а в терминах системного подхода. Вся "программистская часть" будет спрятана в них "под капотом". SysMoLan это не только язык системного моделирования, это и язык запросов к системным моделям (типа SQL, SPARQL), и язык преобразования (мэппинга) системных моделей (типа XSLT, QVT, ATL).
В отличие от ISO 15926, в котором до сих пор не нашлось места для описания ограничений (хотя и предложено делать это на Plan9) и SysML, в котором ограничения можно описывать на отдельном языке OCL, SysMoLan будет поддерживать ограничения "из коробки", так что вполне можно думать и о contract-based design.
7. Современные языки описания систем имеют сразу два представления: текстовое и графическое. Текстовое представление позволяет легко программно генерировать записи на этих языках, а также читать их не только человеку, но и компьютеру. Текстовое представление в разы и разы удобней, когда описания на этом языке большие по объему (помним, как вымерли блок-схемы компьютерных программ и до сих пор не могут прижиться визуальные языки программирования: просто программы стали большие!). Графические описания важны, когда человеку нужно представить наглядно топологию: что там с чем связано в небольшом описании. Два вида представления моделей имеет OMG Essence, два вида представления моделей имеет Modelica.
SysMoLan тоже имеет два вида конкретного синтаксиса представлений (кроме неминуемого "абстрактного синтаксиса"), хотя разработку мы начнём с текстового (и не только потому что это проще, но и для того, чтобы отработать SysMoLan как язык запросов и как язык преобразований).
В инженерии это общепринято: например, так устроена Modelica.
8. Современная инженерия невозможна без описаний на естественных языках. В SysML пришлось добавить текстовые описания для требований по сравнению с UML. SysMoLan обобщает это: в него можно включать полнотекстовые описания на равных правах с модельными описаниями, а не только требования. Плюс из этих описаний всегда можно "вытащить" структурированную информацию и выразить её на самом SysMoLan (язык запросов это поддерживает). Интеграция со всякими DOORS становится вполне возможна.
Лозунг: SysMoLan не воюет с естественным языком, он вместе с ним!
Вообще, SysMoLan по возможности ориентирован на гибридные вычисления:
-- логический (функциональный) вывод/reasoninc для информации о структуре, контрактах модулей (contract design)
-- численные вычисления для мультифизики (как в Modelica)
-- текстовые вычисления (a la IBM Watson -- ответы на вопросы. Или извлечение информации, "понимани", a la CYC)
-- в принципе, сюда же может быть добавлена и геометрическая информация, для геометрических солверов
В этом смысле SysMoLan нацеливается поучаствовать в движении поиск-ориентированной системной инженерии и другой пост-моделеориентированной жизни: http://ailev.livejournal.com/1122876.html
9. Предполагается, что SysMoLan в какой-то момент будет стандартизован. Стандартизация обычно предполагает:
-- коллективное обсуждение и открытость спецификации, понятную процедуру изменения спецификации
-- наличие модельной реализации (доказывающей реализуемость на практики), т.е. сервера и моделера
-- иногда (но не всегда) наличие нескольких реализаций, демонстрирующих совместимость (в консорциуме OASYS стандарт публикуется только после того, как минимум три члена этого консорциума реализовали стандарт. "Неудачный стандарт стандартом не назовёшь").
Наша цель тут -- чтобы SysMoLan стал не менее популярным языком MBSE инициативы INCOSE, чем SysML, AADL, Modelica. Так что вокруг SysMoLan мы планируем некоторую формальную организацию стандартизации (и для поддержки этой организации мы зарегистрировали http://sysmolan.org). Но, как водится в этой стандартизации, на вход стандартизации должен поступить какой-то проект стандарта, коллективная разработка "с белого листа" оказывается неэффективной, проще обсуждать "по тексту" и модельной реализации, если они есть.
Вспомним также закон John Sowa, что при слишком детальной стандартизации-переспецификации в жизнь выйдет не SyMoLan, а более простой вариант для того же самого, так что и со стандартизацией нужно не переусердствовать: удовлетворяющий всех стандарт по факту не удовлетворит никого.
10. SysMoLan служит для накопления знаний. Это означает, что на нём легко подготовить:
-- типовые требования (например, содержащиеся в стандартах)
-- типовые высокоуровневые архитектуры (например, содержащиеся в учебниках)
-- типовые запросы для какого-то сорта комбинированных моделей
Эти знания будут накапливаться в библиотеках справочных системных моделей (по аналогии с библиотеками справочных данных ISO 15926 и библиотеками Modelica).
В этом плане SysMoLan -- это язык представления и накопления инженерных знаний.
11. Какие области применения SysMoLan будут первоочередными?
11.1. Инженерия: "ранние стадии жизненного цикла" (несмотря на то, что эти практики выполняются в ходе всего жизненного цикла, а часто их и вовсе называют "системная инженерия") -- инженерия архитектурных требований и системной архитектуры. "Архитектурный" тут -- это те самые 20% требований и отвечающих им инженерных решений, которые определяют 80% устройства системы. То есть в этом плане SysMoLan -- это язык целеориентированной инженерии требований (типа GSN или i*) и системной архитектуры (типа SysML, AADL, Modelica -- да, мы считаем Modelica и архитектурным языком, а не только языком мультифизического моделирования), а также описания вида жизненного цикла (типа OMG SPEM 2.0 и OMG Essence) и даже организации разработки (ArchiMate) -- и дикий зоопарк продуктов.
11.2. Образование: поскольку SysMoLan поддерживает "из коробки" основные инженерные концепты в рамках системного подхода, он становится идеальным для обучения студентов видеть мир в терминах систем, начальная стадия обучения системного инженера. Это означает, что в дополнение к языку должен быть разработан курс системноинженерного мышления. По факту, такой курс уже разработан, но он пока никак не использует язык моделирования -- http://techinvestlab.ru/files/systems_engineering_thinking/systems_engineering_thinking--TechInvestLab_2014.pdf. После появления хотя бы первых версий языка и моделера этот курс будет существенно переработан не столько в части его содержания, сколько в части упражнений: понимание будет тренироваться и проверяться на решении задач системного моделирования. Для моделе-ориентированной (model-based, model-driven) системной инженерии нужно моделеориентированное системное мышление.
11.3. Интеграция данных (федерирование инженерных информационных систем): поскольку SysMoLan является наследником ISO 15926, то все его достижения и наработки по федерированию данных жизненного цикла, находящихся в разных инженерных системах, вполне приложимы к SysMoLan. Это будет даже лучше, ибо язык стандартизует не только онтологию ("справочные данные") и средства её пополнения, но и как запрашивать данные жизненного цикла, и как преобразовывать их в/из альтернативных представлений в разных инженерных информационных системах. Редактор/моделер SysMoLan должен быть дополнен сервером (поддерживающим язык запросов) и адаптором (обеспечивающим экспорт-импорт в/из разных форматов данных). В этом плане SysMoLan поддерживает пункт 13 из http://ailev.livejournal.com/872954.html -- он предлагает компактное представление нового знания, а для уже имеющегося знания в старых форматах он предлагает мэппинг.
* * *
Этот текст представляет собой обновление и расширение предыдущих двух текстов с постановкой задачи: февральского http://ailev.livejournal.com/1061167.html и июньского http://ailev.livejournal.com/1122497.html. Он рассчитан на тех, кто знаком с упомянутыми в нём языками, стандартами и идеями (сейчас ситуация чуть полегче: для начального знакомства теперь можно прочитать книжку "Системноинженерное мышление в управлении жизненным циклом", 306 страниц по-русски -- . Теперь "для маркетинга" нужно бы переписать его "на чистых идеях", чтобы не поминать ненужных имён стандартов, но я бы перед этим хотя бы чуть-чуть спрототипировал язык. нулевая версия могла бы использовать паттернированую запись триплов для архимейт-подобных диаграмм, плюс многоипостасийные структурные имена, почёрпнутые из ISO 81346. Для детекторного приёмника запись выбора оборудования при этом может быть чем-то вроде =детектор1((реализован((-диод Д 161-320-18 ((имеет((ударный прямой ток((7500@А
На конкретный синтаксис в деталях (обработка пробелов и т.д.) пока внимания не обращаем, а вот как компактненько показать паттерн из нескольких триплов про одно и то же -- вот это да, этим как раз и занимаемся. Так, префикс = из ISO 81346 для =детектор1 означает для , что детектор1((тип((компонент, т.е. функциональный объект с принципиальной схемы. Префикс - в -диод Д 161-320-18 по ISO 81346 означает, что диод Д 161-320-18((типа((модуль, то есть "продукт" из каталога. Всё это "дизайн в классах", что делать с классификаторами и индивидами придумаем чуть позже. А когда отмоделируем детекторный приёмник, то начнём работать с подуровнями системы. Потом добавим описания (ибо на SysMoLan нужно описавать не только саму систему, но и её модели -- это язык мегамоделирования!).
Вместо скобок я бы предпочёл лесенки (не люблю закрывать скобки). Так, чтобы выдать ещё какую характеристику для диода этого детекторного приёмника, я бы писал:
=детектор1((реализован((-диод Д 161-320-18 ((имеет((
ударный прямой ток((7500@А
частота максимальная((500@Гц
* * *
Проблемы для постепенного решения:
-- киберфизические системы (попытки решения в AADL: стык оборудования и софта)
-- какая-то более-менее развитая онтология информатики (software engineering)
-- акаузальное мультифизическое моделирование (Modelica)
-- требования и motivation (хотя бы как в i* или лучше)
-- модуляризация
-- графический синтаксис
-- обоснования по ISO 15026 и так далее (http://ailev.livejournal.com/811715.html)
-- как делать model cheсking (верификация)
* * *
Отдельный вопрос -- это прототипная реализация (сервер, моделер, адаптеры). К этому уже приступили. Не забываем про чеклист для современного моделера -- http://ailev.livejournal.com/1041274.html