Обсуждение

>- про аналогичность представлений о троице в моно-теизме, тайцзи в дао-сизме и множественности описаний системы. Парадоксальность и непостижимость понятия системы именно в этом единстве разного, и различений в единстве; 1,2,3 + кватернер:)

Да, кстати. Троица, кватернер, пентакль, ... :)

Теоретико-множественная терминология, думаю, многое бы упростила. Не было столько синонимов.

Спасибо за очень содержательный доклад. Заставил задуматься тезис о безусловной привязанности понятия система к функции. Вопрос про эл.станцию, которая идет на снос, был вполне уместен - объект еще система, хотя и не та система, которой он был во время рабочего цикла - она уже без функции. Можно сказать, что на стадии утилизации целевой объект (система) является элементом "большой системы", определенной на всем жизненном цикле. Но тогда и функция у этой "большой системы" другая, чем у "малой системы" (целевой системы - станции). Это функция - обеспечение жизнедеятельности социума. Тогда становится понятно, что "малая система" остается элементом "большой системы" пока не завершен полный жизненный цикл - не выполнена социальная функция. По сути, перед нами иерархия систем и иерархия функций: (1) есть система "объект как структура/конструкция" - то, что осталось от целевой системы на стадии утилизации, это система без функции. (Кстати, на этом уровне тетрадка как набор скрепленных листков тоже система - система как структура. Конечно, понятно, что после лекции по системной инженерии на вопрос про тетрадку-систему следует отвечать нажимая на ее функцию, но в общем случае тетрадь - как сложный объект, как структура - является системой и вне всякой функции и после утери своей функции, скажем, и после того, как она вся исписана - мы показываем на нее и называем "тетрадь"). (2) система "конструкция+функция" - система в операционном окружении, функция есть то, что определяет место системы в этом окружении; (3) система реализации системы "конструкция+функция" - предмет системной инженерии, функция этой системы с наименьшими затратами и наиболее безопасно для социального окружения обеспечить выполнение функции системы (2). Тут интересно заметить, что целевая система в качестве элемента входит в две ортогональные иерархии над-систем пространственную и темпоральную: - пространственная иерархия фиксируется в моментальном срезе на стадии эксплуатации (вхождение в операционное окружение - деталь в модуль, модуль в устройство, устройство в комплекс и т.д.) - темпоральная иерархия фиксируется по вхождению целевой системы (как последовательности событий функционирования, как процесса функционирования) в полный жизненный цикл и шире (во времени) - в некоторую социумную деятельность. P.S. Я был бы рад прочитать доклад на упомянутом вами семинаре "Онтологические проблемы инженерии" на тему "Иерархия распределенных во времени систем" - тема философская, но ее можно адаптировать к инженерии (исходные материалы тут - Формализм распределенных во времени систем, во второй книге есть развитие "Иерархия темпоральных систем", но ссылки в сети пока нет - если интересно могу прислать текст).

Если хочется анализировать существенно разные объекты, то они объявляются разными системами. Кроме того, полезно различение целевой (ситуационной) и обеспечивающей (активной, реагирующей на ситуацию) систем, а также систем в операционном окружении целевой системы. Все же увязки этих разных рассмотрений, разных объектов делаются на основании 4D экстенсионализма (т.е. утверждения о том, что если 4 экстента -- контуры по осям длины, ширины, высоты и времени -- одного объекта и другого объекта совпадают, то это один и тот же объект) и постулирования существования таких объектов, как темпоральные части. При этом я заранее отказываюсь от использования вашей терминологии в подобных объяснениях, ибо ваша терминология -- это чисто ваша терминология, а я предпочитаю быть понимаемым многими людьми и поэтому использую онтологию ISO 15926 (чтобы не сочинять тут чего-то своего). Был бы рад вашему докладу по заявленной теме на семинаре, хотя мы ещё не определились с датой семинара, и пока я ничего определённого про организационные вопросы сказать не могу.

«При этом я заранее отказываюсь от использования вашей терминологии в подобных объяснениях, ибо ваша терминология...»

Так и я предельно старался писать в вашей терминологии - извините, если не попал )

«утверждения о том, что если 4 экстента -- контуры по осям длины, ширины, высоты и времени -- одного объекта и другого объекта совпадают, то это один и тот же объект»

Так ведь вопрос (возникший по ходу вашего доклада) и был в том, что электростанция на всем протяжении жизненного цикла не один объект - по крайней мере на стадии утилизации уже нет функции и нет операционного окружения, а целевая система для системной инженерии еще есть. Или, наоборот, если признать, что перед нами один объект - станция на стадии утилизации есть темпоральная часть 4D системы, то функция не является неотъемлемым атрибутом этой системы. Вы ответили, что система та же по указанию - но это философский, а не инженерный ответ :) Но, вообще, мой коммент был не об этом, не о целевой системе, а о системах в которые входит эта целевая система - в пространственную и темпоральную иерархии. Как мне кажется, системная инженерия больше сводится не к видению инженерного продукта в качестве системы, а к пониманию самого этого "видения" как системы, к организации системы "видения" - к деятельности по совмещению этих систем (целевой системы и системы-деятельность). Извините, если опять не попал в терминологию. P.S. Как прояснится с семинаром стучите в личку.

А почему просто сразу не уточнять омоним эл.станция - эл.станция (действующая), эл.станция (сносимая), эл.станция (снесённая, заброшенная)?

Суть моего ответа была в том, что система определяется функцией стадии эксплуатации -- и если это верно по отношению к набору собранных деталей перед тем, как систему запустили в эксплуатацию (самолёту, который только-только покидает конвейер, атомной станции, которую только-только построили), то это верно и по отношению к моменту после окончания эксплуатации. То, что какой-то функциональный и/или физический объект входит сразу во множество иерархий (например, холархий на отношениях часть-целое, но там может быть и множество классификаций, и множество других отношений), это очевидно. Причём это не отдельно пространственные и темпоральные иерархии. Это пространственно-темпоральные иерархии (где пространственные и темпоральные иерархии являются только какими-то срезами. Так, пространственный срез всех объектов по моменту времени -- это "событие"). Вы в значительной мере правы в вашем комментарии про systems engineering management (что мало думать только о системе, а хоть и в операционном окружении, нужно также думать об обеспечивающей системе не меньше, чем об операционном окружении).

В речи уточнения обычно опускаются, остаётся только одно слово, людей ведь не заставишь говорить "по норме" (вон, сколько учёные-русисты не возражали против кофе в среднем роде, а пришлось таки признать его существование). У меня были попытки поиска таких уточняющих "типов" для обозначения системы в ходе полного жизненного цикла -- http://ailev.livejournal.com/1015406.html. Но вряд ли это приживётся (я и сам себя-то не могу заставить такими уточнениями пользоваться). Фишка не в том, что люди не используют подбные уточнения. Они, когда уж совсем прижимает, такими уточнениями пользуются. Но дальше оказывается, что модели данных в информационных системах этих уточнений не учитывают, поэтому происходит отход от шестой нормальной формы (неучёт времени), и далее потеря управления конфигурацией (неверные репликации данных между информационными системами, потеря акутальности данных, искажения данных и т.д.).

«Суть моего ответа была в том, что система определяется функцией стадии эксплуатации ... то это верно и по отношению к моменту после окончания эксплуатации.»

Но ведь деятельность по утилизации уже практически не зависит от этой функции (был ли это завод или ТЭЦ) - не определяется ею.

«Это пространственно-темпоральные иерархии (где пространственные и темпоральные иерархии являются только какими-то срезами. Так, пространственный срез всех объектов по моменту времени -- это "событие").»

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

Тогда нужно сразу определиться - создаётся для людей (лентяи, "экономисты") или для ботов (работы автоматики), при помощи которых люди потом будут пользоваться разработкой (не вручную же мы проверяем ошибки в коде, компилируем, редактируем XML, HTML файлы, хотя, конечно можно поизвращаться). Если ориентироваться на людей, тогда прогресса не будет. Если на программы и алгоритмы, то строгость там только приветствуется. Попробуйте использовать в исходниках что-нибудь не по правилам - компилятор сразу выругается. А люди привыкли. По гиперсамолёту отвечу здесь: алгоритм такой - 1) уточнить омоним, 2) работать с уточнённым термином, а не омонимом). Пока не будет точности, будут проблемы. Уточнение - решение проблем. А если "модели данных в информационных системах этих уточнений не учитывают", то зачем такие модели данных?

Вообще-то есть одно очень правильное замечание: программы нужно писать не для машин, а для других людей, которые должны иметь возможность их прочесть и исправить ошибки, или разобраться и дополнить, или разобраться и использовать повторно. А компьютер (на сегодняшний день, завтра может быть и иначе -- но тогда компьютер превратится в того самого человека из первого предложения) пока только тупо будет эти программы выполнять, в том числе и вместе с ошибками неразобравшихся людей. Про "зачем модели данных, которые не учитывают уточнений, связанных с учётом всего жизненного цикла" -- эти модели данных нужны для тех людей, которые ответственны за систему на протяжении какой-то одной стадии жизненного цикла. Тогда всё в порядке. Проблемы возникают при попытке объединить информацию жизненного цикла (информацию нескольких стадий жизненного цикла). Поскольку итоговая модель оказывается денормализована (пятая нормальная форма -- это не шестая), то люди, проводящую эту интеграцию, оказываются недовольны теми моделями данных, которые им приходится интегрировать. Но люди, которые эти модели данных делали, и которым по большому счёту на полный жизненный цикл наплевать (да и финансирования для выправления коленвала им обычно не выделяют: выделяют только на улучшения их маленького фронта работ, а не на улучшения ситуации в проекте в целом) уверенно отвечают всем, что их эти модели данных устраивают, они их делали, и они отлично ими пользуются для своих целей. В ISO 15926 справочные данные, которые применимы для одной стадии жизненного цикла могут разрабатывать люди с "желтым поясом" -- ибо это легко. А вот люди с "чёрным поясом" имеют полномочия проверять, учитывает ли моделирование данных полный жизненный цикл. Корпоративные RDL обычно делают "желтопоясники", а вот JORD RDL -- чернопоясники.

А почему забыта двойка? Что, единство и борьба противоположностей уже не в моде? Вот она, клерикализация :(

Единство и борьбу противоположностей лучше учить по оригинальным источникам. Дао, потом тайцзи (тот самый инь и янь), затем сы сян (четыре образа), далее "и цзин" и т.д. -- про не меньшую клерикализацию двоичности см. в http://waruna.narod.ru/index8.htm Но и по этой альтернативной клерикализации есть потуги на троицу (вариант инь янь хрень я приводил, а вот ещё: http://en.wikipedia.org/wiki/Taixuanjing).