December 2nd, 2010

2021 год
  • ailev

Метод инженерии шаблонов

Инженерия знаний -- инженерия повторно используемых сведений (т.е. знаний) в форме семантически (т.е. с формальными (т.е. понятными компьютеру) значениями) определенных данных.

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

Схема данных жизненного цикла -- это знания о данных жизненного цикла (откуда мы исключаем НСИ и сами данные -- но оставляем определяющую их схему). Эти знания, выраженные как список шаблонов, имеют группу описаний вёрстки (compose; или "сборки", assembly), в которой выразимы единицы вёрстки:
-- интегральная (т.е. для всех данных) схема, как весь разрабатываемый список шаблонов [подчеркнем слово "разрабатываемый" и оставим за пределами схемы используемые при ее создании шаблоны, уже находящиеся в WIP/RDL более высоких уровней]
-- онтолет (список шаблонов, покрывающих какую-то предметную область -- связный фрагмент схемы данных жизненного цикла, единица модульности). [В ISO 15926 этому примерно соответствует OIM].
-- шаблон

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

Нужно обратить особое внимание, что ISO 15926 мало что говорит про интегральную схему (всё, что говорится -- в проекте BIHG, но там больше о том, что "схема должна быть, и должна быть адекватна"). Онтолет вообще не определяется в ISO 15926, но вводится очень похожее понятие OIM (Object Information Model, по поводу которого существуют большие разногласия у разработчиков -- некоторые считают его введение необходимым, а некоторые относят к пережиткам объект-ориентированного мышления, притащенного из предыдущих проектов стандартизации). И только шаблон является более-менее проработанным объектом инженерии.

Каждый из этих объектов, понимаемый как целевая система, имеет свой жизненный цикл, свои практики жизненного цикла. Мы выбираем слово "инженерия" для шаблонов, чтобы показать важность прохождения определенного жизненного цикла разработки, публикации и использования шаблона -- в отличие от "научного" подхода к онтологизации, который ассоциируется с внезапными озарениями и беспорядочным фиксированием результатов в случайных формах. Сравните computer science и software engineering, ontology как философскую дисциплину и ontology engineering как дисциплину.

Тем самым жизненный цикл схемы данных жизненного цикла на стадии ее инженерии (aka выполнения дисциплины инженерии схемы данных ЖЦ) в существенной мере состоит из выполнения практики инженерии шаблона. Шаблон представляет собой главный объект внимания, главный продукт, на протяжении существенного времени именно шаблон является целевой системой для инженеров схемы.

Дальнейшее изложение будет обзором основных идей методологии характеризации (https://www.posccaesar.org/wiki/TemplateCharacterization), для компактификации знания излагаемое не тамошних терминах ("содержательные оси", например), а в традиционных для системной инженерии ("группы описаний" вместо "осей" -- используем ISO 42010) и дополненное . Изложение будет следовать ISO 24744 и его терминологии (для того, чтобы хоть как-то унифицировать разношерстность описаний ISO 15926 и сопровождающих его наставлений). Конечно, важно и нужно читать оригиналы на английском -- но это не отменяет нужды в русскоязычной терминологии (к тому же многие древние англоязычные тексты правильны по сути, но устарели по терминологии), а также нужды в компактификации этого обширнейшего знания.

[Традиционный порядок (практики, продукты, организация) мы поменяем на "продукты, организация, практики" (ибо бессмысленен разговор про практики, пока непонятно, что мы пытаемся сделать). К организации добавим заинтересованные стороны (а не только роли непосредственных исполнителей практик).]

За рамками метода оставим rules (они же -- constraints, логические условия, которые выходят за рамки аксиомы шаблона) и особенности реализации технологии шаблонов (что нужно делать с шаблонами, чтобы работать с ними в конкретном объект-ориентированном хранилище, или даже в специализированной системе типа Iring или .15926).

1. Рабочие продукты.
1.1. Шаблон
[этот список составлен прямо по документу "характеризации", но его явно нужно основательно переработать. Так, я пока не понимаю, как выразить в этих группах описаний все требуемые частью 8, пункт 7.2 описания -- http://community.livejournal.com/dot15926/15213.html. Непонятно, где учитывать требования Части 6 к определениям и наименованиям в RDL. Я не могу считать все эти требуемые частями 6 и 8 описания "реализационными особенностями".]

По ISO 42010 при описании шаблона можно выделить следующие группы описаний, адресующие интересы разных заинтересованных сторон:

1.1.1. формальная модель: логическая формула [определяется в Части 7]

1.1.2. уровень подробности: наличие графа подъема-опускания -- определение до уровня подробности языка Части 2, или определение только указанием сигнатуры.

1.1.3. полножизненноцикловость (следование духу ISO 15926, as intended by ISO 15926): полножизненноцикловый (full lifecycle) против сокращенного (short-cut) шаблона. Каждый шаблон должен быть применим на протяжении всего жизненного цикла, а не только для целей какой-то стадии. Это задача менеджмента организовать замену сокращенных шаблонов (ибо предметные эксперты могут быть шовинистами одной стадии жизненного цикла).

1.1.4. модульность (assembly): как шаблон собран (дизайн) из или декомпозирован (открытие, discovery) на меньшие шаблоны-компоненты (атомные -- нет полезного использования в предметной области, молекулярные -- полезные, документальные или набора данных -- сборка множества молекулярных, OIMs).

1.1.5. предметные группы описаний:
1.1.5.1. Общий тип (generic type, GNT) [это несводимо к Части 2! Речь идет о предметной области, а не о моделировании -- т.е. обеспечивается не "типизация для модельера", а понимание эксперта предметной области] -- (физический или функциональный) ресурс, практика/процесс, организация/люди, информация и информационные системы.
1.1.1.2. Абстракция и уровень воплощения (level of realization, LOR) -- экземпляр, класс или класс классов [требуется помощь модельера данных, предметные эксперты часто ошибаются!]. Именно в этой точке возникает "четырехуровневая архитектура IEC-61346-4" (требует уточнения для разных жизненных циклов! это ведь только для оборудования!) -- 4 уровня воплощения: тэг, требования, техусловия, оборудование.

1.1.6. сила определения шаблона: публичный (слабоопределенный, который еще не мэппится 1:1 с частным шаблоном или сильноопределенный, когда сигнатура достаточно сильна, чтобы мэппиться на частные шаблоны 1:1) готовится желтопоясными модельерами, и частный -- определяемый в терминах языка 2 и 7 частей, готовящийся чернопоясными экспертами, но не предназначенный для показа предментым экспертам и желтопоясным модельерам. [предположительно -- "юзерские" и "системные" шаблоны, в этом месте нужно еще поразбираться]

1.1.7. уровень RDL: базовые (basic, используют только типы части 2, без специализации), основные (core, используют полезные "варианты" базовых шаблонов -- специализируя их, но не относятся к стандартным или частным классам), стандартные (отражают стандарты организаций стандартизации), частные (proprietary, любой организации), начальные/стартовые (отражают начальный уровень согласия, имеют только историческое значение).

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

Набор данных представляется двумя группами описаний:

1.2.1. Вёрстки (composition; сборки, assembly), в которой выражаются единицы вёрстки:
-- элемент (любое подмножество данных, которое может быть выделено, включая секции, подсекции, подсборки, поля данных или ячейки)
-- ячейка (cell, неделимый элемент или поле данных), мельчайшая единица адресации -- но может быть также структурирован в ходе ??характеризации шаблонами
-- секция: сборка уровня больше элемента, но меньше всего набора данных
-- запись: секция, которая представляет собой ряд или колонку в документе (списке, таблице, плане и т.д.). Это не "запись" на носителе!
1.2.2. Наличием схемы (well-formed source) -- формальная схема набора данных доступна (например, есть схема данных порождающего набор данных приложения -- на любом языке описания схемы) или недоступна (например, набор данных дан "в бумаге" и схема данных неизвестна, или не заслуживает доверия -- например, много информации содержится в кодировках, представленных в приложении текстовыми строками без описания их структуры)

2. Организация

2.1. Профессиональные роли

2.1.1. Исполнители [те, кто непосредственно выполняет практику инженерии шаблона]

2.1.1.1. Предметные эксперты
Инженеры, технологи, менеджеры инженерных проектов и т.д. -- те, кто глубоко знает и понимает предметную область.
2.1.1.2. Модельеры данных
Исполнителями являются модельеры данных "желтого пояса" (уровня предприятия). Модельеры данных "черного пояса" задействованы для работы с WIP/RDL более высоких уровней.
2.1.1.3 Менеджеры
[помним: как минимум, их задача -- обеспечить создание полножизненоцикловых (ух!) шаблонов, ибо предметные эксперты обычно центрируются на одной стадии ЖЦ. Их задача также обеспечить взаимодействие предметных экспертов и модельеров данных]

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

2.2. Инструменты
2.2.1. Редактор шаблонов
Нужно обратить особое внимание на то, какие группы описаний шаблона поддерживает редактор.
Например, многие "редакторы схем" не поддерживают понятия шаблона как такового. Если считать, что "шаблон" соответствует объекту, а его сигнатура задается "атрибутами" в объект-ориентированном редакторе, то сразу чувствуется отсутствие группы описаний уровня подробности (графа поднятия-опускания), а также модульности (какие другие шаблоны используются данным) -- и так далее по всему списку групп описаний.
[не нужно и говорить, что .15926N будет стремиться предоставить возможность редактирования шаблона во всех приведенных группах описаний]

2.2.2. "Песочница" -- RDL в федерации RDL, для хранения создаваемой схемы и доступа к требуемым схемой "внешним" шаблонам

3. Работы
[этот раздел нужно тщательно прорабатывать, собирая материал из многих источников -- тут нужно заметить, что собственно практикам в оригинальном англоязычном документе отводится три страницы из 18, но огромное количество информации находится в виде "диаграмм Магне" и подобных неформализованных источников, откуда собственно практику нужно восстанавливать в явном виде. Всю терминологию нужно тоже перерабатывать -- все эти "идентификации" явно нужно уточнять]

3.1 Вид жизненного цикла инженерии шаблонов
Зависит от того, есть схема данных для наборов данных, или ее нужно восстанавливать из наборов данных.
[Кроме того, я бы рассмотрел типовые ситуации, когда еще нет самих наборов данных -- а есть только или готовая система, описание которой нужно "восстановить", или система только будет проектироваться, и ее описания просто еще нет, а методы описания только нужно выбрать]

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

3.2. Мероприятия
[поскольку у нас инженерия шаблона -- это практика дисциплины инженерии схемы данных жизненного цикла, то она состоит из мероприятий, а те -- из дел]

3.2.1. Означение элемента (characterization) -- анализ синтаксической структуры элементов данных и открытие (discovering) семантического значения для каждого элемента.
3.2.2. Открытие неявных элементов в наборе данных.
3.2.3. Поиск (semantic matching) в словарях, стандартах, учебниках, RDL и т.д.
3.2.4. Формулирование шаблона - выражение на ISO 15926 в качестве шаблона (для использования в одном жизненном цикле).
3.2.5. "Стандартное применение" -- формальность, недоговоренность (ambigity) и эволюция -- вынос в RDS/WIP (JORD)
3.2.6. Версионирование схемы (при непрерывном открытии новых знаний и уточнении схемы нужно управлять версиями)

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

4. Моделирование

4.1. Языки
4.1.1. Язык части 2
4.1.2. Язык части 7 (FOL)
4.1.3. Язык формальной записи шаблона во всей полноте его групп описаний [пока отсутствует]
[4.1.4. .15926L]

4.2. Нотации
4.2.1. Диаграммы части 2 [только как учебные примеры прямо из части 2: в практике их использование неудобно]
4.2.3. Диаграммы части 7
4.2.3. FOL (например, нотация для Prover9)
4.2.4. OWL
4.2.5. Представление формальной записи шаблона во всей полноте его групп описаний [пока отсутствует]
[4.2.6. нотация API .15926L]
[и обращаем внимание, что EXPRESS отсутствует]
* * *

Теперь этот структурный скелет-оглавление нужно нарастить мясом содержательных описаний -- и, конечно, при этом как-то поменяется и предложенная в данном постинге структура.