?

Log in

No account? Create an account
PraxOS 3.0: архитектурные принципы - Разработка PraxOS
October 23rd, 2012
01:10 am
[ailev]

[Link]

Previous Entry Share
PraxOS 3.0: архитектурные принципы
1. Используем театральный блендинг (концептуальная интеграция: использование слов, переносящих элементы значений из одной ситуации в другую, "склеивание миров", морфизм/мэппинг из одной предметной области в другую -- http://ailev.livejournal.com/1015195.html). Собственно, это мы уже неоднократно делали, в http://community.livejournal.com/dot15926/16745.html наиболее развёрнуто:
Театральная метафора

Основная метафора постановки методологии [метод и методология, как объяснено в ISO 24744 -- синонимы]– театральная.

Методология – это сценарий для прописанных ролей, который необходимо исполнить имеющейся труппой реальных людей, назначенных на роли. В ходе постановки пьесы проводится кастинг людей-актеров на роли, эти роли затем разучиваются, закупается реквизит, спектакль репетируется для осуществления правильного взаимодействия актеров друг с другом и реквизитом, а затем осуществляется игра актеров в спектакле соответственно их ролям.
Также я говорил немного на эту тему весной 2010 http://ailev.livejournal.com/818816.html ("Театральная метафора: методологии как сценарии, предприНятие как игра акторов по сценарию. Постановка"), а чуть раньше использовал при переводе на русский ISO 24744 (http://ailev.livejournal.com/816938.html -- "Театральная метафора тут не случайна, она еще много раз пригодится -- акторы, роли, труппа, режиссер-организатор, директор театра, пьесы и сценаристы, импровизация и т.д... Ну, или метафора музыкального ансамбля, которая очень похожа, но в немного более трудном для данного случая языке".).

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

2. Опираться нужно не на подход ситуационной инженерии методов (это был "предварительный подход к снаряду", очень полезный в плане онтологических рассмотрений описаний деятельности), а на подход высокоуровневого моделирования архитектуры предприятия (АрхиМейт как нулевое приближение) и далее низкоуровневое полное моделирование предприятия (см. "PraxOS 3.0: адаптивная архитектура предпринятия", http://praxos.livejournal.com/13988.html). Из ситуационной инженерии методов тем не менее, нужно взять понимание разницы между endeavour и методологической предметной областью (набором паттернов работы -- описаний методов, сценариев).

3. Для того, чтобы учесть и постановочную природу деятельности, и импровизационный ее характер, будем использовать адаптивное управление кейсами (http://ailev.livejournal.com/946134.html) и чеклисты (http://ailev.livejournal.com/1029295.html).

Ключевой момент: мы будем называть сценариями (scripts) "паттерны из библиотеки" -- "template element library", она же community library for templates. В принципе, эти сценарии соотносятся и с user cases для реквизита этих сценариев (ведь тоже переводятся как сценарии). Чем это отличается от "процессов" и "практик"? Процессы и практики -- это именно действия, а вот сценарии -- это паттерны, описывающие для каких-то входных условий и сами действия, и все относящиеся к этим действиям объекты работы (реквизит) и выполнителей (роли).

Кейс же -- это endeavour, конкретное предпринятие-проект (аналог театрального представления по конкретному сценарию в конкретную дату). Отдельная организация-предпринятие -- это тоже такой большой кейс (со всеми его архивами в качестве кейс-файла и регулярным стратегированием на тему "как жить дальше". Это уже даже не представление от занавеса до занавеса, а целый театр со всеми его отдельными представлениями, репертуарными комиссиями и закулисными интригами). Я про предпринятия в части их масштаба и их отличия от community of practice писал чуть подробней тут: http://praxos.livejournal.com/14905.html

4. Ключевая идея -- это подход к предпринятию как к киборгу. Но если раньше я считал, что полезно было бы использовать более точный и продвинутый программистский язык для описания человечьей деятельности в этом киборге (вот, например: рассуждение 2007г., где я сначала говорю про необходимость описывать деятельность на человеческом языке, а затем сбиваюсь на "компьютерную грамотность" -- http://ailev.livejournal.com/470473.html), то после опыта русификации Архимейта (http://ailev.livejournal.com/988360.html, комментарии по этим переводческим "с программистского на менеджерский" решениям -- http://incose-ru.livejournal.com/33568.html) я склоняюсь к ровно противоположной идее: это программистские сценарии нужно описывать по-человечьи, а не по-птичьи (по-айтишному).

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

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

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

Конечно, PLM в данном варианте -- это ACM-система, поддерживающая реализацию набора сценариев для каждого инжинирингового проекта/кейса на базе типовых сценариев (паттернов содержательной работы, паттернов организации работ). Но если в ACM-системе основное внимание уделяется именно сценариям ("скриптам"), то в нашем варианте не меньше внимания уделяется и справочным и проектным данным (PDM). Пока бы я говорил о PLM 3.0 (термин незанятый после демарша Dassault Systemes ;-) у которой:
-- семантическая работа с данными (решает проблемы объект-атрибутной модели данных, описанные в книжке BORO).
-- ACM-движок в части обеспечения сценариев работы (решает проблемы workflow и issue tracking движков)
-- реализованы возможности PDM-системы в части управления конфигурацией не только геометрической и "атрибутивной" информации, но и в части информации разнообразных систем экономического, мультифизического, эргономического и прочего моделирования (решает проблемы управления конфигурацией мегамодели на стадиях высокоуровневого и низкоуровневого моделирования -- http://ailev.livejournal.com/829028.html)

6. Проблема семантической части известна: нужен онтологический язык, удобный для работы с ACM и PDM. Можно считать, что ISO 15926, дополненный какими-то геометрическими (эксперименты Части 3), ACM (наша работа с ОнтоЛаном) и примитивами моделировая (внимательно смотрим на онтологию проекта http://simantics.org) явится решением в первом приближении.

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

7. В части ACM-движка в PLM 3.0 должен быть соблюдён баланс кодов и скриптов.

Такой баланс получается за счёт создания специальных "оболочек" (IDE, shell), которые в диалоге работают со исполняемыми фрагментами (snippets) на скриптовых (сценарных, высокоуровневых, диалоговых, динамических -- в отличие от компилируемых) языках программирования, вызывающими разные коды из их библиотек. Эти языки обеспечивают:
-- оркестровку: централизованное координирование поведения независимо работающих акторов/выполнителей (людей или кодов). Каждый актор не знает о том, что происходит вокруг, он только исполняет свою централизованно выданную партию по заранее написанным нотам. За результат несёт ответственность тот, кто поручил работу.
-- хореографию: взаимокоординированное поведение группы совместно работающих акторов/выполнителей (людей или кодов), которые подстраивают своё поведение друг под друга.

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

Коды и люди -- это внешние по отношению к ACM-движку сущности.

"Скрипт" -- это сценарий (паттерн, программа, алгоритм) либо работы людей, либо работы кодов, либо их совместной работы (часто называемой workflow). Это скриптование в научном компьютинге выполняется часто на языке Питон, а в операционном (operations management) компьютинге из языков типа BPMN.

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

Онтология описания кодов, доступных из сценариев в духе адаптивного управления кейсов -- это как раз то, что вынуждены были сделать люди из проекта Simantics для кейсов моделирования. Вот, например, основные классы в онтологии моделирования задачи многих тел (http://www.vtt.fi/inf/pdf/publications/2011/P766.pdf, стр.75. Специфичное для "мультительности" я выкосил):
-- Analysis, which collects all the necessary data associated to a simulation case; [such as analysis type, duration of the simulated time, and the size of the time step]
-- Case, a system simulation case, which holds all the elements of a simula-tion case organised under the elements model, analysis, and results; [which consists of at the most one component of the classModel, at the most one component of the class Analysis, and at the most one component of the class Results. Thus, the instances of the class Case are containers for all the modelling, analysis, and results data for one simulation case. ]
-- Model and SubModel, which collect all the data associated to a multibody system simulation model and enable modular modelling using nested submodels; and
-- Results, which collects the results data associated with the analyses of the case. [TheResults class is a container for the numerical data produced by the numerical solver for the analysis of the case, defined by the instance of the class Analysis].
8. Языки скриптования создаются по образу и подобию языков программирования, а там пока не пахнет операционным менеджментом (планированием использования ресурсов в части "критической цепи", прогнозами, доступа к конфигурации и т.д.). Вот я писал об этом в 2007г: http://ailev.livejournal.com/460198.html). Тем самым язык сценирования/скриптования проектов-в-смысле critical chain management или описания цепочки поставок может существенно отличаться от языка описания сценариев/практик в архитектуре предприятия или процессного описания, а этот язык может существенно отличаться от языка скриптования для управления оптимизацией мультифизической модели инженерной системы (т.е. языка скриптования для библиотек программ оптимизации и геометрического и прочих солверов).

И это только начало проблем с этими языками.

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

В сегодняшней моделеориентированной [системной] инженерии [и инженериям по специальностям] вопрос решается просто: "актёры не пишут свои сценарии, это пишут специально обученные драматурги". В PLM системах в части issue trackers/workflow описание сценариев работы (процессов)/скриптование делают программисты, используя внутренние языки этих систем (а эти языки весьма специфичны, это даже не Python и не BPMN). В системах моделирования (как инженерных, так и научных) описание сценариев работы кейсов моделирования/скриптование обычно делается на Питоне самими модельерами.

Важно признать, что проектирование и связанное с ним моделирование выполняется как exploratory computing, т.е. это не "водопадный" подход с последовательным однократным прохождением каждой заранее описанной практики/каждого заранее известного сценария. Нет, принимать решение, что делать дальше, нужно прямо в ходе вычислений -- и поправлять имеющиеся сценарии/скрипты прямо по ходу дела в зависимости от ситуации, а при отсутствии сценариев допускать "непосредственное исполнение" (импровизацию, пошаговую работу без сценария/скрипта -- при этом от "автоматизации" остаётся только помощь в ведении протокола, обязательного для ACM-систем. Учёт для аудита/audit trail и возможного последующей рефлексии с извлечением опыта в виде нового сценария или автономизации-с-оптимизацией какого-то сценария в виде эффективно выполняемого кода -- это святое.).

Конечно, в завтрашней моделеориентированной инженерии вопрос качественной методологической/методической/сценарной работы/скриптования/программирования будет решаться многими путями:
-- рост программистской квалификации инженеров (что не так уж невероятно. Тренд включать в образование инженеров программирование как основную дисциплину наряду с математикой и физикой уже налицо).
-- в рамках неизбежно возникающего разделения труда всё более и более частое включение в команды инженерных проектов профессиональных программистов, которые смогут работать со скриптами в ходе проекта (run time), а не во время подготовки производства (up-front "настройка процессов").
-- упрощение самих языков с учётом данных когнитивной науки (например, опора на image schema и блендинг в духе исследований Lakoff вместо опоры на абстрактные математические модели как в Haskell), это даст возможность работы с этими языками если не кухаркам, то простым инженерам.

В любом случае, тут не обойтись одним языком, скорее их будет целый букет и придётся думать в духе cooperative/collaborative languages для cooperative/collaborative solvers (термин по мотивам нынешних штудий группы Алана Кея по архитектурам с использованием разных солверов и разных языков для их скриптинга -- http://vpri.org/html/writings.php).

9. В данном подходе коды/люди/утилиты/приложения представлены не столько как "агенты", сколько как функционалы/capabilities, доступные вовне (сценариям/скриптам в оркестровке и друг другу в хореографии) как services. Но это не веб-сервисы (как и отсылка к семантике в пункте 6 -- это не отсылка к semantic web), с этими тормозами и этой невыразительностью от W3C не нужно иметь дело.

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

10. Начальный набор практик/библиотеки сценариев (конкретные практики из предыдущей версии в http://praxos.livejournal.com/14273.html ещё ждут своего прохода для включения в это уточнённое для моделеориентированной системной/специальной инженерии дерево. Да и дерево неплохо бы пересмотреть, включив в него анализ проблем из III в http://ailev.livejournal.com/1026262.html. Это должна быть отдельная работа, а тут кратенький примерчик просто, чтобы не терять целостности изложения):
Основная деятельность (сценарии, которым следуют люди-производственники)
-- маркетинг 
   --методы длинных продаж SPIN)
-- инженерия (моделеориентированная, в опоре на описания
   формальных систем -- http://ailev.livejournal.com/728605.html)
    -- системная инженерия
    -- инженерия системных целей
    -- высокоуровневое моделирование (инженерия системной архитектуры)
    -- низкоуровневое моделирование (мультифизика, мегамоделирование)
    -- обеспечение качества (верификация)
    -- порождающее производство (из битов в атомы)
    -- приёмка (валидация)
    -- эксплуатация и поддержка
    -- мусоропереработка (disposal)
    -- инженерия знаний, НСИ, справочных данных 
       [в части их создания, "инженерии" -- для переноса опыта 
       между предпринятиями по созданию отдельных систем.
       Cм. также "управление информацией"]
  -- инженерия по специальностям:
    -- механика
    -- электротехника
    -- ...
-- операции
   -- управление конфигурацией (учёт)
   -- управление кейсами [сценарии, планирование графика, 
      учёт факта/контроль выполнения]
   -- управление информацией (знаниями, НСИ, справочными данными)
       http://ailev.livejournal.com/1021613.html
   -- throughput accounting

Оргтехразвитие (сценарии, которым следуют люди-организаторы):
-- стратегирование
   -- деревья стратегии и тактики
   -- управление технологиями (и дилемма инноватора)
-- организационная инженерия (метаописания практик)
   -- архитектура предпринятия
   -- сценирование/описание практик/ситуационная инженерия методов up front
   -- учёт стадии жизненного цикла предприятия (Адизес)
-- ведение проектов развития
   -- leadership


11. ОнтоЛан должен отражать опыт множества ситуаций применения, а не быть заточенным на одну ситуацию, хорошо описываемую первым попавшим под руку для мэппинга стандартом.

Теперь нужно:
-- сделать "рассказ PraxOS" на основе данного текста утрясти терминологию (определиться со всеми синонимами, консистентностью использования блендинговых метафор и т.д.). То есть "доперевести на русский" с причьего языка, использованного в данном постинге.
-- сделать глоссарий из встречающихся по тексту Рассказа концептов, Конечно, в глоссарии уже не будет развёрнутого описания тех подходов, которые были использованы, и обоснования сделанных архитектурных решений. Это описание-с-обоснованием -- как раз данный текст. В глоссарии также не будет прописана связь между понятиями -- это должно быть понятно из Рассказа.
-- Первая итерация: именно из этого глоссария (а не, например, из Архимейта) сделать начальный набор классов ОнтоЛана.
-- Вторая итерация: сделать мэппинг для Архимейта, стандартов ACM, описаний систем exploratory computing и т.д., отредактировав и дополнив первоначальный набор классов.

(5 comments | Leave a comment)

Comments
 
[User Picture]
From:Sergej Pavlenko
Date:April 24th, 2013 04:56 am (UTC)
(Link)
От печки - язык само-общения.

Согласен, что есть много задач, которые надо решить при подступах к систематическому осмыслению предпринятия, и надо их приоритизировать (или иначе упорядочить) для обеспечения решения. При этом первоначально рассуждения на тему "я и мои Задачи" ведется в сознании Интересанта на его внутриголовном языке.

То есть первоначально "Субъект - Объект", Субъект ощущает (зрительно :) Объект, и имеет намерение с Объектом произвести свою Деятельность. Субъекту надо самому с собой разговаривать (писать себе напоминалки наутро). Поэтому согласен, первая Задача - это зафиксировать самому себе язык для внутреннего раассуждения. Затем, конечно, и договориться о языке для общения между несколькими Субъектами. Согласились, что это "театральный язык- подвид русский"
[User Picture]
From:ailev
Date:April 24th, 2013 07:01 am (UTC)
(Link)
Внешнее общение приходится вести на языках, которые привычны клиенту. В любом случае, нужен будет мэппинг (перевод -- отождествление сущностей внутреннего и какого-то принятого у клиента представления).
[User Picture]
From:Sergej Pavlenko
Date:April 24th, 2013 07:25 am (UTC)
(Link)
Прото-метод - что в начале?

Цитата: "2. Опираться нужно не на подход ситуационной инженерии методов (это был "предварительный подход к снаряду", очень полезный в плане онтологических рассмотрений описаний деятельности), а на подход высокоуровневого моделирования архитектуры предприятия (АрхиМейт как нулевое приближение) и далее низкоуровневое полное моделирование предприятия (см. "PraxOS 3.0: адаптивная архитектура предпринятия", http://praxos.livejournal.com/13988.html). Из ситуационной инженерии методов тем не менее, нужно взять понимание разницы между endeavour и методологической предметной областью (набором паттернов работы -- описаний методов, сценариев)."

Предложил бы Идеи (и методы) ранжировать по метрике "расстояние от Идеи до корня Отнологии" :) Наверняка это уже изобретено, просто я об этом не слышал. В такой метрике Идея-СИМ менее мощная, чем Идея-ВМАП. И конечно, опираться надо на более мощную Идею (более высокую по рангу Онтологии).

Далее возникает еще один вопрос: например, если мы возьмем некий Метод (Идею) с метрикой R, то существуют ли (и сколько?) Методы (Идеи) с мощностью (метрикой) между 0 и R ? И какие?

И затем было бы полезно взять ЛЮБУЮ идею из области онтологии "менеджмент" (сорри) и выбрать Идеи на цепочке от этой выбранной Идеи до Корневой Идеи (кстати, какая она? :), с тем чтобы затем двинувшись от Корня Онтологии начать с первого применимого метода и выписать последовательно Дерево Методов Предпринятия. Моя гипотеза: раз уж мы согласились в Театральный язык включить язык Системной Инженерии, то недалеко от Корня Онтологии мы наткнемся на Идею Системы-как-таковой (элементы-связи-эмержентность), затем на Идею Системы-с-управлением, а затем на Идею Создателя И Системы, и для каждой Идеи нужны свои Методы.

Следующая гипотеза: некоторые методы более _ситуативные_, а некоторые более _ригидные_ (или "необходимые"?) в применении. И например Метод "Создатель И Система" - не ситуативный ни разу. А через много этажей - Метод "Кадровая-служба-как-процесс-в-среднем-российском-предпринятии" тоже ни разу не ситуативный. А Метод "Стратегическое-управление-в-среднем-российском-предпринятии" как раз таки сильно ситуативный (именно как по методам, так и по необходимости реализации).

В этом смысле "опираться" надо на более корневую Идею-Метод, а над ней выстраивать менее мощные Идеи-Методы.
[User Picture]
From:ailev
Date:April 24th, 2013 08:19 am (UTC)
(Link)
Довольно много по этой линии рассуждений было сделано в OMG Essence -- это новое поколение ситуационной инженерии методов. Конечно, за основу нужно брать его, а не ArchiMate (ибо основные сущности какой-то предметной области и метод как конкретизация основных сущностей до рабочих проектов и дел определяются в нём). Но всё одно, в нём не хватает того, что могут делать VDML и ArchiMate.

Так что новый "рассказ PraxOS" нужно делать на основе OMG Essence, хотя его придётся дорабатывать. Мы уже вступили по линии Русского отделения INCOSE в кооперацию с SEMAT на эту тему: http://semat.org/?p=814
From:annuitet
Date:May 6th, 2014 11:09 am (UTC)
(Link)
Поскольку слов
My Website Powered by LiveJournal.com