Обсуждение

По причине отваливающихся аддонов я предпочитаю не ставить сразу новые версии, а подождать. Хотя для FF есть тулза для тестеров, которая позволяет включать аддоны с неподходящими версиями. Поэтому если срочный выпуск ФФ, а в настроках какого-то аддона не стоит поддержка версии, то Nightly Tester Tools может спасти.

На сегодня организационные модели крутятся среди одних людей и отмоделированы в одном софте, а технические модели крутятся среди других людей и отмоделированы в другом софте. И эти миры не соприкасаются, отсюда и бардак. Вот-вот. Меня этот бардак сильно пугает. Очень уж все шизофренично, мой моск такого не выдерживает. Наверное поэтому у меня все время мысли к логикам сводятся, надо же как-то упорядочивать бардак.

Вот я сегодня по плану медитирую ровно про эту разницу софтов и связку технологического мира и организационного. Увы, традиционной связки через системы закупки и учета закупленного (EAM) не хватает: по этой связке оптимизирующего рассуждения не проведешь. А до логики или еще какого-то подхода от этого момента в рассуждениях, увы, еще далеко. Логика тут мало что поправит. Нужно понять, как PBS (plant breakdown structure) связана с WBS (work breakdown structure) -- и в этом помогают методы и софт, реализующие, например, DSM и прочие принципы аксиоматического дизайна (если речь идет о дизайне). А теперь к этому нужно прикрутить процессную модель, задачу выделения ресурсов, и организационную модель. Шарах, все это совсем разные софты, разные нотации, разные методы, и PBS в этом месте уже и рядом не стояло. Это-то и напрягает.

Чтобы заинтегрировать разнородный софт, нужно переходить на мета-уровень, т.е. делать мета-модели разных нотаций, и их как-то сопоставлять. Вот тут как бы логика и пригодилась, ибо сопоставлять нужно на концептуальном уровне, на уровне моделей, а не простых данных в реляционных таблицах. Но это мягко говоря нетривиально.

Ну да, хотя тут не столько логика, сколько онтологическая работа. Я вот прямо сейчас думаю о том, как мне выразить "отраслевую PBS" в терминах ISO 15926 (4D-онтология, сама по себе написанная на EXPRESS) и состыковать ее со словарями SBVR (тоже не сахар, подразумевающий еще и три разных нотации, включая, кстати, и common logic), а далее с BPMN+OSM -- и в каком это софте реализовывать. Вот сижу и думаю, это и есть моя работа на сегодня (а, может быть, и завтра).

К вопросу о ISO 15926 -- там тоже будущие нотации непонятны, может и common logic появиться: http://www.matthew-west.org.uk/documents/ISO%2015926-2%20Origins%20and%20possible%20futures.pdf

Онтологие - это да. Но есть загвоздка. Обычные онтологии подходят чтобы мапить реляционные данные. Ну может с иерархией классов. Но у них возникают проблемы, если требуются мета-свойства. Грубо говоря, тут дилемма либо переходить к предикатам высших порядков, либо пытаться это все закодировать в обычной онтологии. Оба варианта геморройные, но последний не масштабируемый. Потому как предикаты высших порядков кодировать - это сразу описания распухают. Ведь предикат высшего порядка в качестве аргумента содержит другой предикат, т.е. табличку. А в табличке куча значений, и оно все множится и множится.

Ну вот там тоже отмечено то о чем я говорю: Этот ИСО поддерживает сцылко на отношения, т.е. higher order Также поддерживает классы классов, тоже хайер ордер. И они говорят что нужны мета-модели для поддержки ФОЛ и Категорий Теорий (что вобщем-то можно считать ХОЛ). Т.е. как бы хочется без таких сложностей, а все-таки рано или поздно надо будет их задействовать.

Вот я от этих сложностей и в ужасе: если нужно соединить парочку (а то и полдюжины) таких онтологий, то этот метауровень появляется в тот же момент: одна модель на EXPRESS, другая на OWL, третья на UML, и под каждым их них свой "родной" язык метамоделирования типа MOF, RDF, CL или просто таблички на exel или еще чего-нибудь столь же достойного... А работать нужно именно с зоопарком. Кто тут прорвался, тот и победил.

Я прочитал что RDF и OWL сводимы к CL. Так что должно быть чуть попроще. По идее EXPRESS тоже должен быть сводим к CL, по крайней мере в значительной степени. Не знаю есть ли тулзы. Я вот думал над тем как это решать, и понял что нужно фандрайзингом заниматься :). Работы много, коммерческие перспективы крайне сомнительны.

В теории работа с зоопарком должна выглядеть так: выбираем общий языг и делаем трансляторы, между ОВЛ, Экспресс, ЦЛ и т.д. и т.п. Ну и типа как можно транслировать в промежуточный язык, потом в любой другой. Типа для этих целей как раз CL и был придуман. Но на практике все конечно сложнее. Первую проблему я уже отмечал: хочется чтобы это был Хаер Ордер язык, для которых есть проблемы с тулзами. С Ферст Ордер тоже есть проблемы с тулзами, но ситуация получше. Т.е. вроде как CL был бы идеальным. Еще круче были бы Дескриптивные Логики, типа OWL/DL, тут тулзов куча, но проблемы с выразительностью. Второй момент: с оттранслированными механически выражениями человеку тяжело работать. Чукча как известно писатель, а не читатель, трансляторы порой выдают редкостную пургу (но эквивалентную). Так что на самом деле, с чтением переведенной спецификации будут проблемы, и они некислые (но решаемые в перспективе). Третий момент: одну и ту же проблему можно записать по разному. К примеру, N-арные отношения можно по разному закодировать в бинарные. Энкодинг мета-описаний - еще хуже. Т.е. частично это пересекается с вышеперечисленной проблемой, но я выделил отдельно, потому как тут опять нужен мета-уровень (т.е. опять таки ХОЛ) для гармонизации таких вот различий. Четвертый момент: так как decidable только Дескриптивные логики, а ФОЛ семидесайдабл, то нужны специально обученные специалисты для разрешения проблем, которые не может решить компьютер. Это типа искусство на данный момент. Хотя можно сказать, что это решаемо, ибо специалисты такие есть и инструментарий есть.

А если воспользоваться знанием освоенным в результате наших недавних дискуссий, можно сказать, что для интеграция этого зоопарка нужен не продукт, а процесс :). Продукты конечно тоже нужны, но их недостаточно.

Ровно этим пытаются заняться в MDA, выбрав в качестве базового языка MOF -- и далее прописывая что-то типа "языка описания и трансформации онтологий" ODM (я об этом писал и приводил ссылки, например http://www.metadataopenforum.org/download.php?dcbda16e069c619010a39352a99df138 (хотя с тех пор уже много воды утекло и там давно уже все сдвинулось -- но не думаю, чтобы было очень много еще инструментов на эту тему). Вот тусовка ровно по этим вопросам: http://www.uni-koblenz.de/confsec/twomde2009/

Ну да. И торговать нужно процессом, а не продуктом :) Собственно, рынком тут является обеспечение интеграции данных, т.е. сервис: разработанные "адаптеры", а не инструментарий для их разработки. Ибо инструментарием все равно никто воспользоваться не сумеет :)

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

Я честно говоря УМЛ очень не люблю, и тема с МОФ не кажется мне перспективной. Ибо УМЛ построен на тяжеловесных конструкциях, манипулировать ими тяжело, и человеку и компьютеру. Геллиш в этом смысле гораздо лучше. Т.е. он базирован на крайне простой и тем не менее выразительной конструкции - бинарные отношения. На этой базе можно все сделать и она "легковесна".

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

Мне очень импонирует подход использованный в системе Jahob http://lara.epfl.ch/dokuwiki/doku.php?id=jahob_system : специфицировать все в ХОЛ логике, генерировать теоремы, а потом анализировать их на предмет преобразоания в решаемые фрагменты. Действительно, большинство подформул решабельно автоматически тем или иным методом, даже если изначально запись в ХОЛ. Ну а то что осталось можно и ручками добить. Причем, я так думаю, что под предметную область можно сделать набор теорем, которые будут пригождаться в аналогичных случаях. Т.е. фактически получаем кастомизированные домейн-специфик пруверы. Раньше мне казалось что ХОЛ подход очень сложен, хотя и заманчив. Но сейчас я думаю, что он даже более перспективен в русле серьезной системной инженерии, ибо он на самом деле экономит усилия человека: ведь чтобы что-то серьезное выразить в ФОЛ или ДЛ логиках надо потрудится. Плюс надо потрудится для того чтобы это все сопровождать. Лучше уж экономить человеческий труд, но извлекать решаемые фрагменты авто-тулзами, тем более, что большинство теорем будут очень простыми.

Для описанного подхода можно предложить сделать классическую экспертную систему по решению задач ХОЛ -- судя по описанному, это ровно тот самый случай ;) Причем наверняка такие экспертные системы уже делаются массово (ежели вообще логический подход можно считать массовым :) Я вчера на заседании INCOSE пытался объяснить нескольким человекам, что в логиках произошел качественный скачок: в агентском подходе вовсю пытаются юзать темпоральные логики, плюс появились эффективные SAT-солверы, плюс железо в виде видеоплат дает еще порядок в скорости. Но мне как-то не верили, что "нп-полнота несколько похудела"...

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