Обсуждение

Скажите, а у вас предусмотрен только статический подход? Я имею в виду, что необходимо отслеживать динамику изменения как объекта, так и модели. Недостаточное внимание к управлению изменениями приводит к тому, что модели остаются излишне абстрактными и постепенно теряют связь с реальным объектом. Не секрет, что отклонения начинаются как минимум при переходе от basic design к рабочему проектированию. Количество отклонений и их динамика тем больше, чем крупнее инженерный объект.

Конечно, модель должна быть не статичная. Для любого моделирования делается управление конфигурацией модели. Другое дело, что я не различаю модели/онтологии/модели данных/программы (хотя там и есть особенности), поэтому подозреваю для сегодняшнего уровня технологий не так много отличий от управления конфигурацией любого программного проекта -- ведение версий всех модулей, билды, release notes и т.д. Я этим текстом отвечал на главный вопрос: вообще в каких нотациях описывать информационные модели? И уже потом будет -- как описывать, примеры, как управлять конфигурацией такого описания (очевидная проблема тут уже помянута -- отслеживание связей между разными уровнями описаний при изменении конфигурации информационной модели), какая нужна квалификация сотрудников, какой инструментарий использовать для таких описаний и т.д.

Я понимаю последовательность. Спасибо. Мне в этом смысле нравится подход группы OMG, которые в методологии UML сразу заложили как статические, так и динамические модели. Кроме того, в стандартном software engineering управление конфигурацией используется параллельно с управлением изменениями и управлениям требованиями (включая traceability и т.п.)

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

Анатолий, 1) а можно город будущего (такая целевая система) смоделировать так, как вы здесь описываете? Если, можно, то, какие входные «данные» нужны для этого? Может есть какие примеры уже кем то выполненной работы для города, как «крупного инженерного объекта»? Системная инженерия городами занимается, или только, чисто железячными инженерными объектами со встроенными компьютерами? 2) правильно ли я понимаю, что разработка объектов моделирования, предметных наборов, микротеорий , т. е. работа на уровнях «архитектурном» и «концептуальном (нейтральном)», - это работа, которую выполняет онтолог «а сейчас по факту принят всеми онтологами» (а не логик)? А логик начинает работать уже с тем, что разработал онтолог, т. е. начинает работать на уровне «прикладном (логическо-физической реализации прикладным софтом)»? Если это так, то когда же работает методолог? Он что то делает в этом «подходе»? Или он «управляет» переходами между работой онтологов и логиков, например?

1. Любые проекты городов, даже для городов сегодняшних -- это проекты городов будущего, просто по определению проектирования. Другое дело, что есть и другие понимания для "проектирования" крупных общественных систем, учитывающие наличием многих и многих проектировщиков. Системная инженерия в таких случаях говорит о системах систем, и методы проектирования существенно отличаются. 2. Да, разработка микротеории предметной области -- это прерогатива онтолога. Методолог работает на предыдущем шаге, когда предметной области еще нет. Онтолог по факту не создаёт предметную область (по факту -- не придумывает её, не design), он пытается ее "открыть" (discover), пытаясь углядеть общее в работах практиков-специалистов, самых разных методологов и используя логические инструменты -- ибо онтология обычно не "придумывается", а соответствует разделяемому пониманию. Логика же интресует сам факт формализации (например, формализм представления компьютерной онтологии/модели данных), а не ее содержание. Есть, конечно, разные варианты-отклонения от этой общей картинки: например, методолог придумывает новую предметную область (создаёт предмет/миротеорию с нуля), а затем обеспечивает популярность этой микротеории, добиваясь исключения других вариантов. Потом приходит онтолог, и ему в этой стерильно чистой ситуации ничего не остаётся, кроме как просто записать результат -- думать уже в отсутствии разнообразия микротеорий в данной сфере уже не нужно. Но и то, ему придется выбрать логический формализм, который может не совпадать с формализмом, использованным методологом, после чего методолог может сильно удивиться результату онтологизации -- но зато у онтолога будет большой связный кусок описания мира, много более связный, чем у методолога. Предметы потребны для деятельности, вот у меня и занимается порождением предметов тот, кто печется о методе.

В первом пункте я, вроде, спрашивал о моделировании города, а не о проектировании его. Странно, а почему микротеории в вашем подходе разрабатывает онтолог, а не теоретик предметной области. Или вы это не различаете? Онтолог использует «логические инструменты», значит ли это, что онтологическая работа, - это логическая работа, такой ее специфический вид, специфическая форма работы, а по со содержанию, все равно, это логическая работа, т. е. здесь работает только логическое мышление? А методолог у вас тоже работает на логических инструментах? Ваша методология – это тоже по содержанию работа логического мышления? Если методолог порождает предметы своим методом, а кто у вас тогда порождает сами объекты и каким путем?

1. Пардон, очитался. Такое моделирование города ведется, конечно, большинством муниципальных служб -- они пытаются собрать на основе самых разных геоинформационных систем данные о водопроводах, канализациях, телефонных линиях связи, фундаментах и т.д. подземной части города, а также прилепить сверху наземные оцифровки -- и добавить данные бюро инвентаризации, транспортных служб и т.д. Задача крайне сложная, и я думаю, что этот мой текст вполне может им помочь разобраться с этим зоопарком моделей с целью интеграции всех этих систем моделирования. 2. Обсуждения про методологов, логиков и онтологов немедленно становятся абстрактными, когда мы вылетаем из конкретной ситуации. Ни одно рассуждение не будет работать во всех ситуациях, ибо в конечном итоге рулит прагматика, а семантикой мы можем только баловаться в очень ограниченных областях. Перескочить от обсуждения постинга про описание информационных моделей сложных инженерных объектов в пару предложений к обсуждению вопроса "ваша методология -- это тоже по содержанию работа логического мышления" мне трудно, ибо не понимаю, зачем. Мышление работает в каких-то логиках, эти логики бывают самые разные, и фишка в том, чтобы их правильно менять. Беда в том, что словом "логика" обозначают и "науку логику", и различные системы формализации, языковой работы и рассуждения/вычисления. Про "методологию" я и не говорю. Эти вопросы про суть логики, методологии и онтологии точно не в режиме комментов, и совсем не к данному постингу. Вот что к данному постингу, так это прием на работу уже в нескольких нам известных организациях (включая нашу собственную) инженеров-онтологов. Матлогику эти онтологи после окончания ВУЗа не забыли, за что и были взяты -- ибо остальному научатся на рабочем месте. :-)

1) Разработка информационгной модели существующего города - это одно. А попадалась ли вам работа по моделированию города будущего? 2)"Перескочить от обсуждения постинга про описание информационных моделей сложных инженерных объектов...", - мне, кажется, я не перескочил, так как хотел выяснить кто какую работу делает при таком "описании" и каким образом (в какой последовательности или в каком порядке, кто что кому передает как результат своей работы и пр.). Мне хотелось понять какова полная позиционная карта тех, кто делает такое описание.И почему это абстрактный разговор? Разве позиционная карта зависит от "конкретной ситуации", какая разница подводную лодку/атомный реактор они будут описывать, или город?

1. Значит, не очитался. Моделирование чего-то будущего -- это существенная часть проектирования. Про проектирование городов см. два коммента назад по этом треду. 2. Я не знаю про "позиционную карту", но регулярно помогаю кадровым службам найти людей для работы по интеграции различных информационных моделей. Для такой работы требуется взаимодействие enterprise architect (ибо архитектурный уровень описания -- это лишь одно из view полного архитектурного описания предприятия, а хоть и расширенного предприятия крупного инженерного проекта), который является системным архитектором по своей родовой сущности (наряду с инженером по требованиям, инженером по интеграции и другими видами системных инженеров), онтолог (специалист по моделированию данных), прикладной программист (писать мэппинги и адаптеры) и администратор баз данных. Ну, и прямой доступ к инженерам по специальностям, которые хорошо разбираются в предметах моделирования, а также прикладным программистам/администраторам/модельерам данных, разбирающимся в участвующих информационных системах.

Кстати, мжно эт раскрыть как то по содержанию "Ни одно рассуждение не будет работать во всех ситуациях, ибо в конечном итоге рулит прагматика", почему не будет работать, например? И что значит "рулит прагматика"? Под прагматикой здесь понимается некий разный набор значений, относимых к разным ситуациям, что ли? Прагматика - это то, что определяет значение? Или иное?

Да нет, очитался. Моделировать можно и то, что есть и то, чего нет. А как это используется в проектировании или исследовании - это другой вопрос. Я спрашиваю о моделировании, а не о проектировании.

The term “pragmatics” and the classic definition of the distinctions among syntax, semantics, and pragmatics are due to Charles Morris (1938). Within semiotics, the general science of signs, Morris distinguished three branches of inquiry: syntax, the study of “the formal relation of signs to one another”, semantics, the study of “the relations signs to the objects to which the signs are applicable” (their designata), and pragmatics, the study of “the relations of signs to interpreters” (1938, p.6), quoted from Levinson (1983, p.1). On this view, syntax concerns properties of expressions, such as well-formedness; semantics concerns relations between expressions and what they are “about”, such as reference and truth-conditions; and pragmatics concerns relations between expressions, their meanings, and their uses in context, such as implicature. In recent work, many have challenged the autonomy of semantics from pragmatics and the sharp distinction between them implied by the traditional trichotomy. The subdiscipline of formal pragmatics is concerned especially with issues where semantics and pragmatics overlap. Это я выдрал из первого же попавшегося под руку текста (http://people.umass.edu/partee/RGGU_2005/RGGU059.pdf). Прагматика -- это когда со знаками работают разные люди, находящиеся в разных ситуациях. А если пытаться найти во всех этих ситуациях что-то общее (исключить разницу людей и ситуаций), то останется семантика. Чистая прагматика -- это когда знаки вводятся исключительно ситуативно, а чистая семантика -- когда пытаемся рассуждать об абсолютных значениях. Я обычно слежу, чтобы разговор не превратился в совсем уж пустопорожний о сферических конях в вакууме -- то есть чтобы была хоть какая-то связь с конкретными людьми и их ситуациями. Прагматика рулит, хотя онтология и логика в их традиционном понимании очень и очень тяготеют к чисто семантическому рассмотрению.

Запутали. "Город будущего" или уже есть, и его можно исследовать-моделировать. Но тогда это "город настоящего" или "город прошлого". Или его еще нет, и тогда моделирование есть часть проектирования (например, форма документирования проекта). Приведите пример, без конкретной ситуации опять сферический конь в вакууме обсуждается.

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

Да, ничего я вас не путаю. Вот я прихожу на предприятие и его обследую/исследую перед тем как проектировать буду информационную систему. Я что с собой приношу? Приношу модель бизнес-процессов которой на этом предприятии нет. Ее может вообще нет в "природе", - это модель как должно быть. Зачем она мне? Затем, чтобы увидеть то, каких бизнес процессов на этом предприятии нет, или они "кривые", А как я это увижу, если у меня перед глазами нет модели "как должно быть". Что тут непонятного, и в чем я вас путаю? Так и с городами. Чтобы смотреть на город Москву как она есть сегодня (на модели ее), надо иметь модель Москвы как города будущего (которого еще нет). Вы хоть немного про Сколково слышали? Как там поселение делать будут слышали? При чем здесь сферический конь? Эт же все конкретные и реальные ситуации, которые нас окружают.

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

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

"Это умение читать по-английски является образовательным цензом для обсуждения логики, онтологии, семантики и т.д", ну, здесь мы с вами расходимся, так как уж не по английски - это точно. По немецки, бы уж лучше сказали. Англо-американцы в онтологии вообще ничего не понимают, спросите это у немцев по случаю. "Конечно, семантика это не про смыслы, а про значения", конечно, вы здесь ошибаетесь. Не буду вас в этом разубеждать сейчас. На скорую руку не буду. Может быть потом. А в СМД смысл и значение точно различают, но не так "Смысл -- это толкование знака в ситуации, а значение "словарно" и постоянно, оно вне ситуативного толкования". На этом закончим.

Я вам в начале задал вопрос "Анатолий, 1) а можно город будущего (такая целевая система) смоделировать так, как вы здесь описываете?", и не получил на него ответа. Сказали бы сразу, честно, что не знаете. И на этом бы закончили. А так все пустое...