September 10th, 2010

Sharge
  • vvagr

Ideal Composer Interface

Under the cut you can see a projected interface for ideal ISO 15926 Composer. All the diagrams and names are for illustration purposes only!

It is a multi-window interface with possibility to bring out simultaneously all necessary windows to create complex Part 7 (or possibly Part 2) diagrams.

It should be possible to open:

Class_of_class windows
Class windows
Relationship windows
Class_of_relationship windows
Role windows

Probable, Individual and Relation windows (not shown).

All with the view on the same federated RDL.

In each window it is possible to browse corresponding part of the RDL as a specialization tree and edit it (modify, create entities).

It is possible to establish typing, classification and role associations between items in different windows, as shown. Composer controls possible associations and their "parameters" entered through textboxes.

Composer draws diagram as associations are established between windows.

It should be possible to show or hide: all existing associations, associations from selected items, individual associations.

In a separate window you can see a domain-specific model, in UML or tabular format, or other formats supported by plugged-in viewers.

Please tell your opinion on the usefulness of this interface and on the possibility of its implementation with not-too-exotic tools.

Collapse )
2021 год
  • ailev

Редактор схемы

По итогам обсуждения потребностей модельеров (очно с vvagr) и архитектуры удовлетворения этих потребностей (в комментах к http://community.livejournal.com/dot15926/6880.html), пришли к интересным выводам:

1. Любые "сервера" 15926 варятся из трипл-стора как суп из топора: много-много программной обвязки и утилит. Ни один промышленный сервер сейчас не поддерживает нужд модельеров. Поэтому код нужно писать самим, и срочно. Код нужен для трех типов систем:
-- сервер системы и проекта (упихнуть данные со всех САПР, систем инженерного документооборота и проектного управления, а также ERP в хранилище данных -- и провязать их друг с другом, поставив под контроль конфигурации. У поставщиков САПР такое называется PLM).
-- сервер справочной информации (RDL в частном случае, НСИ и каталоги в общем случае). Совсем другой паттерн использования.
-- каталог организационной информации (каталог методов и набор DSL для организации плюс настройка воркфлоу для разных окружающих систем). Это PraxOS.

2. В проект dot15926 попадает разработка (или выбор готовых ;) не только трипл-стор и 15926L engine над этим трипл-стор, но и language workbench. А вот композер и каталог методов -- это в praxos. (подробности в дискуссии по приведенной выше ссылке).

3. Чтобы начать работу над любым из заявленных трех типов приложений, нужно реализовать редактирование схемы данных: это задача номер ноль. Странность в том, что по-хорошему это должно укладываться как DSL представления/редактирования/отображения схемы внутрь language workbench, но ежели ждать полноценной реализации language workbench, то может быть потеряно много времени. Поэтому можно попробовать сделать "прототип номер один", который потом выкинется и заменится полноценной language workbench, а для начала будет представлять из себя "моноязыковый редактор" -- и испробовать на нём разные идеи и инструменты. Например, justy_tylor предложил использовать Python + AllegroGraph (API) + wxPython + Scintilla (wxStyledTextCtrl) -- и можно это опробовать на редакторе схемы сначала, а потом уже на полном language workbench, если понравится (и после набития шишек).

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

5. Фишка в том, что для триплетов нужно уметь показать на экране два объекта и отношение между ними. Это делают "нортон коммандеры": на одном пане дерево какой-либо таксономии/классификации с найденным на нем объектом, на другом пане дерево с другим найденным объектом, а между ними протягиваем "мышкой" отношение (задавая его тип). Потом можно поглядеть на сгенерированную диаграмму части второй -- но редактирование огромной схемы идет в терминах протягивания связей/убивания связей между двумя панами с общей таксономией (или классификаторами). Именно так реализовано редактирование большой онтологии в БигМастере, и нужно просто это повторить, это в разы быстрее, чем прокликивание мышкой в однопановых редакторах. В текстовом представлении редактирование непонятно, как реализовать -- динамически выводить кусок сетки в виде текста?! И как потом в этом тексте разобраться? Опять же: функции браузера и навигации к нужному месту оказываются первичными. На полях отображаются ошибки, спецпометки неотображенных объектов и т.д. Псевдографикой выделяются отношения к классам классов и просто классов.

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

В следующей версии -- подумать, как добавить туда темплейты.

В следующей версии -- language workbench, и тем самым возможность описывать разные DSL и рендеренги.

Делать на указанной связке Python и Scintilla (в принципе, на данной стадии это неважно -- важней понять, какие сервисы нужны модельеру, и как сэкономить его время).

Теперь нужно понять, сколько это стоит, кто это сможет сделать, и за какое время.