?

Log in

No account? Create an account
Тезисы к архитектуре софта PraxOS - Разработка PraxOS
March 30th, 2011
03:05 pm
[ailev]

[Link]

Previous Entry Share Next Entry
Тезисы к архитектуре софта PraxOS
Еще пару лет назад софт PraxOS казался недостижимой утопией (http://ailev.livejournal.com/701355.html), а сейчас (после выхода .15926 browser, http://community.livejournal.com/dot15926/21895.html) он кажется утопией уже вполне достижимой, хотя для этого нужно сильно потрудиться. Данные архитектурные тезисы дают основные направления требуемых трудов, как они понимаются сегодня:

1. Главный артефакт, который создаёт софт PraxOS -- это архитектурное описание организации (enterprise architecture, и тут особый привет J.Dietz, http://ailev.livejournal.com/920634.html).
Это описание связывает функцию (цели) и конструкцию (ответственности и полномочия акторов) организации -- http://ailev.livejournal.com/920248.html
Его также можно трактовать как (мета)модель организации (без исторических данных).
Можно считать это архитектурное описание справочными данными, задающими проектные данные (в данном случае -- данные продуктных и коммуникативных фактов, т.е. фактов о транзакциях, если говорить в терминах DEMO. Они же -- исторические данные).

2. Каталог методов организационной работы (как организовано дело, основной предмет PraxOS как набора лучших организационных практик) -- это часть организационной архитектуры. Описание предпринятий этих методов -- это уже исторические данные.
Хотя, как всегда, в этих описаниях есть многоуровневость специализации и экземпляризации (instantiation) метода. Так, начальный каталог методов PraxOS создаётся при помощи софта PraxOS и поставляется вместе с ним для использования в КонкОрге (http://praxos.ru/index.php/Конкорг). Затем происходит специализация организационных методов для условий КонкОрга -- и это тоже происходит при помощи софта PraxOS.

3. Тем самым самым софт PraxOS поддерживает архитектурный язык (в смысле ISO 24744 -- набор концепций), позволяющий выразить:
-- функции организации (в том числе цели) и конструкцию (в том числе акторов, инструменты, информационные системы и т.д.) во взаимосвязи с функциями -- тут, похоже, будет много DEMO
-- каталог организационных методов (думаем об ISO 24744 и OMG SPEM/SEMAT)
-- процессы-workflow (думаем o BPMN)
-- описать информационные системы, поддерживающие работу организации (что традиционно для enterprise architecture: объединение описаний деятельности и описаний информационных систем в рамках одного архитектурного описания).

Именно тут обсуждается вопрос о том, какие группы описаний, какие в этих группах описаны сущности, какие правила соответствия (correspondence rules), если считать, что архитектурное описание строится по ISO 42010. Тут нужно обсуждать, почему все эти Zachman, TOGAF и т.д. с их десятками предначертанных групп описаний не работают. Продуктивный ход -- это деятельностный: каждый метод организационного действия требует удобных для него описаний, а других описаний не требует.
Можно считать, что речь идет о каком-то architectural framework PraxOS, который закрывает описательные потребности организационных методов (текущий начальный список орг.методов см. в http://community.livejournal.com/praxos/7722.html).
Архитектурный язык (в смысле ISO 24744) мы выражаем в терминах специализированных шаблонов ISO 15926.

4. Тем не менее, есть еще понятие архитектурного языка для архитектурных фреймворков (язык в смысле ISO 42010, думаем об UML/SysML/AADL/ArchiMate) можно строить, исходя из следующих выборов:
-- модульный язык, расширяемый нужными DSL (с использованим инструментария language workbench)
-- включающим онтологическую часть (критика UML со стороны команды OPDM)
-- включающим возможность выразить мэппинг его понятий в существующие информационные системы.
Можно считать, что метамоделью (типа MOF для UML/SysML) для этого языка будет ISO 15926-2. Дальше вопрос, каким будет сам язык (набор понятий), и какие диаграммы для него будут простроены.
Скорее всего, это будет модульный онтологический язык .15926L, который будет поддерживать разные организационные DSL (например, виды диаграмм) для поддержки определенных организационных методов.

Тем самым выделяется две работы:
-- создание .15926L (язык шаблонов в нотации Prover9, или язык диаграмм части 7 -- как раз такие языки. Можно ли сделать лучше?)
-- определение первоочередного набора организационных DSL (для чего нужно определить методы, и понять необходимые для них DSL -- например, разобраться диаграммными техниками/DSL для описания жизненных циклов http://ailev.livejournal.com/917251.html и орг.методами, их использующими; диаграммами "сэндвич" из http://ailev.livejournal.com/920248.html и орг.методами, их использующими -- и т.д., причём начиная с методов, а не диаграмм).

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

5. Трансакционные данные (координационные и производственные факты, описания конкретных изделий и т.д. -- исторические данные, данные предпринятий) поддерживаются различными корпоративными информационными системами, имеющими каждый своего производителя и поддерживаемую схему данных, соответствующую какому-то обобщенному методу орг.работы: мы понимаем, что в корпоративных информационных технологиях уже давно нет greenfield проектов, мы всегда приходим уже на истоптанную brownfield инструментальную площадку. Тем самым, в проектах освоения новых организационных методов нужно обеспечить два действия в сфере информационных технологий:
-- дополнение существующих информационных систем новыми, соответствующими требуемой организационной архитектуре видами данных и связанными с ними операциями. Например, это нужно в части обеспечения явного учёта всех необходимых коммуникационных фактов на предприятиях -- то есть установления какого-то аналога VISI протокола для основных транзакций (http://www.demo.nl/practical-case-studies/why-visi). Можно думать об этом как о "настройке" вновь закупаемого и "донастройке" уже эксплуатирующегося софта.
-- интеграция данных уже имеющегося софта, в том числе с созданием (настройкой) нового workflow, соответствующего этой интеграции данных.
Обе этих функции требуют возможности мэппинга справочных данных PraxOS к справочным данным (схемам данных) различного корпоративного софта.

6. Тем самым для софта PraxOS используется комбинация методов "ISO 15926 Inside" и "ISO 15926 Outside" для двух стадий организационной работы PraxOS:

а) определение организационной системы (system definition в V-диаграмме), т.е. использование софт PraxOS начальниками (B-organization): поддержка дискуссии о том, как должно быть (обеспечение дискурса, в терминах DEMO). Сейчас обеспечивается флипчартом, PowerPoint и разными видами оргдиаграмм. Это создание справочных данных, т.е. архитектура организации оригинально разрабатывается и ведется как "ISO 15926 Inside", для чего используется .15926 language workbench, со всей наличной онтологической поддержкой для работы со множеством DSL и возможностями проверки целостности. Это вожделенный "универсальный моделлер", который позволяет создать необходимые организационные модели, необходимые модели методов работы и т.д.

б) воплощение организационной системы (system realization в V-диаграмме), т.е. использование софта PraxOS программистами (D-organization): поддержка интеграции данных, справочные данные как шаблоны ISO 15926 и их аналитические диаграммы. Сейчас обеспечивается IRING или "обменом данных точка-точка". Так как транзакционные данные (производственные и коммуникативные факты,) храним в корпоративных информационных системах, и их используем для разработки, то используем подход "ISO 15926 Outside" в части организации мэппинга: универсальный моделер служит для предоставления справочных данных, позвляющих как настроить и донастроить корпоративные информационные системы для их соответствия разработанной организационной архитектуре, включая выбранные методы организационной работы, так и для целей обмена данными -- т.е. создания адаптеров к корпоративным информационным системам.

Хотим мы, или не хотим, но для полноценного внедрения софта PraxOS в нём должна быть достигнута вся полнота функциональности "ISO 15926 Outside" (т.е. мы в какой-то степени повторим IRING), никакой "развилки" между этими двумя путями нет.

7. Требование к проекту praxos со стороны проекта dot15926 -- к осени (когда завершим поддержку "ISO 15926 Outside") иметь набор организационных DSL (набора понятий плюс видов нотаций), которые нужно будет поддержать в качестве начального набора для "ISO 15926 Inside". Это можно создавать методом претотипирования (например, используя Excel, PowerPoint и Word в качестве "универсального моделера"), но к осени эти языковые модули ОргЛана должны быть готовы (поностальгируем о том, как мы определяли ОргЛан в 2007г.: тут, или в том же 2007г. "выразить сущность организации на Орглане" из http://ailev.livejournal.com/485066.html -- какая поэзия! Тем не менее, многие мысли из тех времен вполне сохранили актуальность).

Так что это у нас будет весьма языко-ориентированное лето, в том числе лето нотационной инженерии (http://ailev.livejournal.com/546301.html, http://ailev.livejournal.com/548756.html, http://ailev.livejournal.com/549681.html, http://ailev.livejournal.com/613067.html) -- впрочем, это я тут уже повторяю кусочками "Еще раз о планах релиза 2.1 PraxOS" годичной давности http://community.livejournal.com/praxos/1719.html

(4 comments | Leave a comment)

Comments
 
From:dmfilippov
Date:March 30th, 2011 07:47 pm (UTC)

Терминологический вопрос

(Link)
Хотелось бы уточнить - Вы сознательно используете в п.5 термин "коммуникационные" в описании трансакционных данных "Трансакционные данные (КОММУНИКАЦИОННЫЕ и производственные факты...", или подразумевается "КООРДИНАЦИОННЫЕ и производственные.."?
В первоисточниках (насколько я понимаю) понятия коммуникационных и координационных актов разделяются; в результате исполнения координационных актов(coordination acts) участники трансакций принимают на себя обязательства (commitments), вследствие чего и возникают координационные факты (C-facts). Коммуникационные акты же необходимы для выполнения предварительных условий (формативных и информативных) для реализации координационного акта. Т.е. имеет место отношение "использования-поддержки" (use-support) между координациоными и коммуникационными актами.
P.S. Не буквоедствую - занимаюсь переводом некоторых из этих самых "первоисточников", пытаюсь разобраться с терминами и их значениями.
[User Picture]
From:ailev
Date:March 30th, 2011 08:45 pm (UTC)

Re: Терминологический вопрос

(Link)
Конечно, это были координационные факты (вы абсолютно правы), с другой стороны DEMO базируется на communicative action theory, что приводит нас к материалам по иллокутивной логике, прагматике в коммуникациях и т.д. Поэтому у меня в голове это немного перемешалось, причём даже не в том значении слова "коммуникационные", в котором вы описываете эти отношения между координационными и коммуникационными актами, а в более широком контексте моих размышлений о важности самых разных современных подходов и связанных с ними групп описаний коммуникаций между агентами.

Я исправил, спасибо.

Насчёт переводов: не забываем, вот наши древние предложения по переводу -- http://ailev.livejournal.com/644440.html (и там ссылка на русский текст). Мы довольно подробно в те поры обсуждали терминологию, и с удивлением обнаружили, что Диец использует "онтологию" как омоним, в четырёх разных смыслах. Ну, мы и перевели это по-разному. Поглядите, вам это может показаться интересным.

Возможно, что нам тоже придется вернуться к этим переводам: мы планируем заняться онтологическим моделированием DEMO (т.е. изложением его в ISO 15926). А для онтологического моделирования понятийные разбирательства с переводом как раз очень полезны.

Эх, мне бы в те давние поры переводов-пересказов DEMO быть таким умным, как я сейчас! :-)
From:dmfilippov
Date:April 1st, 2011 10:20 am (UTC)

Re: Терминологический вопрос

(Link)
Да, спасибо за ссылку на "переводческие разборки" по Дитцу.

Я периодически справляюсь при переводе с глоссарием в упомянутом вами тексте. Согласен с необходимостью придерживаться единой терминологии, а не создавать параллельную языковую реальность.

У меня сохранены ваши материалы <http://ailev.livejournal.com/816938.html> (ISO 24744 (метамодель для методологий разработки) по-русски) и
"Глоссарий системной инженерии"

Буду признателен, если найдете время дать ссылки на аналогичные материалы со словарями/обсуждениями переводов отдельных терминов/семейств терминов.
(Deleted comment)
[User Picture]
From:ailev
Date:March 31st, 2011 02:20 pm (UTC)
(Link)
Обойтись без них нельзя, ибо workflow (последовательность действий агентов -- людей и машин) задаётся именно в терминах workflow, развертки во времени. BPMN 2.0 сегодня является де-факто стандартом для этой предметной области.

В любом случае, нужна какая-то онтология. Самая крутая онтологическая проработка процессов-workflow была именно при создании BPMN 2.0, и эту же онтологию сейчас собираются поддержать все business-process engine (которые сейчас появляются чуть ли не по платформе в неделю). Так что заниматься BPMN 2.0 придётся, невзирая на все неминуемые трудности.
My Website Powered by LiveJournal.com