Category: мода

Category was added automatically. Read all entries about "мода".

2021 год
  • ailev

Roadmap софта .15926

Сегодня утром vvagr доложил о .15926 на заседании POSCCaesar Association. Вот кратенькое содержание его доклада (сам доклад я не слышал, но перескажу. Понятно, что без примера ничего непонятно, но уж лучше так, чем молчать еще месяц):

Софт .15926 планируется в двух поколениях:
-- первое поколение "плагинного IDE" (IDE, плагины к нему, плагины плагинов и т.д.), активная разработка в 2011г.
-- второе поколение архитектуры language workbench (поддержка расширяемого набора DSL), активная разработка в 2012г.

Далее всё будет про первое поколение.

1. Софт .15926 состоит из следующих модулей:



IDE, в ближайшей же версии называемое Editor, в котром можно выделить:
-- семантическую сеть (классы, отношения, индивиды по Части 2, определения и инстансы шаблонов по Части 7, метаданные по Части 6)
-- экранный конструктор шаблонов, позволяющий не только редактировать старые, но и создавать новые шаблоны
-- функция поднятия шаблонов в семантическую сетку классов и отношений Части 2

2. Editor умеет читать:
-- OWL части 8, в вариантах как файла, так и фасада Части 9
-- Iring RDF файлы
-- PCA RDL OWL файл (который выкладывается на вебсайте POSCCaesar каждую ночь)
-- определения частей 2 и 7 (в OWL, читаются однократно)

Editor умеет экспортировать:
-- OWL Части 8, в варианте файла и фасада Части 9

3. Editor поддерживает мэппинг при помощи следующих компонент:
-- builder: это конструкции в Python, описывающие создание семантической сетки на основе каких-то уже имеющихся значений переменных Python
-- loader: это конструкции в Python, поддерживающие чтение (загрузку) каких-то внешних структур данных из файлов или API (таблиц Excel, ODBC, бинарных форматов, XML-форматов, хитрых форматов разных САПР и т.д.) в переменные Python.

upmapper -- пользовательский модуль на Python, который читает какой-то формат данных при помощи конструкций loader и затем записывает прочитанное в семантическую сетку посредством конструкций builder. В одном mapper можно использовать множество разных loaders (т.е. одновременно читать данные из двух разных форматов). Сколько разных задач конверсии данных в нейтральный (т.е. ISO 15926) формат решается, столько и модулей upmapper.

-- scanner: это конструкции в Python, поддерживающие выборку каких-то фрагментов (паттернов) семантической сетки в переменные Python
-- writer: это конструкции в Python, поддерживающие запись из переменных Python в какие-то файлы или API (по сути, это те же форматы, которые использует для чтения loader: таблицы Excel, ODBC и т.д.). Сколько разных форматов поддерживается, столько и вариантов scanner.

downmapper -- пользовательский модуль на Python, который извлекает какие-то фрагменты семантической сетки при помощи конструкций scanner и затем записывает в требуемых форматах конструкциями writer. В downmapper можно одновременно вести вывод в несколько разных форматов (используя один scanner и множество разных writers). Сколько разных задач конверсии нейтрального формата в пользовательские форматы решается, столько и будет разных downmapper.

4. В июне будет выпущен открытый код:
-- Editor (пока без подъема шаблонов, но с "деревянным" конструктором шаблонов)
-- builder
-- .xls loader
-- пример upmapper для методики характеризации требований (ISO 15926 offsite)
-- описана плагинная архитектура

5. Далее разработка ведется сообществом:
-- Editor развивается централизованно (аналитические диаграммы шаблонов, подъем шаблонов и т.д.)
-- централизованно добавляется scanner
-- разные loaders и writers для хитрых форматов данных пишутся по потребности сообществом (теми, кто хорошо знает эти форматы)
-- upmappers подразумевают серьезную онтологическую (а не только программистскую) работу. Они готовятся для каждого проекта отдельно, и подразумевают наличие модельеров данных, хоть как-то понимащих Python. То же относится к downmappers. Если кто-то хочет попробовать себя в роли такого модельера данных (в Москве), пишите мне письма.
-- отдельно решается вопрос о способе поддержке фасада Части 9

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

7. Если Ктулху не будет категорически против, то Новый Год начнем с размышлений про архитектуру второго поколения, language workbench.
2021 год
  • ailev

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

Попробуем написать отрывок потенциального "Стандарта инженерии схемы данных жизненного цикла" как стандарта, задающего описание метода [можно дополнительно протипизировать и "данные жизненного цикла" -- "Стандарт инженерии сжемы данных жизненного цикла целевой системы", что укажет на использование методов системной инженерии, поелику помянут тип "целевая система" из онтолета ISO 15288, ну да ладно. Подробнее про типизацию см. в http://community.livejournal.com/dot15926/16526.html). Немного разъяснений, вопросов и обоснований в квадратных скобках -- и крайне интересно, насколько эти комментарии полезны для читающих, а насколько они лишни и поэтому безжалостно должны вычищаться из текста перед его боевым применением.

0. Практика "Постановка инженерии схемы данных жизненного цикла".

Назначение практики постановки инженерии схемы данных – предоставить обеспечивающую инфраструктуру и услуги для выполнения остальных практик инженерии схемы данных. Данная практика определяет, обеспечивает и обслуживает оборудование, здания и сооружение, инструменты и программно-аппаратные комплексы, наряду с персоналом.

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

В результате успешного выполнения практики постановки инженерии схемы данных:
А) на роли модельеров данных и предметных экспертов назначены конкретные физические лица ["бестиповой" вариант: модельерами данных и предметными экспертами назначены...]
Б) модельеры данных и предметные эксперты обучены (т.е. имеют необходмые компетенции)
В) модельеры данных и предметные эксперты организованы (т.е. определены их полномочия и ответственность)
Г) модельеры данных и предметные эксперты обеспечены рабочими местами и необходимыми IT-сервисами, для чего закуплены и настроены программно-аппаратные средства для инженерии схемы данных и целевой работы с данными [ибо одной схемой не обойдёшься, ее ведь нужно отлаживать на реальных данных -- справочных и данных проекта]
Д) стабильная и надёжная инфраструктура обслуживается и совершенствуется.

Сотрудники организации [избежим слова "акторы", 24744:producers] ДОЛЖНЫ выполнить при постановке инженерии схемы данных следующие мероприятия и дела:
a) организовать людей
Должны быть определены организации (отдельные юрлица, если речь идет о расширенной организации, и подразделения, если речь идет о какой-то отдельной организации), предоставляющие физических лиц для заполнения ролей модельеров данных и предметных экспертов [айтишников для настройки-поддержки софта тут не определяем, их деятельность будет описана отдельной практикой -- хотя в таком различении и есть сомнения]. Инженерия схемы данных, как и любая другая работа по моделированию выполняется небольшим числом хорошо коммуницирующих квалифицированных людей, а не "организациями". Поэтому невозможно "заключить контракты с юрлицами", а потом просто собрать результат работы в виде готового продукта. Должны быть выполнены следующие дела:

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

В контрактах явно определяется, какие именно роли из настоящего стандарта будут исполняться подрядчиком, какая IT-инфраструктура и инструменты будут использоваться.

В контракте явно оговаривается раскрытие Заказчику информации о делегировании конкретных людей и компонент IT-сервисов в число участников проекта инженерии схемы данных жизненного цикла, проектный менеджер [эта роль не определена в данном отрывке стандарта, и нужно еще подумать, вводить ли сразу проектную действительность] ведет справочник назначений (заполнения ролей модельеров данных и предметных экспертов) и справочник IT-сервисов и инструментов.

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

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

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

Необходимо довести до них цели проекта, описать конструкцию контрактов [в том числе неявных, между подразделениями или даже внутри подразделения]

Необходимо представить людям методологию работы (текст настоящего Стандарта и сопутствующие справочные материалы).

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

Рекомендуется использование методов проведения kick-off meetings из проектного управления.

3) проводить регулярные планирующие и контрольные мероприятия в порядке управления проектом
Использовать сценарные техники ролевого проведения планирующих и контрольных мероприятий (планирование итераций в духе Agile методов, планирование в духе LastPlanner и т.д.).

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

c) Обучить участников проекта
Для того, чтобы участники проекта инженерии схемы данных жизненного цикла могли выполнить свою задачу, нужно их обучить. В описании каждого вида актора приведены минимальные компетенции и знания, которыми они должны обладать, чтобы выполнять свою работу.

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

Для обучения участников проекта необходимо выполнить следующие действия:

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

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

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

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

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

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

Необходимо участие модельеров данных в онлайн-сообществах (dot15926, форумы Iring, комьюнити "ISO 15926" в LinkedIn и т.д.).

Практикуется также личная переписка между экспертами (для чего полезно личное знакомство на международных и отечественных конференциях.

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

1) настройка инструментов (IT-сервисов) на совместную работу
Приобретение всех необходимых инструментов (и разворачивание их в виде IT-сервисов) предполагается на предпроектной стадии, на стадии собственно проекта инженерии схемы данных жизненного цикла должна быть проведена только настройка всех потребных IT-сервисов для совместного применения в ходе конкретного инженерного проекта:
Предусловие:к моменту начала настройки существуют:
-- необходимые программные средства и лицензии
-- рабочие места для коллективной работы над моделями (требование: монитор 2560*1600 плюс возможность работы 3-4 человек за одним монитором). Такими рабочими местами должны обладать как модельер данных, так и предметный эксперт.

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

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

2) закрепление исполнителей за рабочими местами
Участвующим в проекте модельерам данных и предметным экспертам [более корректная формулировка: людям, замещающим роли модельеров данных и предметных экспертов] должны быть предоставлены на их рабочих местах необходимые пароли к программам, а также права доступа к тем данным, которые им необходимы для работы. Должен быть проведен инструктаж (в том числе -- обучение) по работе с этими программными средствами в части администрирования [предполагается, что вряд ли работник IT-службы, установивший какой-то Редактор схемы или RDL sandbox проведет инструктаж по собственно моделированию. Скорее, он покажет, как вызывать программу, и куда на сервере можно/нужно выкладывать результаты работы, и как потом схема данных будет попадать в целевое хранилище данных для НСИ и/или инжинирингового проекта]. Всем участникам проекта должен быть известен телефон службы IT-поддержки.

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

Театральная метафора
Основная метафора постановки методологии [метод и методология, как объяснено в ISO 24744 -- синонимы]– театральная. Методология – это сценарий для прописанных ролей, который необходимо исполнить имеющейся труппой реальных людей, назначенных на роли. В ходе постановки пьесы проводится кастинг людей-актеров на роли, эти роли затем разучиваются, закупается реквизит, спектакль репетируется для осуществления правильного взаимодействия актеров друг с другом и реквизитом, а затем осуществляется игра актеров в спектакле соответственно их ролям.

Два уровня: организация и физические назначения
Основная проблема в том, что существует два уровня выполнения данной работы:

А) в наложенной организации проекта («организации, наложенной на существующие юридические лица, http://ailev.livejournal.com/652159.html) находятся формально ответственные (чаще всего – в силу договора) юридические лица, которые должны выполнять те или иные акторские роли и предоставлять те или иные IT-сервисы. Так что нужно заключить правильную систему контрактов, определить полномочия (в том числе по использованию ресурсов -- например, инструментов) и ответственности.[опять же, эти "организации" могут оказаться подразделениями внутри предприятия, а "договора" -- устными соглашениями]

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

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

Необходимость наличия инфраструктуры перед началом моделирования
Тем не менее, согласно правилам Lean management (восьмой тип muda – «making-do», описанный Lauri Koskela в http://www.iglc2004.dk/_root/media/13091%5F088%2Dkoskela%2Dfinal.pdf) нельзя приступать к работе, пока не наличествуют все необходимые ресурсы, это ведет к бесполезной трате времени и наличных ресурсов. Нельзя разрабатывать схему данных жизненного цикла, пока нет квалифицированного модельера данных, или пока нет софта для создания схем данных.

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

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

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

Продукты работы
[продукты должны бы быть специфицированы как "продуктный пул" для всей совокупности практик метода, но уж приведу тут без подробностей и не претендуя на полноту списка -- только для примера. Более того, сама терминология тоже еще не устоялась и требует отдельного разбирательства]

Основные:
-- целевая схема данных (шаблоны и классы), как набор онтолетов (часть местной RDL), возможно в вариантах "нейтральной схемы" и "схемы в формате конкретного хранилища данных" (можно назвать "физической схемой", но тут цепочка явно больше, чем в "трехсхемной модели", и до "физической схемы" может быть еще несколько уровней -- объектная схема, затем реляционная схема, затем b-деревья и т.д.). Схема состоит из отдельных ссылающихся друг на друга онтолетов.
-- схема мэппинга, если он требуется для хранения целевой схемы [а если речь идет о практике интеграции данных с использованием мэппинга/адаптеров, то это отдельная практика]
-- уже наличествующие "доверенные" [то есть те, которым мы доверяем] онтолеты из федерации RDL (как для использования в моделировании, так и для пополнения по итогам моделирования)
-- материалы для моделирования (проектная документация, учебники, словари, стандарты, справочные базы данных и т.д.. Часто еще и "живые эксперты", ибо речь идет о knowledge acquisition, т.е. превращении implicit knowledge в explicit. Тут же -- доступ к поисковым системам, например, Google или Яндекс).
-- отладочные данные

Вспомогательные:
-- Справочник назначений -- ведется Проектным менеджером
-- Справочник IT-сервисов -- ведется Проектным менеджером
-- набор литературы и учебных схем данных для образования модельера данных
-- настоящий Стандарт инженерии схемы данных жизненного цикла [помним, что пул продуктов определяется не для отдельной практики, а для всей дисциплины]

Роли
-- модельер данных
ISO 15926 предусматривает минимально два уровня: "желтый пояс", который способен выполнить какое-то моделирование самостоятельно для использования получившейся схемы в рамках предприятия, и "черный пояс", чьи схемы достойны помещения в публичный (отраслевой, национальный, глобальный) RDL.
Объем знаний: владение методами, описанными настоящим Стандартом [см. также набор практик в http://community.livejournal.com/dot15926/16360.html].

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

Инструменты (IT-сервисы)
-- редактор схемы данных
-- сервер для поддержки местного RDL и участия в федерации RDL (считаем, что пруверы входят в состав сервера)
-- хранилище данных для тестовых загрузок данных (считаем, что адаптер входит в состав хранилища данных, равно как и интерфейсы загрузки и просмотра данных)
2021 год
  • ailev

Редактор схемы

По итогам обсуждения потребностей модельеров (очно с vvagr) и архитектуры удовлетворения этих потребностей (в комментах к http://community.livejournal.com/dot15926/6880.html), пришли к интересным выводам:

1. Любые "сервера" 15926 варятся из трипл-стора как суп из топора: много-много программной обвязки и утилит. Ни один промышленный сервер сейчас не поддерживает нужд модельеров. Поэтому код нужно писать самим, и срочно. Код нужен для трех типов систем:
-- сервер системы и проекта (упихнуть данные со всех САПР, систем инженерного документооборота и проектного управления, а также ERP в хранилище данных -- и провязать их друг с другом, поставив под контроль конфигурации. У поставщиков САПР такое называется PLM).
-- сервер справочной информации (RDL в частном случае, НСИ и каталоги в общем случае). Совсем другой паттерн использования.
-- каталог организационной информации (каталог методов и набор DSL для организации плюс настройка воркфлоу для разных окружающих систем). Это PraxOS.

2. В проект dot15926 попадает разработка (или выбор готовых ;) не только трипл-стор и 15926L engine над этим трипл-стор, но и language workbench. А вот композер и каталог методов -- это в praxos. (подробности в дискуссии по приведенной выше ссылке).

3. Чтобы начать работу над любым из заявленных трех типов приложений, нужно реализовать редактирование схемы данных: это задача номер ноль. Странность в том, что по-хорошему это должно укладываться как DSL представления/редактирования/отображения схемы внутрь language workbench, но ежели ждать полноценной реализации language workbench, то может быть потеряно много времени. Поэтому можно попробовать сделать "прототип номер один", который потом выкинется и заменится полноценной language workbench, а для начала будет представлять из себя "моноязыковый редактор" -- и испробовать на нём разные идеи и инструменты. Например, justy_tylor предложил использовать Python + AllegroGraph (API) + wxPython + Scintilla (wxStyledTextCtrl) -- и можно это опробовать на редакторе схемы сначала, а потом уже на полном language workbench, если понравится (и после набития шишек).

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

5. Фишка в том, что для триплетов нужно уметь показать на экране два объекта и отношение между ними. Это делают "нортон коммандеры": на одном пане дерево какой-либо таксономии/классификации с найденным на нем объектом, на другом пане дерево с другим найденным объектом, а между ними протягиваем "мышкой" отношение (задавая его тип). Потом можно поглядеть на сгенерированную диаграмму части второй -- но редактирование огромной схемы идет в терминах протягивания связей/убивания связей между двумя панами с общей таксономией (или классификаторами). Именно так реализовано редактирование большой онтологии в БигМастере, и нужно просто это повторить, это в разы быстрее, чем прокликивание мышкой в однопановых редакторах. В текстовом представлении редактирование непонятно, как реализовать -- динамически выводить кусок сетки в виде текста?! И как потом в этом тексте разобраться? Опять же: функции браузера и навигации к нужному месту оказываются первичными. На полях отображаются ошибки, спецпометки неотображенных объектов и т.д. Псевдографикой выделяются отношения к классам классов и просто классов.

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

В следующей версии -- подумать, как добавить туда темплейты.

В следующей версии -- language workbench, и тем самым возможность описывать разные DSL и рендеренги.

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

Теперь нужно понять, сколько это стоит, кто это сможет сделать, и за какое время.
2021 год
  • ailev

Дискурс, гламур и баблос

Ряд архитектурных решений, как я их понимаю на сегодняшний день.

1. За неимением гербовой (с графикой), будем писать на простой (только текстом).

2. Одна и та же информация о классах в формате ISO 15926 представлена в трех видах:

а) Дискурс -- в этом виде проходит подготовка OIM инженером-онтологом. Например, именно в этом виде мы представляем метамодель ISO 24744. Для дискурса онтологи используют EXPRESS, OWL, UML/MOF, ORM2, FOL, ControlledEnglish, F-logic и все это должно поддерживать темплейты, без которых при больших объемах вообще никак.
Я сам (после некоторого знакомства с предметом) останавливаюсь на темплейтных диалектах дискурса:
-- математическом дискурсе F-logic (для тех, кто хочет писать коротко и не боится "::") и
-- человеческом дискурсе ControlledEnglish (для тех, кто хочет изобразить коболообразный DSL для не-онтологов).
Дискурс -- короткоживущая форма информации. Она немедленно перегоняется в баблос, как только это возможно. В принципе, баблос тоже перегоняется в дискурс, ежели в нем нужно что-то подправить -- и немедленно отгоняется обратно.
Бывает еще экспертный дискурс: на нем пишут эксперты какой-то предметной области, но он перегоняется в математический или человеческий дискурс, и только потом -- в баблос. Экспертный дискурс нужен нам для того, чтобы на нем описывать индивиды (описывать предпринятия).
Тем самым делать нужно перегонный (из дискурса в баблос) аппарат, возможно двухстадийной перегонки, да еще и с рефлюксом (возвратом баблоса на догонку).

б) Баблос -- то, что находится в RDL, вместе со всей дискуссией о развернутых-неразвернутых темплейтах, синтаксисе аксиом в аннотациях, triple-store, канонических способах доступа по SPARQL Части 9 и прочих всенепременных атрибутах. Баблос всего мира содержится в сообщающихся сосудах. Сегодня баблос хранится главным образом в SandBox из iRINGTools. Баблос никто не видел, кроме особо посвященных в конструкцию SandBox (но как им удается его разглядеть, науке неизвестно).

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

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