https://ailev.livejournal.com/1429330.html

Онтика системных описаний

Тут мы уточним концепты определения и воплощения системы, интереса, оценки интереса, метода описания, вида моделей и моделей, действенной онтики/знания, исходного онтического описания/знания, разделения интересов. 

Это продолжение текста "онтика онтологизации" (https://ailev.livejournal.com/1427265.html), где уточнялись концепты концептуального пространства, предметных областей, значений, онтик, пространства имён, спектра формальности мышления, определения, абстрагирования, конкретизации, концептуальной схемы, разворачивания схемы, коммуникации, разделения (share), видов онтик, теории, дисциплины, учебного предмета, онтологии, 4D экстенсиональной онтологии, описания, модели, альфы.

Как и в случае первого текста, не надейтесь, что поймёте, если не знакомы с содержанием курса онтологики и курса системного мышления. Всё нижеизложенное написано мутно, и требует последующей обширной дискуссии. Но как грубое начальное приближение, исходная точка размышлений (quick and dirty prior) текст этот хорош уж тем, что он есть и предлагает некоторые решения для давних проблем. И пока других текстов на эту тему нет, никто не предложил решений получше, будем пользоваться этим вариантом. 

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

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

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

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

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

Онтическое описание обычно описывает свою предметную область/domain: его онтика существует в виде "исходного кода" в пространстве смыслов как определение/definition и может быть выведена в какой-то внешней форме на разные носители в их отчуждении от интерпретации -- тогда мы говорим об описании/description. В системном мышлении мы говорим об определении и описании воплощения системы как главных, но мы нуждаемся и в определении и описании самих определений и описаний.

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

А если они системы, то мы можем определять и описывать определения и описания, например иметь definition of definition: мы можем определять и описывать знания, чётко понимая, где и как эти знания используются, а затем функционируют (эксплуатируются) в физическом мире. Достаточно показать пальцем на соответствующие мозги и/или компьютеры или даже целые системы из многих мозгов и компьютеров.

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

Интерес 
Интерес/concern -- это определение онтики, которая в свою очередь будет определять систему. Слово "определение" -- это не словарное определение из глоссария, а концептуальное задание (как в "system definition"). Определение -- это некоторое сокращённое описание, по которому можно как-то найти определяемый объект. 

Если мы признаём, что actionable discipline это кусок мозга, и порождаемые при помощи этой дисциплины определения системы тем самым -- это какие-то концептуальные модели (т.е. нейросетевые/коннективистские модели, как-то закодированные в мозгу, интериоризированные), то concern указывает на то, какой сервис (внешнее поведение, результат размышлений) мы хотим получить от определяющей систему онтики в ходе её выполнения мозгом (или компьютером, или мозгом и компьютером). В какой-то мере (мы же работаем не слишком точно, схемоидами, а не схемами с "формальной семантикой" и абсолютно "формальной прагматикой", так что замечаем "в какой-то мере") можно говорить, что concern -- это внешнее описание дисциплины, требование к дисциплине (с соответствующей дискуссией о связанных с требованиями деятельностных потребностях, адресующих другой системный уровень и ограничениях, показывающих нашу осведомлённость об устройстве интересующей дисциплины -- дисциплины, оформляющей/формализующей интерес). Помним, что в системном мышлении требования это не столько какое-то определения/задания/definitions в деонтической модальности ("должен", "может", и т.д. -- модальность предпочтения реализации описания во множестве миров), сколько внешнее по отношению к системной границе определение, т.е. определение системы как "чёрного ящика" (с неизвестным внутренним содержанием, рассмотрение системы как далее неделимого элемента). И тут мы говорим, что "интерес -- это внешнее описание дисциплины", т.е. в системном языке это "требование" в первом его значении, вне связи с модальностью.

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

Concern/интерес позволяет нам искать дисциплины, которые могут помочь справиться с проблемой. Онтологический статус concern -- это модальность вопрошания, вопроса. Можно долго спорить, как именно формулируется этот вопрос. Скажем, в программировании есть "языки запросов". Можно считать, что никаких особых языков тут нет, и запрос делается by example -- просто говорится об одном-двух предметах из искомой дисциплины (concern тут prior для размышления о дисциплине-онтике на ранних стадиях её жизни в мозгу), а остальное подтягивается размышлением, возможно включающим и вопросы и к Гуглю (поиск учебников с "исходным кодом" дисциплины), и к природе -- проведение экспериментов, помогающие гипотезы о дисциплине превратить в теории (т.е. поднять уверенность в использовании дисциплины для надёжного моделирования предметной области, поднять уверенность в возможности влияния на систему с использованием той или иной дисциплины). В любом случае, интерес определяется потребностью стейкхолдера в его влиянии на связанную с системой ситуацию/проект, это требование (не вдаваясь во внутреннее устройство, архитектуру) к нужной для деятельности стейкхолдера дисциплине.

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

Тем самым метод описания (viewpoint) подразумевает какую-то дисциплину плюс модельный инструментарий описания (нотации, моделеры, замечания по жизненному циклу моделирования): это именно метод, т.е. набор практик (дисциплины и инструменты), достаточные для создания описаний, отвечающих на вопросы деятельности по влиянию на предмет concern! При этом метод описания/viewpoint не эквивалентен дисциплине, для которой выбран этот метод. Дисциплина может быть "научной", а может быть "нормативной": она может либо не говорить, что нужно делать для приведения цели в какое-то состояние, а может и говорить. Дисциплина может быть концептуальной (скажем, инженерия требований, как она описывается в "проблемы инженерии требований" https://ailev.livejournal.com/1425741.html, то есть не доходящая до описания конкретных прикладных практик, но вводящая основные понятия, используемые самыми разными прикладными практиками), а метод описания базироваться на прикладной дисциплине (скажем, диаграммы Use Case из практики Use Case 2.0). Мы пока не будем вводить классификации дисциплин, будем просто как-то развёрнуто их характеризовать. И помним, что дисциплины это онтики, которые не просто загружаются в головы, но это онтики, состоящие главным образом из классов и даже классов классов, дисциплины ведь описывают не отдельные индивиды, а классы индивидов и классы классов индивидов, не отдельные отношения между индивидами, а классы отношений и классы классов отношений. Знание -- это то, что может переноситься из проекта в проект, а в каждом проекте ведь свои индивиды.

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

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

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

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

Какие это могут быть описания/онтики? Погуглив, мы обраруживаем, что есть три основных популярных практики и соответствующие им онтики описания предметной области дождя: 
-- Есть метеорология, и можно просто подгонять свою деятельность под те модели, которыми пользуются метеорологи. Мы получаем детальные карты выпадения осадков, прогнозы на отдельные даты и анекдоты типа "я три дня выкачивал из подвала вашу лёгкую облачность без осадков". Это метеорологический "научный" viewpoint.
-- практики заклинателей дождя. Мы узнаём об амулетах, конкретных ответственных за дождь трансцедентных сущностях, получаем описания необходимых ритуалов, а также описания уровня грешности территории, наказанной или награждённой дождём. Это шаманский viewpoint.
-- набор эвристик авиаподразделения, занимающегося обработкой туч разными порошками. В этот вьюпойнт неожиданно входят виды разных порошков, карты аэродромов, физхимия происходящих в туче процессов и в том числе необходим пассивный прогноз от метеобюро, который дополняется средствами моделирования результатов авиавылетов по управлению погодой. Это инженерный viewpoint.

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

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

Разделение интересов является вторым приёмом борьбы со сложностью описания системы (первым приёмом борьбы со сложностью является поуровневое описание системы -- описание отдельных взаимодействующих частей).

Что говорят ISO 42010 и OMG Essence
ISO 42010 говорит только о самых важных (архитектурных) описаниях. При этом стандарт, хотя и поминает "определение системы", но в его диаграммах отражены по большей части рабочие продукты -- все эти модели, методы описания в стандарте представлены их рабочими продуктами, а не определениями. Понятно, что это онтологическая недоработка авторов: во-первых стандарт нужно принимать как стандарт системных всех описаний, а не только архитектурных, а во-вторых нужно чётче говорить, что стандарт имеет дело и с определениями-онтиками и с рабочими продуктами-описаниями для описанных в его диаграммах и помянутых в тексте сущностях (кроме тех моментов, когда стандарт подчёркивает разницу между определениями и описаниями -- definition и description).

OMG Essence наоборот, проводит чёткое различие между альфами-определениями и рабочими продуктами-описаниями. Но сам стандарт в части основных альф говорит только о требованиях (ровно так, как ISO 42010 говорит только об архитектуре), а остальные описания считает относящимися к альфе "система" -- тем самым смешивая различные определения системы, описания системы (рабочие продукты) и воплощение системы. Не спрашивайте даже, какая онтологическая сущность у оригинальной альфы "система" в OMG Essence.

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

Вот эта схема:

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

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

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

По большому счёту, (совокупность ISO42010::моделей)/ISO42010::view -- это тоже sys&onto::модель, но ISO42010 зарезервировал общее слово "модель" за довольно частным его использованием, и даже закрепил всего трёхуровневую структуру моделирования: 1. общее описание/system description, отвечающее на все интересы 2. частное описание, отвечающее на интерес/view, 3. модель/model, только частично отвечающая на интерес. Это деление описаний на уровни, соответствующие удовлетворению требований-интересов вполне осмысленно с одной стороны, но задействование очень общих (общефилософских, и даже вполне бытовых) слов для выражения такой конструкции можно обсуждать отдельно. В любом случае, такая трёхуровневость описаний, определяемых по отношению к интересам является специфичной для современного системного подхода, и при любом выборе терминологии она сохранится -- хотя очевидно, что будет введено много подуровней в каждом из этих уровней description-view-model. Это в какой-то мере похоже на принятое в ISO 15926 решение работать с индивидами, классами и классами классов, а многоуровневость абстракций выражать не отношениями классификации, а отношениями специализации -- при этом выделяя классификаторы на отдельный уровень определений ситуации.

Зачем с этими онтиками так возиться
Нужно решать проблемы:
-- несовместимости способов описаний мира, предлагаемых различными стандартами системной инженерии и менеджмента. Нужно по возможности один раз (за скобками конкретных проектов) решить эти противоречия, хотя это и невозможная задача. Но лучше поменьше оставлять для решения в конкретных проектах и максимум сделать на методологическом шаге, разговаривая об онтике системных описаний, общей для всех системных проектов.
-- несовместимости state-of-the-art способов описания мира, предлагаемых современной онтологикой (в двух её несовместимых вариантах: 1. классических "как по Фреге" с семантическим треугольником, где значение-в-domain и 2. современных "как в deep learning", где используются значения-priors и смыслы-posteriors как места в пространстве смыслов) и системных способов описания мира, предлагаемых в различных стандартах (которые тоже несовместимы между собой, как это указано в предыдущем пункте). Это чуть подробней прописывалось в предыдущем тексте "Онтика онтологизации", https://ailev.livejournal.com/1427265.html
-- предложения русскоязычной терминологии для описаний, выполняемых в рамках дисциплины системного мышления 
-- совместного описания онтик онтологизации в целом и получения системных описаний в частности. Это совместное онтическое описание потом будет использовано для принятия решений, как изложение этого материала может быть разделено по отдельным курсам онтологики и системного мышления. Нас интересует не сам этот текст как "исходный код дисциплины описания мира в целом и систем в частности", а нас интересуют обученные этой дисциплине люди. Так что можно рассматривать эту серию постов не как "статью" или "микромонографию", а как маленький набросок материала для будущих совместимых между собой онтологически и терминологически учебников онтологики и системного мышления.

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

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10213010264665366
Текст поправлен и дополнен по замечаниям Пион Медведевой.