Comments 78
Если вы сказали, что любая табуретка имеет 4 ножки, — это высказывание не является простым. Это высказывание выполнено в логике предикатов
Нет, вы трактовали его в логике предикатов, схватившись за какое-то знакомое вам слово. Это не означает, что оно было сделано в этой логике.
Когда вы слышите слово "экземпляр" из уст ИТ специалиста, знайте, он — путает простые высказывания с высказываниями в логике предикатов.
Является ли программист ИТ-специалистом?
Признак, или набор этих признаков, с помощью которых происходит классификация объектов, называется типом.
"Называется" в какой системе терминов?
Зачастую аналитик думает, что атрибут — это то, что принадлежит типу объектов. Например, создав таблицу "деревья", моделирующую тип объектов "деревья", он создает атрибут "высота" и считает, что этот атрибут принадлежит этому типу.
Кстати, аналитику не следовало бы создавать таблицы, не его это область деятельности. Но не суть.
Но в предметной области термин "атрибут" имеет совершенно иное значение.
В какой предметной области?
Родной язык нисколько не помогает нам строить модели предметных областей.
Вам не помогает, вы хотели сказать? Кто эти "мы", от имени которых вы говорите?
Например, когда я говорю, что машина белая, в сознании аналитика возникает объект с приклеенным к нему стикером, где написано название свойства: белый.
Вы говорите о каком-то конкретном известном вам аналитике?
Машина со стикером на борту — это образ, который заставляет нас думать, что один из методов классификации является более значимым, чем другой.
Но в конкретной предметной области один из методов классификации действительно более значим, чем другой (не всегда, но в подавляющем большинстве случаев).
Все сталкивались с этим, но никто не понимает, в чем причина.
Причина — ошибка в анализе. Странно, "никто" этого не понимает?
Часто принадлежность двух объектов одному типу, принимается аналитиками за их идентичность.
… хотя казалось бы, это прекрасно описано, например, Эвансом.
пользуемся языком, в котором для каждого изменения в мире должен быть найден актор, ответственный за это изменение
Серьезно? Я не знаю, что за языком вы пользуетесь, но в русском языке есть прекрасный пример "рассвело", где нет никакого актора.
Такая картина навязана языком.
Нет, такую картину пытаетесь навязать вы. В моей голове нет приписываемой вами картины.
Если есть свойство, но нет объекта (светло), то к чему лепить стикер?
Если нет объекта, то нет и свойства. "Светло" — это не свойство. "В комнате светло" — это описание конкретной комнаты.
Раз за разом вы пытаетесь выдумать какие-то "заблуждения" (которых другие люди не разделяют) и навязать им (другим людям) свою понятийную систему, хотя совершенно не понятно, какие задачи это решает.
Или изложены заблуждения других людей, то не понятно как часто и при каких обстоятельствах автор их встречал. Это студенты или практикующие аналитики и автор проверял их работы и т.д. Среди кого и насколько широко распространены эти заблуждения?
Это высказывание выполнено в логике предикатов, в которой есть возможность говорить об общих свойствах объектов одного множества.
Допустим.
Первая ошибка связана с тем, что аналитики не умеют разделять эти высказывания
Это высказывание в логике предикатов или «простое высказывание»?
Дальше читать лень
Когда вы слышите слово "экземпляр" из уст ИТ специалиста, знайте, он — путает простые высказывания с высказываниями в логике предикатов.
А это простое высказывание или высказывание в логике предикатов? )
В общем и в целом не надо путать высказывания хоть в простой логике, хоть в логике предикатов с высказываниями в логике ООП, если считать разработчиков Ит-специалистами. "Экземпляр класса", "экземпляр класса Операция", "экземпляр операции" — вполне валидный и устоявшийся термин в разработке, имеющий конкретное наполнение. Всякие совпадения с бизнес-анализом или логикой предикатов — случайны.
Понятно, что мир большой, и я не слышал ни одного аналитика, который бы говорил подобным образом. Это, конечно, не приводит к тому, что нет аналитиков так говорящих. Заметьте, я не делаю общих выводов из своего ограниченного наблюдения, а вы почему-то делаете. Не придерживаетесь ни формальной, ни о более строгой математической логике.
Вот да.
omfg! Экземпляр операции? Srsly?
Ничего не имею против, просто прошу не обобщать. :)
Первый квадратик он назвал «закрепить заготовку в станке», второй квадратик он назвал: «выточить деталь».
Главная ошибка в семантической формулировке самого предложения. То есть некое реальное действие описано в одном предложении одновременно в нескольких аспектах. Аспекты и их обозначения — по ISO 81346.
«Закрепить» — функция, действие, выраженное глаголом. Это аспект "=" (аспект функции).
«Заготовку» — предмет, существительное. Аспект "-" (продукт).
«В станке» — место (локализация) Локализация это аспект "+". Или тоже аспект «продукт», зависит от точки зрения при построении одной диаграммы.
Модель — это множество диаграмм, построенных с разных точек зрения для разных целей. Диаграмм в модели может быть бесконечное количество. Обычно же диаграмм столько, чтобы понять или объяснить что-то для конкретного заинтересованного лица.
Второе предложение — тоже сразу два аспекта.
Если в одном предложении указаны несколько аспектов — это порождает путаницу и сложности с восприятием.
Корректнее диаграмма из двух кубиков. «закрепить» ---> «выточить».
Стрелочка показывает последовательность действий во времени. Диаграмма, связанная со временем.
Иная диаграмма: «заготовка» ---> «деталь». Диаграмма показывает, например, отношения двух объектов. Статическая диаграмма.
Только важно понимать, кому и для чего нужны диаграммы. Тогда они строятся очень просто и быстро. И если не мешать на одной диаграмме разные аспекты — то тоже все будет в порядке. И лучше, чтобы на диаграмме было от 5 до 9 элементов. Так понимать проще.
Я лишь коротко описал вполне простые и понятные идеи стандарта ISO 81346, но чтобы понимать и принимать такие методологии работы, нужно существенно изменить логику и мировосприятие. На холистический (системный) подход. А это — сложно.
Сразу: модель не диаграммы. Чтобы дать определение модели, стоит написать отдельную статью. Но частью модели являются высказывания. Это — точно.
Согласен. Диаграммы — только графическое представление части информации.
Есть описание при помощи слов. Есть — при помощи эмоций, вызываемых определенным смысловым образом.
Я описал основы более-менее корректного построения диаграмм, используя системный подход. Использование одного аспекта одновременно — один из методов. Можно использовать несколько аспектов одновременно. Но тогда трудно будет понимать части модели. Хотя тогда информации на диаграмме может быть больше.
Вопрос всегда в цели модели с точки зрения «заинтересованного лица». Какая цель — таков и метод для представления реальности в модели.
Проблема возникает, когда аналитик начинает думать, что диаграмма — это полноценная модель предметной области. И тут он сильно ошибается, а вместе с этим, он вводит в заблуждение и заказчика.
Согласен. Лечиться это через описание в Стандарте Организации (СТО) и в регламенте работ идей, которые есть в НЛП. Пример: «Есть реальность и есть карта реальности. Карта реальности не равна целой реальности». Ну и так далее, в НЛП более-менее описано. Плюс сразу же, на уровне регламента и СТО прописываются базовые когнитивные методы, но только через via negativa. То есть через ограничения и чего нельзя делать. Обычно это текст о известных когнитивных искажениях. От «нарратива» до «скрытых свидетельств».
И само описание для Заинтересованного Лица Клиента всегда делается строго с учетом его уровня развития, его любимых когнитивных искажений. Для каждого — свое описание, свои диаграммы. Они обычно похожие на 60-70%, но ключевые элементы модели могут очень разными для разных Лиц.
Опять же, важно установить режим работы в проекте, по аналогии с психологом: работаем в режиме «прескриптивном» (предписание) или «дескриптивном» (описание). Суть: лечим причину болезни (прескриптивный) или то, что пациенту не нравится (дескриптивный). Понятно, что результаты будут разные и шаги будут разные.
Да, модель это всегда редукция.
Разумеется.
— Будь актором, подай чашку с чаем.
— Не могу.
— Почему?
— Объемом не совпадает с содержимым.
— Хорошо. Подай чашку с налитый в нее чаем.
— Не могу.
— Почему?
— Нет чашки с налитым чаем.
— Соверши активность, налей.
— Не могу.
— Почему?
— Нет признаков заварки в объеме помещения.
— Что же ты совершаешь поступательно-возвратные движения членом
в объем занятый моим мозгом?
— Проявляю затребованную активность.
Реальность куда сложнее, если даже философские системы зачастую мало чем помогают в ее понимании и описании.
Согласен. Реальность сложнее в неизвестное число раз.
Философские системы, в том числе редукционизм и холизм, и следствие холизма — системный подход, немного помогают в работах над сложными искусственными системами. Особенно хорошо помогает системный подход.
Можно ли на основе системного подхода получить полные и непротиворечивые модели реальности? Скорее всего нет. Но множество более-менее кривых и косых моделей — можно. Для начала работ — вполне подходит, потом можно отрабатывать качество моделей при необходимости. И лучше применять совокупность методов: от шаманизма и интуиции до математической логики. Важно не считать какие-то методы исключительно верными и единственно применимыми.
Обычно с областью действия методологий и возникают проблемы. Если измерять температуру линейкой — может получиться некорректный результат. Но ошибки в применимости той или иной методологии к моделированию реальности — не так очевидны.
Насчет системного подхода: его существенно развили, улучшили и сделали практически стандартом де-факто в огромном количестве областей знания. Инженерное проектирование (примерно с 2006 года), управления проектами (PRINCE2), медицина, программирование, все более-менее развитое производство, финансирование, группа естествознания, экология. Это на вскидку. И процесс идет весьма успешно и дает неплохие результаты.
Из личного опыта: перестроиться на иную логику (системный подход) крайне сложно и одновременно очень просто. Сложно, если много лет работал по логике редукционизма. Особенно много проблем с классификацией, осознание отношений «целое-части», «реальность» — «модели реальности». Весь системный подход кажется кривым бредом и какой-то фигней, странным набором слов. Но в определенный момент в голове «щелкает» и становится понятно. Для этого может потребоваться и 1 месяц и 4 года, зависит от засранности головы классическим образованием. Уупс… Обычное образование и знания, полученные в 1980-2004 годах обычно больше мешают, чем помогают.
Но результаты стоят усилий. Реальное ускорение инженерных проектов — примерно в 5-7 раз, и это не сложно. Научные проекты — можно шлепать быстро и без усилий. Особенно в социальных и экономических науках.
В химии — тоже несложно, но нужно уметь организовать системными методами работу в лаборатории. А это значит 3-6 месяцев учить людей, причем если после института или «какадемий» — то дольше. Проще брать после школы.
Всякие MES/ERP/MRP/CRP — совсем несложно, особенно в торговле. Сложнее в производстве, но там проблемы обычно с сопряжением на низких уровнях, с событиями в реальном времени. Причем от кривости программ зависят. Сама логика, архитектура, алгоритмы, бизнес-процессы и модели — строятся легко и быстро. Но опять же, только из стандартных «кубиков» (лучшие практики). Лично мне еще ни разу не приходилось сталкиваться ни с одним бизнес-процессом или схемой работы, которая не была бы уже реализована в типовых стандартных решениях. Чего бы не придумали «манагары» — все уже давно известно. Проблема только в изучении этого опыта, а не придумывании чего-то кривого и косого на месте.
Программирование — пока не знаю, большие проекты не делал. Система управления проектами на облачных технологиях (G Suite+Wrike+Draw.io+add) + нифига не облачные ePlan+SolidWorks+иная тяжелая инженерная ботва — этот зоопарк более менее быстро внедрили за 6 месяцев и используем на практике. Ага, и сначала всех перевел на Linux, ибо ну нафиг… Хотя до этого работал 26 лет только на инфраструктуре M$. И да, продукты Autodesk у меня вызывают только уныние, пробовал, ну-нафиг…
И да, понимание системного подхода позволило быстро и просто перейти на иные платформы и эффективно работать с новыми инструментами.
В реляционной модели — это разные атрибуты, в OWL — один
Какие характеристики и их значения есть у этого атрибута, помимо названия?
Ага. То есть в системе имеется запись "Высота, от 0 до 1000000 метров", единицы измерения указаны в атрибуте. У типа "Здание" есть ссылка на него вида "имеет атрибут 'Высота'", у типа "Дерево" тоже есть ссылка "имеет атрибут 'Высота'". Так?
Покажите пример пожалуйста, какие могут быть область определения и область значений у атрибута "Высота"?
Зачем мне теория, если я спросил про пример? Тем более что ссылка ведет на курс "Основы проектирования реляционных баз данных", а спрашивал я про OWL, который вы им противопоставляете.
Я, собственно, зачем спрашивал. Один атрибут для всех теоретически создает много проблем, связанных с заданием и изменением его характеристик, как раз потому что это влияет на всех. Для деревьев, зданий, и гор могут быть разные ограничения атрибута "Высота", а еще есть такое понятие как высота звука.
Поскольку вы в очередной раз уклоняетесь от ответа, то похоже сами не очень разбираетесь. Я поискал и нашел описание OWL. Область определения это оказывается классы, к которым атрибут принадлежит. Также можно задавать ограничения специально для класса.
Кстати, обратите внимание, сколько раз там встречается слово "instance" (of some class). Это как раз тот самый "экземпляр".
В общем-то для случаев, когда у одноименных свойств есть разные ограничения, рекомендуют давать им разные имена. И тогда нет большой разницы, делать отдельное свойство "ВысотаЗвука" или свойство "Высота" класса "Звук", все равно это специальное свойство только для этого класса.
В общем-то для случаев, когда у одноименных свойств есть разные ограничения, рекомендуют давать им разные имена. И тогда нет большой разницы, делать отдельное свойство "ВысотаЗвука" или свойство "Высота" класса "Звук", все равно это специальное свойство только для этого класса.
Йеп-йеп-йеп, именно так. Более того, все эти развлечения проходили в той же EAV, при выборе между глобальным списком атрибутов и утаптывании списка в тип сущностей. И вот у меня тут есть система с глобальным, и это боль.
Why do you want the property name to be the same?
That would mean that everytime you got values from the property you
would either have to test whether you got an integer or a double back,
or else you would have to check the type of the instance.
2
ObjectProperty: isTriggeredBy
Domain: ClassA or ClassC
Range: ClassB or ClassD
A way to achieve this differentiation is to use subproperties
Главное — они никак не связаны с типами объектов.А что в этом полезного-то, если все равно надо делать специальное свойство ВысотаЗвука? И в первой цитате тоже пишут, что одинаковые делать не надо. Там есть разные типы свойств, которые задают разные связи, это да, полезно.
Класс в OWL — это множество в отличие от ООП.Классы там описываются так:
<owl:Class rdf:ID="Wine">
...
</owl:Class>
<owl:ObjectProperty rdf:ID="madeFromGrape">
<rdfs:subPropertyOf rdf:resource="http://www.w3.org/..."/>
<rdfs:domain rdf:resource="#Wine"/>
<rdfs:range rdf:resource="#WineGrape"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="hasWineDescriptor">
<rdfs:domain rdf:resource="#Wine"/>
<rdfs:range rdf:resource="#WineDescriptor"/>
</owl:ObjectProperty>
А в языках программирования так:
class Wine
{
WineGrape madeFromGrape;
WineDescriptor hasWineDescriptor;
}
Если первое это множество, то и второе тоже.
"… we need to have a mechanism to describe the classes that individuals belong to and the properties that they inherit by virtue of class membership"
"… нам нужен механизм для описания классов, к которым принадлежат индивидуальности, и свойств, которые они наследуют благодаря принадлежности к классу"
Вот ООП это тоже такой механизм. У него меньше возможностей, чем у OWL, но описывать он позволяет.
Тип точно так же задает характеристики объектов множества, как и разметка OWL. А например
<WineGrape rdf:ID="CabernetFrancGrape"/>
это объявление типизированного объекта, аналогично
var madeFromGrape = new WineGrape('CabernetFrancGrape');
Попробуйте для себя сформулировать различия, а не избегать неудобного вопроса, и вы поймете, что их нет. Логически ООП это подмножество OWL, и в этой части различие только в деталях реализации.
Вот еще же хотел поменять на "момент", подумал что вы поймете, какое из значений имеется в виду, но вы видимо не в курсе.
ВОПРОС — Словарь Ожегова
"2. То или иное положение, обстоятельство как предмет изучения и суждения, задача, требующая решения, проблема."
Почитайте, там и другие значения есть. Но если вам нужен набор символов с вопросительным знаком, то вот он: "В чем логические различия первой и второй записи для моделирования свойств объектов?".
И кстати, если предположить, как из описания класса в RDF можно сделать множество, то под формулировку "это множество" попадает таблица из базы данных.
Я моделирую в OWL и знаю, что в одном классе могут находиться объекты разных типов, чего в ООП невозможно.
Вы, как обычно, не в курсе по поводу того, что возможно в ООП.
Я моделирую в OWL и знаю, что в одном классе могут находиться объекты разных типовДавайте не будем заниматься демагогией. В OWL нет отдельно классов объектов и отдельно типов объектов, объекты сразу объявляются с указанием класса. По тексту в описании OWL слова «тип» и «класс» используются как синонимы:
<owl:Class rdf:ID="Region"/> <owl:Thing rdf:about="#CentralCoastRegion"> <rdf:type rdf:resource="#Region"/> </owl:Thing>
«according to their specific type, WineColor»
«Note that the use of range and domain information in OWL is different from type information in a programming language. Among other things, types are used to check consistency in a programming language. In OWL, a range may be used to infer a type.»
То есть ваше утверждение превращается в «в одном классе могут находиться объекты разных классов».
В ООП объект некоторого класса является объектом и всех родительских классов. В OWL есть и другие виды связей. Это никак не противоречит моему утверждению про подмножество.
В последней цитате описаны различия между OWL и языками программирования, и с учетом более широких возможностей это логично.
От такого аналитика часто можно услышать: «экземпляр класса», с помощью которого он пытается указать на объект — элемент этого множества. Он путает два тезиса: «экземпляр типа» и «элемент множества».
Класс в OWL — это множество в отличие от ООП.
По поводу «instance». Там везде употребляется выражение «instance of some class», что на русский переводится «экземпляр такого-то класса». Если там класс это множество, значит «экземпляр класса» в значении «элемент множества» это допустимое выражение, а ваши утверждения по этому поводу неверны.
А вы почему не пишете, к такому контексту относятся термины? Тип — это и тип в пальто, и тип прутка проката.
… а кроме различий между классом в ООП и OWL вы больше вопросов в комменте, на который вы отвечаете, не увидели? В частности, что полезного в том, что можно сделать сколько угодно свойств с одним именем, и вообще в том, что свойства не связаны с типом объекта?
А я-то наивно думал, что область значений у высоты здания и высоты дерева — разная.
Вы вроде как недавно писали, что область значения и область определения — это характеристики атрибута "высота", который у здания и дерева общий, то есть один. Это значит, что — поскольку это характеристики атрибута — они одинаковые и в случае применения "высоты" к зданию, и в случае применения "высоты" к дереву. Так что не очень важно, что куда отображается, важно, что эти множества не меняются в зависимости от того, в какой сущности применен атрибут.
Во-первых, 100 и 1000 метров — это два порядка (в том смысле, что разница на порядок). А во-вторых, для системы, учитывающей деревья, разрешать ввод высоты в километр — неумно, коллеги засмеют.
А на сколько её ограничивать, если 116 метров реальное значение? 116? 117? 119? 127? 199? 255?
999 выглядит вполне разумным значением — тот же порядок, что известный практический максимум с довольно большим запасом.
Левая граница включительно, правая невключительно — один порядок
Это называется "подгонка под ответ".
А на сколько её ограничивать, если 116 метров реальное значение?
Это хороший вопрос к специалисту в предметной области.
999 выглядит вполне разумным значением — тот же порядок, что известный практический максимум с довольно большим запасом.
Есть маленький нюанс: по этой же логике для зданий нужно брать 9999. Все равно отличается.
У меня в хлебопечке «вес» — это 3 значения: 0.5, 0.75, 1кг и все.
Про здания и деревья вот пример: в задаче выдачи разрешения от аэропорта на строительство здания/сооружения высота объекта вообще считается в единицах метров, но от уровня моря. Тут может оказаться, что здание — 1050м, дерево на соседнем холме — 1150м.
В итоге понимать, как в физическом мире измеряется величина перед сохранением и как потом она будет использоваться после вывода из системы — критически важно.
У меня в живой практике коллега один раз запилил для паспорта объекта благоустройства возраст дерева в годах без всякого указания года высадки и был доволен.
С другой стороны явный перебор с максимализмом и довольно слабое понимание из чего состоит работа БА/СА ИРЛ.
Если вы сказали, что у табуретки 4 ножки, то вы сделали простое высказывание. Если вы сказали, что любая табуретка имеет 4 ножки, — это высказывание не является простым. Это высказывание выполнено в логике предикатов, в которой есть возможность говорить об общих свойствах объектов одного множества.
Второе высказывание является точно таким же простым, как первое, и вполне себе принадлежит логике высказываний. Разберитесь в вопросе прежде чем статьи писать.
Множество бессвязных и нелепых утверждений.
Ну да, проще назвать вопросы "бессвязными и нелепыми утверждениями", чем пытаться на них ответить.
А, чтобы делать модели, этого, естественно, мало
Вы так говорите, как будто познания в математической логике являются необходимыми для того, чтобы делать модели.
Множество бессвязных и нелепых утверждений. Я об этом и написал: мало, кто из аналитиков имеет хотя бы начальную подготовку в математической логике.
Уважаемый, я выше вам указал, что первое же утверждение в вашей статье — с математической точки зрения просто нонсенс.
И ладно, если бы это была какая-то фигура речи, метафора, или еще что-то подобное — все же статья не математическая, такие вещи вполне допустимы.
Но вы же потом из этого вполне строго пытаетесь делать какие-то глубокоидущие выводы. А потом еще говорите, что кто-то "не может в математическую логику".
Вам не стыдно, нет?
Эти высказывания друг от друга отличаются, это несомненно. Однако эти высказывания можно отнести к одному и тому же типу.
Ну так ничего не мешает этим высказываниям быть отнесенным к типу "простое предложение".
… ах, подождите, вы хотели сказать, что эти высказывания относятся к разным типам в рамках типологии, введенной в символической логике? Ну во-первых, я что-то не помню, чтобы где-то был введен закон, что все высказывания трактуются только в терминах математической логики. И вы успешно игнорируете комментарии, где вам говорят, что принудительное введение удобной вам логической системы — это бессмысленное насилие над дискуссией.
Но даже если мы вдруг на мгновение примем, что мы существуем в рамках математической логики, то у меня есть для вас неприятный сюрприз: фраза "операции данного типа начинаются в 17-00 каждый день" не является высказыванием, это высказывательная форма, она неполна, в ней первый объект ("операции данного типа") — это не объект, а предметная переменная. Чтобы эта форма стала высказыванием, необходимо эту переменную заменить на конкретное значение или, наоборот, подставить квантор ("некоторые операции" или "все операции"). Кстати, та же ошибка у вас и в первом абзаце.
Что самое забавное, подставив квантор (ну, например, всеобщности), мы получим высказывание "все операции… начинаются в 17:00 каждый день", которое… неоднозначно, потому что из него нельзя сделать вывод о том, сколько операций начинается в 17:00 каждый день.
Мы приходим еще к одной ошибке: ИТ специалисты тип объектов называют объектом.
Какие-то странны ИТ-специалисты в вашей реальности.
Чтобы куда-то прийти, надо сначала уйти. Вы уже согласились с тем, что ваше утверждения о символической логике неверны?
(а то, куда вы пытаетесь прийти, называется "синекдоха", и ошибкой в принятом смысле этого слова не является)
Вы извините, но у нас с вами разное представление о логике. наверное.
О логике не бывает никаких представлений, есть вполне четкие и однозначные определения.
Если я делаю простое высказывание относительно операции: данная операция началась в 17-00 23-июля, то я понимаю, что это высказывание отличается от высказывания типа: операции данного типа начинаются в 17-00 каждый день
Оба этих высказываний являются, по определению, корректными высказываниями в логике высказываний. Что бы вы себе ни представляли и что бы вы себе там ни отличали.
Заблуждения аналитика