10 тезисов к разработке ОргЛана
1. ОргЛан -- это архитектурный язык и метод архитектурного описания (architectural language и architectural framework в смысле ISO 42010) для PraxOS. Пока мы продолжаем считать PraxOS промышленным каталогом компонент методов (http://praxos.livejournal.com/11084.html), содержащим лучшие методы организационной работы. В этом смысле ОргЛан является языком и нотацией, которые нам даёт для описания организаций каталог компонент методов PraxOS.
2. ОргЛан -- это также язык софта PraxOS, он же -- язык "корпоративного органайзера" (май 2007 (http://ailev.livejournal.com/485066.html, и в связи с этим древним постингом я бы напомнил, что название нынешней главной книжки по adaptive case management заканчивается на get things done - http://ailev.livejournal.com/946134.html, так что мы вполне современны).
Необходимый уровень детальности ОргЛана определяется в том числе и тем, что модель ОргЛана сразу предлагается делать не только "для генерации отчётов/исполнительной документации", но и исполняемой (т.е. не повторяем ошибок с удивлением по поводу "неисполняемого UML" или "неисполняемого BPMN" или "неисполняемого описания в ОргМастер" -- и последующим зоопарком решений этих проблем "недоформализованности"). Причём исполнение (т.е. интерпретация модели на ОргЛане софтом-"выполнителем") может быть сразу во многих смыслах: адаптивного управления кейсами -- case execution, автоматизированного порождения ситуационного метода или шаблона кейса (generative case management/method engineering) и т.д.
А для исполнимости не в среде софта PraxOS можно использовать мэппинги ОргЛана для других моделеров и исполняемых сред.
3. Можно считать, что про user needs и способы реализации мы писали более чем достаточно (а хоть и в марте 2011 -- http://praxos.livejournal.com/12277.html, или в июле 2011 --http://praxos.livejournal.com/12576.html -- мы тут в praxos только об этом и пишем, похоже) и можно приступать к архитектурной работе над ОргЛаном. До сих пор мы считали проектирование ОргЛана проблемой, в том числе не могли указать прототип. Данный постинг бьёт проблему языкотворчества на задачи, а для каждой задачи указывает свой прототип и пути решения.
4. В отличие от традиционных определяемых UML-метамоделями языков описания систем и деятельности (типа ISO 24744, ISO 42010 и т.д.), ОргЛан должен быть
4.1. онтологическим в смысле его типов данных (то есть отражающим структуру реальности), т.е. принципиально расширяемым в целях моделирования любых необходимых структур данных. Для этого ОргЛан будет выражен как микротеория на основе foundational ontology ISO 15926-2 (как IDEAS является foundational ontology для метамодели DoDAF 2.0 -- http://dot15926.livejournal.com/24543.html, а MOF является foundational ontology для метамодели SysML и SPEM). В принципе, мы будем считать синонимами "метамодель" (из мира MDA, UML и MOF) и "микротеорию" (из мира онтологий).
Это существенное отличие от традиционного хода на "онтологическое обогащение UML" (каковое мы видим, например, в OPDL http://www.cesames.net/fichier.php?id=370, http://www.cesames.net/fichier.php?id=371 и в ConML http://www.conml.org/), или "изобретение своей минимальной foundational ontology (как это вышло у ArchiMate). Мы хорошо осознаём тот факт, что изобретать foundational ontology и форматы представления онтологических описаний сегодня неприлично даже в масштабах одного университета (как недавно было сформулировано в ontolog-forum), что уж говорить о нашем маленьком проекте. Мы также не идём по пути OWL, декларируя только самые базовые объекты и отношения. Также мы наследуем работу по линии 4D онтологий IDEAS и ISO 15926 -- но возьмем не IDEAS (опять-таки, близкую к UML и даже используемую в архитектурной работе), а ISO 15926.
Вот схема из спецификации ArchiMate (рис.2 из http://www.opengroup.org/archimate/doc/ts_archimate/chap3.html):
А вот схема для OrgLan:
Для программирования деятельности на ОргЛане тем самым недостаточно знать только сами понятия ОргЛана. Это знание не освобождает от понимания задаваемой foundational ontology "картины мира", т.е. необходим тренинг в 4D extensionalism. Это будет "входной билет", "образовательный ценз", и от этого никуда не уйти. По хорошему, 4D extensionalism в части моделирования данных вообще должен изучаться в школьной программе информатики, ибо это парадигмальная штука, и в ВУЗе это изучать уже поздно (кстати, это не только моё мнение). Поэтому программа адаптивного обучения "программиста/модельера на ОргЛане" должна включать в себя программу онтологического ликбеза.
Мы имеем следующие выгоды такого подхода:
а) гарантированную расширяемость ОргЛана (хотя эта гарантия и несколько "дутая": универсальных онтологий не бывает, но тщательно разработанная foundational ontology тут много лучше любых ad hoc решений) на другие предметные области
б) совместимость с детальными описаниями рабочих продуктов, инженерными описаниями и т.д. (по факту, мы просто даём детальную микротеорию для описания организационных систем, в то время как ISO 15926 "из коробки" имеет микротеорию для описания непрерывных производств). То есть наш "каталог организационных методов" в принципе совместим с "каталогом промышленного оборудования" (http://praxos.livejournal.com/11084.html).
в) возможность использования имеющегося инструментария и опыта работы по моделированию (в данном случае -- моделирования организационных систем, софта ISO 15926, учебников типа книжки о методе BORO -- http://ailev.livejournal.com/938647.html).
Про "ОргЛан для самых обычных пользователей" пока забываем. Нам нужен не "организационный бейсик для одного из организационных аспектов", а приличный универсальный язык. Текстовая и графическая нотация ОргЛана по факту будут текстовой и графической нотацией для DSL в "универсальном моделере" (http://dot15926.livejournal.com/24612.html). Пока не поддерживается многодиаграммность (т.е. не "как UML", или "как внешние DSL", а "как ArchiMate" и "как внутренние DSL на базе одного языка и синтаксиса".
4.2. ОргЛан должен быть полным по Тьюрингу в алгоритмическом смысле (ибо любой язык будет развиваться, пока не станет полным по Тьюрингу -- так лучше мы сразу это предусмотрим).
4.3 Возможны "сурово денормализованные" варианты языка -- в том числе порожденные генератором отчетов, выдающим всяческие "положения", "регламенты" и прочая "распорядительная документация". Т.е. для текстов на ОргЛане должен быть предусмотрен не только "парсинг", но и "рендеринг": http://ailev.livejournal.com/925813.html?thread=9257845).
5. Версии
5.1. В версии 0.1 ОргЛан мы будем описывать примерно на том же уровне формализма, как в ArchiMate -- то есть неформально.
5.2. Затем в версии 0.2 ОргЛана будут использованы только классы и отношения части 2 (характеризация).
5.3. В версии 0.3 затем будут сформулированы шаблоны (часть 7 ISO 15926).
5.4. В версии 0.4 для перехода к Тьюринговой полноте будет использован .15926L.
6. ОргЛан задается системой, состоящей из частей:
6.1. архитектурного описания (основная организация и принципы разработки) -- заготовкой для него является настоящий постинг.
6.2. описывающей деятельность микротеории ОргЛана в составе библиотеки справочных данных PraxOS (соответствует "метамодели" в традиционном понимании ArchiMate, ISO 24744 и т.д.)
6.3. текстовой и графической нотаций для выражения моделей, соответствующих этой микротеории (метамодели).
6.4. механизма описания рендеринга (по мотивам XSLT -- ну, или что-то более удобное и приемлемое), но это будем определять позднее
6.5. механизма расширения ОргЛана, который суть ISO 15926 во всей его полноте.
6.6. адаптивного механизма обучения
6.7. примера моделера и исполняющих сред -- софт PraxOS (две среды: отчёты/рендеринг и execution кейсов в стиле ACM).
6.8. примера описания на ОргЛане (описание КонКорга, типа описания ArchiShurance или примера из ISO 24744)
6.9. По потребности можно будет делать мэппинг в исходные метамодели для частных стандартов -- если это нужно будет для передачи данных оргмодели, задействования чужого софта, переработки терминологии в литературе методов-источников (ISO 24744, ArhciMate, ACM и т.д.) в учебные материалы для PraxOS.
7. За основу в определении scope берём "матрицу предметных областей" из ArchiMate, наглядно показывающую его scope (рис. 5 из http://www.opengroup.org/archimate/doc/ts_archimate/chap3.html):
Но мы будем нещадно модифицировать эту матрицу в сторону расширения domains (берем из недавнего обзора http://praxos.livejournal.com/12576.html и годичной давности спецификации http://praxos.livejournal.com/9003.html), прежде всего в сторону business architecture (по сравнению с традиционными IT-центрированными описаниями), но также и в сторону execution-orientation по сравнению с analysis orientation (на что указывают в adaptive case manatement). За основу моделирования берём (и это как раз определяет scope -- после унификации "похожих" концептов) следующие мета-модели:
7.1. enterprise architecture -- ArhciMate (http://ailev.livejournal.com/940819.html). Сюда же -- доопределиться с описанием системы/подсистемы/надсистемы и показом модульности/сервисов/интерфейсов.
7.2. situational method engineering -- ISO 24744 (набор понятий -- http://ailev.livejournal.com/816938.html).
7.3. adaptive case management -- OMG CMMN (http://neffics.eu/wp-content/uploads/2011/06/11-05-12-CMMN.pdf и много дополнительных материалов в http://ailev.livejournal.com/946134.html). Тут нужно задуматься, как учесть BPMN 2 (простыковаться с которым так хотят управляющие кейсами), и нужно ли его учитывать сразу. Сюда же -- WS Human Task 1.1 -- http://docs.oasis-open.org/bpel4people/ws-humantask-1.1.html
7.4. business rules -- OMG SBVR в части собственно rules (т.е. примерно 10% стандарта, а остальные 90% там про бизнес-онтологию) -- http://praxos.livejournal.com/8380.html
7.5. strategy/motivational model (включая обоснования/предположения -- rationale/assumptions) -- карта действий и результатов (http://praxos.livejournal.com/6777.html)
7.6. business model generation -- http://businessmodelgeneration.com/book, но вот в форме метамодели это придется разрабатывать самостоятельно.
7.8. много ценных идей -- DEMO (с учётом критики из http://www.cordys.com/ufc/file2/cordyscms_sites/download/731375d512f6789e8dd8a2775d26c123/pu/cor0027_modeling_rfi_white_paper_lr_v1.pdf). Координационные и производственные акты, B, I, D-организации и т.д.
7.9 управление вариантами (ибо у нас evolving описание) вкупе с управлением конфигурацией (идентификация, учёт и т.д.). Для двух целей: прохождение развилок (trade-offs) и для поддержки типовых решений (паттернов, шаблонов, "рыб" и т.д.).
7.10. Обмены и контракты -- REA2 и NOMOS (http://ailev.livejournal.com/876070.html), legal кусочек из service science: http://www.loa-cnr.it/Papers/FerrGuarFern.pdf.
7.11. Из TOC: ограничение (роль элемента ОргЛана) и критическая цепь (агрегат workunits) -- придется разработать самим. Все эти "управление проектом через отслеживание его буфера времени" -- это сюда.
7.12. Модель стоимости (потоки, маржиналистский учёт). Придётся разработать самим.
7.13. Модель для KPI. Нужны исследования -- обсуждается это и в GORE, и во многих других местах. Плюс нужно разобраться: нужно ли это вообще, или это просто морок.
7.12 что-то из учебных стандартов (ибо нужно уметь представлять "дисциплины" -- что грузится в голову) -- поглядеть на наличные стандарты для всяких курсов. Но, возможно, придётся разработать самим -- в очередной раз изобрести велосипед.
...
По идее, за каждой строчкой тут стоит какой-то отобранный в PraxOS метод организационной работы. Особо отмечу, что ISO 15288 тут никак пока не участвует: он может потом быть записанным на ОргЛане, ежели будет нужно. Или будет записан новый стандарт "моделеориентированной системной инженерии". Или "инженерии системы систем". Или ещё какой-нибудь. Но это уже "используемый метод работы", а не организационный метод (хотя для групп обеспечения проектных практик, проектных практик и практик соглашения можно было бы и поспорить).
Понятно, что для начала нужно будет взять компактное ядро, поэтому "последовательность интеграции" этих всех частных и разнородных метамоделей отражена в том порядке, каком я их привёл: начинаем с головы списка, и далее медленно-медленно идем до его конца, по метамодели за раз. Но нам нужен сразу весь список, чтобы нарисовать нашу domain-таблицу.
Основные идеи по этому "мегамэппингу" (мэппингу на уровне не столько понятий, сколько domains):
а) добавить разделение на 24744:каталог vs endeavor и ACM:design-time vs run-time (в том числе идея, что case -- это как раз в endeavour). Как это показывать на диаграмме?
б) 24744:workunits, workproducts, producers = ArchiMate:behaviour, passive structure, active structure
в) 24744:нотации, языки трактовать в составе методов описания ISO 42010. Как эти 24744:resources = 15926:reference data показывать на диаграмме?
г) 42010: Stakeholders = actors, причем "не бывает нефункциональных требований", вводим понятие stakeholder case как расширение user case -- и далее думаем, как это связано с ACM
... и так далее.
Нарисовать "карту ОргЛана" с описанием domains нужно в первую очередь.
8. Собственно, неформальное задание языка и его неформальная метамодель будут в какой-то степени похожими на таковое в ArchiMate (http://www.springerlink.com/content/pwh613/back-matter.pdf)
Тем самым на "подложке" из "диаграммы domains" из предыдущего пункта показаны классы и отношения предметной области (а про шаблоны и тьюринг-полновость -- нужно будет еще подумать. Пока же -- Gellish и ArchiMate наши рулевые).
В качестве графической среды на "неформальной стадии" разработки микротеории/метамодели можно пробовать использовать VUE -- http://ailev.livejournal.com/895091.html. Дальше, конечно, работаем с .15926 Editor.
Фишка в том, что metamodel для каждого из этих domains содержит 30-70 понятий, которые существенно между собой пересекаются (весь вопрос только в том, насколько существенно!). Так что в идеале от рефакторинга этих метамоделей мы можем получить более компактное представление предметной области -- но помня при этом про эффект "14 стандартов" (http://xkcd.com/927/). Про соотношение между "рефакторить" (компактифицировать знание) и "интегрировать" (мэппить исходные стандарты) подробнее -- http://ailev.livejournal.com/872954.html.
Я бы сделал следующую оценку:
-- foundational ontology дана нам в 201 типе сущностей части 2 ISO 15926, а
-- организационная онтология вся должна уместиться в 300 классах и отношениях, если выбраны достаточно выразительные классы и отношения.
-- плюс мэппинги (но они формально не входят в ОргЛан. Мэппинги возможны и не в исходные стандарты -- они потом возможны в любые стандарты и могут делаться независимо)
9. ArchiMate также является прототипом того, каков наш подход к определению view: это "отфильтрованные куски полной модели" для показа концептов, относящихся только к какой-то тематической группе описаний, а viewpoint тем самым -- это паттерн фильтра, накладываемого на семантическую сетку модели. Этот вариант явно предусмотрен в ISO 42010, так что мы даже соблюдаем при этом стандарт.
Еще раз: не нужно путать domains с view (ибо domain -- это научный предмет, а view это способ комбинировать модели для этих предметов для более удобного их восприятия, в том числе для понимания их связей между собой. То есть соотношение domain и view как М:N).
В ОргЛане прямо сейчас определяются предметные области (domains), но пока не делается предположений о необходимых view -- если их можно будет задавать динамически "паттернами", то библиотека таких паттернов появится "сама собой", в том числе она будет уникальна для каждого кейса-предпринятия использования PraxOS и ОргЛана. Так что (в соответствии с заветами ACM) мы определение view сдвигаем на run-time -- то есть определяем как "динамическое", а шаблоны для этих veiw (т.е. viewpoints) будут создаваться тоже run-time в community library. С учетом возможности расширения самого состава элементов в этих view (расширяемости ОргЛана) это также можно назвать и "адаптивным" заданием view.
10. Предполагается, что обучение ОргЛану происходит "сержантским методом" -- модельеры проходят много-много упражнений (http://ailev.livejournal.com/907435.html), а учебный комплект состоит из:
-- объяснений и главной последовательности комплексных упражнений
-- регистра затруднений и пояснений к ним (нужно разобраться, в чем именно ментальный затык ученика: какой элементарный навык в комплексной задаче у него дефицитен -- и назвать его)
-- (некомплексных) упражнений на отдельные затруднения (зная, как называется элементарный пропущенный навык -- находим пачку упражнений на его тренировку, а потом возвращаемся к выполнению комплексных упражнений)
-- софта, который способен автоматически определять успешность выполнения упражнений (в первой версии) и затруднения во второй версии. О генерации упражнений пока и не мечтаем.
Понятно, что этот алгоритм сначала нужно описать подробно -- это еще ждет своей очереди. Но эта часть крайне важна, и она обязана входить в комплект поставки. Моделирование на ОргЛане контринтуитивно, затрагивает несколько разных парадигмальных сдвигов, и нужен интенсивный тренинг, чтобы пройти соответствующие метанойи. Это сознательный выбор: контринтуитивные очень мощные модели предметных областей плюс тренинг по преодолению этой контринтуитивности против "интуитивных моделей", "минимального тренинга" и соответствующих им "дурацких методов работы с неадекватными описаниями".
2. ОргЛан -- это также язык софта PraxOS, он же -- язык "корпоративного органайзера" (май 2007 (http://ailev.livejournal.com/485066.html, и в связи с этим древним постингом я бы напомнил, что название нынешней главной книжки по adaptive case management заканчивается на get things done - http://ailev.livejournal.com/946134.html, так что мы вполне современны).
Необходимый уровень детальности ОргЛана определяется в том числе и тем, что модель ОргЛана сразу предлагается делать не только "для генерации отчётов/исполнительной документации", но и исполняемой (т.е. не повторяем ошибок с удивлением по поводу "неисполняемого UML" или "неисполняемого BPMN" или "неисполняемого описания в ОргМастер" -- и последующим зоопарком решений этих проблем "недоформализованности"). Причём исполнение (т.е. интерпретация модели на ОргЛане софтом-"выполнителем") может быть сразу во многих смыслах: адаптивного управления кейсами -- case execution, автоматизированного порождения ситуационного метода или шаблона кейса (generative case management/method engineering) и т.д.
А для исполнимости не в среде софта PraxOS можно использовать мэппинги ОргЛана для других моделеров и исполняемых сред.
3. Можно считать, что про user needs и способы реализации мы писали более чем достаточно (а хоть и в марте 2011 -- http://praxos.livejournal.com/12277.html, или в июле 2011 --http://praxos.livejournal.com/12576.html -- мы тут в praxos только об этом и пишем, похоже) и можно приступать к архитектурной работе над ОргЛаном. До сих пор мы считали проектирование ОргЛана проблемой, в том числе не могли указать прототип. Данный постинг бьёт проблему языкотворчества на задачи, а для каждой задачи указывает свой прототип и пути решения.
4. В отличие от традиционных определяемых UML-метамоделями языков описания систем и деятельности (типа ISO 24744, ISO 42010 и т.д.), ОргЛан должен быть
4.1. онтологическим в смысле его типов данных (то есть отражающим структуру реальности), т.е. принципиально расширяемым в целях моделирования любых необходимых структур данных. Для этого ОргЛан будет выражен как микротеория на основе foundational ontology ISO 15926-2 (как IDEAS является foundational ontology для метамодели DoDAF 2.0 -- http://dot15926.livejournal.com/24543.html, а MOF является foundational ontology для метамодели SysML и SPEM). В принципе, мы будем считать синонимами "метамодель" (из мира MDA, UML и MOF) и "микротеорию" (из мира онтологий).
Это существенное отличие от традиционного хода на "онтологическое обогащение UML" (каковое мы видим, например, в OPDL http://www.cesames.net/fichier.php?id=370, http://www.cesames.net/fichier.php?id=371 и в ConML http://www.conml.org/), или "изобретение своей минимальной foundational ontology (как это вышло у ArchiMate). Мы хорошо осознаём тот факт, что изобретать foundational ontology и форматы представления онтологических описаний сегодня неприлично даже в масштабах одного университета (как недавно было сформулировано в ontolog-forum), что уж говорить о нашем маленьком проекте. Мы также не идём по пути OWL, декларируя только самые базовые объекты и отношения. Также мы наследуем работу по линии 4D онтологий IDEAS и ISO 15926 -- но возьмем не IDEAS (опять-таки, близкую к UML и даже используемую в архитектурной работе), а ISO 15926.
Вот схема из спецификации ArchiMate (рис.2 из http://www.opengroup.org/archimate/doc/ts_archimate/chap3.html):
А вот схема для OrgLan:
Для программирования деятельности на ОргЛане тем самым недостаточно знать только сами понятия ОргЛана. Это знание не освобождает от понимания задаваемой foundational ontology "картины мира", т.е. необходим тренинг в 4D extensionalism. Это будет "входной билет", "образовательный ценз", и от этого никуда не уйти. По хорошему, 4D extensionalism в части моделирования данных вообще должен изучаться в школьной программе информатики, ибо это парадигмальная штука, и в ВУЗе это изучать уже поздно (кстати, это не только моё мнение). Поэтому программа адаптивного обучения "программиста/модельера на ОргЛане" должна включать в себя программу онтологического ликбеза.
Мы имеем следующие выгоды такого подхода:
а) гарантированную расширяемость ОргЛана (хотя эта гарантия и несколько "дутая": универсальных онтологий не бывает, но тщательно разработанная foundational ontology тут много лучше любых ad hoc решений) на другие предметные области
б) совместимость с детальными описаниями рабочих продуктов, инженерными описаниями и т.д. (по факту, мы просто даём детальную микротеорию для описания организационных систем, в то время как ISO 15926 "из коробки" имеет микротеорию для описания непрерывных производств). То есть наш "каталог организационных методов" в принципе совместим с "каталогом промышленного оборудования" (http://praxos.livejournal.com/11084.html).
в) возможность использования имеющегося инструментария и опыта работы по моделированию (в данном случае -- моделирования организационных систем, софта ISO 15926, учебников типа книжки о методе BORO -- http://ailev.livejournal.com/938647.html).
Про "ОргЛан для самых обычных пользователей" пока забываем. Нам нужен не "организационный бейсик для одного из организационных аспектов", а приличный универсальный язык. Текстовая и графическая нотация ОргЛана по факту будут текстовой и графической нотацией для DSL в "универсальном моделере" (http://dot15926.livejournal.com/24612.html). Пока не поддерживается многодиаграммность (т.е. не "как UML", или "как внешние DSL", а "как ArchiMate" и "как внутренние DSL на базе одного языка и синтаксиса".
4.2. ОргЛан должен быть полным по Тьюрингу в алгоритмическом смысле (ибо любой язык будет развиваться, пока не станет полным по Тьюрингу -- так лучше мы сразу это предусмотрим).
4.3 Возможны "сурово денормализованные" варианты языка -- в том числе порожденные генератором отчетов, выдающим всяческие "положения", "регламенты" и прочая "распорядительная документация". Т.е. для текстов на ОргЛане должен быть предусмотрен не только "парсинг", но и "рендеринг": http://ailev.livejournal.com/925813.html?thread=9257845).
5. Версии
5.1. В версии 0.1 ОргЛан мы будем описывать примерно на том же уровне формализма, как в ArchiMate -- то есть неформально.
5.2. Затем в версии 0.2 ОргЛана будут использованы только классы и отношения части 2 (характеризация).
5.3. В версии 0.3 затем будут сформулированы шаблоны (часть 7 ISO 15926).
5.4. В версии 0.4 для перехода к Тьюринговой полноте будет использован .15926L.
6. ОргЛан задается системой, состоящей из частей:
6.1. архитектурного описания (основная организация и принципы разработки) -- заготовкой для него является настоящий постинг.
6.2. описывающей деятельность микротеории ОргЛана в составе библиотеки справочных данных PraxOS (соответствует "метамодели" в традиционном понимании ArchiMate, ISO 24744 и т.д.)
6.3. текстовой и графической нотаций для выражения моделей, соответствующих этой микротеории (метамодели).
6.4. механизма описания рендеринга (по мотивам XSLT -- ну, или что-то более удобное и приемлемое), но это будем определять позднее
6.5. механизма расширения ОргЛана, который суть ISO 15926 во всей его полноте.
6.6. адаптивного механизма обучения
6.7. примера моделера и исполняющих сред -- софт PraxOS (две среды: отчёты/рендеринг и execution кейсов в стиле ACM).
6.8. примера описания на ОргЛане (описание КонКорга, типа описания ArchiShurance или примера из ISO 24744)
6.9. По потребности можно будет делать мэппинг в исходные метамодели для частных стандартов -- если это нужно будет для передачи данных оргмодели, задействования чужого софта, переработки терминологии в литературе методов-источников (ISO 24744, ArhciMate, ACM и т.д.) в учебные материалы для PraxOS.
7. За основу в определении scope берём "матрицу предметных областей" из ArchiMate, наглядно показывающую его scope (рис. 5 из http://www.opengroup.org/archimate/doc/ts_archimate/chap3.html):
Но мы будем нещадно модифицировать эту матрицу в сторону расширения domains (берем из недавнего обзора http://praxos.livejournal.com/12576.html и годичной давности спецификации http://praxos.livejournal.com/9003.html), прежде всего в сторону business architecture (по сравнению с традиционными IT-центрированными описаниями), но также и в сторону execution-orientation по сравнению с analysis orientation (на что указывают в adaptive case manatement). За основу моделирования берём (и это как раз определяет scope -- после унификации "похожих" концептов) следующие мета-модели:
7.1. enterprise architecture -- ArhciMate (http://ailev.livejournal.com/940819.html). Сюда же -- доопределиться с описанием системы/подсистемы/надсистемы и показом модульности/сервисов/интерфейсов.
7.2. situational method engineering -- ISO 24744 (набор понятий -- http://ailev.livejournal.com/816938.html).
7.3. adaptive case management -- OMG CMMN (http://neffics.eu/wp-content/uploads/2011/06/11-05-12-CMMN.pdf и много дополнительных материалов в http://ailev.livejournal.com/946134.html). Тут нужно задуматься, как учесть BPMN 2 (простыковаться с которым так хотят управляющие кейсами), и нужно ли его учитывать сразу. Сюда же -- WS Human Task 1.1 -- http://docs.oasis-open.org/bpel4people/ws-humantask-1.1.html
7.4. business rules -- OMG SBVR в части собственно rules (т.е. примерно 10% стандарта, а остальные 90% там про бизнес-онтологию) -- http://praxos.livejournal.com/8380.html
7.5. strategy/motivational model (включая обоснования/предположения -- rationale/assumptions) -- карта действий и результатов (http://praxos.livejournal.com/6777.html)
7.6. business model generation -- http://businessmodelgeneration.com/book, но вот в форме метамодели это придется разрабатывать самостоятельно.
7.8. много ценных идей -- DEMO (с учётом критики из http://www.cordys.com/ufc/file2/cordyscms_sites/download/731375d512f6789e8dd8a2775d26c123/pu/cor0027_modeling_rfi_white_paper_lr_v1.pdf). Координационные и производственные акты, B, I, D-организации и т.д.
7.9 управление вариантами (ибо у нас evolving описание) вкупе с управлением конфигурацией (идентификация, учёт и т.д.). Для двух целей: прохождение развилок (trade-offs) и для поддержки типовых решений (паттернов, шаблонов, "рыб" и т.д.).
7.10. Обмены и контракты -- REA2 и NOMOS (http://ailev.livejournal.com/876070.html), legal кусочек из service science: http://www.loa-cnr.it/Papers/FerrGuarFern.pdf.
7.11. Из TOC: ограничение (роль элемента ОргЛана) и критическая цепь (агрегат workunits) -- придется разработать самим. Все эти "управление проектом через отслеживание его буфера времени" -- это сюда.
7.12. Модель стоимости (потоки, маржиналистский учёт). Придётся разработать самим.
7.13. Модель для KPI. Нужны исследования -- обсуждается это и в GORE, и во многих других местах. Плюс нужно разобраться: нужно ли это вообще, или это просто морок.
7.12 что-то из учебных стандартов (ибо нужно уметь представлять "дисциплины" -- что грузится в голову) -- поглядеть на наличные стандарты для всяких курсов. Но, возможно, придётся разработать самим -- в очередной раз изобрести велосипед.
...
По идее, за каждой строчкой тут стоит какой-то отобранный в PraxOS метод организационной работы. Особо отмечу, что ISO 15288 тут никак пока не участвует: он может потом быть записанным на ОргЛане, ежели будет нужно. Или будет записан новый стандарт "моделеориентированной системной инженерии". Или "инженерии системы систем". Или ещё какой-нибудь. Но это уже "используемый метод работы", а не организационный метод (хотя для групп обеспечения проектных практик, проектных практик и практик соглашения можно было бы и поспорить).
Понятно, что для начала нужно будет взять компактное ядро, поэтому "последовательность интеграции" этих всех частных и разнородных метамоделей отражена в том порядке, каком я их привёл: начинаем с головы списка, и далее медленно-медленно идем до его конца, по метамодели за раз. Но нам нужен сразу весь список, чтобы нарисовать нашу domain-таблицу.
Основные идеи по этому "мегамэппингу" (мэппингу на уровне не столько понятий, сколько domains):
а) добавить разделение на 24744:каталог vs endeavor и ACM:design-time vs run-time (в том числе идея, что case -- это как раз в endeavour). Как это показывать на диаграмме?
б) 24744:workunits, workproducts, producers = ArchiMate:behaviour, passive structure, active structure
в) 24744:нотации, языки трактовать в составе методов описания ISO 42010. Как эти 24744:resources = 15926:reference data показывать на диаграмме?
г) 42010: Stakeholders = actors, причем "не бывает нефункциональных требований", вводим понятие stakeholder case как расширение user case -- и далее думаем, как это связано с ACM
... и так далее.
Нарисовать "карту ОргЛана" с описанием domains нужно в первую очередь.
8. Собственно, неформальное задание языка и его неформальная метамодель будут в какой-то степени похожими на таковое в ArchiMate (http://www.springerlink.com/content/pwh613/back-matter.pdf)
Тем самым на "подложке" из "диаграммы domains" из предыдущего пункта показаны классы и отношения предметной области (а про шаблоны и тьюринг-полновость -- нужно будет еще подумать. Пока же -- Gellish и ArchiMate наши рулевые).
В качестве графической среды на "неформальной стадии" разработки микротеории/метамодели можно пробовать использовать VUE -- http://ailev.livejournal.com/895091.html. Дальше, конечно, работаем с .15926 Editor.
Фишка в том, что metamodel для каждого из этих domains содержит 30-70 понятий, которые существенно между собой пересекаются (весь вопрос только в том, насколько существенно!). Так что в идеале от рефакторинга этих метамоделей мы можем получить более компактное представление предметной области -- но помня при этом про эффект "14 стандартов" (http://xkcd.com/927/). Про соотношение между "рефакторить" (компактифицировать знание) и "интегрировать" (мэппить исходные стандарты) подробнее -- http://ailev.livejournal.com/872954.html.
Я бы сделал следующую оценку:
-- foundational ontology дана нам в 201 типе сущностей части 2 ISO 15926, а
-- организационная онтология вся должна уместиться в 300 классах и отношениях, если выбраны достаточно выразительные классы и отношения.
-- плюс мэппинги (но они формально не входят в ОргЛан. Мэппинги возможны и не в исходные стандарты -- они потом возможны в любые стандарты и могут делаться независимо)
9. ArchiMate также является прототипом того, каков наш подход к определению view: это "отфильтрованные куски полной модели" для показа концептов, относящихся только к какой-то тематической группе описаний, а viewpoint тем самым -- это паттерн фильтра, накладываемого на семантическую сетку модели. Этот вариант явно предусмотрен в ISO 42010, так что мы даже соблюдаем при этом стандарт.
Еще раз: не нужно путать domains с view (ибо domain -- это научный предмет, а view это способ комбинировать модели для этих предметов для более удобного их восприятия, в том числе для понимания их связей между собой. То есть соотношение domain и view как М:N).
В ОргЛане прямо сейчас определяются предметные области (domains), но пока не делается предположений о необходимых view -- если их можно будет задавать динамически "паттернами", то библиотека таких паттернов появится "сама собой", в том числе она будет уникальна для каждого кейса-предпринятия использования PraxOS и ОргЛана. Так что (в соответствии с заветами ACM) мы определение view сдвигаем на run-time -- то есть определяем как "динамическое", а шаблоны для этих veiw (т.е. viewpoints) будут создаваться тоже run-time в community library. С учетом возможности расширения самого состава элементов в этих view (расширяемости ОргЛана) это также можно назвать и "адаптивным" заданием view.
10. Предполагается, что обучение ОргЛану происходит "сержантским методом" -- модельеры проходят много-много упражнений (http://ailev.livejournal.com/907435.html), а учебный комплект состоит из:
-- объяснений и главной последовательности комплексных упражнений
-- регистра затруднений и пояснений к ним (нужно разобраться, в чем именно ментальный затык ученика: какой элементарный навык в комплексной задаче у него дефицитен -- и назвать его)
-- (некомплексных) упражнений на отдельные затруднения (зная, как называется элементарный пропущенный навык -- находим пачку упражнений на его тренировку, а потом возвращаемся к выполнению комплексных упражнений)
-- софта, который способен автоматически определять успешность выполнения упражнений (в первой версии) и затруднения во второй версии. О генерации упражнений пока и не мечтаем.
Понятно, что этот алгоритм сначала нужно описать подробно -- это еще ждет своей очереди. Но эта часть крайне важна, и она обязана входить в комплект поставки. Моделирование на ОргЛане контринтуитивно, затрагивает несколько разных парадигмальных сдвигов, и нужен интенсивный тренинг, чтобы пройти соответствующие метанойи. Это сознательный выбор: контринтуитивные очень мощные модели предметных областей плюс тренинг по преодолению этой контринтуитивности против "интуитивных моделей", "минимального тренинга" и соответствующих им "дурацких методов работы с неадекватными описаниями".