Обсуждение

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

Факт ориентированность это хорошо, но за ней обычно следует грабли логики первого порядка. В ситуации с модальностями почти любая попытка применения логики первого порядка ведёт к ошибкам, вне зависимости от личности и уровня подготовки применяющего. Проблема кратко рассмотрена в http://www-formal.stanford.edu/jmc/modality/modality.html Нельзя сделать общее логическое описание для всех информационных систем, хотя можно описать общие "циферки" (качества) для дальнейшей интерпретации ими. Лучше представлять факты чистой сигнатурой (темплейт-без-аксиомы). С деятельностным описанием для человека на нормальном литературном английском. Один и тот же пакет инстансов темплейтов может: 1. Верифицироваться кодом на Agda. 2. Рендериться в красивые диаграммы через Java и yFiles. 3. Управлять роботом. Общие данные, разный код. "Циферки" хорошо интерпретируются, в отличие от гибридов унитаза с холодильником на FOL. То есть, нужны алфавит и словарь языка, но словарь именно для людей - операторов и имплементаторов информационных систем.

Нужно просто эзотерическое знание делать реальным, меняя заумь на что-то более сродственное человечьему обычному разуму. Часто это проблема нотации. Деление когда-то было очень эзотерической операцией, но это было во времена римских цифр. При переходе на арабские тут что-то наладилось -- и стало возможным размышление про матан. Думаю, что если дать адекватный абстрактный и не совсем уж плохой конкретный синтаксис для описания систем, то можно неплохо продвинуться. Но нужно точнее прицелиться в те понятия, которые нужно класть на синтаксис. Последним этим занимался Мэтью Вест, а мы, наконец, дошли до того места, где он остановился. Зато у нас теперь есть редактор и сериализация, но никакого конкретного синтаксиса (Мэтью же использовал самый простейший: Express диаграммы, даже не диаграммы Части 2). Про декларативку и "ещё более декларативку" там вполне может оказаться что-то типа шестой нормальной формы, этот аспект ведь в декларативках не обсуждался, насколько я помню. Но я могу просто не знать, моделирование ведь это соседняя предметная область, и все те же идеи могут просто иметь другие имена, и я просто мог либо не увидеть этих рассуждений, либо увидеть незнакомый термин и не признать. В принципе, в численном моделировании "ещё более декларативность" обсуждается в терминах "каузальных" и "акаузальных" моделей (пример каузальных -- MatLab/Simulink, акаузальных -- Modelica), что же касается логицистского моделирования, так уж и не знаю, какие там слова.

Я специально оговорил: -- поскольку нас не волнует decidability, то мы смело можем идти в HOL и модальные логики в плане получения формальной системы (тут нужно сказать, что текущий ISO 15926 ни разу не формальная система, и это источник вечной критики. Хотя у Клювера сотоварищи есть планы его выражения как раз в FOL в конкретном варианте синтаксиса OWL 2 -- но это пока только планы). Но это ведь только про "теоретическую основу", пользователю необязательно это видеть. -- кроме темплейтов за последний год в тусовке появилось ещё одно средство повышения уровня языка: паттерны. Что это такое, и как с ними обходиться, внятно пока не может сказать никто (несмотря на то, что буквально на днях выходит версия 1.2 нашей софтинки с поддержкой пользовательских паттернов, ибо мы формализовали и реализовали язык описания этих паттернов). Я лично думаю, что привязывать конкретный синтаксис нужно не к темплейтам, а паттернам. Это (надеюсь) будет ещё более человечно (как говорят люди из тусовки, "ближе к инженерам"), чем голые темплейты. Остальное да, именно так: верифицироваться, отображаться и использоваться в реальных проектах. Когда я говорю о поддержке системного подхода (понятия "система"), я и имею ввиду именно алфавит и словарь языка для людей. Именно поэтому я ссылаюсь тут не на чисто машинный ISO 15926 как высшее слово разума, а на HQDM, Мэтью Вест его правил именно с интентом сделать понятизацию "системы" более осмысленной для человеков. Но я в затруднении, что взять за основу для конкретного синтаксиса: то ли диаграммки типа как в книжках BORO, то ли придумать чисто текстовую нотацию. А дальше этот конкретный синтаксис мэппить на онтологические паттерны, которые затем превращаются в темплейты, которые затем поднимаются в граф из сущностей части 2. Я думаю, что мы подошли к такому месту, что нужен уже хоть какой-то конкретный синтаксис, без которого трудно будет поупражняться в моделировании, а без упражнений будет трудно сформулировать алфавит и словарь системного языка. Потом вся эта история может повториться в прототипном подходе, но при этом значительная часть собственно "системной" работы и сопутствующей аргументации может быть выполнена на текущем, темплейтно-паттерновом поколении технологий, и перетягивание на новую (или на гибридную, т.е. "добавление" новой) понятийную теорию будет сильно полегче: будет сформулировано (оформлено, документировано) то, что нужно перетягивать.

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

Вот мы с vvagr это и обсуждали: паттерны в ISO 15926 -- это как раз сигнатуры без аксиом (т.е. сигнатуры без подразумеваемого механизма вывода), а уж как они обрабатываются потом (поднимаемыми темплейтами ISO 15926, или рендерами экранных редакторов, или солверами из Agda) это вопрос отдельный. Так что по этому поводу, похоже, у нас консенсус, только терминология чуть разная была использована. Всё одно стоит вопрос про то, -- как базовую систему типов отображать в конкретном синтаксисе (текстовом? графическом? что брать за основу?), и -- какие там типы считать базовыми (например, считать нечеловечьи "темпоральные части" и "функциональные физические объекты" из ISO 15926 правильными начальными типами, или "состояния" и "системные компоненты" из HQDM, или тяжело вздохнуть и сразу делать что-то своё на базе моего доклада по понятию "система" и анализа текущих архитектурных языков плюс Моделики). В любом случае, задача при текущей постановке уже представляется обозримой и обоснованной.

Текстовый и бинарный синтаксисы, а также базовая система типов у меня есть. Потихоньку работаю над имплементициями. Сильно разные вещи - система типов (unit, record, tag, ...) и "базовые типы для описания систем" (функциональные физические объекты, etc) как элементы стандартных библиотек. Диаграммные представления - одну и ту же ситуацию можно представить как state diagram или flowchart. Тоже выбор библиотек.

Ну, это ещё один уровень: система типов для сериализации (у нас в .15926 это, как я понимаю, XSD+RDF). Для меня это не базовые типы, а сериализационные типы ("транспортный формат", как мы использовали OWL для представления типов ISO 15926). Там, конечно, более тонкое отношение между семантикой сериализационного уровня и семантикой видимого людям базового уровня моделирования, тем не менее. Так что мне нужен текстовый или графический синтаксис для представления "системы", "жизненного цикла" и прочих таких понятий системного языка. Ясно, что unit, record и tag про ЗАПИСЬ представлений о системе, но не про собственно систему (то есть мне нужен уровень, когда я могу уже не столько оговаривать, что я работаю с архитектурным описанием, а не архитектурой, с системным описанием, а не системой, сколько просто опускать слово "описание" без потери понятности и осмысленности).

Система типов решает вопросы уровня "сюда можно только число, сюда что-либо из множества cardinal_direction, а сюда только единицу измерения", для чего содержит аналоги part2:Classification. Помещение фактов под модальность тоже осуществляется там. Хорошая система типов это первый уровень формализации, а человекочитаемые нотации и транспортные форматы уже последствия. Поверх этого может быть реализована библиотека "жизненный цикл". А также, библиотеки "пространство", "время", "единицы измерения", etc.

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

Без примера непонятно, увы. Где-то там внизу всегда есть "строки" и "целые". А вот как оно там растёт выше через "типы" к этим "библиотекам" -- уже мне непонятно. В ISO 15926 в этом месте тоже мутновато донельзя (типы XSD, затем 201 тип части 2 на этой базе, затем всё остальное на базе части 2). Фишка в том, что все эти "число, cardinal_direction, единица измерения" представляют смесь того, как говорят о мире, и объектов самого мира -- то есть смесь системы репрезентации и концептуальной схемы (которая абстрактна и описывает мир, а не способ говорения о мире). Вот и непонятно без примера, ибо никаких особых принципов по разделению всех этих возможных около-онтологических сущностей на форматы, типы, классы я пока не усматриваю. Мне понятно, что люди привыкли какими-нибудь "питоновскими словарями" выражать объекты реального мира, не задумываясь, что это означает онтологически. Но вот когда говорим о "пространстве", "времени" и "единицах измерения", хотелось бы понимать, чем они принципиально отличаются от подлежащей системы типов (ибо не о разметке же в памяти и не об языковой интерпретации -- то есть свойствах компьютера речь идёт, а о выражении тех или иных свойств мира).

Мутность и есть следствие разрозненности. Типы есть, в разных сочетаниях (EXPRESS+Part2, FOL+Part2, XSD+OWL+Part2), а системы нет. Базовая система должна равноценно поддерживать нужные типы. В том числе: 1. Vector3d, uint32 и другие типы, значения которых выражены битами/байтами в железе, на котором крутится информационная система. 2. Такие типы как ГородЛондон или ГородОдесса, значения которых представлены в реальном (или возможном) мире, за пределами информационной системы. Если это разные системы, то как когнитивные затраты со стороны пользователей, так и затрачиваемые машинные ресурсы увеличиваются на порядок.

Я полностью это поддерживаю, что пристыковка XML к XSD к OWL к Part 2 и потом через искусственный трюк с дублированием в части 4 типов части 2 и унаследованием ExpressString выражение всего-всего дальше -- это дурдом тот ещё. С удовольствием бы поглядел, как можно без этой головной боли справиться.

Мэтью Вест, кстати, очень жёстко пытается различать те онтологии, которые "про мир", а не не-онтологии "про то, как говорять о мире" (как говорить о мире -- это для него DOLCHE, а про мир -- это ISO 15926). Для него это кардинальное различие. А вот Vector3D и ГородЛондон как раз из этих двух разных подходов: первое "как говорят о мире", а второе -- "про мир", и вот этот стык очень мутный. Пару дней назад нам написали, что в нашей методологии инженерии референсных данных одновременно Москва и данные (абстрактный объект), и индивид физического объекта, а это противоречиво. Мы подискутировали, в дискуссии поучаствовал и Мэтью Вест -- когда я сказал, что "данные correspond физической Москве, и это обычный вординг iso 15926", он отметил, что "никакого correspond, ибо отношение между меткой Москва и индивидом Москва называется в стандарте representation". Витя ему флегматично заметил, что отношение между не меткой Москва и индивидом Москва, а URI http://namespace.ru/cities#Moscow и real 4D Moscow object, и это отношение вообще не в онтологии. Мэтью сказал -- а, так у вас тут genuinely model theory. То есть в этом месте стыков компьютерных типов и реальных типов нужно как-то гармонизировать две теории: онтологию (что есть в мире) и теорию моделирования (как данные представляют реальный мир). Теорий две, механизмов два, компьютер и оперативная память одна. Вот с этой унификацией все и мучаются, в этом месте у всех дребезг, компьютерные типы данных и традиционные онтологии после этого и не дружат между собой.

Рассмотрел этот вопрос отдельным постом: http://justy-tylor.livejournal.com/200155.html

Всего наилучшего!