Заблуждение первое: аналитик путает высказывание в логике высказываний с высказыванием в логике предикатов
Если вы сказали, что у табуретки 4 ножки, то вы сделали простое высказывание. Если вы сказали, что любая табуретка имеет 4 ножки, — это высказывание не является простым. Это высказывание выполнено в логике предикатов, в которой есть возможность говорить об общих свойствах объектов одного множества.
Первая ошибка связана с тем, что аналитики не умеют разделять эти высказывания. Допустим, что аналитик нарисовал диаграмму в нотации BPMN: два квадратика, связанных друг с другом стрелкой. Первый квадратик он назвал "закрепить заготовку в станке", второй квадратик он назвал: "выточить деталь". При этом аналитик сказал: после операции "закрепить заготовку в станке" следует операция "выточить деталь". Что он имел ввиду? Он имел ввиду, что после операции типа "закрепить заготовку в станке" следует операция типа "выточить деталь". То есть, он построил высказывание в предикатах первого порядка. Однако, аналитик путает простые высказывания с высказываниями в логике предикатов и думает, что он сделал простое высказывание.
Следствие из первого заблуждения: в ИТ отрасли появился костыль, прикрывающий эту ошибку. Этот костыль — слово экземпляр. Когда вы слышите слово "экземпляр чего-то" из уст аналитика, знайте, он — путает простые высказывания с высказываниями в логике предикатов.
Заблуждение второе: аналитик не понимает, что такое тип объектов и чем он отличается от класса объектов
Для подавляющего количества случаев, с которыми работает аналитик, класс — это обычное математическое множество. Множества строятся человеком для разных целей. Одна из них — объединение объектов по общим признакам. Например, все, кто вскармливаются молоком, называются млекопитающие. Признак, или набор этих признаков, с помощью которых происходит классификация объектов, называется типом. Тогда класс объектов, объединенный одним набором признаков, связан с типом (набором признаков). Некоторые множества не обладают общим признаком и задаются перечислением их элементов. Аналитик, не различающий класс и тип, часто путает слова: экземпляр и элемент. От такого аналитика часто можно услышать: "экземпляр класса", с помощью которого он пытается указать на объект — элемент этого множества. Он путает два тезиса: "экземпляр типа" и "элемент множества". Экземпляр типа слон — это слон (часто пишут: экземпляр слона, пропуская слово тип). Экземпляр типа класс — это класс (пропуская слово тип, получаем: экземпляр класса). Но аналитики, путающие типы и классы, могут сказать экземпляр класса, но иметь при этом ввиду не класс, а его элемент. Усугубляет эту ошибку созвучие слов "экземпляр" и "элемент" и ООП, в котором тип объектов назван классом.
Заблуждение третье: непонимание того, что такое атрибут
Зачастую аналитик думает, что атрибут — это то, что принадлежит типу объектов. Например, создав таблицу "деревья", моделирующую тип объектов "деревья", он создает атрибут "высота" и считает, что этот атрибут принадлежит этому типу. На это наталкивает его структура реляционной БД, в которой понятие "тип" связано с таблицей, а понятие "атрибут" связано с названием колонки в этой таблице. Но в предметной области термин "атрибут" имеет совершенно иное значение. Если тип — это набор признаков, позволяющих из множества объектов отобрать те из них, которые удовлетворяют этим признакам, то атрибут — это множество таких наборов. Тип создан для того, чтобы выделять из множества объектов его подмножество, атрибут — чтобы делить множество объектов на не пересекающиеся подмножества со своими значениями. Если проводить аналогию, то типу соответствует значение атрибута. При этом атрибут никак не связан с типом. Атрибут — это отдельный способ классификации объектов, не связанный с типом. Однако, можно объекты одного типа разделить на группы в соответствии со значениями атрибута. И тогда рождается то представление, которое есть у большинства аналитиков: атрибут принадлежит типу. Правда, высота у деревьев — это тот же атрибут, что и высота и зданий? В реляционной модели — это разные атрибуты, в OWL — один.
Про атрибуты рекомендую посмотреть лекции
Заблуждение четвертое: свойство не связано с объектом
Родной язык нисколько не помогает нам строить модели предметных областей. Например, когда я говорю, что машина белая, в сознании аналитика возникает объект с приклеенным к нему стикером, где написано название свойства: белый. Однако, как мы выяснили: ни атрибут, ни его значение никак не связаны с типом. Значение атрибута — это один из способов классификации четырехмерного пространственно-временного объема наравне с типом. Тип классифицирует выбранный четырехмерный пространственно-временной объем как машину, значение атрибута классифицирует этот объем как белый. Соединив две точки зрения, мы получаем, что, с одной стороны, выбранный объем можно классифицировать как машину, с другой стороны — как белый. Но белый при этом не является свойством машины, как и машина не является свойством белого. Машина со стикером на борту — это образ, который заставляет нас думать, что один из методов классификации является более значимым, чем другой. Это приводит к коллизиям, с которыми знакомы все аналитики: начинаем дорабатывать модель, и то, что раньше казалось значением атрибута, теперь надо сделать отдельным классом, то, что раньше моделировалось полем в таблице, теперь надо выделить в отдельную таблицу. Все сталкивались с этим, но никто не понимает, в чем причина. А причина в том, что аналитик до сих пор пользуется представлениями о стикере, приклеенном к объекту. Чтобы побороть в себе привычку так мыслить, я использовал следующий прием: я учился лепить стикер "машина" на свойство "белый". Попробуйте, это занятно.
Заблуждение пятое: "такой же" иногда значит "похожий"
Часто принадлежность двух объектов одному типу, принимается аналитиками за их идентичность. Кажется, что такое невозможно, но я постоянно сталкиваюсь с подобной коллизией. Например, если аналитику показать два похожих велосипеда, он не задумываясь скажет, что это — два разных объекта, но если ему показать две похожих операции, он уже не будет столь быстр с ответом и, скорее всего, скажет, что все зависит от точки зрения. Если же аналитику показать два похожих друг на друга свойства, например, показать два белых, то в этом случае аналитик не будет сомневаться ни секунды и скажет, что это — идентичные свойства.
Идентичным для объектов, свойств и операций являются признаки, которые их объединяют, но не сами объекты, свойства или операции. Аналитику надо научиться понимать разницу между типом объектов, свойств и операций и объектами, свойствами и операциями данных типов. Тогда он сможет делать следующие запросы: покажи мне информацию о всех операциях типа "упаковать деталь в контейнер", совершенных с 18-00 по 19-00 в данном цехе. Но аналитик почему-то тип операций называет операцией, а операции данного типа — экземплярами этой операции, и поэтому в запросе он вместо информации об операциях одного типа просит дать информацию о неведомых зверях: каких-то экземплярах операции.
Если с экземплярами операции как-то можно справиться (в смысле можно закрыть глаза на нерусский язык, которым пользуется аналитик, когда произносит "экземпляр этой операции"), то со свойствами такой номер не пройдет. Если идентификация операции в бизнес-анализе связана со словом "экземпляр", то идентификация свойства невозможна в принципе! Я долго пытался понять, в чем причина этого, и единственную подсказку я получил в психологии. Оказывается, первобытный человек, различая объекты, не различал действия и свойства. Для него вчерашний поход на охоту был идентичным походу сегодня. То есть физически идентичным, потому что в сознании первобытного человека время текло циклично, а не линейно, как сейчас.
Понятно, что процесс создания функции для оценки свойств одного типа, благодаря которому рождается понятие атрибута и его значений, тоже остается за границей познаний аналитика. А жаль, потому что он начинает путать свойство со значением атрибута, классифицирующего это свойство.
Заблуждение шестое: активность часто путают с деятельностью
Деятельность предполагает наличие разумного актора, цели, инструмента деятельности, объекта деятельности, акта деятельности, результата деятельности. Весь этот набор как калька скопирован с нашего языка, в котором есть подлежащее, сказуемое, дополнение. Мы уже давно не одушевляем Солнце или машину, но пользуемся языком, в котором для каждого изменения в мире должен быть найден актор, ответственный за это изменение. Например, если речь зашла о свечении, то должен быть тот, кто светит, например, Солнце, если едет, то ответственным за езду является машина. Но есть другой метод моделирования изменений. Этот метод связан с понятием активность. Активность — это описание изменений физического мира, в котором нет актора.
Например, высказывание "машина едет с 18-00 по 19-00" воспринимается аналитиком как объект, совершающий движение. При этом аналитик думает, что машина реально что-то совершает, вплоть до того, что она прикладывает усилия к перемещению! Такая картина навязана языком. Однако, с точки зрения описания активности, есть дорога, машина, наблюдатель, атмосфера и прочие участники движения. В такой парадигме машина не едет, она участвует в движении наравне с другими участниками движения.
Для описания активности у нас в языке есть другая калька: безличные предложения. К сожалению, эта калька не развита в полной мере. Поэтому родной язык при моделировании активности нам не помощник. Если, моделируя деятельность, мы ищем исполнителей ролей актора, инструмента, объекта деятельности и результата, то моделируя активность, мы забываем о ролях, и остаются только участники активности. Моделируя деятельность, мы говорим: для того, чтобы купить продукты, надо поехать в магазин на машине. Моделируя активность, мы говорим: покупка продуктов состоит из поездки в магазин за продуктами. Моделирование активности позволяет нам понять физику происходящего, заменяя субъективные причинно-следственные связи на объективные "часть-целое" и "предшествует-следует". Этот язык предполагает описание фактов без субъективной их интерпретации.
Одновременно с пониманием того, что такое активность, приходит понимание физического смысла таких понятий как операция и функция. Это — пространственно-временные объемы, трактуемые нами как операции, или как функции. В теории деятельности нет понятия пространственно-временного объема, поэтому находясь в рамках этой парадигмы, понять физический смысл операций, или функций невозможно. Если в модели активности операция или функция распадается на множество под-операций или под-функций, то это значит, что один пространственно-временной объем распался на несколько (как правило, пересекающихся). В теории деятельности такая декомпозиция моделируется в сознании аналитика причинно-следственными связями, о которых можно спорить бесконечно, потому что они субъективны и недоказуемы.
С точки зрения моделирования активности есть факт: дорога, машина, атмосфера, наблюдатель, который сообщает нам, что машина едет по дороге. Функция движения — это пространственно-временной объем, включающий в себя все перечисленное. С точки зрения активности машина является частью функции движения наравне с другими ее частями.
Итоги
Итак, подведем итоги.
Физический смысл объекта для аналитика — это кусок пространства, который он может пощупать, или увидеть.
Физический смысл свойства для аналитика — это стикер с названием свойства, приклеенный к объекту.
Физический смысл операции для аналитика — это фильм, в котором кто-то что-то делает.
Если есть свойство, но нет объекта (светло), то к чему лепить стикер? Тогда стикер можно налепить на пространство в целом и сказать, что свойство — это интерпретация пространства, сделанная наблюдателем.
Если есть операция, но нет актора (взрыв сверхновой), то кто это делает? Аналитик говорит: поделим операции на те, у которых есть актор (бизнес-операции) и те, у которых его нет (естественные операции). Аналитик полагает, что во вселенной есть что-то, отличное от естественных операций. Далее он закрепляет правило, что в любой бизнес-операции должен быть актор, даже, если это — неодушевленный объект типа информационной системы, или принтера. Таким образом, выкрутившись из одной коллизии, аналитик создает другую: неодушевленного актора. Кроме того, не понятно, кого назначить актором, когда претендентов на его место больше одного. Решение этой проблемы есть. Оно в том, чтобы отказаться от поиска акторов, и, вместо моделирования деятельности заняться моделированием активности. А в модели активности пусть каждый сам решает, кто актор, а кто нет.
Получается, что объект, свойство, операция — все это разные трактовки пространственно-временных объемов, сделанные наблюдателем. Этот тезис был положен в основу парадигмы моделирования, предложенную Крисом Партриджем и Мэтью Вестом, на основе которого создавался стандарт моделирования предприятий непрерывного цикла ИСО 15926.
Модель трактовки четырехмерного пространственно-временного объема я предложил в своей работе.
Понять ее за один раз невозможно, говорят, что понимание приходит с четвертого прочтения. По идее после понимания этой статьи должно прийти понимание неразделимости пространства и времени, а также умение представлять их вместе.
Комментарии (53)
ChePeter
21.08.2018 12:43+2В статье заблуждения автора, которые он преодолел и делится опытом?
Или изложены заблуждения других людей, то не понятно как часто и при каких обстоятельствах автор их встречал. Это студенты или практикующие аналитики и автор проверял их работы и т.д. Среди кого и насколько широко распространены эти заблуждения?
Sdima1357
21.08.2018 12:46+2Это высказывание выполнено в логике предикатов, в которой есть возможность говорить об общих свойствах объектов одного множества.
Допустим.
Первая ошибка связана с тем, что аналитики не умеют разделять эти высказывания
Это высказывание в логике предикатов или «простое высказывание»?
Дальше читать лень
VolCh
21.08.2018 13:57Когда вы слышите слово "экземпляр" из уст ИТ специалиста, знайте, он — путает простые высказывания с высказываниями в логике предикатов.
А это простое высказывание или высказывание в логике предикатов? )
В общем и в целом не надо путать высказывания хоть в простой логике, хоть в логике предикатов с высказываниями в логике ООП, если считать разработчиков Ит-специалистами. "Экземпляр класса", "экземпляр класса Операция", "экземпляр операции" — вполне валидный и устоявшийся термин в разработке, имеющий конкретное наполнение. Всякие совпадения с бизнес-анализом или логикой предикатов — случайны.
maxstroy Автор
21.08.2018 14:03Я имел ввиду аналитиков, которые приходят к заказчику и говорят: экземпляр этой операции. Вот это — никуда не годится. С другой стороны, тот же аналитик, общаясь с программистом, может сказать это, но имея ввиду конкретные элементы кода. а не объекты из предметной области. Я говорю о тех аналитиках, которые моделируют предметные области и в них совершают подобные ошибки, а не те, которые в разговоре с программистом обсуждают код программы.
SellerOfSmiles
21.08.2018 17:15+1Мне кажется автор статьи имеет ряд заблуждений относительно аналитиков…
Ничего не имею против, просто прошу не обобщать. :)maxstroy Автор
21.08.2018 17:33-1Я поделился своими наблюдениями. Это не обобщение, это статистика. Возможно, есть те, кто не делают эти ошибки, я не утверждаю, что их нет. Я говорю о среднестатистическом аналитике, с которым заказчик чаще всего имеет дело.
CheY
21.08.2018 19:09А автор в реальной коммерческой практике много встречал аналитиков (полагаю, что речь про системных и/или бизнес-аналитиков), которые хоть частично используют аппарат, который здесь описан? То есть сыпет фразами «экземпляр операции», задумывается о корректности использования понятия «атрибут», «тип»…
surVrus
21.08.2018 19:10Первый квадратик он назвал «закрепить заготовку в станке», второй квадратик он назвал: «выточить деталь».
Главная ошибка в семантической формулировке самого предложения. То есть некое реальное действие описано в одном предложении одновременно в нескольких аспектах. Аспекты и их обозначения — по ISO 81346.
«Закрепить» — функция, действие, выраженное глаголом. Это аспект "=" (аспект функции).
«Заготовку» — предмет, существительное. Аспект "-" (продукт).
«В станке» — место (локализация) Локализация это аспект "+". Или тоже аспект «продукт», зависит от точки зрения при построении одной диаграммы.
Модель — это множество диаграмм, построенных с разных точек зрения для разных целей. Диаграмм в модели может быть бесконечное количество. Обычно же диаграмм столько, чтобы понять или объяснить что-то для конкретного заинтересованного лица.
Второе предложение — тоже сразу два аспекта.
Если в одном предложении указаны несколько аспектов — это порождает путаницу и сложности с восприятием.
Корректнее диаграмма из двух кубиков. «закрепить» ---> «выточить».
Стрелочка показывает последовательность действий во времени. Диаграмма, связанная со временем.
Иная диаграмма: «заготовка» ---> «деталь». Диаграмма показывает, например, отношения двух объектов. Статическая диаграмма.
Только важно понимать, кому и для чего нужны диаграммы. Тогда они строятся очень просто и быстро. И если не мешать на одной диаграмме разные аспекты — то тоже все будет в порядке. И лучше, чтобы на диаграмме было от 5 до 9 элементов. Так понимать проще.
Я лишь коротко описал вполне простые и понятные идеи стандарта ISO 81346, но чтобы понимать и принимать такие методологии работы, нужно существенно изменить логику и мировосприятие. На холистический (системный) подход. А это — сложно.maxstroy Автор
22.08.2018 09:05Сразу: модель не диаграммы. Чтобы дать определение модели, стоит написать отдельную статью. Но частью модели являются высказывания. Это — точно.
surVrus
22.08.2018 10:53Сразу: модель не диаграммы. Чтобы дать определение модели, стоит написать отдельную статью. Но частью модели являются высказывания. Это — точно.
Согласен. Диаграммы — только графическое представление части информации.
Есть описание при помощи слов. Есть — при помощи эмоций, вызываемых определенным смысловым образом.
Я описал основы более-менее корректного построения диаграмм, используя системный подход. Использование одного аспекта одновременно — один из методов. Можно использовать несколько аспектов одновременно. Но тогда трудно будет понимать части модели. Хотя тогда информации на диаграмме может быть больше.
Вопрос всегда в цели модели с точки зрения «заинтересованного лица». Какая цель — таков и метод для представления реальности в модели.maxstroy Автор
22.08.2018 10:59Я пытался в свое время придумать нотацию, в которой можно было бы нативно изобразить высказывания. Не получилось. Все нотации, что мне известны, — это упрощенные графы онтологических связей. Полные графы изобразить не получается, но проекции этих графов — пожалуйста. Проблема возникает, когда аналитик начинает думать, что диаграмма — это полноценная модель предметной области. И тут он сильно ошибается, а вместе с этим, он вводит в заблуждение и заказчика. Это — плохо.
surVrus
22.08.2018 16:58Проблема возникает, когда аналитик начинает думать, что диаграмма — это полноценная модель предметной области. И тут он сильно ошибается, а вместе с этим, он вводит в заблуждение и заказчика.
Согласен. Лечиться это через описание в Стандарте Организации (СТО) и в регламенте работ идей, которые есть в НЛП. Пример: «Есть реальность и есть карта реальности. Карта реальности не равна целой реальности». Ну и так далее, в НЛП более-менее описано. Плюс сразу же, на уровне регламента и СТО прописываются базовые когнитивные методы, но только через via negativa. То есть через ограничения и чего нельзя делать. Обычно это текст о известных когнитивных искажениях. От «нарратива» до «скрытых свидетельств».
И само описание для Заинтересованного Лица Клиента всегда делается строго с учетом его уровня развития, его любимых когнитивных искажений. Для каждого — свое описание, свои диаграммы. Они обычно похожие на 60-70%, но ключевые элементы модели могут очень разными для разных Лиц.
Опять же, важно установить режим работы в проекте, по аналогии с психологом: работаем в режиме «прескриптивном» (предписание) или «дескриптивном» (описание). Суть: лечим причину болезни (прескриптивный) или то, что пациенту не нравится (дескриптивный). Понятно, что результаты будут разные и шаги будут разные.
phenik
22.08.2018 07:05Разговор двух системных аналитиков:
— Будь актором, подай чашку с чаем.
— Не могу.
— Почему?
— Объемом не совпадает с содержимым.
— Хорошо. Подай чашку с налитый в нее чаем.
— Не могу.
— Почему?
— Нет чашки с налитым чаем.
— Соверши активность, налей.
— Не могу.
— Почему?
— Нет признаков заварки в объеме помещения.
— Что же ты совершаешь поступательно-возвратные движения членом
в объем занятый моим мозгом?
— Проявляю затребованную активность.
maxstroy Автор
22.08.2018 12:02Приблизительно так выглядит диалог аналитика с предметником, когда аналитик говорит ему: давайте рассмотрим экземпляр этой операции вместо того, чтобы сказать: рассмотрим эту операцию
phenik
23.08.2018 05:47О, сорри, не думал, что системные аналитики такие чувствительные люди) судя по минусям. Просто раздувание стандарта «моделирования предприятий непрерывного цикла» до вселенских масштабов, и придания физического смысла показалось не совсем обоснованным. Реальность куда сложнее, если даже философские системы зачастую мало чем помогают в ее понимании и описании. А системный анализ в свое время мало чем помог в разработке систем реального времени, связанного с многоканальной регистрацией сигналов медико-биологического назначения, и хранения медийных данных разного типа. В связи со спецификой задач связанных с повышенными требованиями к производительности, больших объемов данных, и их слабой структуированностью приходилось обходиться собственными решениями, а не использовать многочисленные готовые СУБД. И это была типичная ситуация в этой области, и аналогичных по требованиям. А ведь это хлеб системных аналитиков, наверное они немало трудились при их проектировании) Правда, это было в прошлом, возможно в последнее время ситуация улучшилась из-за распространения таких систем, и системные аналитики выдают релевантные решения.
surVrus
23.08.2018 11:30Реальность куда сложнее, если даже философские системы зачастую мало чем помогают в ее понимании и описании.
Согласен. Реальность сложнее в неизвестное число раз.
Философские системы, в том числе редукционизм и холизм, и следствие холизма — системный подход, немного помогают в работах над сложными искусственными системами. Особенно хорошо помогает системный подход.
Можно ли на основе системного подхода получить полные и непротиворечивые модели реальности? Скорее всего нет. Но множество более-менее кривых и косых моделей — можно. Для начала работ — вполне подходит, потом можно отрабатывать качество моделей при необходимости. И лучше применять совокупность методов: от шаманизма и интуиции до математической логики. Важно не считать какие-то методы исключительно верными и единственно применимыми.
Обычно с областью действия методологий и возникают проблемы. Если измерять температуру линейкой — может получиться некорректный результат. Но ошибки в применимости той или иной методологии к моделированию реальности — не так очевидны.
Насчет системного подхода: его существенно развили, улучшили и сделали практически стандартом де-факто в огромном количестве областей знания. Инженерное проектирование (примерно с 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 у меня вызывают только уныние, пробовал, ну-нафиг…
И да, понимание системного подхода позволило быстро и просто перейти на иные платформы и эффективно работать с новыми инструментами.
michael_vostrikov
23.08.2018 06:10В реляционной модели — это разные атрибуты, в OWL — один
Какие характеристики и их значения есть у этого атрибута, помимо названия?
maxstroy Автор
23.08.2018 07:07Область определения и область значений.
michael_vostrikov
23.08.2018 09:39Ага. То есть в системе имеется запись "Высота, от 0 до 1000000 метров", единицы измерения указаны в атрибуте. У типа "Здание" есть ссылка на него вида "имеет атрибут 'Высота'", у типа "Дерево" тоже есть ссылка "имеет атрибут 'Высота'". Так?
maxstroy Автор
23.08.2018 09:51Единицы измерения моделируются отдельно. Про них атрибут не знает. Атрибут не имеет единицы измерения, он имеет только область значений. Единицы измерения — это отдельная тема, которую пока не касались. Далее моделируются области определения и значений. Как они моделируются, — тоже не важно. Например, можно создать классы объектов: область определения атрибута и область значений атрибута. И сослаться на эти классы.
michael_vostrikov
23.08.2018 10:01Покажите пример пожалуйста, какие могут быть область определения и область значений у атрибута "Высота"?
maxstroy Автор
23.08.2018 10:39Классы под названием: область значений и область определения.
michael_vostrikov
23.08.2018 11:01Это понятно. И какая информация в них хранится? Ну значения допустим ясно, целые или дробные числа, а область определения какая может быть?
maxstroy Автор
23.08.2018 14:06Нет, область значений — это множество, как и область определения. Это два разных класса объектов. Целые и дробные числа — это лишь два примера таких множеств. Их может быть сколько угодно и каких угодно. Но вы почитайте теорию. Я дал ссылку.
michael_vostrikov
23.08.2018 16:47+1Зачем мне теория, если я спросил про пример? Тем более что ссылка ведет на курс "Основы проектирования реляционных баз данных", а спрашивал я про OWL, который вы им противопоставляете.
Я, собственно, зачем спрашивал. Один атрибут для всех теоретически создает много проблем, связанных с заданием и изменением его характеристик, как раз потому что это влияет на всех. Для деревьев, зданий, и гор могут быть разные ограничения атрибута "Высота", а еще есть такое понятие как высота звука.
Поскольку вы в очередной раз уклоняетесь от ответа, то похоже сами не очень разбираетесь. Я поискал и нашел описание OWL. Область определения это оказывается классы, к которым атрибут принадлежит. Также можно задавать ограничения специально для класса.
Кстати, обратите внимание, сколько раз там встречается слово "instance" (of some class). Это как раз тот самый "экземпляр".
В общем-то для случаев, когда у одноименных свойств есть разные ограничения, рекомендуют давать им разные имена. И тогда нет большой разницы, делать отдельное свойство "ВысотаЗвука" или свойство "Высота" класса "Звук", все равно это специальное свойство только для этого класса.
lair
23.08.2018 17:16В общем-то для случаев, когда у одноименных свойств есть разные ограничения, рекомендуют давать им разные имена. И тогда нет большой разницы, делать отдельное свойство "ВысотаЗвука" или свойство "Высота" класса "Звук", все равно это специальное свойство только для этого класса.
Йеп-йеп-йеп, именно так. Более того, все эти развлечения проходили в той же EAV, при выборе между глобальным списком атрибутов и утаптывании списка в тип сущностей. И вот у меня тут есть система с глобальным, и это боль.
maxstroy Автор
23.08.2018 19:13Вы можете создавать столько атрибутов с одним именем, сколько пожелаете. Главное — они никак не связаны с типами объектов.
michael_vostrikov
23.08.2018 21:11+1Ну я исходил из информации которую нашел, возможно что-то поменялось.
Скрытый текст1
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
maxstroy Автор
23.08.2018 21:30-1Сорри, я не буду комментировать это, потому что класс в ООП — это тип объектов, а класс в OWL — это множество. Путать одно с другим — это одно из заблуждений, про которые я написал.
michael_vostrikov
23.08.2018 22:00Тип точно так же задает характеристики объектов множества, как и разметка OWL. А например
<WineGrape rdf:ID="CabernetFrancGrape"/>
это объявление типизированного объекта, аналогично
var madeFromGrape = new WineGrape('CabernetFrancGrape');
Попробуйте для себя сформулировать различия, а не избегать неудобного вопроса, и вы поймете, что их нет. Логически ООП это подмножество OWL, и в этой части различие только в деталях реализации.maxstroy Автор
23.08.2018 22:14-1Спасибо! Как скажете. Вы же понимаете, что вам не нужны ответы на вопросы, потому что вопросов у вас нет. У вас — все хорошо. Это хорошо, продолжайте думать так, как считаете.
michael_vostrikov
24.08.2018 07:26Вот еще же хотел поменять на "момент", подумал что вы поймете, какое из значений имеется в виду, но вы видимо не в курсе.
ВОПРОС — Словарь Ожегова
"2. То или иное положение, обстоятельство как предмет изучения и суждения, задача, требующая решения, проблема."
Почитайте, там и другие значения есть. Но если вам нужен набор символов с вопросительным знаком, то вот он: "В чем логические различия первой и второй записи для моделирования свойств объектов?".
И кстати, если предположить, как из описания класса в RDF можно сделать множество, то под формулировку "это множество" попадает таблица из базы данных.
maxstroy Автор
23.08.2018 22:25-1Мне реально надоело объяснять разницу между типом объектов и классом, между атрибутом и тем, что моделируется в ООП, OWL исправил эту ошибку, как матлогика исправила логику Аристотеля. Более мне сказать нечего. Я моделирую в OWL и знаю, что в одном классе могут находиться объекты разных типов, чего в ООП невозможно. Все потому что класс не есть тип.
lair
23.08.2018 23:48Я моделирую в OWL и знаю, что в одном классе могут находиться объекты разных типов, чего в ООП невозможно.
Вы, как обычно, не в курсе по поводу того, что возможно в ООП.
michael_vostrikov
24.08.2018 08:09+1Я моделирую в 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», что на русский переводится «экземпляр такого-то класса». Если там класс это множество, значит «экземпляр класса» в значении «элемент множества» это допустимое выражение, а ваши утверждения по этому поводу неверны.
lair
23.08.2018 23:52… а кроме различий между классом в ООП и OWL вы больше вопросов в комменте, на который вы отвечаете, не увидели? В частности, что полезного в том, что можно сделать сколько угодно свойств с одним именем, и вообще в том, что свойства не связаны с типом объекта?
maxstroy Автор
23.08.2018 19:21-1Класс в OWL — это множество в отличие от ООП. Вы опять путаетесь с типами и классами. Хотя, дело ваше.
maxstroy Автор
23.08.2018 14:34Похоже, я понял, в чем трудность понимания. Область значений и область определения не всегда известны на момент создания ИС. Эти множества могут пополняться по мере наполнения базы. Мы не все сразу знаем, часто мы узнаем новое в процессе работы.
lair
23.08.2018 11:34А я-то наивно думал, что область значений у высоты здания и высоты дерева — разная.
VolCh
23.08.2018 13:46Сильно перескаются — самое высокое дерево выше большинства (субъективно) зданий.
lair
23.08.2018 13:54Самое высокое дерево в мире — 116 м.
Самое высокое здание в мире — 828 м. Так что область допустимых значений пересекается меньше чем на четверть (и это будет падать).
maxstroy Автор
23.08.2018 14:40-1Подмножество из области определения может отображаться на подмножество из области значений. Это как-бы очевидный факт.
lair
23.08.2018 14:58Вы вроде как недавно писали, что область значения и область определения — это характеристики атрибута "высота", который у здания и дерева общий, то есть один. Это значит, что — поскольку это характеристики атрибута — они одинаковые и в случае применения "высоты" к зданию, и в случае применения "высоты" к дереву. Так что не очень важно, что куда отображается, важно, что эти множества не меняются в зависимости от того, в какой сущности применен атрибут.
VolCh
23.08.2018 16:28Одного порядка 100-1000 метров.
lair
23.08.2018 16:33Во-первых, 100 и 1000 метров — это два порядка (в том смысле, что разница на порядок). А во-вторых, для системы, учитывающей деревья, разрешать ввод высоты в километр — неумно, коллеги засмеют.
VolCh
23.08.2018 16:42Левая граница включительно, правая невключительно — один порядок :)
А на сколько её ограничивать, если 116 метров реальное значение? 116? 117? 119? 127? 199? 255?
999 выглядит вполне разумным значением — тот же порядок, что известный практический максимум с довольно большим запасом.lair
23.08.2018 17:14Левая граница включительно, правая невключительно — один порядок
Это называется "подгонка под ответ".
А на сколько её ограничивать, если 116 метров реальное значение?
Это хороший вопрос к специалисту в предметной области.
999 выглядит вполне разумным значением — тот же порядок, что известный практический максимум с довольно большим запасом.
Есть маленький нюанс: по этой же логике для зданий нужно брать 9999. Все равно отличается.
Mimus_spb
23.08.2018 07:31С одной стороны напор автора и глубинная, наивная уверенность в собственной правоте не могут не подкупать читателя. Особенно 20!8 году.
С другой стороны явный перебор с максимализмом и довольно слабое понимание из чего состоит работа БА/СА ИРЛ.
Druu
24.08.2018 07:31+1Если вы сказали, что у табуретки 4 ножки, то вы сделали простое высказывание. Если вы сказали, что любая табуретка имеет 4 ножки, — это высказывание не является простым. Это высказывание выполнено в логике предикатов, в которой есть возможность говорить об общих свойствах объектов одного множества.
Второе высказывание является точно таким же простым, как первое, и вполне себе принадлежит логике высказываний. Разберитесь в вопросе прежде чем статьи писать.
lair
Нет, вы трактовали его в логике предикатов, схватившись за какое-то знакомое вам слово. Это не означает, что оно было сделано в этой логике.
Является ли программист ИТ-специалистом?
"Называется" в какой системе терминов?
Кстати, аналитику не следовало бы создавать таблицы, не его это область деятельности. Но не суть.
В какой предметной области?
Вам не помогает, вы хотели сказать? Кто эти "мы", от имени которых вы говорите?
Вы говорите о каком-то конкретном известном вам аналитике?
Но в конкретной предметной области один из методов классификации действительно более значим, чем другой (не всегда, но в подавляющем большинстве случаев).
Причина — ошибка в анализе. Странно, "никто" этого не понимает?
… хотя казалось бы, это прекрасно описано, например, Эвансом.
Серьезно? Я не знаю, что за языком вы пользуетесь, но в русском языке есть прекрасный пример "рассвело", где нет никакого актора.
Нет, такую картину пытаетесь навязать вы. В моей голове нет приписываемой вами картины.
Если нет объекта, то нет и свойства. "Светло" — это не свойство. "В комнате светло" — это описание конкретной комнаты.
Раз за разом вы пытаетесь выдумать какие-то "заблуждения" (которых другие люди не разделяют) и навязать им (другим людям) свою понятийную систему, хотя совершенно не понятно, какие задачи это решает.