?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Универсальный моделер (IDE). Универсальный компилятор (IDE). [21 Nov 2009|08:11pm]
Во первых строках моего поста прошу пардону за непонятность у всех проходящих мимо: каждый термин тут требует для них многочисленных разъяснений (и даже ссылки на первоисточники и другие мои постинги я повторять по десятому разу не буду, в том числе и потому, что сейчас у Яндекса блоговый поиск опять сурово сбоит и найти сегодня ничего нельзя, но я исхитрился и нашел через интерфейс livejournal.ru -- вот начало разговора про универсальный моделер в приложении к оргмоделированию http://ailev.livejournal.com/701018.html. А еще тут -- http://ailev.livejournal.com/748188.html). Постоянным же читателям моего ЖЖ многое должно быть понятно и без разъяснений. Хотя я пишу сейчас даже и не для них, а для собственного разбирательства -- чем продолжаю традицию release often, release early для черновиков, а не публикацию попсовых статей для глянцевых журналов.

В свободные (да и в рабочие тоже -- работа у меня такая) минуты я часто размышляю об "универсальном моделере". Вот его основные черты:
-- у него есть хранилище данных, больше всего похожее на MatrixOne от Dassault Systemes (базовая онтология на 20тыс. класссов, поддержка многопользовательской работы и SOA на макушке -- чтобы обепечивать "программирование-в-большом")
-- но в качестве схемы используется ISO 15926 inside (что странно, ибо RDL-то outside), чтобы исключить постоянный мэппинг для внешних соединений. Сам ISO 15926 при этом контролируется на масштабируемость (выразительность) своих протошаблонов, шаблонов и OIM; и тут нужно еще понять, как делать "диалекты" ISO 15926 -- ведь наверняка программирование такой системы будет включать в себя крутые отползания от стандарта, хотя бы для исправления ошибок или крутого рефакторинга при нахождении нужной масштабируемости.
-- само программирование идет в два приёма, и выполняется в подходе language workbenches: 1. инструментальное -- представляет собой создание динамических редакторов-исполнителей для целевых моделей, выражаемых в их DSL. Вспоминаем language workbenches, но компилируем не только из какого-нибудь UML/MOF в исполняемый на компьютере код, но и из 3D-геометрического представления в код для станка с ЧПУ ("субтрактивное производство") или 3D-принтера ("аддитивное производство"), а лет через пять еще нужно будет выводить описание 3D-компоновки для сборочного робота. 2. целевое -- собственно создание моделей. Думать при этом можно про "модули" (workbenches) от Dassault Systemes V6 (но при этом не стоит путать тамошние workbenches с language workbench: то, что в DS V6 называется workbench является лишь одним из DSL+IDE в language workbenches).
-- само программирование language workbench при этом устроено на COLA (vpri.org), а главными из тамошних идей считаем мультипарадигмальность и "масштабируемость идей". Код получается крошечным и обозримым.
-- все это не менее красиво виртуально-трехмерно чем "тарелочки" у Dassault Systemes V6. Но при этом поддерживается реальное коллаборативное время -- например, как в Croquet с его алгоритмом TeaTime и САПР, засунутым в виртуальный мир.
-- все это, конечно, свободный софт.

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

На закуску этого невнятного постинга я помещу рекламу Markus Voelter (http://www.voelter.de/), который все активнее и активнее пишет на те же темы, что и я -- про фактическое слияние моделирования и программирования (правда, все время сваливаясь в частный случай компиляции DSL в исполняемый код языков программирования. Меня же волновала бы компиляция более общего вида, например shape language в модель на языке ISO 15926 в рамках машиностроительного модуля САПР, а затем в программу для станка с ЧПУ, чтобы заниматься далее порождающим производством). Тем не менее, вот его взгляд Markus Voelter на то, как языковая и модельная парадигма сливаются (в тех же language workbenches):



И еще нужно глядеть на его презентацию о том, что язык и архитектура -- это про одно и то же: http://www.slideshare.net/schogglad/architecture-as-language-2260774 (в этой обширнейшей презентации есть также страстная критика UML примерно по той же линии, что и у меня: DSL выполняет ту же работу лучше).

А вот свежайшая презентация Alfonso Pierantonio про model-driven engineering (model-driven development из которого только маленькая часть) в части эволюции-в-малом (эволюции прикладной модели) и эволюции-в-большом (эволюции метамодели):


Эта презентация намекает, что возможно менять метамодель так, чтобы при этом отслеживать сохранение целостности уже созданных моделей. Пока это rocket science, но через пять лет это будет сидеть где-нибудь глубоко внутри модельного-программного инструментария.

Ecore, KM3, MOF в моей голове полностью соответствуют ISO 15926-2, а UML и прочие "надстройки" -- это уже протошаблоны ISO 15926-2. "Стереотипы" -- это OIM. Разница с текущими моделерами в детальности моделирования (развитости онтологии ISO 15926-2) и наличии организационного механизма накопления экспертного знания в виде RDL.

Все, что я говорю -- это "мужики, MDE и MBSE -- это одно и то же. Только в первом случае у вас команды исполняет процессор, а во втором случае -- люди и станки с ЧПУ". И нужно просто повторно использовать идеи, чтобы не распыляться.

В любом случае, компьютерная революция начнется уже совсем скоро.

Почему я этим всем занимаюсь? Я бы с удовольствием воспользовался готовым универсальным моделером, чтобы делать в нем DSL PraxOS в таких domain как системная инженерия, организационное управление и ситуационная инженерия методов. А дальше бы я применял эти DSL на практике, получал опыт, и выпускал бы новые версии этих языков. Но универсального моделера нетути, и приходится думать, сколько ждать до того момента, когда он появится "сам собой", или примериваться к тому, чтобы затеять его разработку.
27 comments|post comment

Курс по инженерии системной архитектуры [21 Nov 2009|08:32pm]
Месяц назад я писал наброски программы короткого курса системной инженерии (http://ailev.livejournal.com/746511.html), вчера я дал некоторое развитие (программа вводного курса -- http://ailev.livejournal.com/757488.html), а сегодня приведу наметки для курса по инженерии системной архитектуры:

Необходимость отдельного курса по инженерии системной архитектуры: ISO 15288 посвящает меньше двух страниц "архитектурному проектированию", а руководство по системной инженерии INCOSE посвящает 31 страницу обзору "функционального анализа/разнесения" и "синтезу системной архитектуры". Это очень мало. Так, руководство "Подход к методам инженерии системной архитектуры" (MFESA) даже без уточнений для систем разной природы, разных жизненных циклов и разных используемых архитектурных инструментов -- это 482 страницы, руководство «Метод для оценки качества программоемких системных архитектур» (QUASAR)-- 267 страниц.


1. Инженерия системной архитектуры в контексте других практик системной инженерии.
-- практика архитектурного проектирования и дисциплина инженерии системной архитектуры
-- «горбатая диаграмма» системной инженерии и место инженерии системной архитектуры в дисциплинах системной инженерии
-- разделение инженерии системной архитектуры и инженерии требований, рабочего проектирования
-- системные архитекторы, архитектурные коллективы
-- невозвможность единого подхода к инженерии системной архитектуры. Адаптация стандартов.
-- стандарты инженерии системной архитектуры (ISO 15288, ISO 42010, MFESA, QUASAR)
-- методические принципы инженерии системной архитектуры (поддержка ситуационной инженерии методов; масштабируемость; эволюция архитектуры; качество обеспечивающих систем; все типы архитектурных компонент; компонент-ориентированная разработка; хорошо определенные понятия и терминология; архитектуры и их описания как ценные ресурсы; как архитектурные группы описаний, так и области внимания; полнота архитектурных групп описаний; полнота конкретных архитектурных методов; командная работа; независимость оценки архитектуры; анализ влияния перед изменениями архитектуры)

2. Архитектурная онтология
-- системная архитектура
-- архитектурные структуры
-- архитектурные стили, шаблоны и механизмы
-- архитектурные основания и интересы
-- архитектурные представления (representations)
-- архитектурные модели, группы описаний и области внимания (focus area)
-- архитектурные продукты работы
-- архитектурные эскизы (visions) и эскизные компоненты

2. Архитектурные мероприятия
-- планирование и обеспечение ресурсами работ по архитектурной инженерии
-- выявление архитектурных направляющих (drivers)
-- создание первых версий наиболее важных архитектурных моделей
-- выявления возможности переиспользования архитектурных элементов
-- создание вариантов архитектурных концепций (visions)
-- анализ переиспользуемых компонентов и их источников
-- завершение архитектуры и ее представлений
-- оценка и приемка архитектуры
-- сопровождение архитектуры и ее представлений

4. Архитектурный инструментарий
-- архитектурные моделеры
-- архитектурное проектирование с использованием современных САПР
-- инструменты для DSM

В принципе, это все основано на MFESA (полная книжка http://www.freebookspot.in/Books-Method%20Framework%20for%20Engineering%20System%20Architectures.htm) и QUASAR (http://www.sei.cmu.edu/reports/06hb001.pdf) -- при этому учитываем, что QUASAR 3.1 уже включает два типа quality cases: requirements и architectural.
post comment

navigation
[ viewing | November 21st, 2009 ]
[ go | previous day|next day ]