Обсуждение

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

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

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

Добавлю от себя: поддержка поточного ввода данных Это когда можно тупо забивать табличку, а инструмент всё сам раскладывает в рамках метамодели. Что-то типа updateable view. Не сильно критично, ибо можно обойтись импортом из excel, но упрощает жизнь автокомплитом

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

Табличный ввод из каких-то шаблонов? Внешний DSL для описания модели и язык для него с традиционной IDE? Batch ввод -- это всё-таки какие-то импортёры и экспортёры (да, часто в формате экселя). А "поточный ручной ввод" в моделерах -- это как? Пример нужен моделера с типовой такой фичей, иначе непонятно.

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

> -- аннотирование объектов и отношений Да!

Хороший пример. То есть редактор форм (включая табличные формы).

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

issue tracker - лучше использовать существующие, со ссылками, по которым можно открыть модель.

Не перевод, но понимание принципов - безусловно. Для инженера полезно какое-то понимание Части 2 на русском, а вот RDFовские s-p-o - уже точно нет. Так что термин "локализация" надо уточнить.

1. Альтернативные представления модели, конечно. Я охотно верю, что только графическое представление нормативно для многих и многих языков (а хоть и для Архимейта, как пример). И новичкам графическое представление крайне нравится. Но многие языки имеют разные варианты синтаксиса (даже древний EXPRESS был в текстовом и графическом вариантах, а для OMG SBVR нормативны три разных варианта). Ну, и я верю в то, что большие модели должны быть только текстовые, иначе не прорваться без экстраординарных усилий. Поэтому моделер должен поддерживать самые разные представления (т.е. быть language workbench -- внутреннее представление модели отделено от формы представления на экране и бумаге, и сами формы представления могут быть разные и описываться независимо). 2. У меня ISO 15926 у такого моделера мог бы быть под капотом, совершенно необязательно снаружи (хотя да, я и наш опыт с .15926 Editor учитывал, и хотелки к нему, и пока ещё небольшой, но опыт использования). А снаружи я думал бы про Архимейт-по-русски, или VDML по-русски. То есть я имел ввиду не столько возможность перевода на русский базового представления (Части 2, или MOF -- мета-метамодели), сколько представлений мета-модели (т.е. "палитр" в редакторах диаграмм, или русскоязычных идентификаторов в текстовых языках), которые делаются на их основе. Хотя многие люди работают с англоязычными мета-моделями (типами) и русскоязычными идентификаторами в моделях (экземплярами -- которые являются в том числе и сами классами предметной области пользователя, например, в архитектуре предприятия), и им всё ОК.

Можно и существующие, но нужно иметь возможность кликнуть по модели, и получить меню issue tracker (все issue для этого фрагмента модели, порождение нового isseu и т.д.). Сбоку этот issue tracker, или встроенный -- это уже не так важно. Важно, чтобы был (свой или внешний на интерфейсе).

А можно уточнить, что именно моделируется? По описанию похоже на "универсальное моделирование чего угодно", но я не уверен, можно ли настолько обобщить языки и инструменты моделирования. Ограниченные определенной предметной областью инструменты обычно удобнее в изучении и использовании.

Если взять работы OMG, то на базе MOF огромное количество языков там наплодили, и моделируют самое разное -- от технических систем (SysML) до бизнес-моделей (VDML). Так что я бы не считал, что речь идёт о "предметной области", скорее уж о классе формализаций. Конечно, такой моделер будет работать с каким-то классом формализаций. А дальше можно брать этот моделер, и чекать его по этому списку. Если есть конкуренты -- чекать и конкурентов тоже, смотреть, что получилось. Вот возьмите, например, какой-нибудь Archi и модуль архимейта для BiZZdesignArchitect, и прогоните по списку. Впечатлитесь разницей. Или, например, .15926 Editor и iRINGTools.

Метод моделирования, к примеру discrete event simulation или agent-based simulation.

А подробнее? Вот у вас какой-нибудь UML-моделер классический. Или Archi. Где там эти симуляторы?

Хм, Вы говорите о static deterministic моделировании. Упомянутые мной методы относятся к dynamic stochastic моделированию. Стандартные UML-моделеры такие методы моделирования не поддерживают.

Ну да, у меня в голове были "моделеры данных", а не "математические модели". Поглядел список: ничего не мешает его применить и к сравнению каких-то SystemDynamics моделеров или Modelica моделеров...