Архитектура, моделирование, онтологии, далее везде.
Экая забавная цепочка в MBSE: document centruc --> model centric --> hybrid simulation --> fully institutionalized.
Интересно, что model centric тут относится к собственно инжинирингу, а для управления информацией говорится "should be accompanied by a shift from document centric storage and retrieval of information to a data centric paradigm" (http://www.lboro.ac.uk/departments/el/sedc/documents/presentations/model-driven-architecture.pdf).
Судя по всему (например, наличие специальной деятельности в MBSE Инициативе INCOSE -- см. самый свежий их отчет прямо на сайте OMG: http://www.omg.org/docs/syseng/08-06-04.pdf), MBSE пытаются выстроить как обобщение MDA (поддерживаемой OMG) для систем общего вида, только вместо UML там кладется SysML. В MDA выделяют Computational independent model (CIM), которая должна говорить про системные требования и окружение, а в MBSE на этом месте планируют System independent model (про capabilities, системные требования, окружение). Platform Independent model (PIM, независимая от кода, про функционирование системы, а также разметка для трансляции в платформозависимую модель) OMG превращается в Technology Independent Model (логическая модель системы, параметры для трансляции в технологоспецифичную модель, декомпозицию системы) MBSE. Заявление, зачем это делается, аналогичное -- ежели OMG заявляет 25% снижение стоимости разработки программ с помощью MDA, то MBSE магически должна унаследовать эти выгоды.
Поэтому можно прикинуть заранее, какие проблемы будут у MBSE с таким подходом -- те же, что у MDA. На эту тему можно опять же обратиться к работам Chris Partrige про изменение парадигмы программирования, где он разбирает как минимум пропущеный в MDA этап явного определения онтологии (хотя современный подход пытается в виде domain engineering воткнуть что-то подобное и в современные версии MDA).
Очень интересно тут, как люди путаются в трех похожих концепциях, за каждой из которых видят одно и то же -- использование абстракции, чтобы создавать модели, отделяющие логику собственно системы от используемых для ее реализации технологий:
-- онтология, работа понятиями предметной области (как минимум, без этого нельзя сформулировать требования! Просто не будет слов, чтобы эти требования выразить).
-- архитектура
-- модель "высокого уровня".
Сама системная инженерия бодро настаивает, что главный термин тут -- архитектура. У MBSE инициативы INCOSE половина членов одновременно сидит в архитектурной рабочей группе. Ну, и как они это все разводят?
Онтолог там тоже есть -- Ralph Hodgson (http://ontolog.cim3.net/cgi-bin/wiki.pl?RalphHodgson), именно он мешает всем сосредоточиться только на SysML и включает в рассмотрение AP233 как минимум. Его инициатива -- SysMO -- System Model Ontologies, www.sysmo.org (сайт пустой, они живут на закрытой рассылке http://groups.google.com/group/SysMOforum).
Среди заявленных этим Hodgson вопросов -- конверсия SysML в OWL. C другой стороны, есть и прямые активности с AP233 и даже по мэппингу AP233 и SysML (этим занимаются Phil Spiby и Roger Burkhart).
Самая свежая презентация по MBSE -- это http://www.incose.org/orlando/Attach/200901/MBSE-Friedenthal-090115-INCOSE%20Central%20Florida%20Chapter.pdf, пару недель назад, флоридское отделение INCOSE. Все обычно -- "SysML is Critical Enabler for MBSE". В ноябре 2008г. в OMG вышла версия 1.1 SysML, сейчас работают над версией 1.2 (http://omgsysml.org). Дальше классическая путаница: "System Model as an Integration Framework" и "System Architecture Model as Integratin Model" в двух соседних слайдах -- не говоря уже о расхождении употребления слова model с ISO 42010. Очень творческие люди, недосуг им говорить точно -- они ведь моделируют на формальном языке! В примерах сразу понятно, чем занимаются: три военных корабля разных типов и три самолета разных типов атакуют что-то недалеко от берега, активно взаимодействуя между собой и сухопутными войсками. Требуется, чтобы все работало -- System of Systems, как они это обычно называют. Копирайт Lockheed Martin Corporation. Связь SysML с симуляционным моделированием -- для этого специальные типы диаграмм (параметрические), добавленные в SysML по сравнению с UML 2. PBS подозрительно напоминает аналогичные структуры, виденные в разных САПР -- но нарисованные в SysML.
То, что меня интересует прямо сейчас -- это Distributed Model Management Standards, этим занимается Tom Capelle для Jean-Phillipe Lerat. И еще Configuration Management Practices в случае моделей (Ray Jorgensen & Joe Bedocs).
У этой Инициативы INCOSE есть маленький интранет, абсолютно пустой. Впрочем, там находится любопытная ссылка на текст http://math.ucr.edu/home/baez/rosetta.pdf -- о построении некоторой новой неестественной (типа математики) "науки" о системах и процессах путем объединения аналогичных рассуждений физики, топологии, логики и компьютинга.
В это месиво еще и пытаются добавить акторов, обменивающихся сообщениями -- http://golem.ph.utexas.edu/category/2008/03/physics_topology_logic_and_com.html#c015742 (и там далее по треду).
По духу это ровно то же самое, что мы пытаемся делать в PraxOS: отождествить одно и то же, говоримое в разных языках, и дать за счет этого много более компактное описание мира. А за базовый язык выбрать язык системной инженерии в версии избранных стандартов ISO (чтобы никто не обвинял в совсем уж полной самодеятельности).
Вот страничка одного из авторов нового Розеттского камня -- http://math.ucr.edu/home/baez/. Там тоже много интересного, включая физический FAQ, в котором объясняется в том числе и то, почему все металлы серые, а золото -- желтое (http://math.ucr.edu/home/baez/physics/Relativity/SR/gold_color.html).
Эх, где мои семнадцать лет! Ведь это отличный заход на очередную "теорию всего", компактификацию накопленного разношерстного знания.
* * *
Я думаю, пришла пора делать московскую chapter INCOSE. Для этого нужно наскрести в Москве 25 человек системных инженеров. Думаю, к концу года наскребется не меньше.
* * *
Тут нужно напомнить, где есть неплохой блог по архитектурам (и, в связи с полной путаницей понятий, по всяким model-driven подходам): http://www.theenterprisearchitect.eu/
* * *
Свеженький анализ положения дел с Model-Driven Development -- http://www.infoq.com/articles/mdd-misperceptions-challenges. Все это применимо и к MBSE (кстати, MBSE -- это не только model based system engineering, но часто и model based software engineering. Впрочем, содержательная разница не слишком большая). Курсивом я выделил то, что важно для позиционирования и выбора терминологии.
1. Долго не было готовых методологий (увязанных между собой наборов лучших практик).
2. Долго не было правильной инфраструктуры и инструментов, чтобы поддержать MDD. Прежде всего, инструментарий для трассировки требований к решениям, инструментарий по поддержке паттернов. И все эти инструменты составляют инфраструктуру (например, позволяют обмениваться кусками моделей, имеют API к приложениям).
3. MDD не сводится к UML, бывают и другие языки. Но люди-то думают, что только UML -- и плюют на MDD в целом.
4. MDD вовсе не требует обязательного прописывания всех возможных view и всех возможных связей между ними. Для каждого проекта нужна своя методология.
5. Суть -- в элементах моделей, которые повторяются на разных диаграммах. Суть не в отдельных диаграммах, а в том, что диаграммы позволяют одновременно поглядеть на разные свойства и связи этих элементов. Группы описаний (view) -- это только удобный способ группировки, они вовсе не требуют обязательной проработки во всех проектах.
6. Код не равен модели, а модель не равна коду (заодно скажу, что сюда же попадает обсуждение того, равна ли модель архитектуре).
7. Платформонезависимость -- максимальные выгоды, но мозги не могут так думать.
8. Кодерам тоже нужно творить, не только архитекторам. Но в MDD кодерам часто достается только рутина, в результате имеем плохой код для хорошей архитектуры.
9. Не хватает шаблонов, образцов артефактов MDD, содержания прошлых проектов -- контента, которые можно было бы использовать как "рыбы" для конкретной разработки. С пустого экрана редактора модели начинать очень тяжело.
10. MDD -- не только для разработки приложений. MDD дает возможность изменить не только систему, но и ее окружение (поскольку моделируется в том числе и окружение).
* * *
Итого: все говорят об одном и том же, в разных словах, до хрипоты споря об оттенках смыслов. Половина дискуссий напоминает старинные споры о том, чем отличаются базы данных от банков данных и что такое в связи с ними СУБД. Слово "мета" не использует только ленивый, каждый раз это слово означает разный тип связи (иногда конкретизацию-реализацию, иногда специализацию, иногда агрегацию). Слова "архитектура", "модель" и "онтология" (а иногда и "код") используются по вкусу, часто как синонимы.
И важно заметить, что за последние полгода число упоминаний DSL (domain specific languages) выросло в разы.
* * *
Однако, очень не хочется разрабатывать русский хоть как-то непротиворечивый язык для говорения на эти мутные темы моделирования-архитектинга-онтологизации, но именно к этому все и идет. И зафиксировать этот язык в наборе русскоязычных гармонизированных (хотя бы по терминологии) стандартов ISO. Ну, или наборе русскоязычных стандартов, похожих на стандарты ISO.
Интересно, что model centric тут относится к собственно инжинирингу, а для управления информацией говорится "should be accompanied by a shift from document centric storage and retrieval of information to a data centric paradigm" (http://www.lboro.ac.uk/departments/el/sedc/documents/presentations/model-driven-architecture.pdf).
Судя по всему (например, наличие специальной деятельности в MBSE Инициативе INCOSE -- см. самый свежий их отчет прямо на сайте OMG: http://www.omg.org/docs/syseng/08-06-04.pdf), MBSE пытаются выстроить как обобщение MDA (поддерживаемой OMG) для систем общего вида, только вместо UML там кладется SysML. В MDA выделяют Computational independent model (CIM), которая должна говорить про системные требования и окружение, а в MBSE на этом месте планируют System independent model (про capabilities, системные требования, окружение). Platform Independent model (PIM, независимая от кода, про функционирование системы, а также разметка для трансляции в платформозависимую модель) OMG превращается в Technology Independent Model (логическая модель системы, параметры для трансляции в технологоспецифичную модель, декомпозицию системы) MBSE. Заявление, зачем это делается, аналогичное -- ежели OMG заявляет 25% снижение стоимости разработки программ с помощью MDA, то MBSE магически должна унаследовать эти выгоды.
Поэтому можно прикинуть заранее, какие проблемы будут у MBSE с таким подходом -- те же, что у MDA. На эту тему можно опять же обратиться к работам Chris Partrige про изменение парадигмы программирования, где он разбирает как минимум пропущеный в MDA этап явного определения онтологии (хотя современный подход пытается в виде domain engineering воткнуть что-то подобное и в современные версии MDA).
Очень интересно тут, как люди путаются в трех похожих концепциях, за каждой из которых видят одно и то же -- использование абстракции, чтобы создавать модели, отделяющие логику собственно системы от используемых для ее реализации технологий:
-- онтология, работа понятиями предметной области (как минимум, без этого нельзя сформулировать требования! Просто не будет слов, чтобы эти требования выразить).
-- архитектура
-- модель "высокого уровня".
Сама системная инженерия бодро настаивает, что главный термин тут -- архитектура. У MBSE инициативы INCOSE половина членов одновременно сидит в архитектурной рабочей группе. Ну, и как они это все разводят?
Онтолог там тоже есть -- Ralph Hodgson (http://ontolog.cim3.net/cgi-bin/wiki.pl?RalphHodgson), именно он мешает всем сосредоточиться только на SysML и включает в рассмотрение AP233 как минимум. Его инициатива -- SysMO -- System Model Ontologies, www.sysmo.org (сайт пустой, они живут на закрытой рассылке http://groups.google.com/group/SysMOforum).
Среди заявленных этим Hodgson вопросов -- конверсия SysML в OWL. C другой стороны, есть и прямые активности с AP233 и даже по мэппингу AP233 и SysML (этим занимаются Phil Spiby и Roger Burkhart).
Самая свежая презентация по MBSE -- это http://www.incose.org/orlando/Attach/200901/MBSE-Friedenthal-090115-INCOSE%20Central%20Florida%20Chapter.pdf, пару недель назад, флоридское отделение INCOSE. Все обычно -- "SysML is Critical Enabler for MBSE". В ноябре 2008г. в OMG вышла версия 1.1 SysML, сейчас работают над версией 1.2 (http://omgsysml.org). Дальше классическая путаница: "System Model as an Integration Framework" и "System Architecture Model as Integratin Model" в двух соседних слайдах -- не говоря уже о расхождении употребления слова model с ISO 42010. Очень творческие люди, недосуг им говорить точно -- они ведь моделируют на формальном языке! В примерах сразу понятно, чем занимаются: три военных корабля разных типов и три самолета разных типов атакуют что-то недалеко от берега, активно взаимодействуя между собой и сухопутными войсками. Требуется, чтобы все работало -- System of Systems, как они это обычно называют. Копирайт Lockheed Martin Corporation. Связь SysML с симуляционным моделированием -- для этого специальные типы диаграмм (параметрические), добавленные в SysML по сравнению с UML 2. PBS подозрительно напоминает аналогичные структуры, виденные в разных САПР -- но нарисованные в SysML.
То, что меня интересует прямо сейчас -- это Distributed Model Management Standards, этим занимается Tom Capelle для Jean-Phillipe Lerat. И еще Configuration Management Practices в случае моделей (Ray Jorgensen & Joe Bedocs).
У этой Инициативы INCOSE есть маленький интранет, абсолютно пустой. Впрочем, там находится любопытная ссылка на текст http://math.ucr.edu/home/baez/rosetta.pdf -- о построении некоторой новой неестественной (типа математики) "науки" о системах и процессах путем объединения аналогичных рассуждений физики, топологии, логики и компьютинга.
В это месиво еще и пытаются добавить акторов, обменивающихся сообщениями -- http://golem.ph.utexas.edu/category/2008/03/physics_topology_logic_and_com.html#c015742 (и там далее по треду).
По духу это ровно то же самое, что мы пытаемся делать в PraxOS: отождествить одно и то же, говоримое в разных языках, и дать за счет этого много более компактное описание мира. А за базовый язык выбрать язык системной инженерии в версии избранных стандартов ISO (чтобы никто не обвинял в совсем уж полной самодеятельности).
Вот страничка одного из авторов нового Розеттского камня -- http://math.ucr.edu/home/baez/. Там тоже много интересного, включая физический FAQ, в котором объясняется в том числе и то, почему все металлы серые, а золото -- желтое (http://math.ucr.edu/home/baez/physics/Relativity/SR/gold_color.html).
Эх, где мои семнадцать лет! Ведь это отличный заход на очередную "теорию всего", компактификацию накопленного разношерстного знания.
* * *
Я думаю, пришла пора делать московскую chapter INCOSE. Для этого нужно наскрести в Москве 25 человек системных инженеров. Думаю, к концу года наскребется не меньше.
* * *
Тут нужно напомнить, где есть неплохой блог по архитектурам (и, в связи с полной путаницей понятий, по всяким model-driven подходам): http://www.theenterprisearchitect.eu/
* * *
Свеженький анализ положения дел с Model-Driven Development -- http://www.infoq.com/articles/mdd-misperceptions-challenges. Все это применимо и к MBSE (кстати, MBSE -- это не только model based system engineering, но часто и model based software engineering. Впрочем, содержательная разница не слишком большая). Курсивом я выделил то, что важно для позиционирования и выбора терминологии.
1. Долго не было готовых методологий (увязанных между собой наборов лучших практик).
2. Долго не было правильной инфраструктуры и инструментов, чтобы поддержать MDD. Прежде всего, инструментарий для трассировки требований к решениям, инструментарий по поддержке паттернов. И все эти инструменты составляют инфраструктуру (например, позволяют обмениваться кусками моделей, имеют API к приложениям).
3. MDD не сводится к UML, бывают и другие языки. Но люди-то думают, что только UML -- и плюют на MDD в целом.
4. MDD вовсе не требует обязательного прописывания всех возможных view и всех возможных связей между ними. Для каждого проекта нужна своя методология.
5. Суть -- в элементах моделей, которые повторяются на разных диаграммах. Суть не в отдельных диаграммах, а в том, что диаграммы позволяют одновременно поглядеть на разные свойства и связи этих элементов. Группы описаний (view) -- это только удобный способ группировки, они вовсе не требуют обязательной проработки во всех проектах.
6. Код не равен модели, а модель не равна коду (заодно скажу, что сюда же попадает обсуждение того, равна ли модель архитектуре).
7. Платформонезависимость -- максимальные выгоды, но мозги не могут так думать.
8. Кодерам тоже нужно творить, не только архитекторам. Но в MDD кодерам часто достается только рутина, в результате имеем плохой код для хорошей архитектуры.
9. Не хватает шаблонов, образцов артефактов MDD, содержания прошлых проектов -- контента, которые можно было бы использовать как "рыбы" для конкретной разработки. С пустого экрана редактора модели начинать очень тяжело.
10. MDD -- не только для разработки приложений. MDD дает возможность изменить не только систему, но и ее окружение (поскольку моделируется в том числе и окружение).
* * *
Итого: все говорят об одном и том же, в разных словах, до хрипоты споря об оттенках смыслов. Половина дискуссий напоминает старинные споры о том, чем отличаются базы данных от банков данных и что такое в связи с ними СУБД. Слово "мета" не использует только ленивый, каждый раз это слово означает разный тип связи (иногда конкретизацию-реализацию, иногда специализацию, иногда агрегацию). Слова "архитектура", "модель" и "онтология" (а иногда и "код") используются по вкусу, часто как синонимы.
И важно заметить, что за последние полгода число упоминаний DSL (domain specific languages) выросло в разы.
* * *
Однако, очень не хочется разрабатывать русский хоть как-то непротиворечивый язык для говорения на эти мутные темы моделирования-архитектинга-онтологизации, но именно к этому все и идет. И зафиксировать этот язык в наборе русскоязычных гармонизированных (хотя бы по терминологии) стандартов ISO. Ну, или наборе русскоязычных стандартов, похожих на стандарты ISO.