Заблуждения аналитика

Заблуждение первое: аналитик путает высказывание в логике высказываний с высказыванием в логике предикатов


Если вы сказали, что у табуретки 4 ножки, то вы сделали простое высказывание. Если вы сказали, что любая табуретка имеет 4 ножки, — это высказывание не является простым. Это высказывание выполнено в логике предикатов, в которой есть возможность говорить об общих свойствах объектов одного множества.


Первая ошибка связана с тем, что аналитики не умеют разделять эти высказывания. Допустим, что аналитик нарисовал диаграмму в нотации BPMN: два квадратика, связанных друг с другом стрелкой. Первый квадратик он назвал "закрепить заготовку в станке", второй квадратик он назвал: "выточить деталь". При этом аналитик сказал: после операции "закрепить заготовку в станке" следует операция "выточить деталь". Что он имел ввиду? Он имел ввиду, что после операции типа "закрепить заготовку в станке" следует операция типа "выточить деталь". То есть, он построил высказывание в предикатах первого порядка. Однако, аналитик путает простые высказывания с высказываниями в логике предикатов и думает, что он сделал простое высказывание.


Следствие из первого заблуждения: в ИТ отрасли появился костыль, прикрывающий эту ошибку. Этот костыль — слово экземпляр. Когда вы слышите слово "экземпляр чего-то" из уст аналитика, знайте, он — путает простые высказывания с высказываниями в логике предикатов.


Заблуждение второе: аналитик не понимает, что такое тип объектов и чем он отличается от класса объектов


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


Заблуждение третье: непонимание того, что такое атрибут


Зачастую аналитик думает, что атрибут — это то, что принадлежит типу объектов. Например, создав таблицу "деревья", моделирующую тип объектов "деревья", он создает атрибут "высота" и считает, что этот атрибут принадлежит этому типу. На это наталкивает его структура реляционной БД, в которой понятие "тип" связано с таблицей, а понятие "атрибут" связано с названием колонки в этой таблице. Но в предметной области термин "атрибут" имеет совершенно иное значение. Если тип — это набор признаков, позволяющих из множества объектов отобрать те из них, которые удовлетворяют этим признакам, то атрибут — это множество таких наборов. Тип создан для того, чтобы выделять из множества объектов его подмножество, атрибут — чтобы делить множество объектов на не пересекающиеся подмножества со своими значениями. Если проводить аналогию, то типу соответствует значение атрибута. При этом атрибут никак не связан с типом. Атрибут — это отдельный способ классификации объектов, не связанный с типом. Однако, можно объекты одного типа разделить на группы в соответствии со значениями атрибута. И тогда рождается то представление, которое есть у большинства аналитиков: атрибут принадлежит типу. Правда, высота у деревьев — это тот же атрибут, что и высота и зданий? В реляционной модели — это разные атрибуты, в OWL — один.


Про атрибуты рекомендую посмотреть лекции


Заблуждение четвертое: свойство не связано с объектом


Родной язык нисколько не помогает нам строить модели предметных областей. Например, когда я говорю, что машина белая, в сознании аналитика возникает объект с приклеенным к нему стикером, где написано название свойства: белый. Однако, как мы выяснили: ни атрибут, ни его значение никак не связаны с типом. Значение атрибута — это один из способов классификации четырехмерного пространственно-временного объема наравне с типом. Тип классифицирует выбранный четырехмерный пространственно-временной объем как машину, значение атрибута классифицирует этот объем как белый. Соединив две точки зрения, мы получаем, что, с одной стороны, выбранный объем можно классифицировать как машину, с другой стороны — как белый. Но белый при этом не является свойством машины, как и машина не является свойством белого. Машина со стикером на борту — это образ, который заставляет нас думать, что один из методов классификации является более значимым, чем другой. Это приводит к коллизиям, с которыми знакомы все аналитики: начинаем дорабатывать модель, и то, что раньше казалось значением атрибута, теперь надо сделать отдельным классом, то, что раньше моделировалось полем в таблице, теперь надо выделить в отдельную таблицу. Все сталкивались с этим, но никто не понимает, в чем причина. А причина в том, что аналитик до сих пор пользуется представлениями о стикере, приклеенном к объекту. Чтобы побороть в себе привычку так мыслить, я использовал следующий прием: я учился лепить стикер "машина" на свойство "белый". Попробуйте, это занятно.


Заблуждение пятое: "такой же" иногда значит "похожий"


Часто принадлежность двух объектов одному типу, принимается аналитиками за их идентичность. Кажется, что такое невозможно, но я постоянно сталкиваюсь с подобной коллизией. Например, если аналитику показать два похожих велосипеда, он не задумываясь скажет, что это — два разных объекта, но если ему показать две похожих операции, он уже не будет столь быстр с ответом и, скорее всего, скажет, что все зависит от точки зрения. Если же аналитику показать два похожих друг на друга свойства, например, показать два белых, то в этом случае аналитик не будет сомневаться ни секунды и скажет, что это — идентичные свойства.


Идентичным для объектов, свойств и операций являются признаки, которые их объединяют, но не сами объекты, свойства или операции. Аналитику надо научиться понимать разницу между типом объектов, свойств и операций и объектами, свойствами и операциями данных типов. Тогда он сможет делать следующие запросы: покажи мне информацию о всех операциях типа "упаковать деталь в контейнер", совершенных с 18-00 по 19-00 в данном цехе. Но аналитик почему-то тип операций называет операцией, а операции данного типа — экземплярами этой операции, и поэтому в запросе он вместо информации об операциях одного типа просит дать информацию о неведомых зверях: каких-то экземплярах операции.


Если с экземплярами операции как-то можно справиться (в смысле можно закрыть глаза на нерусский язык, которым пользуется аналитик, когда произносит "экземпляр этой операции"), то со свойствами такой номер не пройдет. Если идентификация операции в бизнес-анализе связана со словом "экземпляр", то идентификация свойства невозможна в принципе! Я долго пытался понять, в чем причина этого, и единственную подсказку я получил в психологии. Оказывается, первобытный человек, различая объекты, не различал действия и свойства. Для него вчерашний поход на охоту был идентичным походу сегодня. То есть физически идентичным, потому что в сознании первобытного человека время текло циклично, а не линейно, как сейчас.


Понятно, что процесс создания функции для оценки свойств одного типа, благодаря которому рождается понятие атрибута и его значений, тоже остается за границей познаний аналитика. А жаль, потому что он начинает путать свойство со значением атрибута, классифицирующего это свойство.


Заблуждение шестое: активность часто путают с деятельностью


Деятельность предполагает наличие разумного актора, цели, инструмента деятельности, объекта деятельности, акта деятельности, результата деятельности. Весь этот набор как калька скопирован с нашего языка, в котором есть подлежащее, сказуемое, дополнение. Мы уже давно не одушевляем Солнце или машину, но пользуемся языком, в котором для каждого изменения в мире должен быть найден актор, ответственный за это изменение. Например, если речь зашла о свечении, то должен быть тот, кто светит, например, Солнце, если едет, то ответственным за езду является машина. Но есть другой метод моделирования изменений. Этот метод связан с понятием активность. Активность — это описание изменений физического мира, в котором нет актора.


Например, высказывание "машина едет с 18-00 по 19-00" воспринимается аналитиком как объект, совершающий движение. При этом аналитик думает, что машина реально что-то совершает, вплоть до того, что она прикладывает усилия к перемещению! Такая картина навязана языком. Однако, с точки зрения описания активности, есть дорога, машина, наблюдатель, атмосфера и прочие участники движения. В такой парадигме машина не едет, она участвует в движении наравне с другими участниками движения.


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


Одновременно с пониманием того, что такое активность, приходит понимание физического смысла таких понятий как операция и функция. Это — пространственно-временные объемы, трактуемые нами как операции, или как функции. В теории деятельности нет понятия пространственно-временного объема, поэтому находясь в рамках этой парадигмы, понять физический смысл операций, или функций невозможно. Если в модели активности операция или функция распадается на множество под-операций или под-функций, то это значит, что один пространственно-временной объем распался на несколько (как правило, пересекающихся). В теории деятельности такая декомпозиция моделируется в сознании аналитика причинно-следственными связями, о которых можно спорить бесконечно, потому что они субъективны и недоказуемы.


С точки зрения моделирования активности есть факт: дорога, машина, атмосфера, наблюдатель, который сообщает нам, что машина едет по дороге. Функция движения — это пространственно-временной объем, включающий в себя все перечисленное. С точки зрения активности машина является частью функции движения наравне с другими ее частями.


Итоги


Итак, подведем итоги.


Физический смысл объекта для аналитика — это кусок пространства, который он может пощупать, или увидеть.


Физический смысл свойства для аналитика — это стикер с названием свойства, приклеенный к объекту.


Физический смысл операции для аналитика — это фильм, в котором кто-то что-то делает.


Если есть свойство, но нет объекта (светло), то к чему лепить стикер? Тогда стикер можно налепить на пространство в целом и сказать, что свойство — это интерпретация пространства, сделанная наблюдателем.


Если есть операция, но нет актора (взрыв сверхновой), то кто это делает? Аналитик говорит: поделим операции на те, у которых есть актор (бизнес-операции) и те, у которых его нет (естественные операции). Аналитик полагает, что во вселенной есть что-то, отличное от естественных операций. Далее он закрепляет правило, что в любой бизнес-операции должен быть актор, даже, если это — неодушевленный объект типа информационной системы, или принтера. Таким образом, выкрутившись из одной коллизии, аналитик создает другую: неодушевленного актора. Кроме того, не понятно, кого назначить актором, когда претендентов на его место больше одного. Решение этой проблемы есть. Оно в том, чтобы отказаться от поиска акторов, и, вместо моделирования деятельности заняться моделированием активности. А в модели активности пусть каждый сам решает, кто актор, а кто нет.


Получается, что объект, свойство, операция — все это разные трактовки пространственно-временных объемов, сделанные наблюдателем. Этот тезис был положен в основу парадигмы моделирования, предложенную Крисом Партриджем и Мэтью Вестом, на основе которого создавался стандарт моделирования предприятий непрерывного цикла ИСО 15926.


Модель трактовки четырехмерного пространственно-временного объема я предложил в своей работе.


Понять ее за один раз невозможно, говорят, что понимание приходит с четвертого прочтения. По идее после понимания этой статьи должно прийти понимание неразделимости пространства и времени, а также умение представлять их вместе.

Поделиться публикацией
Комментарии 71
    +8
    Если вы сказали, что любая табуретка имеет 4 ножки, — это высказывание не является простым. Это высказывание выполнено в логике предикатов

    Нет, вы трактовали его в логике предикатов, схватившись за какое-то знакомое вам слово. Это не означает, что оно было сделано в этой логике.


    Когда вы слышите слово "экземпляр" из уст ИТ специалиста, знайте, он — путает простые высказывания с высказываниями в логике предикатов.

    Является ли программист ИТ-специалистом?


    Признак, или набор этих признаков, с помощью которых происходит классификация объектов, называется типом.

    "Называется" в какой системе терминов?


    Зачастую аналитик думает, что атрибут — это то, что принадлежит типу объектов. Например, создав таблицу "деревья", моделирующую тип объектов "деревья", он создает атрибут "высота" и считает, что этот атрибут принадлежит этому типу.

    Кстати, аналитику не следовало бы создавать таблицы, не его это область деятельности. Но не суть.


    Но в предметной области термин "атрибут" имеет совершенно иное значение.

    В какой предметной области?


    Родной язык нисколько не помогает нам строить модели предметных областей.

    Вам не помогает, вы хотели сказать? Кто эти "мы", от имени которых вы говорите?


    Например, когда я говорю, что машина белая, в сознании аналитика возникает объект с приклеенным к нему стикером, где написано название свойства: белый.

    Вы говорите о каком-то конкретном известном вам аналитике?


    Машина со стикером на борту — это образ, который заставляет нас думать, что один из методов классификации является более значимым, чем другой.

    Но в конкретной предметной области один из методов классификации действительно более значим, чем другой (не всегда, но в подавляющем большинстве случаев).


    Все сталкивались с этим, но никто не понимает, в чем причина.

    Причина — ошибка в анализе. Странно, "никто" этого не понимает?


    Часто принадлежность двух объектов одному типу, принимается аналитиками за их идентичность.

    … хотя казалось бы, это прекрасно описано, например, Эвансом.


    пользуемся языком, в котором для каждого изменения в мире должен быть найден актор, ответственный за это изменение

    Серьезно? Я не знаю, что за языком вы пользуетесь, но в русском языке есть прекрасный пример "рассвело", где нет никакого актора.


    Такая картина навязана языком.

    Нет, такую картину пытаетесь навязать вы. В моей голове нет приписываемой вами картины.


    Если есть свойство, но нет объекта (светло), то к чему лепить стикер?

    Если нет объекта, то нет и свойства. "Светло" — это не свойство. "В комнате светло" — это описание конкретной комнаты.


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

      +1
      В статье заблуждения автора, которые он преодолел и делится опытом?
      Или изложены заблуждения других людей, то не понятно как часто и при каких обстоятельствах автор их встречал. Это студенты или практикующие аналитики и автор проверял их работы и т.д. Среди кого и насколько широко распространены эти заблуждения?
        +4
        Это высказывание выполнено в логике предикатов, в которой есть возможность говорить об общих свойствах объектов одного множества.

        Допустим.
        Первая ошибка связана с тем, что аналитики не умеют разделять эти высказывания

        Это высказывание в логике предикатов или «простое высказывание»?
        Дальше читать лень
          +1
          Когда вы слышите слово "экземпляр" из уст ИТ специалиста, знайте, он — путает простые высказывания с высказываниями в логике предикатов.

          А это простое высказывание или высказывание в логике предикатов? )


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

            0
            Я имел ввиду аналитиков, которые приходят к заказчику и говорят: экземпляр этой операции. Вот это — никуда не годится. С другой стороны, тот же аналитик, общаясь с программистом, может сказать это, но имея ввиду конкретные элементы кода. а не объекты из предметной области. Я говорю о тех аналитиках, которые моделируют предметные области и в них совершают подобные ошибки, а не те, которые в разговоре с программистом обсуждают код программы.
              0
              Вы никак не можете уяснить и запомнить, что иметь в виду пишется вот так, а не иначе. Какой-то психологический залом у вас?

              Понятно, что мир большой, и я не слышал ни одного аналитика, который бы говорил подобным образом. Это, конечно, не приводит к тому, что нет аналитиков так говорящих. Заметьте, я не делаю общих выводов из своего ограниченного наблюдения, а вы почему-то делаете. Не придерживаетесь ни формальной, ни о более строгой математической логике.
            –2
            > экземпляр этой операции

            omfg! Экземпляр операции? Srsly?
              +2
              Мне кажется автор статьи имеет ряд заблуждений относительно аналитиков…
              Ничего не имею против, просто прошу не обобщать. :)
                –2
                Я поделился своими наблюдениями. Это не обобщение, это статистика. Возможно, есть те, кто не делают эти ошибки, я не утверждаю, что их нет. Я говорю о среднестатистическом аналитике, с которым заказчик чаще всего имеет дело.
                  +2
                  Приведите статистику.
                    +2

                    … и методику ее получения тоже бы неплохо.

                    0
                    Это не статистика. Это ваше субъективное наблюдение, возведенное в ранг обобщения. Так вам угодно строить диалог с читателями, манипулируя и провоцируя их внимание к вашим идеям.
                  0
                  А автор в реальной коммерческой практике много встречал аналитиков (полагаю, что речь про системных и/или бизнес-аналитиков), которые хоть частично используют аппарат, который здесь описан? То есть сыпет фразами «экземпляр операции», задумывается о корректности использования понятия «атрибут», «тип»…
                    +1
                    Первый квадратик он назвал «закрепить заготовку в станке», второй квадратик он назвал: «выточить деталь».

                    Главная ошибка в семантической формулировке самого предложения. То есть некое реальное действие описано в одном предложении одновременно в нескольких аспектах. Аспекты и их обозначения — по ISO 81346.
                    «Закрепить» — функция, действие, выраженное глаголом. Это аспект "=" (аспект функции).
                    «Заготовку» — предмет, существительное. Аспект "-" (продукт).
                    «В станке» — место (локализация) Локализация это аспект "+". Или тоже аспект «продукт», зависит от точки зрения при построении одной диаграммы.
                    Модель — это множество диаграмм, построенных с разных точек зрения для разных целей. Диаграмм в модели может быть бесконечное количество. Обычно же диаграмм столько, чтобы понять или объяснить что-то для конкретного заинтересованного лица.
                    Второе предложение — тоже сразу два аспекта.
                    Если в одном предложении указаны несколько аспектов — это порождает путаницу и сложности с восприятием.
                    Корректнее диаграмма из двух кубиков. «закрепить» ---> «выточить».
                    Стрелочка показывает последовательность действий во времени. Диаграмма, связанная со временем.
                    Иная диаграмма: «заготовка» ---> «деталь». Диаграмма показывает, например, отношения двух объектов. Статическая диаграмма.
                    Только важно понимать, кому и для чего нужны диаграммы. Тогда они строятся очень просто и быстро. И если не мешать на одной диаграмме разные аспекты — то тоже все будет в порядке. И лучше, чтобы на диаграмме было от 5 до 9 элементов. Так понимать проще.
                    Я лишь коротко описал вполне простые и понятные идеи стандарта ISO 81346, но чтобы понимать и принимать такие методологии работы, нужно существенно изменить логику и мировосприятие. На холистический (системный) подход. А это — сложно.
                      0
                      Сразу: модель не диаграммы. Чтобы дать определение модели, стоит написать отдельную статью. Но частью модели являются высказывания. Это — точно.
                        0
                        Сразу: модель не диаграммы. Чтобы дать определение модели, стоит написать отдельную статью. Но частью модели являются высказывания. Это — точно.

                        Согласен. Диаграммы — только графическое представление части информации.
                        Есть описание при помощи слов. Есть — при помощи эмоций, вызываемых определенным смысловым образом.
                        Я описал основы более-менее корректного построения диаграмм, используя системный подход. Использование одного аспекта одновременно — один из методов. Можно использовать несколько аспектов одновременно. Но тогда трудно будет понимать части модели. Хотя тогда информации на диаграмме может быть больше.
                        Вопрос всегда в цели модели с точки зрения «заинтересованного лица». Какая цель — таков и метод для представления реальности в модели.
                          0
                          Я пытался в свое время придумать нотацию, в которой можно было бы нативно изобразить высказывания. Не получилось. Все нотации, что мне известны, — это упрощенные графы онтологических связей. Полные графы изобразить не получается, но проекции этих графов — пожалуйста. Проблема возникает, когда аналитик начинает думать, что диаграмма — это полноценная модель предметной области. И тут он сильно ошибается, а вместе с этим, он вводит в заблуждение и заказчика. Это — плохо.
                            0
                            Проблема возникает, когда аналитик начинает думать, что диаграмма — это полноценная модель предметной области. И тут он сильно ошибается, а вместе с этим, он вводит в заблуждение и заказчика.

                            Согласен. Лечиться это через описание в Стандарте Организации (СТО) и в регламенте работ идей, которые есть в НЛП. Пример: «Есть реальность и есть карта реальности. Карта реальности не равна целой реальности». Ну и так далее, в НЛП более-менее описано. Плюс сразу же, на уровне регламента и СТО прописываются базовые когнитивные методы, но только через via negativa. То есть через ограничения и чего нельзя делать. Обычно это текст о известных когнитивных искажениях. От «нарратива» до «скрытых свидетельств».
                            И само описание для Заинтересованного Лица Клиента всегда делается строго с учетом его уровня развития, его любимых когнитивных искажений. Для каждого — свое описание, свои диаграммы. Они обычно похожие на 60-70%, но ключевые элементы модели могут очень разными для разных Лиц.
                            Опять же, важно установить режим работы в проекте, по аналогии с психологом: работаем в режиме «прескриптивном» (предписание) или «дескриптивном» (описание). Суть: лечим причину болезни (прескриптивный) или то, что пациенту не нравится (дескриптивный). Понятно, что результаты будут разные и шаги будут разные.
                      –2
                      Разговор двух системных аналитиков:
                      — Будь актором, подай чашку с чаем.
                      — Не могу.
                      — Почему?
                      — Объемом не совпадает с содержимым.
                      — Хорошо. Подай чашку с налитый в нее чаем.
                      — Не могу.
                      — Почему?
                      — Нет чашки с налитым чаем.
                      — Соверши активность, налей.
                      — Не могу.
                      — Почему?
                      — Нет признаков заварки в объеме помещения.
                      — Что же ты совершаешь поступательно-возвратные движения членом
                      в объем занятый моим мозгом?
                      — Проявляю затребованную активность.

                        0
                        Приблизительно так выглядит диалог аналитика с предметником, когда аналитик говорит ему: давайте рассмотрим экземпляр этой операции вместо того, чтобы сказать: рассмотрим эту операцию
                        0
                        О, сорри, не думал, что системные аналитики такие чувствительные люди) судя по минусям. Просто раздувание стандарта «моделирования предприятий непрерывного цикла» до вселенских масштабов, и придания физического смысла показалось не совсем обоснованным. Реальность куда сложнее, если даже философские системы зачастую мало чем помогают в ее понимании и описании. А системный анализ в свое время мало чем помог в разработке систем реального времени, связанного с многоканальной регистрацией сигналов медико-биологического назначения, и хранения медийных данных разного типа. В связи со спецификой задач связанных с повышенными требованиями к производительности, больших объемов данных, и их слабой структуированностью приходилось обходиться собственными решениями, а не использовать многочисленные готовые СУБД. И это была типичная ситуация в этой области, и аналогичных по требованиям. А ведь это хлеб системных аналитиков, наверное они немало трудились при их проектировании) Правда, это было в прошлом, возможно в последнее время ситуация улучшилась из-за распространения таких систем, и системные аналитики выдают релевантные решения.
                          0
                          Реальность куда сложнее, если даже философские системы зачастую мало чем помогают в ее понимании и описании.

                          Согласен. Реальность сложнее в неизвестное число раз.
                          Философские системы, в том числе редукционизм и холизм, и следствие холизма — системный подход, немного помогают в работах над сложными искусственными системами. Особенно хорошо помогает системный подход.
                          Можно ли на основе системного подхода получить полные и непротиворечивые модели реальности? Скорее всего нет. Но множество более-менее кривых и косых моделей — можно. Для начала работ — вполне подходит, потом можно отрабатывать качество моделей при необходимости. И лучше применять совокупность методов: от шаманизма и интуиции до математической логики. Важно не считать какие-то методы исключительно верными и единственно применимыми.
                          Обычно с областью действия методологий и возникают проблемы. Если измерять температуру линейкой — может получиться некорректный результат. Но ошибки в применимости той или иной методологии к моделированию реальности — не так очевидны.
                          Насчет системного подхода: его существенно развили, улучшили и сделали практически стандартом де-факто в огромном количестве областей знания. Инженерное проектирование (примерно с 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 у меня вызывают только уныние, пробовал, ну-нафиг…
                          И да, понимание системного подхода позволило быстро и просто перейти на иные платформы и эффективно работать с новыми инструментами.
                          0
                          В реляционной модели — это разные атрибуты, в OWL — один

                          Какие характеристики и их значения есть у этого атрибута, помимо названия?

                            0
                            Область определения и область значений.
                              0

                              Ага. То есть в системе имеется запись "Высота, от 0 до 1000000 метров", единицы измерения указаны в атрибуте. У типа "Здание" есть ссылка на него вида "имеет атрибут 'Высота'", у типа "Дерево" тоже есть ссылка "имеет атрибут 'Высота'". Так?

                                0
                                Единицы измерения моделируются отдельно. Про них атрибут не знает. Атрибут не имеет единицы измерения, он имеет только область значений. Единицы измерения — это отдельная тема, которую пока не касались. Далее моделируются области определения и значений. Как они моделируются, — тоже не важно. Например, можно создать классы объектов: область определения атрибута и область значений атрибута. И сослаться на эти классы.
                                  0

                                  Покажите пример пожалуйста, какие могут быть область определения и область значений у атрибута "Высота"?

                                    0
                                    Классы под названием: область значений и область определения.
                                      0
                                      Это понятно. И какая информация в них хранится? Ну значения допустим ясно, целые или дробные числа, а область определения какая может быть?
                                        0
                                        Нет, область значений — это множество, как и область определения. Это два разных класса объектов. Целые и дробные числа — это лишь два примера таких множеств. Их может быть сколько угодно и каких угодно. Но вы почитайте теорию. Я дал ссылку.
                                          +1

                                          Зачем мне теория, если я спросил про пример? Тем более что ссылка ведет на курс "Основы проектирования реляционных баз данных", а спрашивал я про OWL, который вы им противопоставляете.


                                          Я, собственно, зачем спрашивал. Один атрибут для всех теоретически создает много проблем, связанных с заданием и изменением его характеристик, как раз потому что это влияет на всех. Для деревьев, зданий, и гор могут быть разные ограничения атрибута "Высота", а еще есть такое понятие как высота звука.


                                          Поскольку вы в очередной раз уклоняетесь от ответа, то похоже сами не очень разбираетесь. Я поискал и нашел описание OWL. Область определения это оказывается классы, к которым атрибут принадлежит. Также можно задавать ограничения специально для класса.
                                          Кстати, обратите внимание, сколько раз там встречается слово "instance" (of some class). Это как раз тот самый "экземпляр".


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

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

                                            Йеп-йеп-йеп, именно так. Более того, все эти развлечения проходили в той же EAV, при выборе между глобальным списком атрибутов и утаптывании списка в тип сущностей. И вот у меня тут есть система с глобальным, и это боль.

                                              0
                                              Вы можете создавать столько атрибутов с одним именем, сколько пожелаете. Главное — они никак не связаны с типами объектов.
                                                +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


                                                Главное — они никак не связаны с типами объектов.
                                                А что в этом полезного-то, если все равно надо делать специальное свойство ВысотаЗвука? И в первой цитате тоже пишут, что одинаковые делать не надо. Там есть разные типы свойств, которые задают разные связи, это да, полезно.

                                                Класс в 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, но описывать он позволяет.
                                                  –1
                                                  Сорри, я не буду комментировать это, потому что класс в ООП — это тип объектов, а класс в OWL — это множество. Путать одно с другим — это одно из заблуждений, про которые я написал.
                                                    0

                                                    Тип точно так же задает характеристики объектов множества, как и разметка OWL. А например
                                                    <WineGrape rdf:ID="CabernetFrancGrape"/>
                                                    это объявление типизированного объекта, аналогично
                                                    var madeFromGrape = new WineGrape('CabernetFrancGrape');
                                                    Попробуйте для себя сформулировать различия, а не избегать неудобного вопроса, и вы поймете, что их нет. Логически ООП это подмножество OWL, и в этой части различие только в деталях реализации.

                                                      –2
                                                      Спасибо! Как скажете. Вы же понимаете, что вам не нужны ответы на вопросы, потому что вопросов у вас нет. У вас — все хорошо. Это хорошо, продолжайте думать так, как считаете.
                                                        0

                                                        Вот еще же хотел поменять на "момент", подумал что вы поймете, какое из значений имеется в виду, но вы видимо не в курсе.


                                                        ВОПРОС — Словарь Ожегова
                                                        "2. То или иное положение, обстоятельство как предмет изучения и суждения, задача, требующая решения, проблема."


                                                        Почитайте, там и другие значения есть. Но если вам нужен набор символов с вопросительным знаком, то вот он: "В чем логические различия первой и второй записи для моделирования свойств объектов?".


                                                        И кстати, если предположить, как из описания класса в RDF можно сделать множество, то под формулировку "это множество" попадает таблица из базы данных.

                                                        –1
                                                        Мне реально надоело объяснять разницу между типом объектов и классом, между атрибутом и тем, что моделируется в ООП, OWL исправил эту ошибку, как матлогика исправила логику Аристотеля. Более мне сказать нечего. Я моделирую в OWL и знаю, что в одном классе могут находиться объекты разных типов, чего в ООП невозможно. Все потому что класс не есть тип.

                                                          0
                                                          Я моделирую в OWL и знаю, что в одном классе могут находиться объекты разных типов, чего в ООП невозможно.

                                                          Вы, как обычно, не в курсе по поводу того, что возможно в ООП.

                                                            +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», что на русский переводится «экземпляр такого-то класса». Если там класс это множество, значит «экземпляр класса» в значении «элемент множества» это допустимое выражение, а ваши утверждения по этому поводу неверны.
                                                          0

                                                          … а кроме различий между классом в ООП и OWL вы больше вопросов в комменте, на который вы отвечаете, не увидели? В частности, что полезного в том, что можно сделать сколько угодно свойств с одним именем, и вообще в том, что свойства не связаны с типом объекта?

                                                      –1
                                                      Класс в OWL — это множество в отличие от ООП. Вы опять путаетесь с типами и классами. Хотя, дело ваше.
                                                    0
                                                    Похоже, я понял, в чем трудность понимания. Область значений и область определения не всегда известны на момент создания ИС. Эти множества могут пополняться по мере наполнения базы. Мы не все сразу знаем, часто мы узнаем новое в процессе работы.
                                            0

                                            А я-то наивно думал, что область значений у высоты здания и высоты дерева — разная.

                                              0
                                              Сильно перескаются — самое высокое дерево выше большинства (субъективно) зданий.
                                                0

                                                Самое высокое дерево в мире — 116 м.


                                                Самое высокое здание в мире — 828 м. Так что область допустимых значений пересекается меньше чем на четверть (и это будет падать).

                                                  –1
                                                  Подмножество из области определения может отображаться на подмножество из области значений. Это как-бы очевидный факт.
                                                    0

                                                    Вы вроде как недавно писали, что область значения и область определения — это характеристики атрибута "высота", который у здания и дерева общий, то есть один. Это значит, что — поскольку это характеристики атрибута — они одинаковые и в случае применения "высоты" к зданию, и в случае применения "высоты" к дереву. Так что не очень важно, что куда отображается, важно, что эти множества не меняются в зависимости от того, в какой сущности применен атрибут.

                                                    0
                                                    Одного порядка 100-1000 метров.
                                                      0

                                                      Во-первых, 100 и 1000 метров — это два порядка (в том смысле, что разница на порядок). А во-вторых, для системы, учитывающей деревья, разрешать ввод высоты в километр — неумно, коллеги засмеют.

                                                        0
                                                        Левая граница включительно, правая невключительно — один порядок :)

                                                        А на сколько её ограничивать, если 116 метров реальное значение? 116? 117? 119? 127? 199? 255?

                                                        999 выглядит вполне разумным значением — тот же порядок, что известный практический максимум с довольно большим запасом.
                                                          0
                                                          Левая граница включительно, правая невключительно — один порядок

                                                          Это называется "подгонка под ответ".


                                                          А на сколько её ограничивать, если 116 метров реальное значение?

                                                          Это хороший вопрос к специалисту в предметной области.


                                                          999 выглядит вполне разумным значением — тот же порядок, что известный практический максимум с довольно большим запасом.

                                                          Есть маленький нюанс: по этой же логике для зданий нужно брать 9999. Все равно отличается.

                                                        0
                                                        Дело же не только в левой и правой границе. Есть еще точность задания значения и допуск на саму величину, если мы говорим вообще о жизни.
                                                        У меня в хлебопечке «вес» — это 3 значения: 0.5, 0.75, 1кг и все.
                                                        Про здания и деревья вот пример: в задаче выдачи разрешения от аэропорта на строительство здания/сооружения высота объекта вообще считается в единицах метров, но от уровня моря. Тут может оказаться, что здание — 1050м, дерево на соседнем холме — 1150м.
                                                        В итоге понимать, как в физическом мире измеряется величина перед сохранением и как потом она будет использоваться после вывода из системы — критически важно.
                                                        У меня в живой практике коллега один раз запилил для паспорта объекта благоустройства возраст дерева в годах без всякого указания года высадки и был доволен.
                                              0
                                              С одной стороны напор автора и глубинная, наивная уверенность в собственной правоте не могут не подкупать читателя. Особенно 20!8 году.

                                              С другой стороны явный перебор с максимализмом и довольно слабое понимание из чего состоит работа БА/СА ИРЛ.
                                                +1
                                                Если вы сказали, что у табуретки 4 ножки, то вы сделали простое высказывание. Если вы сказали, что любая табуретка имеет 4 ножки, — это высказывание не является простым. Это высказывание выполнено в логике предикатов, в которой есть возможность говорить об общих свойствах объектов одного множества.

                                                Второе высказывание является точно таким же простым, как первое, и вполне себе принадлежит логике высказываний. Разберитесь в вопросе прежде чем статьи писать.

                                                  –1
                                                  Я прочитал комментарии. Пока у меня сложилось ощущение театра абсурда. Множество бессвязных и нелепых утверждений. Я об этом и написал: мало, кто из аналитиков имеет хотя бы начальную подготовку в математической логике. А, чтобы делать модели, этого, естественно, мало. Я призываю тех аналитиков, которые знают, что такое математическая логика, объединиться.
                                                    +1
                                                    Множество бессвязных и нелепых утверждений.

                                                    Ну да, проще назвать вопросы "бессвязными и нелепыми утверждениями", чем пытаться на них ответить.


                                                    А, чтобы делать модели, этого, естественно, мало

                                                    Вы так говорите, как будто познания в математической логике являются необходимыми для того, чтобы делать модели.

                                                      +2
                                                      Множество бессвязных и нелепых утверждений. Я об этом и написал: мало, кто из аналитиков имеет хотя бы начальную подготовку в математической логике.

                                                      Уважаемый, я выше вам указал, что первое же утверждение в вашей статье — с математической точки зрения просто нонсенс.
                                                      И ладно, если бы это была какая-то фигура речи, метафора, или еще что-то подобное — все же статья не математическая, такие вещи вполне допустимы.
                                                      Но вы же потом из этого вполне строго пытаетесь делать какие-то глубокоидущие выводы. А потом еще говорите, что кто-то "не может в математическую логику".
                                                      Вам не стыдно, нет?

                                                        0
                                                        Вы извините, но у нас с вами разное представление о логике. наверное. Если я делаю простое высказывание относительно операции: данная операция началась в 17-00 23-июля, то я понимаю, что это высказывание отличается от высказывания типа: операции данного типа начинаются в 17-00 каждый день. Вы же, видимо не отличаете.
                                                          +1

                                                          Эти высказывания друг от друга отличаются, это несомненно. Однако эти высказывания можно отнести к одному и тому же типу.

                                                            0
                                                            Конечно, одно — простое, второе — записывается в кванторах, но аналитики думают, что это высказывания одного типа.
                                                              0
                                                              квантор там только один «каждый». :) Возможно вы имели в виду «Все операции данного типа всегда начинаются в 17-00 каждый день», но это не очевидно.
                                                                0
                                                                Это очевидно, но пока народ спорит именно с этим!
                                                                  0

                                                                  Нет, это мало того что не очевидно, это еще и неоднозначно.

                                                                0

                                                                Ну так ничего не мешает этим высказываниям быть отнесенным к типу "простое предложение".


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


                                                                Но даже если мы вдруг на мгновение примем, что мы существуем в рамках математической логики, то у меня есть для вас неприятный сюрприз: фраза "операции данного типа начинаются в 17-00 каждый день" не является высказыванием, это высказывательная форма, она неполна, в ней первый объект ("операции данного типа") — это не объект, а предметная переменная. Чтобы эта форма стала высказыванием, необходимо эту переменную заменить на конкретное значение или, наоборот, подставить квантор ("некоторые операции" или "все операции"). Кстати, та же ошибка у вас и в первом абзаце.


                                                                Что самое забавное, подставив квантор (ну, например, всеобщности), мы получим высказывание "все операции… начинаются в 17:00 каждый день", которое… неоднозначно, потому что из него нельзя сделать вывод о том, сколько операций начинается в 17:00 каждый день.

                                                                  –2
                                                                  Мы приходим еще к одной ошибке: ИТ специалисты тип объектов называют объектом. Но это все связано. Потому что в ООП тип объектов называют именем объекта.
                                                                    0
                                                                    Мы приходим еще к одной ошибке: ИТ специалисты тип объектов называют объектом.

                                                                    Какие-то странны ИТ-специалисты в вашей реальности.

                                                                      0

                                                                      Чтобы куда-то прийти, надо сначала уйти. Вы уже согласились с тем, что ваше утверждения о символической логике неверны?


                                                                      (а то, куда вы пытаетесь прийти, называется "синекдоха", и ошибкой в принятом смысле этого слова не является)

                                                                0
                                                                Вы извините, но у нас с вами разное представление о логике. наверное.

                                                                О логике не бывает никаких представлений, есть вполне четкие и однозначные определения.


                                                                Если я делаю простое высказывание относительно операции: данная операция началась в 17-00 23-июля, то я понимаю, что это высказывание отличается от высказывания типа: операции данного типа начинаются в 17-00 каждый день

                                                                Оба этих высказываний являются, по определению, корректными высказываниями в логике высказываний. Что бы вы себе ни представляли и что бы вы себе там ни отличали.

                                                                0
                                                                Я не являясь математиком в смысле эксперта, запросил консультацию у математика, изучающего и преподающего матлогику в течение нескольких десятков лет. Получил аналогичный ответ сходу. Т.е. это у человека сработал математический инстинкт.

                                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                            Самое читаемое