?

Log in

No account? Create an account
Разработка PraxOS Below are 10 entries, after skipping 10 most recent ones in the "Разработка PraxOS" journal:

[<< Previous 10 entries -- Next 10 entries >>]

August 13th, 2011
06:18 pm
[ailev]

[Link]

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), а учебный комплект состоит из:
-- объяснений и главной последовательности комплексных упражнений
-- регистра затруднений и пояснений к ним (нужно разобраться, в чем именно ментальный затык ученика: какой элементарный навык в комплексной задаче у него дефицитен -- и назвать его)
-- (некомплексных) упражнений на отдельные затруднения (зная, как называется элементарный пропущенный навык -- находим пачку упражнений на его тренировку, а потом возвращаемся к выполнению комплексных упражнений)
-- софта, который способен автоматически определять успешность выполнения упражнений (в первой версии) и затруднения во второй версии. О генерации упражнений пока и не мечтаем.

Понятно, что этот алгоритм сначала нужно описать подробно -- это еще ждет своей очереди. Но эта часть крайне важна, и она обязана входить в комплект поставки. Моделирование на ОргЛане контринтуитивно, затрагивает несколько разных парадигмальных сдвигов, и нужен интенсивный тренинг, чтобы пройти соответствующие метанойи. Это сознательный выбор: контринтуитивные очень мощные модели предметных областей плюс тренинг по преодолению этой контринтуитивности против "интуитивных моделей", "минимального тренинга" и соответствующих им "дурацких методов работы с неадекватными описаниями".

(4 comments | Leave a comment)

July 29th, 2011
11:40 am
[ailev]

[Link]

Что моделировать в организации, или опять о софте PraxOS как "универсальном моделере"
Можно было бы определить предметную область PraxOS как "то, что моделируется софтом PraxOS" (и наоборот: что является предметной областью PraxOS, то и моделируется софтом PraxOS). Ну, и что должно быть описано на ОргЛане?!

1. Организационная архитектура (enterprise architecture) -- можно думать об ArchiMate (http://ailev.livejournal.com/940819.html) с его business, applications, technology покрытием. Несмотря на всеохватность этой терминологии, сама выразимая на ArchiMate архитектура не так уж и велика. Так, уже сегодня обсуждаются добавки по целеполаганию (motivational).

2. Но если поглядеть, что поддерживают своим софтом конкуренты архитектурных моделеров, то свежий июльский 2011 обзорчик Enterprise Architecture Tool Selection Guide (http://www.enterprise-architecture.info/Images/EA%20Tools/Enterprise%20Architecture%20Tool%20Selection%20Guide%20v6.2.pdf) показывает следующие предметные области:
-- governance, risk, compliancy
-- program management
-- enterprise/IT-portfolio management
-- Business/IT strategy
-- Enterprise Architecture
-- Solution Architecture
-- Software Engineering

Обращает на себя внимание "айтицентрический" взгляд на организацию. Несмотря на все заклинания про нужность связи деятельности предприятия и его IT, предметная область деятельности предприятия затрагивается "внутри" самого предмета IT, а не сама по себе.
Тем самым по факту вводится два уровня моделирования организации: А) "общеархитектурное" (эскизный проект), верхнеуровневое и Б) в рамках создания самого софта, "рабочее" (детальное).

3. Ключевое тут -- это упор в "архитектурах" из полноценного описания метода работы (и сопутствующего моделирования предпринятия/endeavour) на именно что моделирование "технологии" (инструментов и артефактов), но не:
-- собственно ситуационного метода работы (http://ailev.livejournal.com/905099.html). Даже если выполнить элементарные отождествления (ArchiMate:object/passive structure=ISO24744:WorkProduct, ArchiMate:behaviour=ISO24744:WorkUnit, AchiMate:subject/active structure=ISO24744:Performer), многое остаётся за бортом: метод ("методология разработки", как что-то сделать: независимо от организации/управления ходом работ, упор на предметное содержание) часто крутится вокруг понятия "жизненный цикл" (http://ailev.livejournal.com/917251.html), но я не встречал в архитектурных языках какого-либо упоминания "жизненного цикла".
-- "дисциплины" (то, что грузят в голову, http://ailev.livejournal.com/930608.html) и сюда бы я отнёс также методы описаний (viewpoints) -- guides, models, languages и notations из ISO 24744, architectural framework из ISO 42010.
-- "организации в узком смысле" (распределение полномочий по задействованию акторов и обработка отказов/"выходы в дискурс": работа с координационными актами в DEMO),
-- стратегирования/обоснований (что не совсем точно относить к мотивационным моделям: http://praxos.livejournal.com/6777.html).

4. Поддержки эволюции организации и модели (прежде всего а)работа с вариантами оргмодели, и контроль конфигурации модели в ходе изменений -- поддержка соответствия между разными оргбазисами). Это должна быть явная поддержка управления технологиями, как метода перескока с одного поколения технологии на другое (http://ailev.livejournal.com/928711.html). Пример того, что нужно было бы уметь поддерживать явно в развертке во времени: http://ailev.livejournal.com/939027.html, только на место "системной инженерии" там поставьте любой другой метод и соответствующие ему дисциплины и технологию.

5. Есть многое другое, что пока непонятно, как реализовывать:
-- работу с ограничениями (т.е. эксплицитное моделирование "потока", throughput и ограничений на нём), чтобы реализовать "фокусирование по Голдратту".
-- dynamic case management dynamic case management (http://ailev.livejournal.com/711517.html, плюс http://www.itbusinessedge.com/cm/community/features/interviews/blog/case-management-is-step-forward-in-bpm-evolution/?cs=39882 и много-много других работ), для которого непригодны практики BPM (business process management), к которым традиционно тяготеет современная enterprise architecture.
-- сюда же можно отнести разбирательство с complex event processing, а также работу с business rules -- они тоже пока никак не затронуты мейнстримом организационного моделирования

6. Несмотря на то, что все архитектурные языки, а также метамодели ситуационной инженерии методов поддерживают "расширения", вряд ли этих расширений будет хватать. Это общеметодологическое замечание: как микротеорию (предмет) не растягивай, толку не будет, ибо не бывает универсальных онтологий. Современным выходом из ситуации выглядит опора всех архитектурных, методических, реализационных, технологических, дисциплинарных и прочих описаний на какую-то компактную и максимально общую "верхнюю" (foundational, upper) онтологию -- а все остальные группы описаний обязаны быть привязаны к типам этой онтологии. В DoDAF это 4D онтология IDEAS, в PraxOS по факту мы выбираем близкого родственника -- ISO 15926, тоже 4D.

7. В таком подходе софт PraxOS поддерживает не только каталог компонент методов PraxOS, но тесно связанную с ним организационную архитектуру (enterprise architecture), а также много чего другого -- чем, конечно, сильно отличается от типичных "организационных моделеров". Так что задаваемый в июльском 2011 обзорчике Enterprise Architecture Tool Selection Guide (http://www.enterprise-architecture.info/Images/EA%20Tools/Enterprise%20Architecture%20Tool%20Selection%20Guide%20v6.2.pdf) списке требований к софту оргмоделирования можно было бы выделить три группы:
-- поддерживаемые модели (вопросы типа "поддерживаем ли ArchiMate и TOGAF 9")
-- характеристики самого софта (работа с репозиторием, многопользовательская работа, лицензирование и т.д.)
-- цели и способы использования в организации.

Софт PraxOS вполне мог бы унаследовать требования по характеристикам самого софта, но вот поддерживаемые модели и цели и способы использования в организации наследовать из традиционных оргмоделеров не нужно.

8. Интересно, что задача "догнать и перегнать гигантов современного оргмоделирования" не кажется такой уж несбыточной:
а) реализация мощного движка онтологического программирования с поддержкой DSL общего вида (проект dot15926, реализующий подход language workbench в части онтологического программирования) может дать фору в собственно программистской работе: реализация софта PraxOS как настройки этого софта "универсального моделера" на ряд определенных в PraxOS DSL оргмоделирования может оказаться более эффективной и масштабируемой по предметным областям, нежели реализация специализированного софта.
б) некоторый онтологический тренинг в разы увеличивает скорость понимания проблем тех или иных предлагаемых методов описаний (я думаю, что имеющие опыт моделирования в ISO 15926 люди читают тексты спецификации ArchiMate абсолютно другими глазами, нежели опытные объект-ориентированные или даже функциональные программисты), что даёт шанс быстрой разработки как-то совместимого между собой за счёт опоры на ISO 15926 набора микротеорий для помянутых в предыдущих пунктах постинга разных предметных областей организации деятельности.

Трудность и огромные риски проигрышу "мейнстриму оргмоделирования" лежит в задаче удобного и понятного рендеринга (см. про соотношение "написания парсеров" и "написания рендеров" в http://ailev.livejournal.com/925813.html?thread=9257845). Можно сказать, что по части "парсинга" мы вполне можем быть впереди планеты всей, но по причине де-факто нашего игнорирования рендеринга мы можем отстать принципиально. Так что сейчас в PraxOS нужно обратить особое внимание на нотации и рендеринг, чтобы дать в проект .15926 надлежащие вводные на этот счёт.

(4 comments | Leave a comment)

June 27th, 2011
01:37 pm
[ailev]

[Link]

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

2. Лучшим на сегодня мне известным способом быстро обеспечить архитектурное описание, равно как и зафиксировать требования, является малевание от руки простых диаграммок фломастером на флипчарте (архитектурное описание, с приписанными там да сям отдельными словами, обозначающими требования), сопровождаемые словами из разных статей, учебников и прошлых жизненных ситуаций (ситуационный метод, вытаскиваемый из библиотеки компонент метода -- прямо из головы).
Хихикну в сторону, что аналитические диаграммы ISO 15926 во всём мире сейчас тоже рисуют карандашом на бумажке, в крайнем случае -- в PowerPoint, Word или Visio. Сапожники, как водится, без сапог: кто предлагает универсальные языки описания всего, читаемые машиной, сам остаётся без такого языка.
Итого: технологии по факту нет -- дисциплина не описана, и передаётся исключительно изустно, язык описания требований и архитектуры неформален, инструменты времён изобретения доски с мелом. Самый современный инструмент -- это телефон, на который фотографируют флипчарт.

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

4. Для фиксации требований и архитектурных описаний ISO 42010 рекомендует использовать архитектурные языки и подходы (framework) к архитектурному описанию (тут нужно учесть, что стандарт поминает architectural framework, но вот Open Group свой TOGAF называет не framework, а method. А поскольку мы уже перевели viewpoint как метод описания, относящийся к конкретной группе описаний -- view, то за framework оставляем слово "подход", заодно давая приоритет терминологии ISO 42010 над терминологией частных подходов-frameworks).

На сегодня есть множество популярных архитектурных языков: SysML/UML, AADL, ArchiMate и т.д.. Эти языки обычно объект-ориентированные и позволяют выразить объекты (классы, экземпляры, процессы, их атрибуты, отношения между экземплярами классов и т.д.). Язык мы тут понимаем как пара из языка и нотации (а иногда и нескольких нотаций) ISO 24744.

На сегодня есть множество популярных архитектурных подходов к описанию (architectural, или architecture framework, сводящихся к описанию набора view и их взаимосвязи): Захмановский, RM-ODP, TOGAF, DoDAF, ARIS и т.д..

Архитектурных подходов к описанию (т.е. наборов view) много больше, нежели языков, которые могут обеспечить viewpoints для этих view. С другой стороны, многие языки описания имеют свои предпочтения по поводу подхода к описанию -- ибо они предполагают использование отдельных видов диаграмм, которые легко перепутать с группами описаний (veiw). И люди их путают! Общее правило тут таково:
-- в архитектурных подходах разные view тематические, и могут подразумевать множество моделей для их описания. Например, финансовая группа описаний может требовать моделей баланса и отчёта о прибылях и убытках, группа описаний организации -- конструктивной диаграммы DEMO и органиграммы и т.д.
-- в архитектурных языках разные view прежде всего "онтологические", и чаще всего представляют собой какой-то один вид диаграмм. Так, в UML есть Activity Diagramm и Class Diagram.

Но на каждой общее правило есть множество исключений: если UML еще представляет собой более-менее чистый "язык", то уже ArchiMate содержит в себе существенную долю подхода к архитектурному описанию, а подход ARIS в существенной мере поддержан его же языком.

Это порождает много трудностей по использованию разных языков описания для выражения разных подходов -- по-хорошему, для любых подходов можно было бы использовать любые языки, но это не совсем так. См., например, серию обсуждений использования языка ArchiMate для подхода TOGAF: http://www.via-nova-architectura.org/artikelen/tijdschrift/using-archimate-with-an-architecture-method.html, http://www.via-nova-architectura.org/artikelen/tijdschrift/using-archimate-with-togaf.html, http://www.via-nova-architectura.org/artikelen/tijdschrift/using-archimate-with-togaf-2.html.

Более того, разные архитектурные языки могут мэппиться друг ко другу (концепты одного языка могут соотноситься с концептами другого языка, так что обеспечивается "перевод"), и из-за этого возникает дикая путаница между мэппингами языков и использованием языков для изображения разных групп описаний (см., например, https://doc.telin.nl/dsweb/Get/Document-38740/, где сравнивается ArchiMate и UML, RM-ODP, EDOC Profile for UML, BPMN, ARIS -- сам список того, с чем сравнивается ArchiMate поражает своей разнородностью).

5. Главная критика архитектурных языков: они невыразительны. На них нельзя многого выразить из того, что нужно для описания систем. Характерен анализ, данный при разработке онтологически-ориентированного архитектурного языка OPML ( http://www.cesames.net/fichier.php?id=370, http://www.cesames.net/fichier.php?id=371). Еще одно подтверждение невыразительности -- отсутствие имитационного моделирования (см. http://ailev.livejournal.com/819251.html).

Невыразительность, конечно, компенсируется: архитектурные языки просты, их легко выучить. Но это как Basic в языках программирования: недаром говорилось, что начавшего программировать на BASIC потом невозможно уже научить программировать хорошо. Выразить мир девятью корнями матерного диалекта можно, но лучше бы этого не делать в промышленных масштабах.

Проблема в том, что для большинства архитектурных языков за основу берется UML, и (невзирая на все отличия) поэтому вся критика UML относится и к архитектурным языкам. UML -- это такой архитектурый BASIC, коверкающий архитектурное мышление.


ПРЕДЛОЖЕНИЕ по решению ситуации с архитектурными языками: использовать для архитектурного языка какую-то upper ontology (например, ISO 15926-2). Несмотря на полное понимание, что для разных задач нужны разные онтологии ("нет универсального способа представления действительности"), каждая из них разрабатывалась с целью максимальной выразительности и расширяемости.

А для любых отдельных методов описания можно использовать микротеорию, разрабатываемую на основе этой базовой онтологии. Архитектурный язык становится тем самым ситуативным: модульно расширяемым по ситуации без потери выразительности. Каждая ситуация/система требует своего набора микротеорий, требуемых для ее описания.

6. Главная критика архитектурых подходов очень похожа на критику инженерии методов: они неситуативны. Любой архитектурный подход плохо работает в ситуации, хотя бы немного отличающейся от ситуации, для которой он разработан. Например, описание организационной (социотехнической) системы существенно отличается от описания "железной" (киберфизической) системы -- это означает, что подходы описания организационной архитектуры (enterprise architectural framework) должны бы существенно отличаться от подходов описания "просто систем", а ввиду невероятного различия между собой этих "просто систем" и использования в этих подходах архитектурных языков разной степени выразительности, нельзя быстро подобрать хоть как-то подходящий подход к архитектурному описанию.

Так, DoDAF является обязательным подходом для описания систем в военных закупках США. Но единогласное мнение: он заставляет подробно описывать неважное, а важное приходится описывать вне этого подхода!

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

ПРЕДЛОЖЕНИЕ: аналогом ситуационного архитектурного подхода был бы заведомо избыточный каталог групп описаний, из которого можно было бы набирать небольшое число нужных в данной ситуации групп описаний -- плюс недостающие группы описаний можно было бы порождать каким-то регулярным способом.

7. По итогам двух предложений мы приходим к следующей конструкции:
а) в качестве архитектурного языка выбирается какая-то картина мира (upper ontology), в которую потом гарантированно впишутся многочисленные группы описаний
б) каждая группа описаний поддерживается своей микротеорией и соответствующей ей нотацией (DSL, viewpoint), а объекты разных микротеорий отождествляются друг с другом через correspondence view.
в) все эти DSL можно хранить в каталогах, и использовать по мере потребности -- понимая, что они будут совместимы между собой и всеми остальными описаниями (т.е. решена проблема интеграции данных разных описаний, даже если эти DSL поддерживаются разным софтом).

8. Я пытаюсь тут рассказать не столько о том, что подход (7) позволит формально определять все мэппинги из путаницы (4), оставляя людям возможность работать с лучшим инструментарием (т.е., это способ продолжить работать со множеством диалектов архитектурных Бейсиков). Нет, я не имею ввиду что-то типа "ISO 15926 outside для архитектурного моделирования", чтобы как-то определять correspondence rules для программных средств архитектурного моделирования разных производителей, поддерживающих разные подходы и языки.

Скорее, я имею ввиду развитие чего-то типа "ISO 15926 offsite" (http://dot15926.livejournal.com/22909.html), создание нового расширяемого архитектурного языка для requirements and architecture acquisition -- в форме библиотеки справочных данных (каталога DSL, т.е. микротеорий+нотаций, aka каталога групп описаний, aka каталога ситуационного архитектурного подхода). В этот ситуационный архитектурный подход можно было бы интегрировать удачные находки нынешних архитектурных бейсиков, но оставить возможность развития (т.е. систематического пополнения этой библиотеки).

9. А пока из всего этого разнообразия для целей описания организационной архитектуры мне больше всего нравится ArchiMate (http://www.opengroup.org/archimate/doc/ts_archimate/, свободный моделер -- http://archi.cetis.ac.uk/), за которым я слежу уже некоторое время. Если нужно что-то делать срочно, то я бы брал его за основу. Даже любители ARIS могут его использовать (http://www.ids-scheer.ru/ru/ARIS/ARIS_Software/ARIS_ArchiMate_Modeler/35028.html), равно как и любители другого платного софта (http://www.bizzdesign.com/index.php/tools/architect и т.д.).

Недостатки, как водится, являются отражением достоинств: небольшое количество предметно-ориентированных базовых языковых концептов (микротеории организации), приписанных к четко указанным возможным view (матрице слоёв*аспектов) -- Business Layer (Business actor, Business role, Business collaboration, Business interface ...), Application Layer (Application component, Application collaboration, Application interface, Data object ...), Technology Layer (Node, Device, Network, Communication path ...), Relationships (Association, Access, Used by, Realization, Assignment ...).

В этом языке-подходе переплелись средства как предмет-ориентированные (описание организации и ее технологической инфраструктуры), так и общие (т.е. непредметно-ориентированные, типа объектов representation, отношений aggregation, composition и т.д.). Понятно, что для конкретных целей ситуации моделирования может не хватить ни тех, ни других.

Детализация описания, выход в более специализированные модели, и тем самым обеспечение исполняемости описаний (например, BPMN описания процессов, которые можно было бы скормить какому-нибудь workflow-движку; описание данных, которые можно было бы скормить какой-нибудь СУБД) представляется более чем ограниченными.

Плохо также и то, что за основу явно берется UML -- везде, где только можно. Это существенно ограничивает онтологическую выразительность.

10. Главная критика текущих подходов к архитектурному описанию: их группы описаний пытаются быть недеятельностными, т.е. независящими от используемых методов работы. Это означает, что мы не можем описать финансы так, чтобы было удобно для маржиналистской работы с ними (throughput accounting) и традиционной (cost world, в которой постоянные и переменные издержки перемешаны). Мы не можем описать организационный мир в терминах транзакций, путаемся между функциональным (т.е. типа IDEF0, без развертки во времени) и процессным (т.е. типа IDEF3, с разверткой по времени) описаниями "процессов", не понимаем, как в это упихнуть "проекты" в смысле проектного управления и т.д.

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

Уйти от этого нельзя, даже если пытаться ограничиться "общим архитектурным языком". Либо ты различаешь физический объект и функциональный объект, используя методы системного подхода, и это отражается в архитектурном языке; или различаешь актора и акторские роли, и это отражается в архитектурном языке, либо этого ничего нет, и получаемые в рамках какой-то пары архитектурного подхода и языка группы описаний оказывается невозможно использовать.

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

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

12. Поэтому задача создания архитектурного подхода к описанию системы вполне укладывается в задачу создания каталога методов: это как раз "язык" и "нотация" из ISO 24744. Трудность тут только в том, что формализм ISO 24744 не позволяет легко выражать связку между всеми этими языками и нотациями. Но на данном уровне рассуждений это и неважно.

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

Поэтому идея Harold Lawson ("LAF следует группам практик из ISO 15288") в целом верная: начинать нужно с каталога методов работы с системой, а не с определений "что обычно входит к корпоративную архитектуру" или "какие группы описаний обычно нужны стейкхолдерам сложного инженерного объекта", "какие группы описаний нужны для работы с PLM" и т.д.

(5 comments | Leave a comment)

March 30th, 2011
03:05 pm
[ailev]

[Link]

Тезисы к архитектуре софта 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

(5 comments | Leave a comment)

December 28th, 2010
11:32 pm
[ailev]

[Link]

Итоги 2010 года
Ровно год назад, 28 декабря 2009г., были опубликованы уточненные планы PraxOS по релизу 2.3 (http://community.livejournal.com/praxos/455.html).

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

Главным результатом 2010 года я считаю то, что довольно сложные концепции, которые мы в предыдущих наших консультационных проектах объясняли клиентам неделями, удается втолковать буквально за несколько дней: как мы и ожидали, компактификация знания даёт свои плоды.

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

Главная текущая проблема -- это письменное отображение ситуации постановки метода во всей его многоуровневости и разнообразии участвующих сторон. Проблема не решена по сей день, хотя какие-то примеры методик в соответствии с ISO 24744 и были разработаны. Язык системного подхода/системной инженерии в сочетании с языком ситуационной инженерии методов (я молчу уже о примеси онтологизирования) делает сейчас PraxOS почти недоступным для понимания простыми смертными. Сложность усугубляется тем, что каждый раз требуется удерживать трехуровневость:
-- разработка каталога компонент метода -- выбор из кучи имеющихся подходов, или разработка собственного (методологи и приглашенные специалисты)
-- постановка метода -- обучение и настройка инструментов (служба развития, менеджеры)
-- собственно работа (сотрудники, выделенные для этой работы).

Поскольку клиента интересует всегда даже не работа, а только ее результат (побыстрее и задёшево), то нужно
а) объяснить, что результат работы невозможен без собственно работы -- и на работу нужно выделить адекватные ресурсы
б) объяснить, что работа (ах, ах, какая неожиданность!) сложна, нова, и готовых ресурсов для нее нет -- нужно обучить (а часто еще и нанять) людей, закупить инструменты и "поставить метод"
в) объяснить, что "поставить метод" нельзя, ибо никто не соображает на текущий момент, что же именно нужно делать -- нужно сосредоточиться, и провести исследования, разработать метод (подготовить методики), выбрать инструменты.

Дальше всё зависит от того, насколько формализована деятельность в организации. Если организация выделяет ресурсы по устным распоряжениям и готова воспринимать метод в устной форме -- это одна ситуация. Ежели ресурсы выделяются путем тендерных закупок, а методики принимаются только в письменном виде -- другая ситуация.

Теперь нужно осознать, что редко речь идет об одном методе: чаще всего их нужно несколько сразу.

Формы компактного выражения всего этого организационно-постановочного знания пока нет, формы компактного выражения каталога методов пока тоже нет, упрощенной терминологии пока тоже нет -- следование стандартам явно не упрощает дело, хотя и способствует полноте раскрытия любых вопросов. Засада в том, что "полностью раскрытый вопрос" оказывается толстым томиком, который уже никто никогда не прочтёт! Нужно как-то научиться разрывать гипертекст описания метода на обозримые куски. Нужно разработать какие-то более простые и осмысленные группы описаний, нежели тупой dump of full method according ISO 24744.

Так что 2011 год мы начинаем в поисках простоты изложения PraxOS, ибо уже есть что излагать.

(7 comments | Leave a comment)

December 18th, 2010
07:05 pm
[vvagr]

[Link]

Альтернатива моделирования ISO 24744 Action
Вернёмся на минуточку к моделированию ISO 24744.

Вариант моделирования Action как class_of_event был рассмотрен в http://community.livejournal.com/praxos/5446.html

А почему бы не отмоделировать Action как оношение involvement_by_reference, в котором WorkProduct это involved, а Task - involver типа activity?

На будущее:

Надо подумать о том, что 15926-2 выделяет отдельно approval - и это не activity!  Часть 2  предписывает использовать approval не просто для одобрения рабочего продукта, а всегда для одобрения рабочего продукта в каком-то отношении, в качестве чего-то. То есть одобряется именно включение данного план-графика в состав проектной документации (отношение), а не план-график сам по себе.

В 24744 это не так - approved - это именно состояние рабочего продукта. Можно ли как-то онтологически скрестить два подхода?

(Leave a comment)

October 7th, 2010
10:21 pm
[ailev]

[Link]

Оргсистема предприятия и управление знаниями: заказчик, организатор, методолог, онтолог, программист
Предприятие (enterprise) -- это люди и оборудование/помещения с известным распределением полномочий и ответственностей.

Метод -- способ работы. Компоненты метода -- это последовательности стадий работы во времени (процессы разработки), единицы работы (практики), акторы (люди и инструменты), продукты работы, языки и нотации для таких продуктов работы, как модели.

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

Это только логическое различение, а не физическое деление. Понятно, что одна и та же ручка/компьютер/человек могут участвовать как в производстве, так и в организовывании производства.

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

Часто организационная система явно выделяется не только как "логическое рассмотрение", но и как физически отдельно существующая "служба развития" и подчиняется эта служба специальному менеджеру -- "директору по развитию". С другой стороны, по мере совершенствования явной постановки методов, директорами по развитию становится всё Правление, а собственно производством занимается уже линейный менеджмент и его сотрудники.

PraxOS -- это каталог компонент методов работы, который организационная система использует для постановки методов своей работы (самоорганизации), а также методов работы производства.

Девиз TechInvestLab -- организуем организаторов (мы -- обеспечивающая система для организационной системы, т.е двигаем организационную систему по ее жизненному циклу), то есть осуществляем в целевом предприятии постановку методов организационной системы из каталога PraxOS.

Основная задача организационной системы -- это осуществить постановку методов производства, используя при этом соответствующий каталог компонент этих методов (разработанный самостоятельно, или взятый из других каталогов, например каталога компонент методов PraxOS).

Каталог методов включает в себя знания (повторно используемую информацию), структурированные в форме компонент методов.
Современные предприятия называют знания о методе своей работы (хотя и не структурированные в форме компонент методов) нормативно-справочной информацией (master data). Нормативно-справочная информация включает в себя сведения о клиентах и поставщиках, присутствующей на рынке продукции, нормативном регулировании производства, технических стандартах и т.д.

Особенность НСИ в том, что она
а) крайне разнородна по форме. Это текстовые файлы, сканы бумажных документов, файлы сотен форматов, разнороднейшие базы данных.
б) крайне разнородна по содержанию.

НСИ собирается разными акторами, которые используют ее в своих целях. Поэтому в совместном ходе работ (workflow) нескольких акторов вполне возможно расхождение информации. Так, заказ клиента X, который указал новый адрес доставки, может быть доставлен по его старому адресу -- ибо актор приема заказа ведет свою базу адресов клиентов, а актор доставки заказов может вести свою базу (или пользоваться какой-либо заказной базой адресов, которая плохо обновляется). Такого сорта проблем множество, и поэтому есть тенденция к интеграции нормативно-справочной информации разных акторов. Нынешнее поколение корпоративных информационных технологий предусматривает такую интеграцию на уровне одного предприятия, а в планах передовых предприятий стоит такая интеграция в рамках расширенного предприятия (группы предприятий, которые совместно выполняют большие проекты).

Проекты корпоративной информатизации сегодня -- это во многом проекты интеграции нормативно-справочной информации. Беда тут в том, что разные корпоративные информационные системы (CAD/PLM, ERP, EAM и т.д.) по-разному подходят к проблеме управления нормативно-справочной информацией. Более того, у разных служб предприятия свои бюджеты на развитие (то есть организацию своей деятельности, постановку новых методов работы), поэтому управление НСИ организовано "островками" -- вокруг CAD/PLM со своей терминологией, вокруг ERP со своей терминологией, вокруг EAM со своей терминологией и т.д.

Проблема управления НСИ как частью знаний о методе усугубляется тем, что требуется поддержать кооперацию работы разных групп специалистов, профессионально обеспечивающих разные стороны работы с информацией:
1. Предприниматель/Заказчик (главная заинтересованная сторона, задает цели). Должен быть кто-то, кто задает цели существования производства, и требует надлежащих его характеристик, которые могут обеспечить знания в форме компьютерной системы НСИ.
2. Методолог/стратег/технолог - определяет метод/стратегию работы. Он берет смысл у заказчика и выстраивает метод, удерживая цель -- "для чего работаем". Он объясняет онтологу, какие знания нужны, исходя из интересов заказчика. Чаще всего такой работой занимаются "аналитеги" всех мастей. Главное тут -- системное мышление, удержание целого из многих мелких деталей, каждая из которых важна для какой-то заинтересованной стороны. Проблема в том, что таких людей не готовят: менеджеры слишком неформальны, а инженеры часто не озабочены методом как таковым. Так что подобным часто занимаются "самородки-самоучки", часто автоматически попадающие тем самым в службу развития. Именно тут используется ISO 24744, деревья Голдратта, BPMN 2 и т.д.
3. Онтолог -- занимается инфологией, "моделированием данных", описанием знаний, необходимых для реализации метода/стратегии/технологии в понятной компьютеру форме. На входе у него implicit знания, на выходе -- explicit данные на носителях. Чаще всего такой работой занимаются "прикладные" айтишники, которые интересуются предметной областью производства или организации. Очень редко этим занимаются производственники, которые не забыли вузовский курс логики и имеют склонность к философствованию. Именно тут используется ISO 15926.
4. Программист -- занимается датологией, формальной работой по хранению, пересылке, трансформации данных безотносительно смысла этих данных. Это "системные программисты" и "системные интеграторы", которые поднимут базу данных, наладят SOA, напишут компилятор, обеспечат все нужные интерфейсы и перекодировки. Именно тут используются языки программирования в ассортименте (включая онтологические языки и их обработчики).

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

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

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

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

(6 comments | Leave a comment)

October 2nd, 2010
02:31 pm
[ailev]

[Link]

Промышленные каталоги методов (2)
Ассорти мыслей про каталог методов (продолжение http://community.livejournal.com/praxos/9600.html и еще более раннего http://ailev.livejournal.com/849563.html).

1. В части управления предприятием один и тот же паттерн рефакторинга (вынесения за скобки) находится в самых разных областях:
-- управление эволюцией портфолио продуктов как одной системой (слайд 32 из http://jcse.org.za/upload/events/100/product_lines_2_0_jcse_30apr2010presentation.pdf, и там же помянут ряд других паттернов в терминах "продуктовых линий" -- эволюция сервисов в SOA как одна система, MBE как одна точка в спектре самых разных стратегий продуктовых линий, SoS/FoS высокоадаптивные системы и т.д.).
-- ситуационная инженерия методов предполагает по факту method line и управление эволюцией портфолио методов обеспечивающей системы как целого (непротиворечивый "репозиторий фрагментов методов")
-- движение НСИ в его ERP-изводе (MDM)
-- каталоги комплектующих, из которых создается продукция

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

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

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

Все это про "рефакторинг для программирования-в-большом". Это рефакторинг корпоративных информационных систем.

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

3. Язык, о котором говорится про управление знаниями и создание каталогов крайне разнится:
-- каталоги/справочники в САПР и PLM (много реже -- тоже используется термин НСИ, например для продукта "Вертикаль" от АСКОН).
-- мастер-данные (MDM) и НСИ в сфере ERP
-- репозиторий (в ситуационной инженерии методов).
-- библиотека справочных данных (в моделировании данных)

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

Для начальства лучше всего про рефакторинг корпоративных информационных систем научились рассказывать люди из MDM (master data management). У них самые лучшие презентации, самые лучшие примеры и налаженный лучше всего маркетинг. С учетом того, что они оккупировали ERP-приложения, пользователями которых очень часто являются менеджеры и финансисты, максимальное количество IT-денег на подобный "рефакторинг для программирования в большом" уходит именно в сторону MDM. Поэтому люди даже из CAD/CAM/CAE/PLM задумываются, не начать ли им говорить на этом языке MDM (а пока у них язык PDM/PLM).

4. Сегодняшний этап "рефакторинга" (то есть интеграции приложений с "выносом за скобки" одинаковых знаний) всех этих мастер-данных, НСИ, приводит к следующим проблемам:
-- требуется интегрировать знания/каталоги/справочные данные для всего жизненного цикла, т.е. собирать эти данные из всех частных приложений CAD/PLM, PIM (product information management), ERP и т.д.. Для структурирования этих знаний нужна новая парадигма, ибо тут задействуются и "процессы", и "продукты", и "акторы" (организации -- роли и инструменты) и модели/метамодели и многое другое. По факту нужно принять подход каталогов методов, как интегрирующих другие каталоги (продуктов, сервисов, инструментов и т.д.).
-- работа с системой, элементом системы (в каталоге!) и физическим продуктом. Явное введение "тега" для использования этого системного языка (см. презентацию Мэтью Веста -- http://www.vniiaes.ru/files/RuSEC%202010.rar).
-- объектные схемы определяются даталогически (т.е. игнорируя прикладное значение классов и их атрибутов): значение определяется логикой приложений, а выбираемые для наименования классов и атрибутов слова ситуативны и многозначны. Например, "модификатор" -- типичное название атрибута, но смысл "модификации" будет понятен только прикладной программе. Поэтому при объединении всех этих MDM, справочников и репозиториев возникают огромные проблемы соотнесения. Эти проблемы относятся не столько к традиционной для MDM проблеме "разницы в написании одинакового", сколько в "разном значении одинаково написанного" -- плюс разные средства валидизации целостности (например, как в физике: "контроль размерности при вычислениях", т.е. контроль типов). Решением этой проблемы является наличие независимой от отдельных приложений "связной картины мира" (upper ontology), к которой подвязываются все приложения -- тем самым происходит контроль типов.
-- как верно было замечено в работах консорциума EPISTLE, "что для одного приложения атрибут, то для другого приложения класс". Общая объектная база данных не получается из объединения нескольких объектных баз. Для решения этой проблемы нужно перейти к безатрибутной, т.е. факт-ориентированной модели данных. Это трипл-стор, OWL, SPARQL.

Тем самым очередное продвижение в "рефакторинге" корпоративных информационных систем интеграции данных состоит в их вышеописанной семантизации:
- каталоги методов (а не только продуктов и акторов), структурирование в соответствии с метамоделью ISO 24744 [но этот извод деятельностного подхода пока не нашел отражения в промышленности, разве только как переход к "процессному подходу", чего явно недостаточно].
-- использование системного подхода и тегов, чтобы отследить связь между каталогами элементов системы, системой и физическим продуктом.
-- использование upper ontology (конкретного продукта или нейтральной -- типа ISO 15926, расширенного средствами представления методов и систем
-- использование факт-ориентированного хранилища данных (т.е. трипл-стор), позволяющего организовать онтологическую работу.

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

6. Даже SOA с объектной должна стать семантической! И тут нужно обязательно добавить, что SOA отражает ход от "продуктов" и "объектам" к методам работы, учитывающим также собственно работы (процесс, происходящий во времени). Так что SOA явление не временное, а постоянное: это попытка перейти к комплексным описаниям метода, составленного из элементарных компонент метода. Каталоги сервисов -- это полноправные каталоги методов, только в их зачаточной стадии, и ограниченные строго IT-составляющими. Так что неизбежна как семантизация SOA, так и выход понятия "сервис" за рамки чисто айтишного сервиса. Другое дело, что ситуационная инженерия методов говорит про все то же самое, что SOA, только более внятным языком.

7. Из существенных препятствий для построения полноценных каталогов методов нужно отметить
а) необходимость разбирательства с текущей множественностью представления работ (ибо со множественностью представления продуктов уже кое-как учатся справляться):
-- жизненные циклы/процессы разработки
-- workflow/процессы в смысле BPMN 2.0 (включая issue tracking/поручения)
-- проекты (в смысле управления проектами)
-- сервисы (попытка перейти от акторов/producers (люди, инструменты -- организация) к выполняемым ими работам, то есть шаг от акторов-объектов к их процессной стороне)
-- организационные транзакции (в смысле DEMO)
Понятно, что тут нужно использовать подход ISO 42010, и никаких "суммы атрибутов" -- только аккуратные correspondence rules между различными viewpoints.
б) разобраться с иерархизацией метода-для-системы (с тегами), т.е. сделать мереологию для методов.

(Leave a comment)

August 23rd, 2010
08:25 pm
[ailev]

[Link]

Об расширение ISO 24744
Метамодель ISO 24744 дана в атрибутной нотации (UML). Известные следующие возражения против такой нотации (принципы EPISTLE, которые обосновывают факт-ориентированную запись):
а) атрибуты должны быть определены как сущности, на которые ссылаются через отношения
б) на атрибуты сами по себе нельзя сослаться, и они очень негибки к изменениям
-- атрибуты не позволяют строить их историю
-- информацию про атрибуты попросту негде держать (например, единицы измерения, или язык описания)
-- атрибуты не позволяют иметь различные значения (много описаний, много имен, изменяющиеся значения)
-- атрибуцию (attribution) нельзя описать
в) что является сущностью в одной модели, является атрибутом в другой модели
-- что является сущностью, а что атрибутом зависит от выбранной группы описаний
-- это совсем не поддерживает интеграцию моделей

Для меня существенным является пункт в), про плохую интеграцию моделей в атрибутной записи.

Поэтому я серьезно задумываюсь, стоит ли продолжать расширение ISO 24744 в UML, как это первоначально предполагалось (см. http://community.livejournal.com/praxos/6777.html -- расширение для стратегирования/обоснований).

Не будет ли правильней сначала честно отразить ISO 24744 в безатрибутную запись ISO 15926, и только затем делать расширения?

Как всегда, при этом сразу появляются новые проблемы:

а) моделирование ISO 24744 само по себе представляет собой приключение (и чем больше я знакомлюсь с проблемой моделирования, тем бОльше пугаюсь).
Насколько я понимаю, требуется примерно год full time, чтобы научиться сносно "программировать по сути" (pun intended) на ISO 15926 -- по оценкам тех людей, которые начинали этим заниматься в промышленных корпорациях.

б) не решена задача с шаблонами. Для проекта EqHub было создано 140 шаблонов (сигнатур, представляющих из себя таблички). Непонятно, какие шаблоны нужно будет создать для ISO 24744 и его расширений, а какие можно использовать из других проектов (шаблоны создают в EqHub, в Bechtel, Emmerson, Bentley, как минимум).
Все усугубляется тем, что в головах у нынешнего комьюнити шаблоны и таблички -- одно и то же. У меня почему-то ISO 24744 не представляется табличками (а, может, инженеры правы? Может, как раз табличками и нужно, и люди будут радоваться? Программистов ведь немного, а в экселе вон какие сложные навороты люди привыкли делать! Есть, кстати, класс "спредшитных языков", их очень Алан Кей любит упоминать. Может, именно такое и сделать?)

в) по-прежнему отсутствие инструментария. Текущий инструментарий (обнаружено два работоспособных редактора справочных данных: iRING 2.0 и Bentley Class Editor), похоже, подходит для какого-то моделирования Насосов и Датчиков через калейдоскоп почти хаотично выскакивающих табличек и кусочков деревьев, но мне не кажется это хоть как-то удобным для Методов с их обширными текстовыми описаниями и многочисленными торчащими из них в разные стороны отношениями, а не легко помещающимися в табличку числами. Хотя, может, мир спасёт какая-нибудь "нашлёпка к Excel", делающая из этой платформы спредшитный онтологический язык с контролем типов и прочим -- и взамен "понятности интерфейса" полной недокументируемостью и неотлаживаемостью.
В любом случае, инструментарий держит, и держит сильно: побеждают не идеи, а инструменты. Либо из dot15926 в praxos поступит какой-то инструментарий, либо praxos так и будет заниматься содержательным поиском разрозненных методов, но не их формализацией, обобщением, складированием и совместным развитием. То есть методы будут, но не поставленные под контроль конфигурации, непонятно как публикуемые, с непонятной терминологией и т.д.
Проблема еще в том, что praxos требует не просто "редактора классов" из dot15926, а настроенный Method composer, запрограммированный как DSL на платформе из dot15926. То есть нужен инструмент-2, написанный на инструменте-1.

г) для того, чтобы результаты такого моделирования не пропали, требуется сделать формальное комьюнити, которое будет просматривать результаты моделирования и далее подавать на регистрацию в JORD. Более того, за подачу в JORD еще и деньги придется платить (от имени комьюнити), а без подачи в JORD эти игры с ISO 24744+15926 будут любительством и детским садом.

(4 comments | Leave a comment)

July 18th, 2010
08:34 pm
[ailev]

[Link]

Промышленные каталоги методов
По сути, стандарт ISO/TS 8000-100:2009 описывает некоторый способ организации программирования (programming-in-the-large, в стандарте прямо указывается на то, что выполнение его требований задает компьютерные языки, и естественным языком тут не обойдешься) производства. В нем вводится классификация данных, в которой различается нормативно-справочная информация (НСИ, master data, http://ru.wikipedia.org/wiki/%D0%9D%D0%A1%D0%98) и текущая информация по проводимым организацией сделкам aka экземплярам процессов (transaction data, данные специфичные для endeavour):



Конечно, master data одной организации -- это transaction data для другой организации, всё зависит от позиции деятеля и ее группы описаний.

Методы, которые лежат в PraxOS -- это master data, в части ВидовРабот больше всего похожие на service, procedure or process masters. Как пишется в стандарте, "These masters are still relatively rare except in the health care and vehicle repair industries where automated billing for services or insurance reimbursement is common. Typically a service is best described as a procedure or a process". Оставим в стороне онтологические вопросы о связи метода, сервиса, процедуры (workflow) и практики/вида жизненного цикла (process) -- http://ailev.livejournal.com/849563.html

Кроме ВидовРабот, конечно, в методах есть еще и ВидыПродуктов (item or material master, item of supply concept, asset master и т.д.), и ВидыАкторов, которые много более распространены.

По сути, мы хотим из деталек (частей, parts) создавать методы. Для описания этих деталек служат промышленные каталоги.

PraxOS, по сути, представляет собой промышленный каталог -- только вместо описаний продуктов в нем лежат описания методов. Проблема в том, что описания методов не характеризуются (т.е описываются в терминах пар "свойство-значение") в рамках упрощенных каталожных стандартов, типа ISO 22745. Но создание каталога методов в ISO 15926 вполне возможно, причем в полном соответствии с ISO 8000.

Нужно только заметить, что ISO 15926 RDL одновременно представляет собой:
-- словарь (и это явно помянуто в ISO 8000:110 в таблице словарей Annex C)
-- спецификацию данных (хотя и не формата IG из ISO 22745), ибо в нем хранятся OIM
-- собственно каталог, ибо в нем хранятся информационные объекты (методы и части методов), характеризованные по OIM и соответствующие формальному синтаксису.

Это не единственный стандарт, в котором у одного набора данных (RDL -- это data set, логически упорядоченный набор данных) есть разные (в нашем случае три) функции. Набор данных по ISO 13584 (он же -- древний формат для каталога PLIB, part library, предшественник ISO 10303 aka STEP, из которого STEPLIB после переделки стала в итоге Gellish library) также представляет собой словарь и спецификацию данных (две функции).

Совсем необязательно держать все данные в одном флаконе, в одном RDL. ISO 15926 позволяет создать федерацию RDL, и разделить словарь и OIM на его основе, а также OIM и каталог частей (продуктов, работ с продолжительностью и без, акторов и инструментов, или методов как таковых). Или не разделять, имея ввиду это соответствие лишь для общения с окружающим инженерным миром и декларации соответствия стандартам.

В любом случае, требуется в явном виде договориться о том, как использовать в явном виде словарную и каталожную часть ISO 15926: все необходимые понятия там есть, только нужно договориться об их способе употребления. А спецификационная часть там присутствует, это OIM. Хотя и тут дополнительная определенность бы не помешала.

В данной архитектуре OIM 24744 (спецификация данных, метамодель) четко отделяется от каталога методов (модели методов и их частей/продукции и комплектующих), а каталог методов четко отделяется от transactional data из endeavour.

Похоже, что для описания всего этого месива концепций нужно будет иметь разные группы описаний, для которых разные группы стандартов задают разные методы описаний. Ну, и мэппинг между основными элементами, определяемые этими методами описаний (типа "метамодель в OMG = OIM в 15926 = спецификация данных в 8000".

В любом случае, нужно как-то вписываться в текущий контекст корпоративной информатизации и по максимуму задействовать признанную на производстве (а не в науке или в программировании) терминологию там, где она нам не мешает. Ориентироваться, конечно, нужно на международные стандарты. Судя по всему, они смоют всю отечественную систему ГОСТов лет за пять-семь.

(Leave a comment)

[<< Previous 10 entries -- Next 10 entries >>]

My Website Powered by LiveJournal.com