Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Category:

Крокет (Сквик) вместо ГосМастера, Protege и ResearchCYC

Следуя своей краткой программе работ (http://ailev.livejournal.com/461813.html) я как-то прошелся по ее пункту 1 (понять, какое мышление нужно поставить организатору) -- и пришел к выводу, что организатору в части планирования/программирования правильно поставить мышление, схожее с программистским. Тут нужно добавить, что организатору также нужно поставить мышление в части работы с людьми -- но это пока оставим на будущее. Можно считать, что какие-то фиксации содержания менеджерской части курса прошли и в ходе серии из трех семинаров, в которых обсуждался менеджмент 21 века.

Теперь согласно пункту 2 нужно выбрать моделлер, и зафиксировать предметную область (она же -- education knowledge, содержание образования) в виде онтологии -- формализации концептуализации. Далее привожу пунктиром очень непроработанное рассуждение, с которым я намерен поработать некоторое время:

1. Текущий тренд -- это оформление содержания образования в онтологии, используя OWL. Собственно, для этого сгодился бы любой инструмент концептуального моделирования -- хоть ГосМастер, хоть ResearchCYC. Для терминологических систем чаще всего сейчас используется Protege (например, http://protege.stanford.edu/conference/2003/Ameen_Abu-Hanna.pdf).

2. Но нужно учесть, что основные концепты в организации деятельности могут и должны быть поддержаны софтом -- этот софт должен выполнять следующие функции:
а) быть учетной системой, показывающей текущее и плановое состояния выполнения работ в организации (расчеты расписаний и буферов) -- issue tracking and planning
б) быть учетной системой, показывающей приближение к цели (расчеты throughput) -- для бизнес систем это throughput и constraint accounting
в) быть системой обмена сообщениями между членами организации -- это wiki, блоги и комменты к issue tracking
Софтовая система (я называл ее ранее ПраксОС) должна быть вполне учебной (фиксировать основные понятия, быть средой, в которой решаются большинство учебных задач и ведутся учебные проекты) -- но быть при этом не игрушкой, а вполне рабочей системой.
Тем самым задача концептуального моделирования становится сложнее:
а) концептуальная модель должна соответствовать учебному плану
б) понятия концептуальной модели должны быть "поддержаны учебным софтом" (что бы это ни значило).

3. Современный подход к программированию позволяет так или иначе выражать предметное знание -- идет ли речь о domain specific languages и поддерживающих их стилях программирования, или все ограничивается классическим объект-ориентированным подходом, понятиям для описания предметной области соответствуют понятия программы. Это означает, что при соответствующих процедурах кодирования и специфицирования программ, можно надеяться, что в программе содержится и искомая нами онтология.

4. Онтология (в разных ее вариантах -- в том числе метаданные, в том числе верхние уровни спецификации программы) может быть "вытащена" в удобном для восприятия виде из программы, если соответствующая система программирования умеет смотреть на свои программы. Так, в смолток-системах существует Refactoring Browser, созданный специально для того, чтобы было удобно изучать тексты программ и проводить с ними различные необходимые для рефакторинга преобразования. Вполне возможно создание Ontology Browser по его мотивам.

5. Похоже, что для Ontology Browser можно использовать модель интерфейса Tweak (объединение модели интерфейса непосредственного манипулирования объектами Morphic и разведения рендеринга и представления данных MVC -- model-view-controller), с учетом того, что объекты в этой модели имеют роли и соответствующие им "костюмы". Для презентации на экране таких объектов можно использовать алгоритмы "самоупорядочения" (скажем, объекты, соответствующие подразделениям организации, собирались бы в необходимый граф структуры организации примерно так же, как в примерах из Сквика буквы собираются в строки и форматированный текст).

6. Тем самым я нагло говорю, что при соответствующем развитии системы программирования никакого моделлера не нужно, а онтологию можно будет выдирать (в том числе при особой потребности -- и в формате OWL) прямо из текста программы. Поэтому как можно быстрее нужно приступать к онтологической работе, что в данном случае будет означать проектирование и программирование программной системы.

7. В качестве выбора программной системы (метаметаонтологии) я бы предложил использовать смоллток в варианте Сквик-Крокет:
а) перспективная живая и быстроразвивающаяся свободная смоллток-система, в которой доступно огромное количество языковых библиотек для Сквика
б) это p2p-система, со встроенными алгоритмами координации между инстансами
в) в ней реализован интерфейс Tweak

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

9. Поэтому одно из первых рассмотрений должно быть стилевое: каким образом работы, участники организации, регламенты, оргструктуры и расписания отражаются в программе. Организационная метаонтология (интересующая нас на этом проходе) -- воплощается в софте на языке метаметаонтологии объектов и сообщений (т.е. на смоллтоке). Онтология конкретной организации -- тут вопрос, получается ли она конкретизацией софта, или далее лежит в данных. Похоже, что в предлагаемом стиле эту онтологию конкретной организации правильно вписывать прямо в текст софта (для класса Организационное_звено порождая Отдел_доставки и Производственный_блок). Интересно понять последствия такого стиля программирования -- с учетом многочисленных заверений от пробовавших его, что "ничего страшного, просто вам такое непривычно". Еще раз: я не предлагаю разделять программу и данные -- я предлагаю некоторые куски программы считать данными в какие-то моменты времени (они будут выступать в роли данных, например для редактирования или отображения в специализированном отчете), а в какие-то другие моменты времени для других целей эти же куски программы будут вполне себе исполнимой программой. Совсем необязательно думать при этом, что все это именно смоллток-тексты. Это могут быть и domain specific languages, отличающиеся по синтаксису от собственно смоллток-программы (хотя над этим нужно еще специально подумать -- и помнить при этом про "абстрактный синтаксис").

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

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

Дальше это все нужно подробно проработать, ибо пока я иду на "верхнем чутье". Изложенные тут идеи для меня ужасно сомнительны, но представляются достаточно безумными, чтобы оказаться верными.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 19 comments