Roadmap софта .15926

Jun 07, 2011 14:26

Сегодня утром vvagr доложил о .15926 на заседании POSCCaesar Association. Вот кратенькое содержание его доклада (сам доклад я не слышал, но перескажу. Понятно, что без примера ничего непонятно, но уж лучше так, чем молчать еще месяц):

Софт .15926 планируется в двух поколениях:
-- первое поколение "плагинного IDE" (IDE, плагины к нему, плагины плагинов и т.д.), активная разработка в 2011г.
-- второе поколение архитектуры language workbench (поддержка расширяемого набора DSL), активная разработка в 2012г.

Далее всё будет про первое поколение.

1. Софт .15926 состоит из следующих модулей:




IDE, в ближайшей же версии называемое Editor, в котром можно выделить:
-- семантическую сеть (классы, отношения, индивиды по Части 2, определения и инстансы шаблонов по Части 7, метаданные по Части 6)
-- экранный конструктор шаблонов, позволяющий не только редактировать старые, но и создавать новые шаблоны
-- функция поднятия шаблонов в семантическую сетку классов и отношений Части 2

2. Editor умеет читать:
-- OWL части 8, в вариантах как файла, так и фасада Части 9
-- Iring RDF файлы
-- PCA RDL OWL файл (который выкладывается на вебсайте POSCCaesar каждую ночь)
-- определения частей 2 и 7 (в OWL, читаются однократно)

Editor умеет экспортировать:
-- OWL Части 8, в варианте файла и фасада Части 9

3. Editor поддерживает мэппинг при помощи следующих компонент:
-- builder: это конструкции в Python, описывающие создание семантической сетки на основе каких-то уже имеющихся значений переменных Python
-- loader: это конструкции в Python, поддерживающие чтение (загрузку) каких-то внешних структур данных из файлов или API (таблиц Excel, ODBC, бинарных форматов, XML-форматов, хитрых форматов разных САПР и т.д.) в переменные Python.

upmapper -- пользовательский модуль на Python, который читает какой-то формат данных при помощи конструкций loader и затем записывает прочитанное в семантическую сетку посредством конструкций builder. В одном mapper можно использовать множество разных loaders (т.е. одновременно читать данные из двух разных форматов). Сколько разных задач конверсии данных в нейтральный (т.е. ISO 15926) формат решается, столько и модулей upmapper.

-- scanner: это конструкции в Python, поддерживающие выборку каких-то фрагментов (паттернов) семантической сетки в переменные Python
-- writer: это конструкции в Python, поддерживающие запись из переменных Python в какие-то файлы или API (по сути, это те же форматы, которые использует для чтения loader: таблицы Excel, ODBC и т.д.). Сколько разных форматов поддерживается, столько и вариантов scanner.

downmapper -- пользовательский модуль на Python, который извлекает какие-то фрагменты семантической сетки при помощи конструкций scanner и затем записывает в требуемых форматах конструкциями writer. В downmapper можно одновременно вести вывод в несколько разных форматов (используя один scanner и множество разных writers). Сколько разных задач конверсии нейтрального формата в пользовательские форматы решается, столько и будет разных downmapper.

4. В июне будет выпущен открытый код:
-- Editor (пока без подъема шаблонов, но с "деревянным" конструктором шаблонов)
-- builder
-- .xls loader
-- пример upmapper для методики характеризации требований (ISO 15926 offsite)
-- описана плагинная архитектура

5. Далее разработка ведется сообществом:
-- Editor развивается централизованно (аналитические диаграммы шаблонов, подъем шаблонов и т.д.)
-- централизованно добавляется scanner
-- разные loaders и writers для хитрых форматов данных пишутся по потребности сообществом (теми, кто хорошо знает эти форматы)
-- upmappers подразумевают серьезную онтологическую (а не только программистскую) работу. Они готовятся для каждого проекта отдельно, и подразумевают наличие модельеров данных, хоть как-то понимащих Python. То же относится к downmappers. Если кто-то хочет попробовать себя в роли такого модельера данных (в Москве), пишите мне письма.
-- отдельно решается вопрос о способе поддержке фасада Части 9

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

7. Если Ктулху не будет категорически против, то Новый Год начнем с размышлений про архитектуру второго поколения, language workbench.
Previous post Next post
Up