?

Log in

No account? Create an account

Entries by category: it

Open-source наконец!
Sharge
vvagr
Создание платформы .15926 в основных чертах завершено, и для упрощения разработки приложений на ней мы приняли решение о раскрытии исходных кодов редактора.

Код опубликован в репозитории https://github.com/TechInvestLab/dot15926.git , вы можете скачать архив или клонировать репозиторий по ссылке. Инструкции по запуску и некоторую дополнительную информацию можно найти в вики проекта https://github.com/TechInvestLab/dot15926/wiki/Starting-the-software---Dependencies

Код раскрыт под лицензией GNU Lesser General Public License версии 3 https://www.gnu.org/licenses/lgpl.html . Это означает, что он может быть использован в том числе как часть проприетарного и/или коммерческого софта. Разумеется, мы с удовольствием примем помощь иных комитеров, готовых что-то сделать с кодом. Обращайтесь за правами.

Откомпилированные версии (стабильная 1.43 и экспериментальная 1.5beta) могут быть по-прежнему скачаны с http://techinvestlab.ru/dot15926Editor вместе с пользовательской документацией. На сегодня опубликованный код соответствует версии 1.5beta.

Выпуск версии 1.5beta редактора .15926 Editor
Sharge
vvagr
http://techinvestlab.ru/dot15926Editor15beta/


Всё новое и интересное в этой версии связано с образцами (patterns).

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

Редактор позволяет импортировать образцы из базы данных онлайнового редактора TIP Manger, используемого группой IIP. При этом проводится верификация и выявление высокоуровневых образцов моделирования.

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

В этой версии можно ознакомиться также с тремя новыми способами представления и визуализации данных ISO 15926:

- Открытое расширение, позволяющее превратить редактор в сервер Связанных Данных (Linked Data) с семантическим поиском. При этом управление шаблонами веб-страниц, представляющих данные для изучения человеком, осуществляется через определяемые пользователем образцы.

- Основанный на образцах экспорт в табличный формат для простых отчётов по RDF-данным.

- Простейший графический экспорт для представления топологии технических систем в формате .xgml, пригодном для просмотра удобными и свободными графическими редакторами.

Редактор поддерживает продемонстрированный ранее в альфа-версии доступ к API внешних баз данных и сервисов, учебный адаптер к Google Maps API (https://github.com/ailev/anird/wiki) иллюстрирует эти возможности.

Кроме того, редактор позволяет теперь полностью работать с файлами в формате Turtle - поддерживаются и чтение, и сохранение файлов .ttl .

Мы выпускаем бета-версию в основном потому, что ещё не все новые свойства и возможности отражены в документации.

Хакатон - веб-движок
Sharge
vvagr
В репозитории https://github.com/ailev/anird опубликован код, запускающий локальный веб-сервер и конструирующий веб-страницы по семантическим данным, вытащенным из внешнего источника.

Как запустить вебсервер и посмотреть пример - написано на странице https://github.com/ailev/anird/wiki/WebPresentationSpecEng (англ.).

Более подробной документации пока не ожидается, смотрите пример и читайте документацию фреймворка Flask.

Почему ISO 15926
2019
ailev
За последнюю пару лет ситуация с объяснением того, почему интеграционные (федеративные, 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 и программного обеспечения.

Архитектурные языки, архитектурные подходы (frameworks), UML profiles и 4D extensionalism
2019
ailev
DoDAF 2.02 (Department of Defence Architecture Framework Version 2.02, принят в августе 2010г., http://cio-nii.defense.gov/sites/dodaf20/index.html) -- это обязательный для использования архитектурный подход министерства обороны США. Во всех военных проектах США используют предопределенный набор тематических групп описаний.

Этот набор описаний выражен в терминах метамодели MD2 (http://cio-nii.defense.gov/sites/dodaf20/DM2.html), so the architectures can be integrated, analyzed, and evaluated to mathematical precision. Эта метамодель представляет собой ограниченный словарь, в терминах которого описываются модели этой архитектуры. Фишка в том, что логический уровень этой метамодели представляет собой UML-профиль для IDEAS, которая является 4D upper ontology (http://cio-nii.defense.gov/sites/dodaf20/Ontology1.html), ближайшим родственником Части 2 ISO 15926.

Недавно была выложена книжка Chris Partridge "Business Objects: Re-Engineering for Re-Use", 2000г., с изложением основных идей технологии BORO (http://www.brunel.ac.uk/%7Ecssrcsp/BusObj.pdf). Именно технология BORO и легла в основу 4D онтологии IDEAS. В этой книжке педантично расписано (хотя и не в терминологии ISO 15926), какие проблемы решаются переходом от описаний в объектно-атрибутивной парадигме к логической (классы), и почему нужно было вводить 4D. Я бы считал, что для промышленных онтологов это обязательное чтиво, там есть множество объяснений, до которых не снисходят авторы текстов по ISO 15926. Конечно, при этом не нужно забывать, что тамошняя онтология совсем не похожа на ISO 15926, и учиться нужно не представленной там онтологии, а излагаемому в книжке куску философской логики.

А теперь критика DoDAF 2.02:
1. IDEAS там появилась из понимания, что архитектурной информацией нужно обмениваться между разными архитектурными системами. Идея интеграции (в данном случае архитектурных) данных неминуемо влечёт вызов онтологических духов, а современные онтологические духи всё чаще и чаще выбирают 4D, чтобы не запутаться в отслеживании превращения гусеницы Дуси в куколку Дусю, а затем и бабочку Дусю.
Мы вполне могли бы выбрать ISO 15926 для тех же целей: интеграции архитектурной информации, в том числе информации enterprise architecture. Но мы лучше выберем ISO 15926 не для задач outside (как была выбрана модель IDEAS), а для задач offsite и inside. Я пока не чувствую острой необходимости перегонять модели ARIS в модели DoDAF или ToGAF. Мне бы эти модели разрабатывать, и вряд ли с использованием этих архитектурных подходов. Тем не менее, я бы использовал ISO 15926 непосредственно в качестве метамодели: so the architectures can be integrated, analyzed, and evaluated to mathematical precision.

2. Идея сделать UML-профиль для ISO 15926, чтобы работать с UML-редакторами, мне представляется сугубо неправильной. Тут два возможных варианта:
-- поступить, как в BORO, и вместо диаграмм Части 7 придумать богатый графический язык для выражения ISO 15926 (в том числе расширяемый микротеориями, задающими "профили", как в UML)
-- сделать свой "похожий на UML" графический язык с онтологическими расширениями, пройдя по пути OPML (http://www.cesames.net/fichier.php?id=370, http://www.cesames.net/fichier.php?id=371).
-- считать, что будет много разных DSL, и принципиально не заморачиваться одним каким-то базовым графическим или текстовым языком. Много-много projectional editors, показывающих в разных DSL кусочки общей семантической сетки. И сосредоточиться на придумывании этих DSL для разных views. Пока склоняемся к этому варианту, ибо остальные являются частными случаями этого.

3. Что касается использования IDEAS, то два уровня неадекватности (UML-профиль, а поверх него давно критикуемый жестко определенный набор методов описаний собственно архитектуры) полностью закрывают возможные достоинства использования IDEAS -- я писал об этом механизме нивелирования достоинств технологий неудачностью использующих их приложений тут: http://ailev.livejournal.com/936771.html.
Мы тем самым должны отойти от жесткой заданности набора методов описаний, но дать все необходимые механизмы для ситуативного его построения (см. http://praxos.livejournal.com/12468.html).