Category: архитектура

Category was added automatically. Read all entries about "архитектура".

2021 год
  • ailev

Презентация .15926 Editor

Открытая презентация .15926 Editor состоится в среду 9 октября 2013г. в 17 часов по адресу Голиковский пер., дом 11 (офис TechInvestLab.ru, это одноэтажный особняк, вход со двора, дверь "1", две минуты пешком от метро Третьяковская, карта: http://www.techinvestlab.ru/til_ru_contacts).

На презентации будут показаны "живьём":
-- основные возможности текущей (1.31) версии .15926 Editor: лучше один раз увидеть, чем прочитать больше ста страниц документации.
-- новые возможности, которые появятся в версии 1.4: работа с паттернами и мэппингами общего вида, в том числе демонстрация примера реализации мэппинга паттернов из таблиц Excel.

Конечно, ответим на возникающие по ходу презентации вопросы и выслушаем пожелания: в этом главный смысл собраться очно.
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

Система -- это функция и конструкция, представленные в различных группах описаний

.15926O состоит из нескольких онтолетов:
а) системного подхода -- в котором дается понятие системы и связанные с ней понятия. Предлагается сделать это с опорой на онтолет системы, описанный в приложениях к ISO 15288 и ISO 42010
б) программирования -- которое мы понимаем как информационное моделирование/онтологизирование. Это мы пока подробно не разбирали.
в) метода, которое мы должны будем сделать на базе переформулированного в терминах системного подхода и расширенного обоснованиями ISO 24744 (спасибо Harold Lawson, который указал на то, что описания метода должны быть сформулированы в терминах понятий системного подхода -- и именно это он проталкивает в SEMAT).

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

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

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

2. Дискуссия вокруг functional_physical_object, затеянная Hans Teijgeler (http://www.15926.info/ и тред в LinkedIn. По сути, всё сводится к "абстрактному" пониманию "функции" и "материальному" (в пределе -- физическому) пониманию "конструкции".
Вся эта "четырехуровневая архитектура" ISO 15926 (которая не четырехуровневая, и не архитектура) -- это то, как "функция" переходит в "конструкцию" по мере жизненного цикла холона в системе (сначала этот холон определяется функционально все более подробно, а затем становится понятна его конструкция в какой-то момент -- и после этого наступает реализация).
Тут же -- дискуссия о модели системы (описании функции и конструкции системы) и самой "железной" системе (система -- это класс или экземпляр?).
Проблема в том, что в реальной жизни существенно путаются:
а) функция и конструкция -- инженеры и функцию и конструкцию называют одинаковыми именами, после чего регулярно путают в типизации (относят онтологически к не тому классу, после чего удивляются, почему к функции неприменимы операции, которые можно сделать только с конструкцией, и наоборот).
б) класс (чертеж), класс (каталожная деталь) и экземпляр (железная деталь, в том числе установленная на место, обозначенное в чертеже). Например, в каталожной спецификации путаются как элементы функции, так и элементы конструкции ("сборочное описание"), так и элементы, подтверждающие их связь (архитектурное описание, поведенческие модели).
Тем самым, разделение функции и конструкции -- контринтутивно для сегодняшней инженерии (и уж совсем запредельно для не-инженеров).

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

4. Гипотеза: для обсуждения любой системы нужно иметь не менее двух онтолетов -- один для описания ее функциональности, другой для описания ее конструкции. Наличие веерных матриц позволяет сделать гипотезу, что этих онтолетов может быть некоторое количество. Тут нужно указать, что разница между "многоуровневым" функционально-конструктивным и "многоаспектным" по ISO 42010 описанием пока не слишком понятна -- можно ли выразить многоуровневое описание в рамках одного предметно-специфического архитектурного фреймворка, или каждый такой фреймворк работает только на стыке двух ближайших уровней организации системы -- это нужно еще обсуждать.
Тем самым идея многоаспектного описания, сопряженная с понятием системы и ее архитектуры, и идея онтолета как локальной онтологической единицы для какой-то предметной области (как-то соответствует viewpoint из 42010 и language из 24744) -- это близкосвязанные идеи. Так, .15926N должен как-то это учитывать при работе с онтолетами (например, группировать их в рамках каких-то единиц более высокого уровня -- тех же architectural framework).

5. Функция плюс много конструкций, конструкция плюс много функций: модуль (функциональность) против системы (понимаемой тут как конструкция). Это обсуждается в довольно глубокой работе Wim Gielingh по Extended GARM (http://www.15926.info/functional-physical-object/GARM-paper.pdf). Тут же обсуждение "параметризации" как функции и "генерации" конструкции соответствующей функциональной моделью. Тут же понимание функции как design intention и конструкции как design solution.

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

Требуется: разработать компактный высокоуровневый (upper ontology) онтолет, в терминах которого выразимы все вышеприведенные идеи для "системы": многоуровневость организации (холархия), архитектура, функция и конструкция, архитектурное многоаспектное описание и т.д. (гипотеза: многоаспектное описание не удастся выразить без онтолета информатики).

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

Онтологический мэппинг, онтологический рефакторинг и пространство концепций

1. Предположим, что мы хотим записать в RDL компоненты методов, определенные ISO 42010 и ISO 24744. Содержание этих стандартов в чем-то пересекается: каждый из них определяет модели, виды моделей, языки. Как именно пересекается содержание этих стандартов, и что из этого следует -- это предмет особого разбирательства. Очень грубо: пусть эти стандарты оба содержательного объема 1 знаниевых единиц, и содержание этих стандартов пересекается на 0.25з.е каждого из них.

2. У нас есть выбор:
а) Рефакторинг: завести новый "гармонизированный стандарт" -- PraxOS01, и в него загрузить "переваренные" оба стандарта, получив тем самым знания в объеме 1.75з.е. (экономия пересекающейся части в 0.25 одного из стандартов), или
б) Мэппинг: отмоделировать оба этих стандарта как связные куски знания, а затем выполнить мэппинг пересекающихся части, получив тем самым знания в объеме 2.25 (0.25 добавляются на описание мэппинга, плюс каждый стандарт представлен полностью, включая дублирующиеся неотрефакторенные части).

Содержательно вся эта модульно-языковая история укладывается в два разных подхода -- синтетический (то есть "интеграционный", т.е. мэппинг разношерстных денормализованных описаний) и проекционный (не мэппинг, а рефакторинг при презентации, а затем денормализация по мере необходимости репрезентации) --вот об этом из свежего ISO 42010(на стр. 36 из 55):
There are two common approaches to the construction of views: the synthetic approach and the projective approach. In the synthetic approach, the Architect constructs views of the system-of-interest and integrates these views within an architecture description using model correspondences. In the projective approach, the Architect derives each view through some routine, possibly mechanical, procedure of extraction from an underlying repository".
Сам ISO 42010 употребим с обоими подходами, ISO 15926 также нейтрален к этим подходам -- это всё реализационные особенности, отражающие стиль реализаторов.

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

Это означает, что для "интеграции приложений" (корпоративных информационных систем, как в iRing, или имитационных моделей, как в Симантикс) лучше подходит онтологический мэппинг, а вот для исследовательского проекта PraxOS лучше подходит онтологический рефакторинг.

Обсуждение того, как изменится стратегия образования в данном случае опускаем, только заметим, что если учить нужно сути дела и компактифицировать знание, лучше путь (а), если нужно выполнять формальные требования compliance, то нужно идти по (б).

3. Для того, чтобы каким-то образом вести обсуждения, аналогичные обсуждениям по пункту 2, нам нужно иметь соответствующий набор понятий. Подходящей кандидатурой для "набора шаблонов, в терминах которых выражена подлежащая мэппингу или рефакторингу одна из предметных онтологий" является пресловутый онтолет (http://community.livejournal.com/dot15926/12093.html -- но там все время говорилось об одной предметной области, а тут их явно две "начальных", плюс "итоговвая", плюс "мэппинг").

4. В каком-то смысле пересекаются разные понятия, имеющие отношение к модуляризации:
4.1. онтолет: набора шаблонов для выражения моделей отдельной предметной области (группировка шаблонов по их тематизму"). Можно осторожно предположить, что каждый онтолет соответствует одному языку моделирования (и мы тут немедленно утыкаемся в проблему модульности языков), который соответствует одному виду моделей (и мы утыкаемся в то, что некоторые виды модели явно используют два языка плюс correspondence rules между их примитивами). Это осторожное предположение я пытаюсь обсуждать тут: http://ailev.livejournal.com/872130.html
4.2. namespace -- в том понимании, каком это слово используется для OWL namespaces в Части 8 (группировка шаблонов по их источнику").
4.3. каталог -- набор инстансов, соответствующих каким-то онтолетам и кем-то проверенных (зарегистрированных). Например, каталог компонент методов -- инстансы компонент методов, соответствующие онтолетам этих компонент.
4.4. workbook: взаимосвязанный набор шаблонов для целей редактирования, хранения, передачи (произвольная часть RDL). Есть гипотеза, что запрос возвращает из RDL как раз workbook -- или наоборот, размещает workbook в RDL.
4.5. сервер: часть шаблонов, находящихся на конкретном сервере федерации
4.6. мэппинг: набор отношений, которые показывают связь понятий одного [?модуля] с другим (и могут включать в себя ссылки на исполняемые команды). Я тут даже затрудняюсь сказать, какого сорта тут модуль -- ибо он может быть вообще "не местный", т.е. не из мира ISO 15926/

5. Все вышесказанное относится к наборам ID, но не labels -- поэтому нельзя говорить о "пространстве имён". Скорее уж, это "пространство концептов", conceptspace (в том числе помянутые namespaces из OWL тут тоже -- conceptspace). Речь тут идет о наборе концептов, понимаемом однозначно во всем богатстве их связей какой-то группой предметных специалистов, независимо от родного языка или предпочитаемого сленга. Все они, например, однозначно понимают шаблон-из-части-7, в этом смысле "Часть 7" тут не пространство имен, а пространство концептов.

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

6. Все вышесказанное можно реализовывать несколькими способами:
а) честно факториентированно: делать соответствующие отношения и хранить все связи. Модульность становится лишь одним из способов агрегации единиц RDL (RDI -- reference data items), и этих видов модульности может быть сколько угодно, они могут быть развиваемы по ходу дела. Модульность в таком подходе честный first class object. Платить приходится резким замедлением работы, база дико засоряется.
б) нечестно, как сейчас в RDL/WIP: модульность выражать префиксами прямо в текстовой строке label -- но даже не хочется обсуждать, почему это так ужасно.
в) модульность делать зависящей от реализации, т.е. дополнить число предписанных для thing атрибутов-в-смысле-части-2. И операции выводить в интерфейс (иметь их "в коде", а не "в базе").