Итак
поехали
существуют в предметных областях древовидные структуры - деревья. следует помнить, что не не всякое дерево является классификатором. иногда дерево может оказаться на деле не тем чем может казаться на первый взгляд.
помимо отношения классификации между элементами дерева могут быть и другие отношения, и важно уметь различать эти дополнительные виды отношений, чтобы корректно с ними работать.
1. отношение разбиения
разбиение является одним из важнейших отношений. оно в организации инженерных знаний является важным инструментом.
между элементами дерева разбиения существует отношение “часть - целое”.
это важное отношение которое может существовать между физическими объектами, индивидами в мире. второе название у этого отношения “истинная часть”. сделано это для того чтобы не путать части объектов с частями описаний, классами частей для классов целого и другими использованиями слова “часть” для обозначения чего попало.
(видимо, тут речь идет за использование самого слова “часть” как знака, которым может обозначать много чего в мире, помимо настоящих частей физических объектов и индивидом. таким образом слово “часть” дополнительно дополняется/усиливается/маркируется словом “истинная”, чтобы явно подчеркнуть именно то самое отношение которое обозначает разбиение “часть-целое” ). это от того что в жизни и в разных контекстах словом/знаком “часть” можно обозначить все что попало.
примеры:
хвост кота является частью кота
крыша дома является частью дома
грифель карандаша является частью карандаша.
таким способом - явным наведением внимания на часть чего-то целого, выделяют подсистемы из систем.
шариковая ручка с колпачком состоит из истинных частей: самой ручки и колпачка.
автомобиль состоит из истинных частей: самого автомобиля и колес.
и тут я оказался не прав.
дается объяснение в чем собственно не прав и как это починить
Проверка высказываний о части-целом по FPF
Вердикт: оба высказывания содержат ошибку Whole-as-part
Оба примера нарушают принцип анти-рефлексивности истинных частей (по C.5 / A.14 Mereology ): истинная (пропериальная) часть по определению не тождественна целому .
Формальное определение (по спецификации)
Термин
Определение
Обозначение
Часть (не обязательно истинная)
x есть часть y ⟺ x входит в y или x = y
PartOf(x, y)
Истинная часть (proper part)
x есть истинная часть y ⟺ x часть y И x ≠ y
ProperPartOf(x, y)
Неспособная часть (improper part)
x есть неспособность часть y ⟺ x = y
x = y
Ключевое правило: Если x = y, то x не может быть истинной частью y. Это следует из анти-симметрии: если x часть y и y часть x, то x = y, и они не являются истинными частями друг друга.
Разбор высказывания 1
«Шариковая ручка с колпачком состоит из истинных частей: самой ручки и колпачка.»
Проблема: двусмысленность “самой ручки”
Слово “ручка” используется в двух разных смыслах:
Смысл
Что имеется в виду
Истинная часть?
Смысл A
Корпус ручки (без колпачка)
Да, истинная часть целого «ручка с колпачком»
Смысл B
Вся ручка как артефакт (включая колпачок)
Нет, это само целое, неспособность часть
Если под “самой ручкой” понимается Смысл B , то высказывание ошибочно: целое («ручка с колпачком») не может быть истинной частью самого себя.
Если под “самой ручкой” понимается Смысл A (корпус без колпачка), то высказывание корректно.
Вывод: высказывание содержит онтологическую двусмысленность и требует уточнения. Без уточнения оно нарушает антипаттерн Term-as-dual-kind (один термин скрывает два разных вида).
Исправленная версия 1
Шариковая ручка с колпачком состоит из истинных частей:
├─ Корпуса ручки (без колпачка)
└─ Колпачка
Разбор высказывания 2
«Автомобиль состоит из истинных частей: самого автомобиля и колес.»
Проблема: явная ошибка Whole-as-part
Здесь двусмысленности нет: “сам автомобиль” явно означает всё целое. Целое автомобиль не может быть истинной частью самого себя.
Это классический антипаттерн Whole-as-part по C.5 :
ОШИБКА:
Автомобиль = {сам автомобиль, колесо₁, колесо₂, колесо₃, колесо₄}
↑ это само целое, не истинная часть
ПРАВИЛЬНО:
Автомобиль = {кузов, двигатель, колесо₁, колесо₂, колесо₃, колесо₄, ...}
Исправленная версия 2
Автомобиль состоит из истинных частей:
├─ Кузова
├─ Двигателя
├─ Колесо₁, Колесо₂, Колесо₃, Колесо₄
├─ Трансмиссии
├─ Салона
└─ ... (прочие агрегаты)
Сводная таблица ошибок
Высказывание
Тип ошибки
Паттерн
Исправление
1 («ручка с колпачком»)
Онтологическая двусмысленность термина «ручка»
Term-as-dual-kind
Уточнить: корпус без колпачка
2 («автомобиль»)
Целое объявлено своей истинной частью
Whole-as-part (C.5)
Убрать «сам автомобиль» из списка истинных частей
Ключевой принцип FPF (C.5 / A.14)
Целое никогда не является истинной частью самого себя.
Если вы пишете X состоит из {X, Y, Z} — это логическое противоречие в мерологии. Правильная форма:
Целое = {часть₁, часть₂, ..., частьₙ}
где каждая частьᵢ ≠ Целое.
но, с примером с желудем из руководства тоже не все так однозначно:
А что не так с желудем? нормально же общались ...
Проверка высказывания: «жёлудь состоит из истинных частей — плода и шляпки»
Вердикт: высказывание содержит двойную ошибку
Терминологическая двусмысленность (антипаттерн Term-as-dual-kind).
Смешение BoundedContext : бытовое и ботаническое понимание жёлудя не совпадают.
1. Двусмысленность термина «плод»
В русском языке слово «плод» имеет минимум два смысла, и в этом высказывании они конфликтуют:
Смысл
Что имеется в виду
Применение к жёлудю
Смысл A (ботанический)
Целый плод как орган растения
Сам жёлудь целиком — это плод дуба
Смысл B (бытовой)
То, что внутри обёртки, «сам орех»
Семя/орех внутри плюски
Если высказывание использует Смысл A , то получается:
«Жёлудь состоит из истинных частей: самого жёлудя и шляпки» — это ошибка Whole-as-part (целое объявлено своей собственной частью).
Если высказывание использует Смысл B , то формально противоречия нет, но:
Слово «плод» подменено (в ботанике это не плод, а семя ).
Читатель из другого контекста (биолог) прочитает высказывание по-своему и увидит абсурд.
По A.14 и F.3 (Sense Clustering), это требует явного SenseCell -разделения: одно слово — два локальных смысла, и нельзя держать их в одном утверждении без явного указания, какой используется.
2. Смешение BoundedContext: быт vs ботаника
По A.1 (BoundedContext), отношение «часть-целое» всегда контекстуально. Проверим жёлудь в двух контекстах:
Контекст 1: Бытовое понимание
EntityOfConcern: Жёлудь (как его видит ребёнок/собиратель)
├─ ComponentOf: Орех (твёрдая внутренняя часть)
└─ ComponentOf: Шляпка (чашечка, в которой сидит орех)
Здесь высказывание прагматически корректно (если заменить «плод» на «орех»), потому что человек физически видит две отдельные части.
Контекст 2: Ботаническое понимание
EntityOfConcern: Жёлудь (ботанический плод дуба)
├─ = сам плод (орех с кожурой)
└─ НЕ часть: Плюска (шляпка) — это видоизменённые прицветники,
обёртка ВОКРУГ плода, но НЕ часть плода
В ботанике плюска — не часть жёлудя , а отдельная структура (обёртка, чашечка), которая окружает плод. Жёлудь = плод. Плюска — это то, в чём плод сидит.
Значит, в ботаническом контексте высказывание ложно : шляпка не является частью жёлудя.
3. Применение A.14 (Mereology)
По A.14 , прежде чем сказать «X состоит из частей Y и Z», нужно:
Проверка
Результат для высказывания
Recover the EntityOfConcern
Не указано: жёлудь-плод (ботаника) или жёлудь-сборка (быт)?
Choose the relation kind
Предполагается ComponentOf, но в ботанике плюска не ComponentOf жёлудя
No roles/methods in mereology
Здесь нет смешения с ролями/методами
Boundary compatibility (POR-5 / ComponentOf)
Граница целого не определена: плюска внутри границы жёлудя или снаружи?
A.14 прямо требует : «ordinary words such as part, member, phase, aspect, section, version, module, function, role, and ingredient can all sound like ‘part of’ while naming different relation kinds. Recover the EntityOfConcern and choose the relation kind».
Здесь восстановление EntityOfConcern разрушает высказывание: в зависимости от контекста ответ разный.
4. Сводная таблица проблем
#
Проблема
Паттерн FPF
Последствие
1
«Плод» = двусмысленный термин
Term-as-dual-kind, F.3
Читатель из другого контекста поймёт иначе
2
Жёлудь = плод (ботанически), но в списке частей «плод» фигурирует как часть
Whole-as-part (C.5)
Целое объявлено своей частью
3
Плюска в ботанике — не часть жёлудя
A.14 (ComponentOf требует structural parthood)
В научном контексте высказывание ложно
4
Не указан BoundedContext
A.1 (BoundedContext)
Утверждение выглядит универсальным, но таковым не является
5. Исправленные формулировки
Вариант А: бытовой контекст (явно указан)
В бытовом понимании «жёлудь» (сборная конструкция: орех + обёртка)
состоит из истинных частей:
├─ Ореха (семя, твёрдая внутренняя часть) — ComponentOf
└─ Шляпки (плюски, чашеобразная обёртка) — ComponentOf
Вариант Б: ботанический контекст (явно указан)
В ботаническом контексте:
├─ Жёлудь = плод дуба (орех с семенной кожурой) — это целое
├─ Плюска (шляпка) — обёртка из прицветников,
│ не являющаяся частью плода
└─ Отношение: Pluska surrounds Acorn (не ComponentOf, а SpatialRelation)
Вариант В: универсальная формулировка с мостом (F.9)
SenseCell 1: Жёлудь_бытовой (сборная конструкция)
├─ ComponentOf: Орех
└─ ComponentOf: Шляпка
SenseCell 2: Жёлудь_ботанический (плод дуба)
└─ = Орех + семенная кожура (без шляпки)
Bridge: Жёлудь_бытовой ↔ Жёлудь_ботанический
├─ kind: ⋂ (пересечение)
├─ CL: 1 (низкая конгруэнтность)
├─ Loss: "Бытовое понятие включает шляпку; ботаническое — нет"
└─ scope: Explanation-only (не Substitution)
Ключевой принцип FPF, иллюстрируемый этим примером
A.14 + A.1 : слово «часть» не имеет универсального смысла. Прежде чем строить мерологию, нужно:
Явно указать BoundedContext (быт, наука, инженерия, право).
Восстановить EntityOfConcern (что именно является целым).
Выбрать конкретный вид отношения (ComponentOf, ConstituentOf, PortionOf, PhaseOf, MemberOf).
Пример с жёлудем — дидактический : он показывает, что даже в простейших бытовых утверждениях может скрываться онтологический конфликт между контекстами, который без явного FPF-оформления остаётся невидимым и приводит к ошибкам в инженерии, интеграции или передаче знаний.
для того чтобы найти и определить часть какого-то целого, надо мысленно его это самое целое разделить.
Формула разделения такая: все атомы объекта “часть Б ” входят в число объекта "целое А" .
если формула выдает положительный ответ, то все сходится и Б является частью А.
Альтернативные названия отношения “часть-целое”:
композиция,
входит в состав
вложенность
дерево разбиения построенное на базе таких отношений в обиходе выражается как "А состоит из … ".
Глубина таких разбиений больше чем 2 уровня.
такое разбиение используется в деревьях задач в проектном управлении - дерево декомпозиции задач проекта - project breakdown structure.
так же оно явно используется в конструкторской документации на изделие - дерево вложенности, дерево разбиения продукта - product breakdown structure. глубина разбиений может достигать 20+ уровней вложенности.
бывают ситуации когда нам заранее известно, что все индивиды одного класса входят в состав всех индивидов другого класса. т.е. речь идет об общем правиле композиции для всех индивидов одного класса и всех индивидов другого класса. тут появляется типовой шаблон описания индивидов для этих классов, которые связаны такими отношениями.
upd: это было добавлено ретроспективно, уже после того как были вставлены примеры с автомобилем
Объяснения про типовой шаблон описания
Разбиения по общему правилу композиции: типовой шаблон описания
Уточнение структуры (важно для корректности)
Формулировка «все индивиды класса A входят в состав всех индивидов класса B» буквально читается как «каждое A — часть каждого B», что почти никогда не истинно (не каждое колесо входит в каждый автомобиль). Точная структура, которую вы описываете, другая:
Правило универсально (применяется ко всем индивидам обоих классов), но парthood локален : каждый индивид-целое класса B имеет в своём составе своих индивидов-частей класса A, определённого типа и количества.
То есть существует типовое правило композиции , связывающее два класса, и из него вытекает шаблон описания любого индивида-целого.
Пример 1: Молекула воды и атомы (самый чистый)
Параметр
Значение
Класс-часть (A)
Атом (водорода, кислорода)
Класс-целое (B)
Молекула воды
Правило композиции
Каждая молекула воды = ровно 2 атома водорода + 1 атом кислорода
Шаблон описания
Молекула_воды := 2×Атом_H + 1×Атом_O
Здесь правило с фиксированной кардинальностью и без вариаций. Шаблон полностью определяет состав любой молекулы воды — зная шаблон, вы знаете состав каждой конкретной молекулы.
Пример 2: Автомобиль и колёса
Параметр
Значение
Класс-часть (A)
Колесо
Класс-целое (B)
Автомобиль
Правило композиции
Каждый автомобиль имеет ровно 4 колеса как структурные части (опционально +1 запасное)
Шаблон описания
Автомобиль := Кузов + Двигатель + 4×Колесо + Трансмиссия + Салон
Шаблон задаёт слоты (места под части). Чтобы описать любой конкретный автомобиль, вы заполняете шаблон: указываете, какие именно колёса, какой двигатель и т.д.
Пример 3: Книга и страницы (переменная кардинальность)
Параметр
Значение
Класс-часть (A)
Страница
Класс-целое (B)
Книга
Правило композиции
Каждая книга состоит из обложки, переплёта и N страниц, где N варьируется
Шаблон описания
Книга := Обложка + Переплёт + N×Страница, N ≥ 1
Здесь кардинальность переменная (параметр N), но сам шаблон неизменен для всех книг. Это показывает, что шаблон может содержать параметры.
Пример 4: Предложение и слова (с порядком)
Параметр
Значение
Класс-часть (A)
Слово
Класс-целое (B)
Предложение
Правило композиции
Каждое предложение = упорядоченная последовательность слов
Шаблон описания
Предложение := ⟨Слово₁, Слово₂, …, Словоₙ⟩
Здесь появляется порядок : важна не только множественность частей, но и их последовательность. Это уже не чистый ComponentOf, а упорядоченная структура (SerialStepOf / порядок).
Что даёт типовой шаблон (суть концепции)
Типовой шаблон описания — это переиспользуемая структурная схема , применимая к любому индивиду класса-целого. Его практическая ценность:
Предсказуемость описания. Зная шаблон класса «Автомобиль», вы заранее знаете, какие поля (слоты) нужно заполнить, чтобы описать любой конкретный автомобиль.
Проверяемость. Можно проверить, что каждый индивид класса B действительно содержит требуемые части класса A в нужном количестве (валидация по шаблону).
Единообразие. Все индивиды класса B описываются одинаково, что позволяет автоматизировать обработку, сравнение, агрегацию.
FPF-формализация
Элемент
Паттерн FPF
Роль в шаблоне
Отношение «часть-целое»
A.14 (ComponentOf)
Структурная парthood между индивидами
Объявление слотов частей в целом
C.3 (Intent вида) + A.6.5 (SlotSpec)
Шаблон живёт в сигнатуре вида класса B как набор слотов под части типа A
Гарантированная собранность целого из частей
C.13 (Compose-CAL, конструктивное обоснование)
Каждый индивид B реально сконструирован из индивидов A
Кардинальность (2×, 4×, N×)
Ограничение в сигнатуре
Фиксированное, переменное или упорядоченное количество частей
Порядок частей (пример 4)
A.14 (SerialStepOf) + алгебра порядка
Когда важен не только состав, но и последовательность
Ключевой инсайт FPF: типовой шаблон — это не отдельная сущность, а часть сигнатуры (Intent) вида класса-целого. Вид «Автомобиль» в своём Intent объявляет: «имеет слот колёса типа Колесо с кардинальностью 4». Этот слот и есть шаблон, который заполняется при описании каждого конкретного автомобиля.
Различение, которое здесь критично
Не всякое «входит в состав» — это ComponentOf (структурная парthood). По A.14 , проверьте тип отношения:
Если…
То это…
Пример
Часть конструктивно необходима для целостности целого
ComponentOf
Колесо в автомобиле, атом в молекуле
Элемент просто собран в группу без интеграции
MemberOf (коллекция)
Карта в колоде, человек в списке
Часть — это количество того же вещества
PortionOf
20 л топлива в баке
Часть — это временной срез того же носителя
PhaseOf
Версия документа, стадия процесса
Для типового шаблона композиции (ваш случай) релевантен именно ComponentOf — конструктивная структурная парthood. Если вместо него подставить MemberOf, шаблон потеряет свойство целостности: удаление «части» перестанет ломать целое.
например,
снова вернемся к примеру с автомобилем где ИИ надавал мне по рукам.
нам заранее известно в части автомобиля, что каждый индивид автомобиля вот такой:
Автомобиль состоит из истинных частей:
├─ Кузова
├─ Двигателя
├─ Колесо₁, Колесо₂, Колесо₃, Колесо₄
├─ Трансмиссии
├─ Салона
└─ ... (прочие агрегаты)
и для каждого конкретного автомобиля это как утверждение об индивидах - частях и целых. но то же самое выразить в виде отношений классов кузов, трансмиссия, колесо. как указать что у автомобиля обычно одна трансмиссия (а бывает и более одной), и колес в среднем 4, но бывает и более 4 колес и менее 4 колес.
тут нет однозначного и простого ответа как это описывать. вопрос решается по-разному.
важно уметь отличать модели “разбиений в классах” от моделей “разбиений индивидов”, если такое в жизни случится. и важно помнить у чего бывает истинная композиция, а у чего ее не бывает.
Парочка объясняющих примеров таких разбиений
Разбиения в классах vs разбиения индивидов
Пример 1: «Транспорт» — классы vs индивиды
Разбиение в классах (таксономия видов)
Класс: Транспорт
├─ Подкласс: Автомобили
│ ├─ Подкласс: Легковые
│ └─ Подкласс: Грузовые
├─ Подкласс: Мотоциклы
└─ Подкласс: Велосипеды
Отношение: SubkindOf (⊑) — «является подвидом»
Что происходит: мы делим абстрактный вид на более конкретные подвиды. Каждый подвид — это тоже вид, не экземпляр.
Разбиение индивидов (мерология частей)
Индивид: МояToyotaCamry_2020 (конкретный автомобиль)
├─ Часть: Кузов_номер123
├─ Часть: Двигатель_серия456
├─ Часть: КолесоПереднееЛевое
├─ Часть: КолесоПереднееПравое
├─ Часть: КолесоЗаднееЛевое
└─ Часть: КолесоЗаднееПравое
Отношение: ComponentOf — «является структурной частью»
Что происходит: мы делим конкретный экземпляр на его физические части. Каждая часть — это тоже экземпляр, не вид.
Проблема смешения
Если кто-то скажет:
«Мой автомобиль Toyota Camry делится на легковые и грузовые»
Это категориальная ошибка : индивид (конкретная машина) не может делиться на подвиды. Подвиды — это свойство класса «Автомобили», не конкретной машины.
Или наоборот:
«Вид ‘Транспорт’ состоит из двигателя, колёс и кузова»
Это тоже ошибка: вид не имеет физических частей. Части есть у экземпляров вида.
FPF-формализация
Аспект
Разбиение классов
Разбиение индивидов
Что делим
U.Kind (вид)
U.Entity (экземпляр)
Отношение
SubkindOf (⊑, C.3.1)
ComponentOf (A.14)
Результат деления
Другие виды (подвиды)
Другие экземпляры (части)
Пример
Легковые ⊑ Автомобили
Двигатель_X ComponentOf ToyotaCamry_Y
Проверка
«Является ли X подвидом Y?»
«Является ли X физической частью Y?»
Истинная композиция vs её отсутствие
Пример 2: Автомобиль vs Команда разработчиков
Истинная композиция (структурное целое)
Целое: Автомобиль
├─ ComponentOf: Двигатель (структурная часть)
├─ ComponentOf: Кузов (структурная часть)
├─ ComponentOf: Трансмиссия (структурная часть)
└─ ComponentOf: Колёса (структурные части)
Отношение: ComponentOf — структурная часть, необходимая для целостности целого
Что происходит: удаление двигателя ломает структурную целостность автомобиля. Автомобиль без двигателя — это не автомобиль, а набор запчастей. Части функционально интегрированы в целое.
Проверка: Если удалить часть, целое перестаёт быть тем же целым? Да → истинная композиция.
Отсутствие истинной композиции (коллекция)
Целое: КомандаРазработчиков_Alpha
├─ MemberOf: Алиса (член коллекции)
├─ MemberOf: Борис (член коллекции)
└─ MemberOf: Виктор (член коллекции)
Отношение: MemberOf — членство в коллекции, не структурная часть
Что происходит: если Борис уволится, команда остаётся командой (просто с меньшим количеством членов). Целое не теряет структурную целостность. Члены коллекции не функционально интегрированы в единое структурное целое.
Проверка: Если удалить члена, целое перестаёт быть тем же целым? Нет → это коллекция, не композиция.
Проблема смешения
Если моделировать команду как ComponentOf:
ОШИБКА:
КомандаРазработчиков_Alpha
├─ ComponentOf: Алиса
├─ ComponentOf: Борис
└─ ComponentOf: Виктор
Последствия:
Структурная интерпретация: удаление Бориса «ломает структуру команды» — но на деле команда просто уменьшается
Идентичность: если Борис ушёл и пришёл новый человек, это «та же команда» или «другая команда»? В ComponentOf — другая (изменились части). В MemberOf — та же (изменилось членство)
Мерологические доказательства: в ComponentOf можно доказывать свойства целого через свойства частей (Σ-баланс). В MemberOf это не работает
FPF-формализация
Аспект
Истинная композиция
Коллекция (не композиция)
Отношение
ComponentOf (A.14)
MemberOf (A.14)
Удаление части
Ломает целостность целого
Не ломает целостность
Идентичность
Зависит от частей
Не зависит от членства
Функциональная интеграция
Да (части работают вместе)
Нет (члены могут действовать независимо)
Пример
Автомобиль = {двигатель, кузов, колёса}
Команда = {Алиса, Борис, Виктор}
Мерологические доказательства
Работают (Σ-баланс)
Не работают
Сводная таблица: как различать
Вопрос
Разбиение классов
Разбиение индивидов
Истинная композиция
Коллекция
Что делим?
Вид (U.Kind)
Экземпляр (U.Entity)
Структурное целое
Коллекцию
Отношение
SubkindOf (⊑)
ComponentOf
ComponentOf
MemberOf
Результат
Подвиды (виды)
Части (экземпляры)
Структурные части
Члены
Удаление элемента
N/A (виды не удаляются)
Ломает целое
Ломает целое
Не ломает целое
Идентичность
N/A
Зависит от частей
Зависит от частей
Не зависит от членства
Пример
Легковые ⊑ Автомобили
Двигатель ∈ ToyotaCamry
Двигатель ∈ Автомобиль
Алиса ∈ Команда
Практическое правило проверки
Для различения классов vs индивидов:
«Делится ли абстрактное понятие на более конкретные понятия, или конкретная вещь на физические части?»
Если абстрактное → классы (SubkindOf)
Если конкретное → индивиды (ComponentOf)
Для различения композиции vs коллекции:
«Если удалить элемент, целое перестаёт быть тем же целым?»
Если да → истинная композиция (ComponentOf)
Если нет → коллекция (MemberOf)
Контрпримеры для тренировки
Контрпример 1: «Библиотека»
Классы:
Библиотека (вид) → Научные библиотеки, Публичные библиотеки
Индивиды:
ГородскаяБиблиотека_№5 (экземпляр) → Здание, Книги, Компьютеры
Коллекция:
КнигиВБиблиотеке_№5 = {Книга1, Книга2, Книга3, ...}
Здесь книги — это MemberOf коллекции «КнигиВБиблиотеке», не ComponentOf здания библиотеки. Удаление книги не ломает библиотеку как целое.
Контрпример 2: «Программа»
Классы:
ПрограммноеОбеспечение → ОперационныеСистемы, Приложения, Драйверы
Индивиды:
МойWordPress_версия5.8 → Ядро, Плагины, Темы, БазаДанных
Композиция или коллекция?
Ядро + плагины = ComponentOf (удаление ядра ломает программу)
Плагины между собой = MemberOf коллекции «ПлагиныWordPress» (удаление одного плагина не ломает другие)
Ключевой инсайт
Смешение этих отношений приводит к:
Категориальным ошибкам — приписывание свойств одного уровня другому
Неправильной идентичности — целое считается «другим», когда оно то же самое
Некорректным доказательствам — применение мерологических правил к коллекциям
FPF требует явного указания:
Это SubkindOf (классы) или ComponentOf (индивиды)?
Это ComponentOf (композиция) или MemberOf (коллекция)?
Без явного указания модель двусмысленна и приводит к ошибкам при рассуждениях, автоматизации или интеграции с другими системами.
способ записи деревьев разбиений может быть реализован по-разному: в спец-софте для описания таких разбиений, в таблицах, сырым текстом на специальном языке описания древовидных разбиений.
полученные описания можно далее визуализировать для наглядного представления или для презентации или для объяснения другим агентам.
даже описание в табличном формате можно выполнять несколькими вариантами.
в лбом случае, важно явно описывать что именно разбивается в конкретной таблице - отдельный индивид, или класс. и помнить, что истинное отношение композиции могут быть только у индивидов. для классов отношение композиции нуждается в дополнительных комментариях - обязательно ли у целого должны быть такие части, какое количество таких частей и т.д.
2. иерархии
иерархия - это “организация от высшего к низшему” в самом общем значении. но этот термин могут применять и к классификаторам - “иерархия классов”. в древней Греции “иерархия” означала “управление верховного священнослужителя”
иерархия классов - означает организацию от общего к частному, от абстрактного к более конкретному. более абстрактное в такой иерархии означает более высокую категорию, значит более высокий класс и более высокое положение в структуре.
не все что выглядит как древовидная структура может являться композицией, классификацией, специализацией. другими словами может быть такое дерево, которое не композиция, не классификация, не специализация.
существуют деревья построенные на отношениях “подчиненный - командир”. такие иерархии могут называть “пирамида”.
иерархия феодалов:
0 король,
-1 герцог, граф,
-2 барон,
-3 рыцарь
иерархия классов классов
как дерево могут выглядеть иерархии классов классов. в таком дереве классы классов организованы в порядке “от простого к сложному”.
такое дерево можно изобразить, но описать онтологически сложно.
пример (из биологии):
экземпляры класса “род” являются надклассами экземпляров класса “вид”.
такое надо осмыслить.
Собственно, в чем тут сложность и что не так с иерархией классов классов
Иерархия классов классов: онтологический разбор
Суть концепции
Иерархия классов классов — это структура, где:
Существуют классы (виды, типы)
Эти классы сами являются экземплярами более высоких классов (метаклассов)
Отношения между классами образуют иерархию (дерево)
В FPF это описывается через C.3.1 (Kinds) и C.3.2 (MemberOf) , но требует явного разделения уровней, чтобы избежать антипаттерна A6.5-S6 (NoHiddenUnion) .
Пример 1: Биологическая таксономия
Структура
Метакласс: Таксон (Taxon)
├─ Экземпляр: Род (Genus) = Panthera
│ └─ Надкласс для:
│ ├─ Вид (Species) = Panthera tigris (тигр)
│ ├─ Вид (Species) = Panthera leo (лев)
│ └─ Вид (Species) = Panthera pardus (леопард)
├─ Экземпляр: Род (Genus) = Canis
│ └─ Надкласс для:
│ ├─ Вид (Species) = Canis lupus (волк)
│ └─ Вид (Species) = Canis familiaris (собака)
└─ Экземпляр: Род (Genus) = Felis
└─ Надкласс для:
├─ Вид (Species) = Felis catus (домашняя кошка)
└─ Вид (Species) = Felis silvestris (лесная кошка)
FPF-формализация
Уровень
FPF-сущность
Пример
Отношение
Метакласс
U.Kind (метавид)
Таксон
—
Класс (экземпляр метакласса)
U.Kind (вид) + MemberOf(вид, Таксон)
Panthera (род)
MemberOf(Panthera, Таксон, slice)
Подкласс (экземпляр метакласса)
U.Kind (вид) + MemberOf(вид, Таксон)
Panthera_tigris (вид)
MemberOf(Panthera_tigris, Таксон, slice)
Отношение иерархии
U.SubkindOf (⊑)
Вид ⊑ Род
Panthera_tigris ⊑ Panthera
Индивид
U.Entity
Конкретный тигр
MemberOf(Tiger_001, Panthera_tigris, slice)
Ключевое различие
Вопрос
Ответ
Panthera — это класс или экземпляр?
Это класс (вид) в отношении к индивидам (тиграм), но экземпляр метакласса Таксон
Panthera tigris — это класс или экземпляр?
Это класс (вид) в отношении к индивидам (конкретным тиграм), но экземпляр метакласса Таксон
Какое отношение между Panthera и Panthera tigris?
SubkindOf (⊑): вид является подвидом рода
Какое отношение между Panthera и Таксон?
MemberOf: род является экземпляром метакласса Таксон
Пример 2: Программирование (классы и метаклассы)
Структура
Метакласс: Тип (Type)
├─ Экземпляр: Класс (Class) = Animal
│ └─ Надкласс для:
│ ├─ Подкласс (Subclass) = Mammal
│ └─ Подкласс (Subclass) = Reptile
├─ Экземпляр: Класс (Class) = Vehicle
│ └─ Надкласс для:
│ ├─ Подкласс (Subclass) = Car
│ └─ Подкласс (Subclass) = Truck
└─ Экземпляр: Класс (Class) = Shape
└─ Надкласс для:
├─ Подкласс (Subclass) = Circle
└─ Подкласс (Subclass) = Rectangle
FPF-формализация
# Метакласс
Kind: Тип
KindSignature: {имеетСлоты, имеетМетоды, можетНаследоваться}
# Классы (экземпляры метакласса)
Kind: Animal
MemberOf(Animal, Тип, slice)
KindSignature: {дышит, двигается, ест}
Kind: Mammal
MemberOf(Mammal, Тип, slice)
SubkindOf(Mammal, Animal) # Mammal ⊑ Animal
KindSignature: {кормит_молоком, теплокровный}
# Индивиды (экземпляры классов)
Entity: Dog_001
MemberOf(Dog_001, Mammal, slice)
MemberOf(Dog_001, Animal, slice) # транзитивно через ⊑
Проблема смешения уровней
Неправильно:
"Animal — это экземпляр Типа, и Dog — это экземпляр Animal,
значит Dog — это экземпляр Типа"
Почему это ошибка: Это нарушает A.6.5 (RelationSlotDiscipline) . MemberOf не транзитивно через разные уровни:
MemberOf(Animal, Тип) — класс является экземпляром метакласса
MemberOf(Dog, Animal) — индивид является экземпляром класса
MemberOf(Dog, Тип) — ложно : индивид не является экземпляром метакласса
Правильно:
MemberOf(Dog, Mammal, slice)
SubkindOf(Mammal, Animal)
→ MemberOf(Dog, Animal, slice) # транзитивно через ⊑
Но:
MemberOf(Animal, Тип, slice)
MemberOf(Dog, Animal, slice)
↛ MemberOf(Dog, Тип, slice) # НЕ транзитивно!
Пример 3: Библиотечная классификация
Структура
Метакласс: Категория (Category)
├─ Экземпляр: Категория = Наука
│ └─ Надкатегория для:
│ ├─ Подкатегория = Физика
│ ├─ Подкатегория = Химия
│ └─ Подкатегория = Биология
├─ Экземпляр: Категория = Искусство
│ └─ Надкатегория для:
│ ├─ Подкатегория = Музыка
│ └─ Подкатегория = Живопись
└─ Экземпляр: Категория = Технология
└─ Надкатегория для:
├─ Подкатегория = Программирование
└─ Подкатегория = Инженерия
FPF-формализация
# Метакласс
Kind: Категория
KindSignature: {имеетНазвание, имеетПодкатегории, используетсяДляКлассификации}
# Категории (экземпляры метакласса)
Kind: Наука
MemberOf(Наука, Категория, slice)
Kind: Физика
MemberOf(Физика, Категория, slice)
SubkindOf(Физика, Наука)
# Книги (индивиды)
Entity: Книга_001
MemberOf(Книга_001, Физика, slice)
MemberOf(Книга_001, Наука, slice) # транзитивно
Почему онтологически сложно описать
Проблема 1: Смешение MemberOf и SubkindOf
По C.3.1 и C.3.2 , это два разных отношения:
Отношение
Что связывает
Транзитивность
SubkindOf (⊑)
Вид с видом (k₁ ⊑ k₂)
Да: если k₁ ⊑ k₂ и k₂ ⊑ k₃, то k₁ ⊑ k₃
MemberOf(e, k)
Индивид с видом
Да внутри вида: если e ∈ k₁ и k₁ ⊑ k₂, то e ∈ k₂
MemberOf(k, MetaK)
Вид с метавидом
Нет : если k₁ ∈ MetaK и k₂ ∈ MetaK, это не говорит об отношении между k₁ и k₂
Антипаттерн A6.5-S6 (NoHiddenUnion): если один предикат MemberOf используется для обоих случаев (индивид→вид и вид→метавид), это скрывает разные ValueKind и нарушает дисциплину слотов.
Проблема 2: Иерархия vs экземплярность
Когда мы говорим “экземпляры класса ‘род’ являются надклассами экземпляров класса ‘вид’”, мы смешиваем:
Экземплярность: Panthera — экземпляр метакласса Таксон
Иерархия: Panthera_tigris ⊑ Panthera
Эти два утверждения живут на разных уровнях:
Первое: MemberOf(Panthera, Таксон)
Второе: SubkindOf(Panthera_tigris, Panthera)
Попытка объединить их в одну фразу создаёт онтологическую путаницу.
Проблема 3: Визуализация vs формализация
Дерево легко нарисовать:
Таксон
├─ Panthera (род)
│ ├─ Panthera tigris (вид)
│ ├─ Panthera leo (вид)
│ └─ Panthera pardus (вид)
└─ Canis (род)
├─ Canis lupus (вид)
└─ Canis familiaris (вид)
Но формально это два разных дерева:
Дерево 1: Иерархия видов (SubkindOf)
Panthera
├─ Panthera tigris
├─ Panthera leo
└─ Panthera pardus
Дерево 2: Экземплярность метакласса (MemberOf)
Таксон
├─ Panthera
├─ Canis
└─ Felis
Попытка объединить их в одно дерево скрывает различие между ⊑ и MemberOf.
Сводная таблица: как правильно описывать
Аспект
Неправильно
Правильно (FPF)
Метакласс
“Класс классов” (двусмысленно)
U.Kind с KindSignature, экземпляры которого — другие U.Kind
Экземпляр метакласса
“Класс” (смешение уровней)
U.Kind + MemberOf(k, MetaKind, slice)
Отношение между классами
“Является частью” (мерология)
SubkindOf (⊑) для иерархии видов
Экземпляр класса
“Элемент класса”
U.Entity + MemberOf(e, k, slice)
Транзитивность
“Если A ∈ B и B ∈ C, то A ∈ C”
Явно указать: транзитивно ли через ⊑ или нет
Практическое правило проверки
Когда вы видите “иерархию классов классов”, задайте три вопроса:
Это SubkindOf или MemberOf?
Если связь между видами (род → вид) → SubkindOf (⊑)
Если связь между видом и метавидом (вид → таксон) → MemberOf
Транзитивно ли отношение?
SubkindOf транзитивно
MemberOf транзитивно только через SubkindOf, не через другой MemberOf
Не смешаны ли уровни?
Индивиды, виды и метавиды — разные ValueKind
Один предикат не должен скрывать разные уровни (A6.5-S6)
Контрпример: где это ломается
Сценарий: “Вид — это экземпляр рода”
Почему это ошибка:
Panthera_tigris — это вид (класс)
Panthera — это род (класс)
Отношение между ними — SubkindOf (⊑), не MemberOf
Правильно: “Вид является подвидом рода” (Panthera_tigris ⊑ Panthera), а не “экземпляром рода”.
Почему это важно: Если вы скажете MemberOf(Panthera_tigris, Panthera), вы смешиваете уровни: вид становится экземпляром другого вида, что нарушает онтологию.
Ключевой инсайт
Иерархия классов классов — это не одно дерево, а два переплетённых дерева :
Дерево иерархии видов (SubkindOf): род → вид → подвид
Дерево экземплярности метакласса (MemberOf): метакласс → классы
Попытка объединить их в одно дерево создаёт онтологическую путаницу. FPF требует явного разделения этих двух отношений и явного указания, какое отношение используется в каждом случае.
стеки
надо еще научиться отличать стеки, которые описываются как иерархическая структура.
диаграммы стеков выглядят как стопки тарелок. собственно названия стек ровно это и означает (стопка)
в программировании стек является одной из фундаментальных структур данных. но сейчас не об этом.
стеки строятся на отношениях “опирается на”, “основан на”, “использует”.
в технологиях стеки (стеки технологий, технологические стеки) - это иерархии (стопки) поддерживающих друг друга технологий. в стеке одна технология является фундаментом для другой технологии (поддерживает ее), а верхняя (по иерархии) технология работает с опорой на нижнюю технологию (использует, опирается). верхняя технология является надстройкой над нижней технологией.
распространенная ошибка не различать (путать) разные виды “древовидных” структур. сложно бывает с разбиениями и классификациями.
навык надежного различения вида разбиения требует тренировки и наработки. можно находить вокруг себя “деревья” которые упоминались в статье и разобраться для себя о том на каких отношениях построены окружающие вас деревья.
“систематическое” и “системное” мышления
“систематическое” (догадка: от “систематика”) мышление работает в направлении деревьев классификаторов, обобщения, определения типов объектов. мышление с использованием онтологий.
противоположное мышление “систематическому” - “хаотическое” мышление
“системное мышление” работает в направлении разбиения объектов на взаимодействующие части, умение видеть целое, видеть частью какого целого на следующем системном уровне оно является.
это мышление помогает обнаружить (осознать) у системы новые свойства, которых нет у ее частей. это называется эмерджентными свойствами.
противоположные варианты “системному” мышлению:
“холистическое” мышление - желание видеть во всем целое, отказ от разбиения на части целого. целостное восприятие.
“редукционистское” мышление - считает что у системы новых свойств не возникает. редуцирует систему к ее частям.
системное мышление способно разработать и собрать “компьютерную систему”,
способно спроектировать, создать и ввести в эксплуатацию “систему космического запуска”
такие дела.
спасибо за внимание.
время мышления письмом: ( 10 + 60 + 30 + 20 ) минут.