SysMoLan Studio

[ailev]

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

Comments

[vvagr]

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

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

[ailev]

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

[vvagr]

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

[ailev]

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

[fractaler]

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

[fractaler]

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

[justy_tylor]

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

А после рассмотреть эти модели с позиций предшествовавших инструментов и стандартов (включая и проект .15926), чтобы понять, почему они там непредставимы (или представимы с существенным неудобством и когнитивным/машинным boilerplate). Иначе ошибки прошлого будут повторены опять и снова.

[ailev]

Конечно. С двумя замечаниями

[justy_tylor]

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

А быстрый мэппинг от модели к картинке можно поначалу устроить через Graphviz. Боксики, стрелочки и градиенты настраиваются буквально на любой вкус.

[ailev]

Нужно определиться, что такое "модель", ибо в Archi и многих моделерах "модель" это просто всё то, что лежит в базе данных, а диаграммные представления и аспекты по факту не различаются. На деле же -- есть "прожектор" (там в кучу свалены все понятия и связи), аспекты/view, созданные и отфильтрованные по viewpoints, и собственно "отображаемое view" (тексты или разные диаграммы). И обсуждение того, как же называются и где лежат те синтаксические правила, которые делают "отображение view на подходящем медиа в подходящей форме" -- то самое MVVC со связыванием данных

[vit_r]

Для создания языков нужны лингвисты.

[justy_tylor]

Только единожды за историю была ситуация, когда лингвист написал хоть как-то жизнеспособный язык программирования. Увы, результат оказался весьма write-only на проектах больше "админского скрипта". Статьи, которые Ларри написал в процессе разработки Perl 6, намного интереснее, чем сами новые и старые версии Perl.

Для понимания и создания языков программирования полезно знакомство с материалами лингвистики и когнитивной лингвистики. Но помимо этого нужно хорошо понимать предметную область. Например, так: https://justy-tylor.livejournal.com/252880.html

[vit_r]

"Нужны" - в смысле "в команде", а не "дать на откуп".

[justy_tylor]

В команде лингвист не требуется. Вот консультации кого-то уровня Хомского или Лакоффа могут быть полезны. А вузовские обезьянки без собственных разработок - нет.

[alexander_mikh]

По опыту построения "Architecture as code" и ковыряния с Archi - технически все не так сложно

[ailev]

Абсолютно согласен, примерно так и думаю. Любой моделер сам по себе должен втыкаться с систему версионирования (где хранятся результаты моделирования и другими моделерами тоже) и систему управления изменениями (issue tracker). У меня об этом большой комплект статей был про студии -- https://ailev.livejournal.com/1280626.html (он есть в списке "литературы", и там внутри по ссылкам всё подробней прописано).

[alexander_mikh]

да, я это все прочитал поэтому и откоментировал: мое предложение сместить точку обсуждения и первоначальной работы с IDE/Jupyter/VS code/Eclipse на: это средство автоматизации архитектуры, "настройка" над гитхабом, которая живет в начале жизненного цикла. Моделер должен не втыкаться в трекер и систему версионирования, а возглавить.

[ailev]

Ну, можно и так сказать, про "возглавить". Собственно примерно это я и говорю чуток другими словами в более позднем, чем комментируемый текст тексте "онтологии и SysMoLan", в пункте, начинающемся со слов "Но можно пройти на шаг дальше и научиться трассировать схемы..." -- https://ailev.livejournal.com/1449992.html