September 11th, 2010

2021 год
  • ailev

Roadmap .15926

Очень грубый Roadmap

Стадия 0: Редактор схемы
a) engine.15926 -- поддержка целостности, версионирования и т.д. Работает над каким-то хранилищем (например, Sesame/pySesame или AllegroGraph). Поскольку хранилище мы (пока?) не разрабатываем, то его и не пишем. Поддерживает разворачивание шаблонов и прочую ISO 15926-специфику.
b) editor.15926 -- редактирование схемы 15926, как обсуждалось в последних постингах (http://community.livejournal.com/dot15926/7346.html, http://community.livejournal.com/dot15926/6915.html).
с) printer.15926 -- табличные/текстовые отчеты по схеме (возможно, со вставкой каких-то базовых диаграмм окрестности 1 от сущности). См. пример мастера отчетов из ОргМастера в качестве интерфейса -- http://bigc.ru/publications/bigspb/pic/modern_teh_org_14.gif
d) sandbox.15926 -- интеграция в федерацию песочниц (iRING и JORD), работа со внешними схемами (запросы, импорт-экспорт).

Ключевая user story: разработать модель данных (в том числе с шаблонами), распечатать ее для изучения, и послать ее в JORD. Есть ощущение, что это можно получить до Нового Года, если правильно специфицировать модули и разделить работы.

Стадия 1: Сервер (к сентябрю 2011, т.е. уже через год)
а) багфиксы и мелкие доделки к (engine, editor, sandbox).15926
b) server.15926 -- сервер данных, а по сути SOA-платформа (придется по-взрослому интегрироваться с каким-то инструментарием SOA, типа WSO2/Python -- все эти транспорты, идентификации, регистри и т.д., хотя и хочется избежать этой корпоративной монструозности) с веб-паблишингом (SDK задания веб-форм), контролем версий, утилитами экспорта-импорта в общие (excel, UML и т.д.) форматы и SDK утилит экспорта-импорта (то есть mapping editor, scope editor из iRING -- тут). По сути должна получиться сравнимая с enterprize Brige, AVEVA Portal, ENOVIA и т.д. инструментальная система (минус все прикладные моменты, связанные с инженерными схемами и адапторами к ним -- но все SDK для их обслуживания и построения).
c) system.15926 -- настройка server (задействие SDK) на работу с инженерными данными: уточнение веб-форм, "гладкий" вызов разных viewers третьих разработчиков, адапторы к САПР и т.д. Ключевая user story: положить взаимосвязанные модели из сотни источников в сотне форматов, отследить версии. Найти и посмотреть результаты через веб.
d) catalogue.15926 -- все, что нужно для каталога продукции. Ключевая user story: получить данные каталога от множества поставщиков (через веб, с промежуточным утверждением), найти данные, отдать эти данные в САПР или ERP через адаптор).
e) [PraxOS -- уточнение DSL-расширений, OIM и т.д.]

Стадия 2: Метод (осень 2011 -- и весь 2012)
a) IDE.15926 -- IDE с language workbench, позволяющая 1. определить различные DSL и 2. редактировать Схему (и данные) путем их использования.
b) перевод editor.15926 на технологию language.15926
с) render.15926 -- рендер (по факту, это рендеринг отчетов, которые получаются из диаграмм в IDE.15926, но которые затем
c) organizer.15926 -- все, что нужно для организации деятельности (ISO 24744 и каталог методов с соответствующими DSL для создания организационной модели и workflow).
d) search.15926 -- семантический поиск, семантический мэппинг и прочие игры с языком
e) rules.15926 -- business rules и прочая предметная логика с выходом на 15926L (программирование бизнес-логики в ISO 15926)

Стадия 3 Продукт (весь 2013)
a) перевод (editor, system, catalogue).15926 и сделанных на их основе приложений на новые коды и технологии (language, organizer, search, rules).15926 -- т.е. добавка DSL, а также workflow по итогам разработок третьей стадии.

Конечно, все это много раз может потом поменяться, но пока это ничему из сказанного ранее не противоречит. Сроки и даты -- с потолка.

Пара заметок к Стадии 0:

1. Пример картинки "нортон БигМастера" -- http://bigc.ru/instruments/bigmasterpro/demo/manual/om_profi/pic/sb_72.png, http://bigc.ru/instruments/bigmasterpro/demo/manual/om_profi/pic/sb_48.png. В принципе, там на сайте раздают и учебную (ограничение: в классификаторах допускается не более 180 понятий) версию, есть и вся документация (откуда я и взял эту страничку). Мне кажется, что опыт этой системы обязательно нужно использовать, там много интерфейсных находок. Вот, например, как там вводят жизненный цикл (http://www.hr-portal.ru/img/uz/o/pic_3_type_models.gif) -- интересно, что показывают они потом этот ЖЦ в виде Excel-таблички, а не графика.

2. Нужно сразу делать I18N и L10N, я видел уже много проектов, которые обжигались на этом (т.е. делать сразу английский и русский интерфейсы).

3. На стадии 0 необязателен тонкий клиент, это вполне может быть Scintilla+wxPython.

4. Какие-то формы UNDO весьма и весьма желательны. Мой опыт показывает, что редакторы без UNDO невыживабельны, а UNDO требует учета в архитектуре сразу же.

5. Допускаю, что стадия 0 -- однопользовательская.

6. Я постарался все разбить на какие-то куски, которые можно было бы делать в разных местах силами разных людей/команд, и которые были бы связаны через API. Ежели я чего-то недоучёл, поправьте.

7. Мэппинг ушел в стадию 1 (мы не iRING дублируем), но вот иерархия sandbox должна быть сразу.

8. Реализовать ли OWL-ограничение или полный ISO 15926 -- пока не знаю. Это нужно спросить у модельеров (их мнения тут пока разделяются, но позиция "готовы терпеть ограничения ради совместимости с OWL" пока выигрывает). Но вот шаблоны в соответствии со стандартом реализовывать нужно, пока непонятно (ни содержательно, ни интерфейсно -- табличками?) как.