Обсуждение

"Моделер этой системы "из коробки" должен поддерживать ведение системных холархий (breakdown structures: system, product, work, etc. -- в соответствии со стандартом IEC81346) и описания входящих в них систем, в то же время предоставляя возможность для верхнеуровневого (архитектурного) описания систем и подсистем, входящих в эти холархии в соответствии со стандартом ISO42010. " Хотелось бы понимать - что значит "описания входящих в них систем" и "предоставляя возможность для верхнеуровневого (архитектурного) описания".

И второй важный вопрос - должна ли первая версия кроме холархий поддерживать классификаторы. Я утверждаю что должна. И тогда вопрос - на каких классификаторах верхнего уровня (онтологиях или онтиках) основываться? Означают ли ссылки на IEC81346 и 42010 что просто из этих стандартов тупо берутся списки объектов, и используются как типы для объектов, создаваемых в моделлере?

Для начала хорошо бы формально описать модель. А лучше несколько. На чём угодно - JSON, S-expressions, Python, на любом придуманном прямо сейчас псевдо-языке. Как цель, для чего должен быть удобен этот SysMoLan. А после рассмотреть эти модели с позиций предшествовавших инструментов и стандартов (включая и проект .15926), чтобы понять, почему они там непредставимы (или представимы с существенным неудобством и когнитивным/машинным boilerplate). Иначе ошибки прошлого будут повторены опять и снова.

Описания входящих в них систем -- это разные view, описывающие систему на том или ином уровне системной иерархии. Я просто уточнил, что для первой реализации мне было бы достаточно иметь архитектурные view уровня детальности как в SysArchi (а не какие-нибудь view трёхмерных моделей с моделями для метода конечных элементов из САПР). Но редактор таких view хотелось бы иметь "из коробки", сразу после редактора разбиений. То есть хотелось бы прямо управлять конфигурацией (разбиения) и моделировать архитектуру как-то более детально и удобно, чем просто указывая разбиения.

Вот я не уверен, что мы можем обойтись лишь is_a и is_part_of (это пахнет "семантическими сетями" из далёких 80-х, я ещё в середине 80-х делал моделер с такими двумя типами отношений). А какую онтику вообще брать на верхнем уровне, нужно обсуждать отдельно. Опыт ведь подсказывает, что тупо взятые из стандарта онтики оказываются потом кривыми, и мало что добавляют, кроме фразы "соответствуют стандарту".

Конечно. С двумя замечаниями: -- ошибки в языке всё одно будут сделаны. -- поскольку текущая команда нацелена существенно на учебные применения и мечтает о каких-то графических view "для менеджеров", то представимость моделей и ужасы реализации при всех заявлениях о текстовой части будут проверяться на графических view. И мечта о полноценном языке моделирования тут может сильно скукожиться. Архитектурно это самое сложное: чисто текстовый инструмент реализовать не дадут, а графическое представление может убить проект с самой расшикарной формальной моделью. Меня это пугает больше всего. Но акцент на моделировании "для людей" (человек как интерпретатор модели), а не на мэппинге (компьютер как интерпретатор модели). Хотя компьютерные преобразования модели, конечно, предусматриваются "из коробки". Я бы, конечно, тоже формально описывал модель сначала (язык SysMoLan), а о том, как будут выглядеть графические view в Editor и как реализацию новых view описывать на Platform, обсуждал потом. Пока я лишь помню, что описать какую-то систему с предприятием на архитектурном самом верхнем уровне в ArchiMate можно (несмотря на невероятную онтологическую кривость тамошней только относительно формальной модели -- кривости указаны, например, в материалах по SysArchi), а в .15926 что-то описать архитектурно было запретительно трудно -- и механика с паттернами не помогала, паттернов было слишком много, и они были слишком формальны. Онтологически корректные модели никто не мог моделировать, а .15926 онтологическую кривизну не поощрял. Так что "уровень онтологичности языка" тут обсуждаемая штука. Ну, и накопилось некоторое количество идей в ходе разработки SysMoLan (там ведь много чего в комментах раскидано в постах 2015 года), их нужно достать в связи с новыми вводными данными -- уроки прошлых проектов были ещё свежи в голове. Тут ещё проблема в том, что формальную модель сразу можно было бы писать на Julia (использовать ли тамошние графовые пакеты, универсальные языки запросов и т.д. -- открытый). Но Julia и тамошнюю экосистему толком пока никто не знает из разработчиков. Я бы прежде всего опыт Modia (Modelica на Julia) изучал там, хотя этот опыт очень специфический, конечно.

Одна модель может иметь несколько диаграммных представлений для различных аспектов - здесь про состав, там про время и события, etc. Даже если основные (потому что инвесторы?) стейкхолдеры хотят учебных картинок, всё равно придётся разбираться с цельными моделями. А быстрый мэппинг от модели к картинке можно поначалу устроить через Graphviz. Боксики, стрелочки и градиенты настраиваются буквально на любой вкус.

Нужно определиться, что такое "модель", ибо в Archi и многих моделерах "модель" это просто всё то, что лежит в базе данных, а диаграммные представления и аспекты по факту не различаются. На деле же -- есть "прожектор" (там в кучу свалены все понятия и связи), аспекты/view, созданные и отфильтрованные по viewpoints, и собственно "отображаемое view" (тексты или разные диаграммы). И обсуждение того, как же называются и где лежат те синтаксические правила, которые делают "отображение view на подходящем медиа в подходящей форме" -- то самое MVVC со связыванием данных. В Julia народ радуется не graphviz, а штукам типа http://nbviewer.jupyter.org/github/JuliaTeX/TikzGraphs.jl/blob/master/doc/TikzGraphs.ipynb -- но людям очень хочется сразу иметь что-то типа yEd плюс возможность редактировать граф текстом. Я сам бы тоже сначала делал картинки только в одну сторону, а не в две, в стиле nroff/troff (как в TikzGraphs и GraphViz). Ещё в Julia есть графовый движок. А у NVIDIA есть штатная библиотека разгона графовых операций на GPU. Но это в сторону промышленных применений и графов с сотнями тысяч нодов. Текущий же разговор идёт в учебные применения, где нужно нарисовать три десятка нодов, но удобно и красиво. И часть народа просто не понимает, что слово "нарисовать" тут уже из синтаксиса, ибо есть вариант и "написать текстом в языке".

Первое - не техническая проблема. Людей нельзя учить ошибочному "вот первая диаграмма, на которой отдельная модель, а вот вторая, на которой другая, а потом где-то на странице 153 замечание, что Шарик на первой это то же самое, что Шурик на второй" даже в качестве, хм, "упрощения". Нужны viewpoints. Я бы в такой ситуации объяснил стейкхолдерам, к каким печальным последствиям ведёт отсутствие viewpoints для качества образовательного продукта и последующего бизнеса. А вот с Julia проблемы уже технические. За пределами числодробильни там практически нет экосистемы. Пользовательская аудитория UI-библиотек для веба или десктопа ничтожно мала, что сказывается на доступности и стабильности. Основной деятельностью команды, в такой ситуации, может стать починка или переписывание с нуля тех библиотек для Julia, которые "казалось бы есть".

"Вот я не уверен, что мы можем обойтись лишь is_a и is_part_of" А можно пример, где нужно ещё что-то, кроме "is"?

"Вот я не уверен, что мы можем обойтись лишь is_a и is_part_of" А можно пример, где нужно ещё что-то, кроме "is"?

ISO 15926-2, там довольно много отношений в базовых 200 понятиях. ArchiMate 3.0, там десяток типов стрелочек.

Да, так вот можно хотя бы 1 (конкретный) пример "со стрелочками"/отношениями, который невозможно представить без стрелочек, используя только "is"?

Причина-следствие, например.

Как вариант: "Причина" имеет синоним - "Вызыватель следствия". Например, "Сильный ветер" -> "Вызыватель поломки деревьев" -> "Вызыватель следствия". Также, "Сильный ветер как причина поломки деревьев" -> "Сильный ветер". -> = "is".

Онтологи так не рассуждают обычно. Поглядите учебники онтологии, там это подробно.

"Поломка деревьев" -> "Результат сильного ветра" -> Результат

А "Вам шашечки или ехать?"

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

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