Еще раз о планах релиза 2.3 PraxOS

Jan 13, 2010 00:53

Два дня подряд семинарили с vvagr у нас в офисе по поводу того, что такое PraxOS, и как его получить -- и даже нарисовали какую-то версию 0.1 карты действий и результатов (что, впрочем, никак не поколебало плана, изложенного в первом постинге praxos, http://community.livejournal.com/praxos/455.html -- каковой план продолжает потихоньку выполняться). Итоги этих посиделок:

1. Выделены базовые методы PraxOS:
-- ситуационная инженерия методов (ISO 24744, BPMN 2, STT, DEMO).
-- онтологическая инженерия (ISO 15926-2,7,8). Сюда же -- терминология (SBVR, SKOS).
-- нотационная инженерия (http://ailev.livejournal.com/546301.html, http://ailev.livejournal.com/548756.html, http://ailev.livejournal.com/549681.html, http://ailev.livejournal.com/613067.html -- хотя это только одна из школ, наверняка есть под другими названиями другие школы. Уж графическими языками кто только не занимался, и на тему выразительности графического представления наверняка должны быть работы.)

Эти методы должны быть применены, чтобы получить PraxOS. Проблема та же, что в получении любого "компилятора языка, написанного на самом этом языке": PraxOS нужен, чтобы получить эти методы, а эти методы нужны, чтобы получить PraxOS.

Еще одна проблема: все эти методы части довольно слитного куска знания, назовем это условно методологией. Поэтому выделение именно этих трех составляющих довольно условно.

2. Определены базовые роли для сценариев использования PraxOS (напомню: use cases являются основным методом получения функциональных требований):
-- создатель ядра PraxOS (методологи-онтологи-логики-языковеды, они же писатели базовых методов; программисты -- в свою очередь писатели компиляторов-редакторов, и писатели веб-сервисов на базе OWL/RDF; а еще комьюнити менеджеры комьюнити всех остальных ролей). Эти люди напишут Софт PraxOS и начальные методы, при помощи которых потом заработает все остальное.
-- писатели методов (методисты-учителя-ученые/инженеры), которые будут пополнять репозитарий методов PraxOS, используя Софт PraxOS как композер методов.
-- ученики методов (которые используют репозитарий методов и привернутые к этому репозитарию справочные, обучающие, экзаменационные/рейтинговые и прочие приложения, не требующие method enactment), которые будут использовать Софт PraxOS как браузер методов.
-- пользователи методов (которым нужен именно method enactment для их конкретного проекта), которые будут использовать Софт PraxOS в целях управления жизненным циклом/процессом/проектом в их ситуации.

Вполне возможно, что прямо сейчас нужно применить метод персонажей.

3. Софт PraxOS должен быть:
-- коллаборативным, чтобы браузить и редактировать методы могла группа. Это заодно означает, что там должно быть весьма развито управление конфигурацией репозитория методов, вполне возможно существование "сервера мира" и "сервера аватаров" и многие другие специфические свойства, важные для средств коллаборативной разработки. Возможны и дополнительные функции "социального веба" (например, поддержка определения и ведения рейтинга участников комьюнити PraxOS).
-- масштабируемым, для чего должен располагаться в облаке.
-- доступным не только для браузинга и редактирования людьми, но и для браузинга и редактирования комьютерами, с которым интегрироваться будет через фасад-ISO15926.

Технология софта пока представляется больше всего похожей на гибрид бульдога, носорога, змеи и ежа:
-- language workbench, в которой вместо AST используется онтологическое представление в терминах ISO 15926-2, а языки определяются в терминах шаблонов из ISO 15926-7,8.
-- не только многонотационность, типичная для language workbench, но и многоязычность, что подразумевает не только разницу национальных языков i18n+l10n, но и разницу в словарных комьюнити (т.е. работу с SBVR, SKOS или чем-то подобным).
-- коллаборативность real-time обеспечивается по алгоритмам, гарантирующим синхронизацию миров (например, движком Cobalt/Croquet/Teleplace).
-- социальный аспект коллаборативности задается всяческими вариантами френдований/командообразований, рейтингований, разделяемых закладок, голосовых и видеочатов и т.д.. Как это происходит с технологической стороны пока непонятно.
-- универсальность и масштабируемость гарантируется использованием какого-нибудь triple store типа AllegroGraph и веб-интерфейсами как у MatrixOne (наряду с посадкой на облако)
-- enactment подразумевает выполнение каких-то вычислений над данными (а не только редактирование, поиски и отображение). Не факт, что все эти вычисления сводятся к логическим вычислениям (хотя первым в голову приходит вычисление критической цепочки и

Смешать, взбить, подавать горячим в вечной альфа-версии.
Абсолютно непонятно, как собрать команду, способную произвести такой технологический коктейль. Зато понятно, почему до сих пор ситуация с софтом PraxOS не сдвигалась с мертвой точки.

4. Репозиторий методов PraxOS будет считаться состоявшимся, ежели он будет примерно в объеме OPFRO (1100 элементов методов) плюс еще примерно столько же. Для начала туда нужно откомпилировать, перевести на русский и отредактировать по содержанию методы OPRFO, а затем добавить заново кодированные методы TOC. Это уже будет работа комьюнити методистов-учителей-ученых/инженеров PraxOS, а не создателей ядра PraxOS.
Previous post Next post
Up