Category: общество

Category was added automatically. Read all entries about "общество".

2021 год
  • ailev

Почему ISO 15926

За последнюю пару лет ситуация с объяснением того, почему интеграционные (федеративные, MDM и т.д.) решения нужно делать именно на основе ISO 15926, изменилась. Если раньше нужно было сравнивать реляционные и объект-атрибутные (то бишь традиционные ООП) модели данных традиционных MDM и иных "интеграционных" и "шинных" решений в их конкуренции с ISO 15926, то сегодня на рынке много самых разных игроков:
-- аристотелевская традиция (куда попадают практически все известные на сегодня варианты MDM-решений, SOA-реализаций с ESB, варианты "много интеграций точка-точка, и ничего в этом нет страшного").
-- простая интеграция на основе технологий семантического веба (т.е. факт-ориентированная модель, а не объект-ориентированная, но без какой-то онтологической начинки). Это новые игроки, которые подчёркивают преимущество, гибкость и всеохватность факт-ориентированной модели, считая что они легко моделируют "по потребности" недостающие справочные данные. Более того, они демонстрируют убедительные примеры. Грубо говоря, "всё то же самое, что ISO 15926, только без этих ваших сложностей овладения 201 типом, темплейтами, паттернами".
-- "словарное соответствие" ISO 15926 -- по факту, сюда попадает любая схема данных, если она опубликована и открыта (т.е. её можно пробовать мэппить независимо от разработчика). Например, XMpLant и множество схем данных CAD/PLM вендоров попадает в эту категорию. Это может быть как "семантические технологии" (то есть RDF/OWL), так и "просто XML схема" (в разы чаще).
-- "внеуставное моделирование" для ISO 15926 (попытка использовать кусочек RDL -- но не полностью, например, игнорируя 4D)
-- полноценное моделирование в ISO 15926, "как задумано разработчиками"

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

Аналогичные аргументы используются и для обсуждения MDM-предложений (централизованное ведение RDL внутри компании с надеждой на обслуживание этой RDL партнёров и поставщиков в масштабе отрасли или бизнес-эко-системы).

Вот эти "преимущества ISO 15926" (и огромное спасибо Hans Teijgeler за обсуждение):

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

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

2. "Простые решения", как основанные на ISO 15926 (но игнорирующие 4D онтологию), так и основанные на RDF/OWL, хорошо работают только в рамках одной стадии жизненного цикла (только проектирования, или только сооружения, или только эксплуатации). При выходе за рамки стадии жизненного цикла приходится моделировать всю сложность объекта "система", который изменяется во времени.

ISO 15926 за счет использования 4D онтологии предлагает нормализацию до 6й нормальной формы. Если использовать более простые модели данных, то денормализация порождает кошмар управления конфигурацией данных, находящихся у разных участников жизненного цикла: синхронизация изменений становится весьма и весьма нетривиальной, как в любом случае денормализации.

Все альтернативные решения не гарантируют этой нормализации по всему жизненному циклу системы, а ограничиваются только нормализацией вплоть до 5й нормальной формы на одной стадии жизненного цикла. Но ведь кто-то после этого должен будет проинтегрировать/профедерировать на всём жизненном цикле эти островки интеграции/федерации для одиночных стадий! В этот момент выяснится, что от "простых и быстрых решений" опять придётся переходить к специально предназначенным для этого решениям ISO 15926, переучивать людей, делать очередной мэппинг данных. Ибо модель данных ISO 15926 как раз и получилась такой нетривиальной из-за того, что решала проблему интеграции данных по всему жизненному циклу: в ней полностью поддержано понятие "система", в части постепенной эволюции и уточнения модели системы, а затем замены компонент в ходе функционирования воплощённой "в металле и бетоне" системы (подробнее о сложности понятия "система" и требований к языкам поддержки системы, в том числе необходимость поддержки темпоральных объектов и отношений, см. доклад http://incose-ru.livejournal.com/39744.html).

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

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

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

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

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

5. Особое внимание к повышению уровня языка:
-- над триплами реализована семантическая сетка из типов Части второй.
-- темплейты, что позволяет резко упростить работу.
-- паттерны, что позволяет ещё больше упростить работу.

Альтернативные интеграционные предолжения содержат какие-то свои собственные способы поднимать уровень высказываний по сравнению с "ассемблером из триплов", но указанных трёх уровней нет ни у кого.
* * *
Конечно, обратной стороной медали тут является сложность освоения модели данных ISO 15926 по сравнению с "простыми и поэтому надёжными решениями" для одной стадии жизненного цикла (неудивительно, что список "трудностей освоения" по факту совпадает со списком "главных достоинств" -- http://dot15926.livejournal.com/30492.html). Но наш опыт показывает, что не так страшен чёрт, как его малюют. Особенно, если учесть:
-- понимание, как осваивать стандарт, потихоньку растёт (см. http://dot15926.livejournal.com/27293.html, довольно много людей успешно продвинулись, следуя этой последовательности).
-- усилия по подъему уровня языка (т.е. освоение работы с паттернами, это писк ISO 15926-моды буквально последнего года) дадут ещё одно снижение образовательного ценза для подключения к работе с модельерами данных обычных инженеров
-- наличие такого софта, как .15926 Editor, который поддерживает всё вышеописанное "из коробки", свободно доступен и позволяет попробовать все решения без привлечения какого-то крупного поставщика RDL и программного обеспечения.
2021 год
  • ailev

Версия 1.3: поддержка жизненного цикла разработки библиотеки справочных данных

Большинство фич скорого уже релиза .15926 Editor версии 1.2 в состоянии "in test", по ним дописывается документация. Самое время подумать о фичах версии 1.3.

В версии 1.2 наш Editor поумнел, пошустрел и стал надёжней, а в версии 1.3 он должен будет обеспечить поддержку методологии разработки RDL. Это означает:

1. Должна быть обновлена наша методология разработки справочных данных (как по содержанию -- с учётом новых наработок в комьюнити ISO 15926, так по форме -- с учётом появления стандарта Essence).

2. Поддерживаем работу с файлами RDL прежде всего (со SPARQL-endpoint тоже будем разбираться, но позже), для файлов поддерживаем версионирование (цель: иметь commit и прочие операции с версиями прямо из Editor).

3. Поддерживаем работу с issue tracker (один редактирует, другой проверяет, ошибки обсуждаются, третий утверждает и публикует, и т.д.).

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

Поэтому просим людей, которые как-то используют в работе наш .15926 Editor (мы знаем, такие люди есть!), дать предложения по самым нужным им фичам в части управления конфигурацией RDL и поддержки жизненного цикла разработки RDL. Сюда комментами, или письмом -- всё одно. Вовремя фичу попросите -- вовремя фичу получите!
2021 год
  • ailev

Закон ОМа: описание [практики] постановки [метода] инженерии схемы данных жизненного цикла

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

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

Тут есть свои:

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

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

В ISO 15288 декларирование типа вылезает в заголовки. Так, все 25 processes этого стандарта имеют намеренное решение тип (process) включить в заголовок с именем конкретной практики, но в оглавлении это выглядит совершенно избыточным (так, я снял эту типизацию в переводе -- а сейчас вновь задумался, не вернуть ли её). Другой пример из стандартов ISO 15288 -- это рекомендация добавлять тип "система", когда подчеркивается использование системного подхода, например, вместо "самолёт" говорить "система самолёт". Я с этой рекомендацией не соглашаюсь обычно ("всё есть системы, так зачем это каждый раз говорить?"), но сегодня в очередной раз задумался над пользой принудительной типизации.

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

Компромиссным вариантом является "декларирование типа" -- как в языках программирования, типизация показывается явно при первом употреблении объекта. В моём вчерашнем постинге я использовал такой подход к типизации, указывая "практики дисциплины" (заодно указав и отношение композиции дисцилины из практик, и тип "практики" для списка индивидуальных практик дисциплин, и указав тип "дисциплина" для индивидуальных методов типа "Инженерия схемы данных жизненного цикла"). Ежели идти дальше, то для типов нужно указать, из какого онтолета они пришли -- "практика" пришла в явном виде из ISO 24744 (там это process), а "дисциплина" -- путем обобщения разных наборов практик (что отражалось в различных "дисциплинах системной инженерии" -- "дисциплина инженерии требований", "дисциплина инженерии системной архитектуры"). Тут я просто обобщил "практику" вверх до "дисциплины" (а не только вниз до уровня "мероприятия" и "дела", как это делается в онтолете ISO 24774).

Пример с дисциплиной (вновь введенное понятие), практикой (использующейся как в ISO 24744, так и в ISO 24744), мероприятием (использующимся только в 24774 для более мелких практик) и делом (использующимся опять таки как мельчайшая единица как в ISO 24744 и ISO 24774) показывает, что нам не обойтись для моделирования метода собственным онтолетом, который должен входить в .15926O.

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

В качестве упражнения: опустим типы из ISO 24744/24774 в предыдущем предложении -- смысл ведь не изменится! "В отдельном постинге (http://community.livejournal.com/dot15926/16745.html) я выполню упражнение по описанию постановки инженерии схемы данных жизненного цикла (которая, по идее, должна быть специализацией постановки в ситуационной инженерии методов -- примерно в том же смысле, в котором мы говорим о "специализации шаблонов")". Интересно, сколько людей сочтет "более понятным" типизированный вариант, а сколько нетипизированный?

Этот пример также даст понимание, как может выглядеть описание (рендеринг) методологии в части описания практик (я, правда, не понимаю, правильно ли публиковать это в dot15926, ибо речь идет явно об организационной практике -- а тогда это должно идти в praxos. Типичный пример двойной классификации). Обратите внимание, что многие формулировки и типы в этом примере предписаны ISO 24774 (практики, мероприятия, способ нумерации и т.д.), но существенно также используется типизация по ISO 24744 (даже слово "метод" -- это тоже тип к "инженерии схемы данных", наряду с "продуктами работ") -- но не думаю, что требуется как-то специально обозначать эти пространства имён. Всякие объяснения выбранной терминологии тоже опущены (так, "инженерия схема данных" подразумевает прохождение целевой системы схемы данных по полному жизненному циклу -- от замысла и определения пользовательских потребностей до валидации и эксплуатации. "Разработка" же обычно ассоциируется с более коротким жизненным циклом проекта, заканчивающимся на проектировании -- невзирая на совпадение "проектирования" и "изготовления" для информационных продуктов). "Многоуровневые типизации" и "буквальные типизации" (типа "шаблон практики постановки..." -- чтобы показать, что тип "постановки метода инженерии" в ISO 24744 будет не "process", а "ProcessKind", или использование "метод" как обозначение того целого из практик-продуктов-организации, что подлежит постановке) я старался не использовать. Интересно было бы получить замечания, где дополнительная типизация была бы полезна и уместна (а где, наоброт, осталась лишняя). В целом, "остаточная типизация" следует ISO 24774, как ее можно обнаружить в ISO 15288, взятом за образец предлагаемого описания/рендеринга. Заодно в качестве побочного эффекта мы получаем текст "процессного стандарта", выполнение которого можно проверять по ISO 15504 (SPICE), ибо такой текст читается как "описание типового процесса" (reference process model) в смысле этого стандарта оценки соответствия.
medved

Фреймовые vs. факт-ориентированные нотации

На тему отображение ОО структур во фреймовых/атрибутных нотациях супротив факт-ориентированных/предикатных.

Допустим есть у нас пара классов из 24744, в java-подобной нотации:

WorkUnitKind {
  String getPurpose();
  int getMinCapLevel();
  Outcome[] getResult();
  TaskKind[] getComponent();
}

ProcessKind extends WorkUnitKind {
  ProcessKind[] getChild();
  ProcessKind getParent();
  StageWithDurationKind[] getTemporalContext();
}


Но жаба-подобная нотация не совсем онтологическая, я использовал ее чтобы задать исходные данные, посему перепишем ее в Темплейтной нотации 15926:7 и в F-logic. Первая будет примером факт-ориентированной нотации, вторая - фреймовой соответственно (F - означает frame).

Задача состоит в том, чтобы закодировать следующие понятия:
1. специализация - ProcessKind есть подкласс WorkUnitKind
2. атрибуты - записать, какие атрибуты есть у каких классов, атрибутами в данном случае считаем data property типа String getPurpose
3. отношения - то же самое для отношений, хотя в данном случае можно считать, что отношение задаются одним или двумя свойствами, только они ссылаются на Entity, а не на data, к примеру StageWithDurationKind[] getTemporalContext().
Вобщем, будем следовать OWL традиции, и считать что есть data property и object property.
4. cardinality для отношений
5. задать инстансы и их свойства

Темплейтная нотация

Чисто для наследования запись выполняется просто:
Specialization(ProcessKind, WorkUnit Kind).

Для свойств тоже все просто, нужно задать по темплейту для каждой свойства:
StringProperty(WorkUnitKind, Purpose)
IntProperty(WorkUnitKind, MinCapLevel)
ObjectProperty(WorkUnitKind, Result, Outcome)
ObjectProperty(WorkUnitKind, Component, TaskKind)

ObjectProperty(ProcessKind, TemporalContext, StageWithDurationKind)
ObjectProperty(ProcessKind, Child, ProcessKind)
ObjectProperty(ProcessKind, Parent, ProcessKind)


Также имеет смысл указать, что Child и Process - это два стороны одной медали два конца одного и того же отношения, т.е. Parent есть инверсия Child. Это можно делать разными способами, например просто указать на инверсию:
InvertedProperty(Parent, Child)

Либо задавать отношение темплейтом, в котором в качестве параметра передавать имена для обоих концов, но сие есть не очень гибко:
Relationship(ProcessKind, ProcessKind, Child, Parent).
Также в данном темплейте можно указать и кардиналити:
Relationship(ProcessKind, ProcessKind, Child, 0, *, Parent, 0, 1).

Более гибко однако задавать и свойства и кардиналити отдельными фактами:
т.е. добавить еще
Cardinality(Child, 0, *).
Cardinality(Parent, 0, 1)


Инстантиация тоже выполняется прямолинейно:
Classification(RequirementEngineering, ProcessKind)

Хотя в случае 24744 нам нужно инстанциировать RequirementEngineering как Clabject, т.е. использовать специальный темплейт, который добавит специализацию для RequirementEngineering как подкласс Process связаны:
Clabject(RequirementEngineering, ProcessKind)

Для того, чтобы Clabject знал что RequirementEngineering должен быть именно подклассом Process, нужно связать последний с ProcessKind отношением Power/PartType, например с помощью такого темплейта:
Powertype(Process, ProcessKind)

Инстантиация свойств тоже делается несложно, нужно только придумать немного другие имена для темплейтов, нежели в случае определения пропертей:
StringPropertyInst(RequirementEngineering, Purpose, 'blah-blah-blah')
IntPropertyInst(RequrementEngineering, MinCapLevel, 1)
ObjectPropertyInst(RequrementEngineering, TemporalContext, DesignPhase)


Хотя имеет смысл определить специальные темплейты для каждого класса, чтобы было удобнее инстанциировать свойства:
WorkUnitKind_Purpose(RequirementEngineering, 'blah-blah-blah')
WorkUnitKind_MinCapLevel(RequirementEngineering, 1)
ProcessKind_TemporalContext(RequrementEngineering, DesignPhase)


Здесь есть некоторый недостаток, что имя темплейта должно включать имя класса, для которого определяется атрибут, ибо атрибуты могут дублироваться. В контексте ОО, нужно помнить, что Purpose задан именно в WorkUnitKind, а TemporalContext - в ProcessKind, хотя и тот и другой есть у ProcessKind. Но наследование атрибутов в Темплейтной нотации не выразить.

Этот недостаток исправляет

Нотация F-logic

Насколько я знаю, фреймовые нотации являются предшественниками ОО, т.е. они как раз удобнее в нашем случае:
WorkUnitKind [
    Purpose{1:1}*=>_string,
    MinCapabilityLevel{1:1}*=>_integer,
    Result{0:*}*=>Outcome,
    Component*=>TaskKind].
ProcessKind :: WorkUnitKind[
    Child*=>ProcessKind,
    Parent{0:1}*=>ProcessKind,
    TemporalContext*=>StageWithDurationKind].


Как видно, сия запись практически не отличается от Джавовской.
Единственно, что сюда надо добавить описание того, что Child и Parent - инвертированные отношения:
inverted(ProcessKind, Child, ProcessKind, Parent).

F-logic позволяет задавать сии свойства и по частям, в виде отдельных утверждений, что фактически делает ее факт-ориентированной нотацией:
ProcessKind :: WorkUnitKind.
ProcessKind[Child*=>ProcessKind].
ProcessKind[Parent{0:1}*=>ProcessKind].
ProcessKind[TemporalContext*=>StageWithDurationKind].


Инстантиация тоже выполняется прямолинейно:
RequirementsEngineering:ProcessKind[
  Purpose->'blah-blah-blah',
  MinCapLevel->1,
  TemporalContext->{DesignPhase}
].


Специально задавать инстанциацию как Clabject не нужно, ибо в F-logic это можно выразить на уровне аксиом, нужно лишь указать, какие классы связаны Power/PartType отношением:
powertype(WorkUnit, WorkUnitKind).
powertype(Process, ProcessKind).


Можно также инстанциировать по частям:
RequirementsEngineering:ProcessKind.
RequirementsEngineering[Purpose->'blah-blah-blah'].
RequirementsEngineering[MinCapLevel->1].
RequirementsEngineering[TemporalContext->{DesignPhase}].


Также отмечу что нет нужды помнить какой атрибут из какого класса - атрибуты наследуются.


В целом можно сделать вывод, что оба варианты нотаций вполне себе прямолинейны, только F-logic более компактна. Тем не менее внутри она преобразуется в примерно такие же предикаты, как и в Темплейтной нотации, только по другому именованные.