Концепт-архитектура софта PraxOS
В очередной раз пофантазируем о том, каким мог бы быть софт PraxOS. Конечно, пока обсуждаем только концепт-архитектуру, которая (как и концепт-кары) бесконечно далека от принимаемой для промышленной разработки версии -- но если сегодня начать с такими концептами, то лет за пять вполне можно и до промышленной версии дойти. Что мне нравится, так это существование работающих прототипов для любой из частей этой концепт-архитектуры. Остается только собрать эти идеи из разных систем в одно работающее целое. Вот из каких элементов могла бы состоять PraxOS-система:
1. Интерфейсер -- генератор отчетов, редактор, дебаггер и прочий интерфейс с человеком. Основные черты:
-- на первый взгляд воспринимается как средство подготовки презентаций, но не типа PowerPoint, а зум-презентации типа Prezi (http://prezi.com).
-- Презентации состоят из отдельных представлений, которые берутся из набора, похожего на энциклопедию визуальных представлений (помните "периодическую таблицу методов визуализации"? http://www.visual-literacy.org/periodic_table/periodic_table.html) по способу, похожему на предлагающийся в SmartArt из PowerPoint 2007 (содержание остается одним и тем же в рамках одного типа картинки, но сама картинка представления этого содержания меняется -- а тип картинки подсказывается некоторой экспертной системой, основываясь на требованиях по представлению содержания: много там или мало текста, связей, графики и т.д.).
-- Каждое представление препрограммируется как отображение данных модели согласно метаданных метамодели на некую нотацию. Это и есть DSL: свой для каждого представления, которое является просто отображаемой на презентации картинкой (необязательно прямоугольной), и оно редактируемо (т.е. служит как средством вывода, так и средством ввода данных модели).
-- представления могут быть в форме, особо удобной для манипулирования (редактирования), например двухпанельные Commanders или многопанельные Browsers. Они, понятно, набираются из элементарных представлений, но всякие варианты драг-н-дроп (включая управление через жестовые интерфейсы) обязательно поддерживаются.
2. Проектор-контроллер -- обеспечение объединения презентаций разных интерфейсеров (общий драг-н-дроп прежде всего, общие команды ко всем интерфейсерам, жестовый интерфейс для группы людей и т.д.). В двух вариантах:
-- в реале управление выводом интерфейсеров на разные имеющиеся вокруг экраны, как в g-speak (http://www.oblong.com/), плюс другие идеи из MS project Natal.
-- в виртуале раскидывание вывода интерфейсеров по предметам окружающего мира, как в http://www.qwaq.com/, но управление опять-таки как в project Natal (а внутри -- тот же g-speak).
Только не поддавайтесь очарованию тамошних примеров манипулирования фотографиями и фильмами: очень много работы с предметами PraxOS будет нормальной текстовой и табличной (в том числе формовой), а не идеографической-иероглифической.
3. Репозиторий -- его задача поддерживать целостную базу знаний (в классическом понимании: ежели программы, которые трудятся над данными, хранятся в базе данных, равно как и схема базы данных, то такую базу данных назовем базой знаний). В репозитории есть:
-- upper ontology. Например, из ISO 15926. Или из ISO 18629 (PSL). Вряд ли из SBVR, ибо тамошняя модель очень небогата.
-- RDL (и тут нужно подумать, собственная или внешняя), как минимум состоящая из метамоделей предметов
-- предметные модели
Как именно это все устроено внутри (семантич.сетка, логика, объекты) -- это предмет отдельного обсуждения. Судя по сегодняшним онтологическим трендам, все неизбежно скатывается к логике.
Двоюродные дедушки этого репозитория PraxOS -- репозитории современных САПР (SPF, SmarTeam, Vnet и т.д.).
4. Коммуникатор -- интерфейс Pub/Sub (думайте о каком-то гибриде между реализацией Facade из ISO 15927-7 и real-time data distribution specification, OMG DDS http://portals.omg.org/dds) для связи с внешним программным миром (другими движками PraxOS, адаптерами к legacy-приложениям и т.д.).
5. Движок -- мультипарадигмальная мультиязыковая платформа программирования. На ней, собственно, все остальное и написано. Например, это может быть пиумартовская COLA с добавками логической парадигмы, но обязательно умеющая распараллелиться (сейчас, как я понимаю, у COLA с параллельностью никак).
6. Предметы -- метамодели предметной области для Репозитория+Коммуникатора (включая словари для "локализации" для словарных сообществ) плюс отображения в нотации для Интерфейсера (или добавка к этим нотациям), плюс какие-то аналитические программы (проверка целостности, статистика, вычисления и т.д.). Эдакие стандарты типа оргметамоделей OMG -- BMM, SPEM и т.д. Примерно соответствуют "профайлам", или "mdac", или "плагинам" для UML2-моделеров.
И не забыть сюда же разные варианты тьюториалов (каждый предмет поставляется в виде учебного софта, а затем этот учебный софт разворачивается на реальное применение).
Чем лучше будет продумана архитектура, тем больше частей других элементов софта PraxOS удастся реализовать в виде предметов. В идеале софт PraxOSа написан сам на себе, и весь состоит из Предметов. Как этого добиться -- отдельный разговор (bootstrapping, конечно!).
Дальше нужно обсуждать:
-- обеспечивающие предметы (предметы, обеспечивающие функционирование PraxOS, но не связанные с организационным моделированием), т.е. уточнять архитектуру: программистская часть работы.
-- целевые предметы (состав поддерживаемых PraxOS предметных областей организационного управления, предметы всевозможных САПР, предметы АСУ ТП и т.д.), т.е. заниматься экспертной (непрограммистской) частью работы. Конечно, лучше всего обсуждать целевые предметы, документируя обсужденное с использованием средств обеспечивающей системы -- обеспечивающих предметов по разработке предметов.
-- существующие международные стандарты, на рекомендации которых можно (я бы даже сказал: нужно) опереться.
1. Интерфейсер -- генератор отчетов, редактор, дебаггер и прочий интерфейс с человеком. Основные черты:
-- на первый взгляд воспринимается как средство подготовки презентаций, но не типа PowerPoint, а зум-презентации типа Prezi (http://prezi.com).
-- Презентации состоят из отдельных представлений, которые берутся из набора, похожего на энциклопедию визуальных представлений (помните "периодическую таблицу методов визуализации"? http://www.visual-literacy.org/periodic_table/periodic_table.html) по способу, похожему на предлагающийся в SmartArt из PowerPoint 2007 (содержание остается одним и тем же в рамках одного типа картинки, но сама картинка представления этого содержания меняется -- а тип картинки подсказывается некоторой экспертной системой, основываясь на требованиях по представлению содержания: много там или мало текста, связей, графики и т.д.).
-- Каждое представление препрограммируется как отображение данных модели согласно метаданных метамодели на некую нотацию. Это и есть DSL: свой для каждого представления, которое является просто отображаемой на презентации картинкой (необязательно прямоугольной), и оно редактируемо (т.е. служит как средством вывода, так и средством ввода данных модели).
-- представления могут быть в форме, особо удобной для манипулирования (редактирования), например двухпанельные Commanders или многопанельные Browsers. Они, понятно, набираются из элементарных представлений, но всякие варианты драг-н-дроп (включая управление через жестовые интерфейсы) обязательно поддерживаются.
2. Проектор-контроллер -- обеспечение объединения презентаций разных интерфейсеров (общий драг-н-дроп прежде всего, общие команды ко всем интерфейсерам, жестовый интерфейс для группы людей и т.д.). В двух вариантах:
-- в реале управление выводом интерфейсеров на разные имеющиеся вокруг экраны, как в g-speak (http://www.oblong.com/), плюс другие идеи из MS project Natal.
-- в виртуале раскидывание вывода интерфейсеров по предметам окружающего мира, как в http://www.qwaq.com/, но управление опять-таки как в project Natal (а внутри -- тот же g-speak).
Только не поддавайтесь очарованию тамошних примеров манипулирования фотографиями и фильмами: очень много работы с предметами PraxOS будет нормальной текстовой и табличной (в том числе формовой), а не идеографической-иероглифической.
3. Репозиторий -- его задача поддерживать целостную базу знаний (в классическом понимании: ежели программы, которые трудятся над данными, хранятся в базе данных, равно как и схема базы данных, то такую базу данных назовем базой знаний). В репозитории есть:
-- upper ontology. Например, из ISO 15926. Или из ISO 18629 (PSL). Вряд ли из SBVR, ибо тамошняя модель очень небогата.
-- RDL (и тут нужно подумать, собственная или внешняя), как минимум состоящая из метамоделей предметов
-- предметные модели
Как именно это все устроено внутри (семантич.сетка, логика, объекты) -- это предмет отдельного обсуждения. Судя по сегодняшним онтологическим трендам, все неизбежно скатывается к логике.
Двоюродные дедушки этого репозитория PraxOS -- репозитории современных САПР (SPF, SmarTeam, Vnet и т.д.).
4. Коммуникатор -- интерфейс Pub/Sub (думайте о каком-то гибриде между реализацией Facade из ISO 15927-7 и real-time data distribution specification, OMG DDS http://portals.omg.org/dds) для связи с внешним программным миром (другими движками PraxOS, адаптерами к legacy-приложениям и т.д.).
5. Движок -- мультипарадигмальная мультиязыковая платформа программирования. На ней, собственно, все остальное и написано. Например, это может быть пиумартовская COLA с добавками логической парадигмы, но обязательно умеющая распараллелиться (сейчас, как я понимаю, у COLA с параллельностью никак).
6. Предметы -- метамодели предметной области для Репозитория+Коммуникатора (включая словари для "локализации" для словарных сообществ) плюс отображения в нотации для Интерфейсера (или добавка к этим нотациям), плюс какие-то аналитические программы (проверка целостности, статистика, вычисления и т.д.). Эдакие стандарты типа оргметамоделей OMG -- BMM, SPEM и т.д. Примерно соответствуют "профайлам", или "mdac", или "плагинам" для UML2-моделеров.
И не забыть сюда же разные варианты тьюториалов (каждый предмет поставляется в виде учебного софта, а затем этот учебный софт разворачивается на реальное применение).
Чем лучше будет продумана архитектура, тем больше частей других элементов софта PraxOS удастся реализовать в виде предметов. В идеале софт PraxOSа написан сам на себе, и весь состоит из Предметов. Как этого добиться -- отдельный разговор (bootstrapping, конечно!).
Дальше нужно обсуждать:
-- обеспечивающие предметы (предметы, обеспечивающие функционирование PraxOS, но не связанные с организационным моделированием), т.е. уточнять архитектуру: программистская часть работы.
-- целевые предметы (состав поддерживаемых PraxOS предметных областей организационного управления, предметы всевозможных САПР, предметы АСУ ТП и т.д.), т.е. заниматься экспертной (непрограммистской) частью работы. Конечно, лучше всего обсуждать целевые предметы, документируя обсужденное с использованием средств обеспечивающей системы -- обеспечивающих предметов по разработке предметов.
-- существующие международные стандарты, на рекомендации которых можно (я бы даже сказал: нужно) опереться.