Итак, попробую еще раз медленно. У нас есть обозначение объекта в виде ID. Далее мы строим связи этого ID с ID, обозначающими классы объектов, Моделью объекта является ID и сумма таких связей. (В самом примитивном виде, конечно). Вырожденный случай, когда есть ID, но нет ни одной связи — тоже модель, иначе получается парадокс. Тот же парадокс, что и пустое множество вдруг будет считаться не множеством.
Я так думаю, что мой велосипед связан с попыткой решить две простых задачи:
1. Как описать априорное знание про экстент, которым мы пользуемся, чтобы описывать его как объект, операцию и проч.
2. Как решить задачу: функциональный объект молоток, гвоздодер и молоток-гвоздодер связаны друг с другом некими операциями. Возможно, объединение, вычитание, но чего? смысла? точек зрения? моделей? не знаю, но хочу, чтобы такая возможность была описана явно.
Мы описываем экстент в два этапа. Сначала мы договариваемся, как мы будем смотреть на этот экствент: как на событие, как на операцию, как на объект? Затем мы делаем описание этого экстента объективно. То есть перечисляем те факты, которые нам известны про этот экстент исходя из априорного знания о том, что это такое: объект, операция, или событие (список продолжать). Эти факты описывают данный экстент без привязки к субъективной точки зрения. Они «объективны». Например, железяка такого-то размера. Это описание включает в себя априорное представление экстента как объекта! Если бы мы описывали этот же экстент в качестве операции, нас мало волновали бы размеры этой железяки, а больше — время начала существования железяки и время окончания ее существования. А геометрические размеры были бы опциональны. Лишь затем появляется субъективное описание этого объекта. Например, железяка — молоток. Вот именно двухступенчатость описания эестента нужна мне для развязки неких коллизий. А иначе мне не к чему привязать «объективную» точку зрения.
название объекта — и есть его ID. Поэтому я и предложил использовать ID вместо имени. То есть не Куликовская битва, а объект ID=123. Пока мы знаем, что есть объект, на который ссылается данный ID, но ничего более не знаем про этот объект. Вы предложили строить модель вокруг этого ID. Я соглашусь с Вами, но что обозначает этот ID? Вот это тот вопрос, который я задал и пытался на него ответить. Если это в одном случае ID обозначает событие, а во втором — операцию, то надо признать, что то, что обозначает ID может быть одновременно и событием и операцией. Это следствие трассировки. Так что же это в природе? я попытался дать ответ на этот вопрос.
Круглый квадрат — это название объекта, про который мы более ничего не знаем. Например, у меня есть собака, имя которой круглый квадрат. До тех пор, пока название не связано с классом объектов, оно нам говорит только о факте существования объекта, но не говорит нам ничего ни о природе этого объекта. Если я скажу, что круглый квадрат относится к классу собак, то у нас появится информация о природе этого объекта.
Атрибут не может относится к классу. Атрибут относится к типу. Атрибут — это из логики Аристотеля, у которого нет классов, а есть типы. ООП в этом жестоко нас обмануло. Назвав типы объектов классами. Но про это отдельная песня, которую я сейчас не касался. Я бы рекомендовал Вам использовать термин атрибут и его значение только вместе с термином тип объектов и экземпляр этого типа. Если же говорить о классах, то классы описываются только перечислением их объектов, но не описываются атрибутами. ООП все перепутало.
Теперь про экстент. Я могу рассматривать экстент как физический объект и одновременно как физическую операцию. Модели в моей башке одного и того же экстента, представленного в виде физобъекта или в виде физоперации будут сильно различаться. И эти модели очень сильно будут отличаться от моего представления о функциональном смысле этого физобъекта или физоперации. Более того, в моей башке могут уживаться много представлений о функциональном смысле одного физического объекта или одной физической операции. И все эти представления связаны либо с физобъектом, либо с физоперацией и в конечном результате с одним экстентом. Вот эти связи я хотел бы моделировать. Итак: экстент относится со множество разных физических объектов: операция, объект, событие, и так далее. затем каждый из них я хотел бы связать с субъективной точкой зрения на эти физические объекты.
Итого, если автопилот нами разобран, то я утверждаю, что один и тот же экстент связан с одним и тем же представлением этого экстента в виде физического объекта — железяка и связан с двумя функциональными объектами гвоздодер и молоток. Именно этот кейс я пытался описать.
Мне страшно неудобно перед Вами за то, что я плохо изъясняюсь. И к тому же, возможно, я не прав. Но попробуем еще раз. В ИСО мне не хватает сущностей. Возможно, в этом причина. Например, я искал такую сущность в ИСО, как модель в голове у субъекта. К этой модели я мог бы привязать множество представлений этой модели. Но не могу, потому что такой сущности, как модель объекта в голове у субъекта в ИСО нет. С молотком та же проблема. Не хватает одной сущности. Эта сущность — представление экстента в виде физического объекта. Не молотка и не экстента, а именно физического объекта, у которого есть ширина, высота и длина. И я хочу иметь возможность смотреть на тот же экстент как на операцию. Тогда у этого экстента как физической операции появится описание операции как физической операции, не как субъективной. И этих сущностей нет в ИСО. И понятно почему их нет. Потому что в ИСО считается, что функциональность объекта предопределена создателем этого объекта. Однако, я предлагаю такой эксперимент. В раскопках мы нашли объект неизвестного нам назначения. Например, каменный наконечник от копья. Мы сделали вывод, что перед нами функциональный объект — наконечник. Потом оказалось, что способ охоты древних людей был совершенно иным. Они подходили к животному и договаривались с ним, что сегодня животное отдаст им свою жизнь в обмен на то, что в следующей жизни животное родится человеком. А каменные наконечники древние придумали для того, чтобы поприкалываться над нами, — дикими людьми будущего. И они изготавливали и разбрасывали их повсюду, чтобы порадовать себя такой шуткой. И тогда понятно, что функция таких наконечников не в том, чтобы убивать, а в том, чтобы доставить удовольствие. Вопрос простой: может ли это все смоделировать ИСО? Я не спрашиваю как, хотя бы может, или нет? может ли оно смоделировать тот факт, что сначала мы считаем, что функция объекта одна, затем мы меняем свое представление об этой функции, а затем меняем снова.
Я в своих статьях подчеркиваю этот факт, что все, что мы имеем, — это всегда модель. С реальностью мы не работаем в принципе. Но у модели, которой мы пользуемся, есть уровни. Вопрос, сколько этих уровней и какие объекты рождаются на каком уровне модели. Об этом я подробно рассуждаю, когда показываю, что сначала мы моделируем пространство, затем мы моделируем объекты, затем мы моделируем смысл этих объектов и все это происходит одновременно.
В одной из своих статей я подчеркивал, что даже ID является моделью предметной области, поскольку содержит информацию: есть объект. Если ID связать с классом, то мы классифицируем этот объект. И так далее — каждая новая связь с очередным классом позволяет нам прояснить что-то новое об объекте. Например, принадлежность объекта классу синих объектов моделируется в информационной системе множеством разных способов: от атрибутов до связей. Но в предметной области это все тот же факт: объект принадлежит классу синих предметов. Если Вы говорите о том, что только связи моделируют объект, то я тут же придумаю одну модель, в которой синий предмет моделируется связью, и модель, в которой синий предмет моделируется атрибутом. И Ваше определение будет противоречивым
Как программисту мои рассуждения могут показаться слишком надуманными и лишними. Вопрос, который я обсуждаю, больше нужен аналитику. Эти вопросы возникают при проведении митингов с заказчиком и попытке так сформулировать ТЗ. чтобы и вашим и нашим было понятно, о чем идет речь. Программисту дают вообще не модель предметной области, а модель реализации. Поэтому программист не видит моделей предметных областей, или точнее не должен их видеть. Но проблема в том, что аналитики вырастают из программистов. И эти аналитики начинают видеть, например, наследование в предметной области. То есть то, чего там в принципе быть не может. И вот эти аналитики, к сожалению, не делают разницы между моделированием предметной области и моделированием реализации. И тогда возникает вопрос: о чем я тут пишу? Для таких аналитиков моя статья кажется чисто философской и лишенной практического смысла
Имя, или ID — это информационный объект, который моделирует что? Вот то, что он моделирует я и рассматриваю. Я написал статью, посвященную различному количеству разных сущностей, которые возникают при моделировании предметной области. Вы просто по какой-то причине не различаете объект предметной области и информационный объект, который хранит информацию об этом объекте. Это не плохо, это состояние отрасли(.
пусть у нас есть многофункциональный прибор. Алексей использует его в качестве термометра, Андрей — в качестве барометра, а Зинаида — в качестве зеркала. Все это один и тот же эксстент, но выполняющий разные функции одновременно. Эти функции отличаются только точкой зрения на физический объект.
Из Ваших рассуждений следует вывод, который противоречит тезисам, которые я слышал ранее. Или я думаю, что противоречит. Был вопрос, который ставил Мэтью Вест: автопилот существует, если прибор, который выполняет функцию автопилота, сломался? Ответ — да. Еще один вопрос: автопилот существует, если им в данным момент не пользуется пилот? Ответ также очевиден: да. В своем определении гвоздодера Вы предложили определять его только теми экстентами, когда они выполняли функцию, но в другие моменты времени Вы отказали экстенту быть связанным с функциональным объектом гвоздодер. Я же говорю о том, что гвоздодер — это экстент длиной 10 лет. И молоток — это экстент длиной 10 лет. И эти экстенты равны друг другу точно также как равны экстенты многофункционального физического объекта, который выполняет множество разных функций.
Если я понятно выразил свою мысль, то Вам должно стать очевидным, что функции можно складывать, вычитать.
Да, наверно так и надо трактовать мои потуги нарисовать свое представление о моделируемых предметных областях. Я только начал излагать основы этого видения. Далее пойдут более сложные конструкции. От операций я перейду к процессам, функциям. И дать определения этих конструкций мне удастся только на основе моего определения события. ИСОшное для этого не годится. Поэтому пришлось ввести свое.
В проектировании активности предприятия смена масштаба — это явление рядовое и нужное. Мы описываем активность с разных точек зрения и с разным масштабом. Ваше предложение сводится к тому, чтобы исключить трассировку между моделями. Это плохая идея. Трассировка как раз и делает модели частями одного целого. В этом и стоит задача. Как сделать множество моделей активности с разной степенью детализации, с разных точек зрения и при этом сохранить трассировку. Иначе — рушится идея создания модели для всех этапов жизненного цикла.
Спасибо огромное за комментарий! Я хочу подчеркнуть, насколько важно то, что Вы сейчас сказали. Технарям действительно не нужны философские рассуждения. Им нужны практические рецепты применения этих рассуждений. Но вот тут собака-то и порылась. Вы как собираетесь моделировать предметную область? ER-диаграммами? Диаграммами классов? И тот и другой метод проектирования дают точность в полкилометра мимо. Если Вас устраивает такая точность, то Вы вполне можете использовать существующие методы проектирования данных. Но, если вы хотите полновесного попадания в цель, то Вам придется учиться очень много и очень долго.
Далее Вы будете «автоматизировать процессы». Если Вы действительно хотите помочь организации. то Вам придется глубоко проникнуть в суть того, что такое «процесс». Иначе Вы просто не сможете учесть то множество корреляций, которое (множество) в итоге развалит всю стройность планируемой системы. Как правило, эти корреляции исключаются на уровне интуиции. Однако, поскольку нет языка, чтобы это описать, нет возможности этому научить. И следовательно, мы как алхимики учимся на собственных ошибках за счет клиента.
Повторюсь, большинство аналитиков не знают того, о чем я пишу. И большинству аналитиков это не нужно. И большинству аналитиков это не интересно. Я прекрасно отдаю себе отчет в этом. Однако, существуют немного людей, которым также как и мне важно знать, что они делают и почему именно так надо делать, а не иначе. Вот для них я пытаюсь описать свое видение, потому что другие точки зрения меня пока не устраивают.
Про Куликовскую битву — этот пример показывает неверное определение термина события в ИСО. Нет событий в природе нулевой ширины. Это я как доктор физик говорю. Всегда мы найдем такую точку зрения, которая покажет нам ненулевую ширину события.
Видимо в ИСО пропущен тот класс объектов, который мне необходим для моделирования предметной области. Мне нужен объект, который бы говорил нам, как мы рассматриваем данный экстент: как объект, как операцию, как информационный объект, или как функцию. Этот первый шаг позволит нам настроить наше восприятие и начать описывать экстент так, как мы договорились его описывать. Это можно описать так. Предположим мы учимся моделированию сущего и учитель просит нас описать данный экстент в виде объекта, затем в виде операции, а затем в виде события. И мы старательно настраиваем свое восприятие, чтобы описать экстент в том или ином виде. Вот что мне нужно — это двухшаговая модель. От экстента — к его представлению в виде объекта и затем от представления экстента в виде объекта к субъективным моделям этого объекта. При этом на первом шаге я получаю описание экстента в виде физической модели в соответствии с выбранным шаблоном(объект, операция и проч), а на втором я получаю субъективную трактовку этому описанию.
Для одного молоток, для другого гвоздодер. Молоток — функциональный объект. Гвоздодер — тоже функциональный объект. Отличаются только тем, что один субъект считает эту железяку молотком, а второй — гвоздодером. Я правильно рассудил? Если да, то функциональные объекты отличаются только точкой зрения на них.
Если событие — временная граница, то она не может быть неким фронтом, о котором говорится в ИСО. Это первая претензия к термину событие. Вторая — это невозможность рассмотрения события более пристально, если это понадобится, а именно в виде операции, например. Но в жизни это сплошь и рядом: событие Куликовская битва при ближайшем рассмотрении становится операцией, или функцией, или функциональной структурой и так далее. Третья претензия — это невозможность отразить множественность трактовок одного события. Теперь активность. Этот зверь в ИСО вообще подернут туманом. Я назвал 4 структуры, которые мне известны: операция, процесс, функция, функциональная структура. Это далеко не все конструкции, которые можно придумать, но наиболее распространенные. Активность — это про что? Из определения не поймешь.
Экстенты равны друг другу, если совпадают. Это абсолютно понятно. Далее: один экстент может трактоваться как функциональный объект, как информационный объект, как операция. Это тоже не должно вызывать нареканий, потому что в ИСО нет ограничений на экстенты, которые могут трактоваться так и не могут трактоваться иначе. То есть, любой экстент ассоциируется с любым количеством функциональных объектов, информационных объектов и операций. В моем мире события — тоже 4-Д объекты. Причину я изложил подробно в статье. Поэтому любой экстент может трактоваться как событие. Я не знаю, какие термины ввести, чтобы сказать простую вещь: что есть трактовка экстента как объекта, события, операции и есть трактовка уже объекта, событие и операции. Я принял допущение, что функциональность объекта, события и операции отражает субъективный взгляд на событие, объект и операцию. (Список объектов можно продолжать). Я не нашел других терминов в ИСО для отражения субъективной точки зрения. Именно функциональность объектов отличает разные точки зрения на один физический объект. Это и было взято за основу. Если есть другие термины, то они должны быть названы, и приведены в соответствие с терминами физический и функциональный объект.
1. Как описать априорное знание про экстент, которым мы пользуемся, чтобы описывать его как объект, операцию и проч.
2. Как решить задачу: функциональный объект молоток, гвоздодер и молоток-гвоздодер связаны друг с другом некими операциями. Возможно, объединение, вычитание, но чего? смысла? точек зрения? моделей? не знаю, но хочу, чтобы такая возможность была описана явно.
Атрибут не может относится к классу. Атрибут относится к типу. Атрибут — это из логики Аристотеля, у которого нет классов, а есть типы. ООП в этом жестоко нас обмануло. Назвав типы объектов классами. Но про это отдельная песня, которую я сейчас не касался. Я бы рекомендовал Вам использовать термин атрибут и его значение только вместе с термином тип объектов и экземпляр этого типа. Если же говорить о классах, то классы описываются только перечислением их объектов, но не описываются атрибутами. ООП все перепутало.
Теперь про экстент. Я могу рассматривать экстент как физический объект и одновременно как физическую операцию. Модели в моей башке одного и того же экстента, представленного в виде физобъекта или в виде физоперации будут сильно различаться. И эти модели очень сильно будут отличаться от моего представления о функциональном смысле этого физобъекта или физоперации. Более того, в моей башке могут уживаться много представлений о функциональном смысле одного физического объекта или одной физической операции. И все эти представления связаны либо с физобъектом, либо с физоперацией и в конечном результате с одним экстентом. Вот эти связи я хотел бы моделировать. Итак: экстент относится со множество разных физических объектов: операция, объект, событие, и так далее. затем каждый из них я хотел бы связать с субъективной точкой зрения на эти физические объекты.
Итого, если автопилот нами разобран, то я утверждаю, что один и тот же экстент связан с одним и тем же представлением этого экстента в виде физического объекта — железяка и связан с двумя функциональными объектами гвоздодер и молоток. Именно этот кейс я пытался описать.
Из Ваших рассуждений следует вывод, который противоречит тезисам, которые я слышал ранее. Или я думаю, что противоречит. Был вопрос, который ставил Мэтью Вест: автопилот существует, если прибор, который выполняет функцию автопилота, сломался? Ответ — да. Еще один вопрос: автопилот существует, если им в данным момент не пользуется пилот? Ответ также очевиден: да. В своем определении гвоздодера Вы предложили определять его только теми экстентами, когда они выполняли функцию, но в другие моменты времени Вы отказали экстенту быть связанным с функциональным объектом гвоздодер. Я же говорю о том, что гвоздодер — это экстент длиной 10 лет. И молоток — это экстент длиной 10 лет. И эти экстенты равны друг другу точно также как равны экстенты многофункционального физического объекта, который выполняет множество разных функций.
Если я понятно выразил свою мысль, то Вам должно стать очевидным, что функции можно складывать, вычитать.
Далее Вы будете «автоматизировать процессы». Если Вы действительно хотите помочь организации. то Вам придется глубоко проникнуть в суть того, что такое «процесс». Иначе Вы просто не сможете учесть то множество корреляций, которое (множество) в итоге развалит всю стройность планируемой системы. Как правило, эти корреляции исключаются на уровне интуиции. Однако, поскольку нет языка, чтобы это описать, нет возможности этому научить. И следовательно, мы как алхимики учимся на собственных ошибках за счет клиента.
Повторюсь, большинство аналитиков не знают того, о чем я пишу. И большинству аналитиков это не нужно. И большинству аналитиков это не интересно. Я прекрасно отдаю себе отчет в этом. Однако, существуют немного людей, которым также как и мне важно знать, что они делают и почему именно так надо делать, а не иначе. Вот для них я пытаюсь описать свое видение, потому что другие точки зрения меня пока не устраивают.
докторфизик говорю. Всегда мы найдем такую точку зрения, которая покажет нам ненулевую ширину события.Видимо в ИСО пропущен тот класс объектов, который мне необходим для моделирования предметной области. Мне нужен объект, который бы говорил нам, как мы рассматриваем данный экстент: как объект, как операцию, как информационный объект, или как функцию. Этот первый шаг позволит нам настроить наше восприятие и начать описывать экстент так, как мы договорились его описывать. Это можно описать так. Предположим мы учимся моделированию сущего и учитель просит нас описать данный экстент в виде объекта, затем в виде операции, а затем в виде события. И мы старательно настраиваем свое восприятие, чтобы описать экстент в том или ином виде. Вот что мне нужно — это двухшаговая модель. От экстента — к его представлению в виде объекта и затем от представления экстента в виде объекта к субъективным моделям этого объекта. При этом на первом шаге я получаю описание экстента в виде физической модели в соответствии с выбранным шаблоном(объект, операция и проч), а на втором я получаю субъективную трактовку этому описанию.