Все модели, которые мы строим, должны так или иначе моделировать 4-х мерное пространство-время, потому что именно так мы представляем себе окружающий нас мир. Об этом рассказано в книге Криса Партриджа. Даже то, что кажется, не имеет отношения к 4-пространству, при внимательном рассмотрении оказывается оным. Правда, не всегда существующим в реальности, иногда — это воображаемый нами мир. Всем, кому интересно, как это происходит, рекомендую внимательно прочитать эту книгу. Однако, советую не обращать внимания на определение события в этой книге, — оно дано неверно.
Например, что такое болт? Это 4-х мерный объект, который ограничен в пространстве-времени определенными границами. Для моделирования болта существуют нотации, которые моделируют эти границы. Например, чертеж болта моделирует поверхность, которая ограничивает 3-х мерный объем. Добавив к этому чертежу еще 6 координат, зависящих от времени, мы получим модель поверхности 4-Д пространства — времени, которая моделирует болт.
Однако, что такое операция? Это — тоже 4-х мерный объект, который также, как и болт ограничен определенными границами в пространстве и во времени. Правда, представить себе операцию как 4-объект намного сложнее. Существуют три причины, по которым нам сложно это сделать.
Во-первых, в отличие от болта операция имеет менее плотное строение. Может ли болт пересекаться в пространстве-времени с другим болтом? Опыт подсказывает, что нет. Операции, в отличие от болтов, менее плотные. Поэтому операции могут пересекаться в одном пространстве – времени. Если бы операции были настолько же плотные, как и болт, то нам было бы проще их представить. Но, с другой стороны, ошибкой было бы думать, что болт не может пересекаться с другими объектами. Например, болт одновременно может существовать в одном пространстве с объектом, который состоит из темной материи. И, если бы мы воспринимали темную материю своими органами чувств, мы бы сказали, что болт не является плотным объектом, и тогда представить себе болт в качестве плотного объекта было бы затруднительно.
Во-вторых, восприятие нами операции как четырехмерного объекта затруднено тем, что в нашем языке разделены описания трехмерного пространства и времени. Поскольку мы не можем перемещаться во времени назад, эта четвертая координата нашего мира выглядит для нас иначе, чем пространственные координаты. Поэтому в языке представление трех координат пространства отличается от представления четвертой координаты – времени, и те объекты, форма и состав которых меняется во времени, воспринимаются нами иначе, чем те объекты, форма и состав которых во времени не меняются.
Например, форма и состав болта во времени неизменны. Поэтому мы можем представить себе болт как 3-объект. Представить себе операцию так же просто уже не получается, потому что ее форма и состав меняются со временем. Однако, и болт с точки зрения микронаблюдателя, который мог бы видеть квантовые скачки, выглядел бы не менее странно: как объект, чья форма и состав постоянно меняются. Такому микронаблюдателю представить себе болт в качестве статичного объекта было бы также трудно.
Помимо указанных трудностей в моделировании операции существует еще одна причина, пожалуй, самая трудная для понимания. Эта трудность возникла из особенностей нашего языка, который, в свою очередь, реализует паттерны нашего мифического сознания. В языке есть члены предложения: подлежащее, сказуемое и дополнение, которые моделируют актора, совершаемое им действие и объект деятельности. Из этого языкового паттерна следует, что наши обычные предложения моделируют деятельность, а в теории деятельности операция – это связь между актором и объектом деятельности, но не объект! Поэтому сам язык говорит нам: операция — это связь, а не объект. Но такая связь возможна, если есть актор. Актором в языке может быть любой одушевленный (например, олень), или неодушевленный (например, Солнце) объект. Но в моделях, которые строят аналитики, актором может быть только субъект. Иначе, если мы скажем, что что-то неживое совершает операцию, мы, тем самым, наделяем неживое способностью к разумной деятельности, то есть, одушевляем предметы. Если же мы достаточно дисциплинированы как аналитики, то мы не можем сказать, что робот совершил действие, мы можем лишь сказать, что действие произошло и робот был одним из его участников. Таким образом, с помощью теории деятельности мы можем описать только те операции, которые совершены субъектом, и только с одной точки зрения – с точки зрения этого субъекта. Если же нам нужно смоделировать операции, произошедшие без участия субъекта (например, вспышку сверхновой), или операции, трактовку которых мы хотели бы видеть с разных точек зрения (например, операцию купли-продажи), то такая метамодель операции нам не подходит. Для решения подобных задач мы должны научиться моделировать операции иначе. Такой способ моделирования есть, и он – моделирование операций как 4-объектов. Кстати, то же касается и бизнес-функций, но про них я расскажу в другой статье.
Как я уже сказал ранее, болт и операция — это четырехмерные объекты в пространственно-временном континууме. Чем же тогда отличаются болт и операция? Не более, чем способами описания одного и второго. Мне давно хотелось поставить общую задачу и понять, какие способы описания 4-объектов существуют вообще, и с какими типами объектов они обычно ассоциируются. Для этого надо было сделать два шага: сначала сделать равноправными время и пространство, создать язык описания такого мира и классифицировать способы описания этого мира, а затем полученные результаты отмаппить обратно в стандартные языковые паттерны. Я сделал это, и в следующих статьях постараюсь изложить.
Замечу, что для физики равноправие между пространственными координатами и временем давно является нормой. Недавно это равноправие для себя открыли и философы, но до сих пор это знание недоступно инженерам-онтологам. Давайте же попробуем воспользоваться этим представлением и посмотреть, к каким открытиям это нас приведет.
Комментарии (159)
sakhavat
06.01.2017 17:54прежде чем вывалить этот поток сознания все ж надо дать определение — что такое «болт» и «операция», почему болт «плотный», а операция «рыхлая» и т.д.
возможно, что неправильное понимание простых вещей приводит к сложным построениям и парадоксам
sakhavat
06.01.2017 19:46вощем, когда начинаешь с «объекта» всегда заканчиваешь кашей в башке
если ты уже ввел «4 мерность», то у тебя уже есть «способ интерпретации»
а «болт и операция» не «способ интерпретации», а результат интерпретации
ты сам то себя хорошо понимаешь?
CrazyViper
06.01.2017 21:26+3Ход рассуждений интересен, как и сама тема, но я не согласен с базовыми аксиомами, а поэтому и со всем последующим выводом. Да и вообще очень много не доказанных тезисов. Такое количество аксиом намекает на ошибочность теории.
Во-первых, в отличие от болта операция имеет менее плотное строение. Может ли болт пересекаться в пространстве-времени с другим болтом? Опыт подсказывает, что нет.
Может, если сильно ударить кувалдой или положить под хороший пресс, или расплавить. Но вот зачем нам это моделировать? Для какой практической задачи?
Если пытаетесь построить модель реального мира, то вам к физикам. Они пытаются это сделать: уже дошли до кварков и продолжают копать глубже. А корпускулярно-волновой дуализм всегда все портит и не позволяет смотреть на объекты только как на объекты — приходится еще и о волнах думать. Да еще эта теория струн…
Я это к чему, моделировать надо только минимально и достаточную для вашего проекта часть бизнеса. Тогда и только тогда можно получить задачу с приемлемой сложностью и решить ее. Эрик Эванс давно об этом говорил, но вот на практике его подход мало где применяют.
Но в моделях, которые строят аналитики, актором может быть только субъект. Иначе, если мы скажем, что что-то неживое совершает операцию, мы, тем самым, наделяем неживое способностью к разумной деятельности, то есть, одушевляем предметы.
Вот это самый спорный момент. Здесь несколько недоказанных высказываний, на основании которых делается, на мой взгляд, ошибочный вывод.
И да, как выше в комментариях уже просили — дайте определение понятию «операция», а то возможно мы за этим словом видим совершенно разные смыслы.
maxstroy
06.01.2017 21:41Может, если сильно ударить кувалдой или положить под хороший пресс, или расплавить. Но вот зачем нам это моделировать? Для какой практической задачи?
Потому что две разные операции одновременно могут находиться в одном 4-пространстве, или пересекаться. Это как щебень в бочке и песок в той же бочке занимают одно пространство: бочку. На практике такое приходится моделировать очень часто, потому что один ресурс одновременно участвует в двух операциях — это нормально.
Я это к чему, моделировать надо только минимально и достаточную для вашего проекта часть бизнеса. Тогда и только тогда можно получить задачу с приемлемой сложностью и решить ее
Минимально достаточную для чего? Если мы решаем задачу интеграции разных ИС, структура данных которых заранее предполагается разнообразной, то мы хотим того или нет, приходим к необходимости моделировать все возможности.
Вот это самый спорный момент. Здесь несколько недоказанных высказываний, на основании которых делается, на мой взгляд, ошибочный вывод
Или используем метонимию для моделирования участия объекта в операции. То есть «делает» — это в данном контексте метонимия, а не факт. Если сказать, что трансформатор «преобразует» напряжение, то это – метонимия, которая раскрывается так: трансформатор, исполняет роль преобразователя напряжения, который (преобразователь) участвует в процессе преобразования напряжения. О метонимии можно прочитать в книге «Метафоры, которыми мы живем», авторы: Джордж Лакофф, Марк Джонсон. Другой распространенной метонимией будет высказывание: «компьютер решает задачи».
lair
06.01.2017 23:58О метонимии можно прочитать в книге «Метафоры, которыми мы живем», авторы: Джордж Лакофф, Марк Джонсон.
Вас не смущает тот факт, что в русской литературоведческой традиции у метонимии может быть другое определение?
То есть «делает» — это в данном контексте метонимия, а не факт.
… вот это и есть недоказанное высказывание.
Если сказать, что трансформатор «преобразует» напряжение, то это – метонимия, которая раскрывается так: трансформатор, исполняет роль преобразователя напряжения, который (преобразователь) участвует в процессе преобразования напряжения.
(а) а что же тогда преобразует напряжение?
(б) почему трансформатор не может преобразовывать, но может исполнять роль? почему преобразователь не может преобразовывать (заметим, это высказывание противоречит языковому смыслу; я уж молчу про случившийся с вами плеоназм), но может участвовать в процессе?
Makhinko
07.01.2017 01:18+1Тема очень интересная. Посоветуйте, пожалуйста, еще хороших книг по моделированию бизнес-процессов.
maxstroy
07.01.2017 09:33+1Есть лишь классика, но ее читать тоже трудно, потому что ошибки на ошибках и ошибками погоняют. Я не встречал ни одной книги по описанию активности предприятия, которая бы удовлетворила меня. Везде — попытка продать консультационные услуги по промывке мозгов, но нигде нет строгой теории построения модели предприятия и его активности. Попытки создать ее есть, но опять же — все они сваливаются к какой-то религии в области управления.
Дубейковский по IDEF0
Менеджмент по нотам Григорьев
7 нот менеджмента — коллектив авторов
Брюс сильвер на английском — по нотации BPMN
a1111exe
07.01.2017 09:34+2Спасибо за интересную статью!
Правда, смущает частое прямо какое-то околорелигиозное отношение к четырёхмерному пространству-времени. Не только в этой статье, а вообще.
Имхо, как бы не следует забывать, что понятие о четырёхмерном пространстве-времени есть абстракция, существующая и имеющая практический смысл в первую очередь для физики, изучающей явления т.н. "внешнего" мира. Реально же никаких эмпирических доказательств существования физического трёхмерного пространства не имеется.
Если уж стремиться моделировать что-то на основе наиболее достоверных знаний о реальности, то не следует фиксировать число размерностей моделируемого пространства. Если моделируются изменения, полезной окажется ось времени, а дополнительные размерности могут соответствовать различным однородным параметром моделируемой системы.
В конце концов, всё наше эмпирическое знание сводится к тому, что существует многомерное восприятие, в котором трёхмерное пространство, "упакованное" во "внешний" мир (и во сны), является лишь подмножеством куда большей системы.
maxstroy
07.01.2017 10:12+1Про многомерное восприятие поспорю. Мы просто не умеем различать модели от моделей моделей. Например, есть модель объекта, — это представление 4-объекта в виде, удобном для понимания. есть множество похожих моделей — объектов, которые мы воспринимаем как похожие. Есть модель моделей этих объектов — тип. Кто бы мог подумать, что тип — это модель моделей?! И понятно, что модель и модель моделей не могут существовать в одном пространстве-времени, пусть и воображаемом.
a1111exe
07.01.2017 12:51+1Не совсем понял сказанное Вами в контексте спора с многомерным восприятием.
Вообще, понятие о моделях и языках n-го уровня (часто для +1 уровня относительно предметного используется префикс "мета" — метаязык, метамодель...) давным-давно известно и (по идее) является тайной только для тех, кто толком не изучал современную логику.
Ares_ekb
07.01.2017 13:11+2Жесть. Я был уверен, что все эти мета — это в значительной степени изобретение консорциума OMG. Даже статью писал про MOF. А оказывается это всё опять из математики и вообще со времен Аристотеля. Просто маркетологи от программной инженерии опять взяли давно известные вещи и описали их простым языком для технарей и бизнеса. А есть что-нибудь почитать на тему современной логики про мета и т.п.?
a1111exe
07.01.2017 15:23+3По идее, должен подойти любой учебник по мат. логике. Хотя довольно резкий акцент на необходимости различения между предметными логикой и языком, и логикой и языком исследователя мне встретился в учебнике "Математическая логика" С.К. Клини. Он там прямо с первой странцы пишет буквально следующее:
"Но тут мы встречаемся с парадоксом: разве для того, чтобы изучать логику с помощью математики (да и вообще любым систематическим методом), нам не придётся пользоваться самой логикой? (...) Основная идея здесь состоит в том, что мы будем тщательно различать логику, которую мы изучаем, и логику, с помощью которой это делается. Но тогда нам придётся различать и соответствующие языки: (...). Необходимо всё время помнить об этом различии между изучаемой (предметной) логикой и логикой как средством такого изучения (т.е. логикой исследователя). Тому, кто не готов к этому, стоит сразу же закрыть эту книгу и подыскать себе другое занятие по вкусу (скажем, составление шарад или пчеловодство)."
a1111exe
07.01.2017 16:11+3Кстати, если интересует широкий обзор (выходящий далеко за пределы логики) более-менее современной аналитической мысли, то всячески рекомендую эту работу (да и мне, кажется, пришло время ещё раз перечитать):
http://yanko.lib.ru/books/philosoph/blinov-ladov-lebedev=analytic_philosophy.htm
А также вот эту:
maxstroy
07.01.2017 13:27+1Я хотел сказать, что то, что за н-мерие, как правило, выдается смешение уровней абстракции. Моделирование нашего мира — это моделирование 4-х мерного пространства-времени только потому что именно так мы видим наш мир. Никак иначе мы его представить не можем. На уроке математики лектор сказал: представим себе 4-мерное пространство. Студенты умно наморщили лоб, а лектор рассмеялся, потому что представить себе его мы не можем в принципе. Есть уловка, правда. Это представление себе времени, как 4-ой координаты. Так мы можем хоть как-то представить себе 4 измерения, но пять и более — нет. Поэтому мы не моделируем н-мерное пространство в нашем сознании, но моделируем как некую абстракцию математическими методами. Про моделирование н-мерного пространства мат методами я расскажу много позже, а сейчас все, что у нас есть — это 4-пространство
a1111exe
07.01.2017 15:50+2Я хотел сказать, что то, что за н-мерие, как правило, выдается смешение уровней абстракции.
Под многомерным восприятием я имею в виду, что данные восприятия автоматически распределяются по нескольким множествам, образуя вполне себе ортогональные друг другу пространства, единственной точкой пересечения которых является сам воспринимающий субъект. Довольно стандартно и общепринято разделение на 5 независимых ощущений: визуальные, аудиальные, вкусовые, запахи и тактильные. Каждую из этих категорий можно (и, имхо, естественно) рассматривать как некоторое параметрическое пространство. При этом я бы добавил ещё эмоциональное пространство, а также, вслед за Платоном и Бертраном Расселом — пространство абстрактных идей.
Не вижу в этом смешения уровней абстракции. Если оно есть, буду рад помощи понять это.
Моделирование нашего мира — это моделирование 4-х мерного пространства-времени только потому что именно так мы видим наш мир.
А как быть с теми, кто видит мир не так?
Никак иначе мы его представить не можем. На уроке математики лектор сказал: представим себе 4-мерное пространство. Студенты умно наморщили лоб, а лектор рассмеялся, потому что представить себе его мы не можем в принципе. Есть уловка, правда. Это представление себе времени, как 4-ой координаты. Так мы можем хоть как-то представить себе 4 измерения, но пять и более — нет.
Есть же разница между "представить в воображении" и "представить дискурсивно". В первом случае максимум, на что мы способны — 2-х мерная плоскость, потому что именно так нам даются визуальные образы. Многомерная действительность нам даётся, но не визуально, поэтому у нас нет опыта для её визуального представления. Уловка, которую Вы описали, выводит представление из воображения и переводит в дискурсивную область осей координат, а воображение остаётся с 2-х мерной картинкой 4-х осей и видимостью, что чего-то представилось. А зачем на самом деле нужна эта видимость? Убрать её — и можно представлять себе сколькоугодно-мерные пространства. Дискурсивно, естественно.
Про моделирование н-мерного пространства мат методами я расскажу много позже
Жду с нетерпением!
maxstroy
07.01.2017 16:11+1Под многомерным восприятием я имею в виду, что данные восприятия автоматически распределяются по нескольким множествам, образуя вполне себе ортогональные друг другу пространства,
О, да! И вот тут впервые я рад сказать. что мои исследования ограничены лишь нашим визуальным восприятие. Рад — потому что впервые был задан корректный вопрос. Спасибо за него! Когда Монж придумал метод ортогональных проекций, его работы были засекречены в военных целях. То есть такой простой метод давал уже достаточное преимущество. Я же пытаюсь рассказать и классифицировать не весь спектр наших ощущений, а лишь описать способ моделирования нашего мира, но уже с учетом времени.
А как быть с теми, кто видит мир не так?
Пока забить на них). Ничего лучше не предложу пока.
Жду с нетерпением!
Самый сложный объект, который я моделировал, — это сценарий (неопределенность в будущем, вероятность нашего знания в прошлом). Вот о нем я и планировал рассказать
Ares_ekb
07.01.2017 10:37+3На сколько я понимаю, авторам BORO понадобилась 4-мерность по двум причинам:
1) они таким образом определяют идентичность объектов
2) и ещё таким образом обобщают объекты, события, состояния объектов — всё это частные случаи обобщенного 4-мерного объекта.
1 — например, как идентифицировать человека? По имени, по номеру паспорта, по внешности, по какой-то совокупности признаков? Как вы понимаете, что перед вами тот же самый человек? В базах данных для идентификации объектов могут использоваться либо естественные ключи (номер паспорта и т.п.), либо суррогатные (какой-нибудь GUID). Но опыт показывает, что естественные ключи не особо хороши. У человека может не быть паспорта, может меняться паспорт. Бывает, что ИНН у разных людей совпадает. Такие ключи не подходят для идентификации. А суррогатные ключи — это вообще что-то искусственное, не существующее в реальности.
В BORO предлагается следующий подход. Если в 4-мерном пространстве-времени условно представить траекторию развития и движения человека от рождения до смерти, то это будет некая непрерывная линия. И поэтому мы понимаем, что это один и тот же человек. Представьте, что вы фотографируете человека на долгой выдержке или снимаете его на видео, а потом просматриваете в ускоренном режиме. Человек как бы размазывается в такого 4-мерного червяка. И мы понимаем, что всё это один человек в разные моменты времени.
В таком подходе определённо что-то есть. Правда, телепортация, если она возможна, рушит эту теорию. Хотя, фиг знает, наверное при телепортации 1) либо создаётся точная копия старого объекта и это уже новый объект, 2) либо этот объект перемещается в новое место через какие-то не воспринимаемые нами измерения и при этом сохраняется непрерывность этого многомерного «червяка». Аналогично с путешествиями во времени. Вот, кстати, недавно была статья на эту тему, там есть видео про телепортацию.
В любом случае, такой способ определения идентичности объектов через их непрерывность в многомерном пространстве — это уже лучше, чем идентификация по естественным или суррогатным ключам — по каким-то атрибутам. Кстати, про атрибуты в BORO тоже много написано. Мы привыкли воспринимать всё через сито сущностей, атрибутов. А они говорят, что никаких атрибутов нет, есть состояния.
2 — это ещё более мутная тема. Я не на столько хорошо это понимаю, чтобы описать в комментарии, лучше прочитать книгу. Ну, про события уже писал выше. С их точки зрения — это объекты в 4-мерном пространстве-времени без временной протяженности, моментальные.
Зачем вообще всё это нужно? По большом счёту люди воспринимают реальность как совокупность сущностей, атрибутов, связей. И это началось не 60-70 лет назад с изобретением ER-моделей. А это так уже на протяжении тысячелетий. В книге упоминаются разные древнегреческие философы, всякие теории про субстанции и т.п. Короче, ER, ООП и т.п. своими корнями идут ещё с тех времен. Маркетологи просто придумывают для всего этого новые названия.
Но у такого «классического» подхода есть недостатки. Например, вы разрабатываете базу данных, в которой учитываются сведения, скажем, о программистах и руководителях проектов. И у первых, и у вторых есть ФИО, но все остальные атрибуты очень сильно отличаются. Как правильней смоделировать эти сущности? 1) Сделать две отдельные сущности: программист и РП? 2) Сделать одну сущность «сотрудник» с атрибутом «роль», «должность» или «вид» и объединением всех атрибутов программистов и РП? 3) Сделать базовую сущность «сотрудник», от которой унаследовать программиста и РП?
В реальности есть факт принадлежности сотрудника к классу/группе программистов или РП. Но смоделировать этот факт мы можем тремя разными способами. Согласно авторам BORO, это признак того, что сам язык моделирования неправильный! Одни и те же реальные объекты, факты, события разные люди могут моделировать по-разному. Это значит, что они моделируют не реальность как она есть, а какие-то частные сведения о реальности. Например, они моделируют не человека как он есть, а паспорт человека или его водительское удостоверение. Пересказать всю книгу невозможно, это просто для затравки.a1111exe
07.01.2017 15:13+2Спасибо за развёрнутый комментарий.
1 — например, как идентифицировать человека? По имени, по номеру паспорта, по внешности, по какой-то совокупности признаков? Как вы понимаете, что перед вами тот же самый человек?
Есть колоссальная разница между тем, что требуется для идентификации человека в некотором контексте (например, в какой-то конкретной бизнес-логике), и между тем, каким образом происходит идентификация на уровне понимания в чьём-то конкретном сознании. Лично я не вижу причины даже пытаться имитировать естественный процесс идентификации в сознании, если только бизнес-цель не заключается имеено в этом (исследование этого процесса).
Как вы понимаете, что перед вами тот же самый человек?
Сильно сомневаюсь, что сегодня уже существует достоверный научный ответ на этот вопрос. Хотя бы потому, что для этого потребовалось бы не менее достоверное научное объяснение сознания и явления понимания в сознании.
Но если речь чисто о моём мнении, то примерно так.
Изначально всё воспринимается в виде этакого калейдоскопа ощущений (у меня даже есть подобные воспоминания из детства, хотя, конечно, это объективно ничего не доказывает). Так происходит ввиду того, что ассоциативная система ещё относительна пуста. Однако, функции по формированию индивидуальности (кратковременная и долговременная память, та же ассоциативная система и т.д.) уже работают в полную силу, обрабатывая эмпирические данные. Там, в этом чёрном ящике бессознательного, регулярности в потоке восприятия обрабатываются определённым образом, так, что в долговременной памяти обновляется нечто вроде многомерной структуры данных вида hashmap, в которой ключи являются наборами паттернов восприятия, а значениями другие наборы паттернов восприятия и так далее — классификация признаков от общего к частному. Так, например, ребёнок начинает узнавать маму: на совокупности текущих паттернов в его сознании разворачивается структура данных вплоть до уровня, где хранится аудиальный паттерн "мама" вместе с остальными, относящимися к этому же уровню классификации, включая положительный эмоциональный отклик. В какой-то момент взросления сознание начинает принимать более активное участие в составлении классификации, добавляя ещё более абстрактный компонент — имена и числа. Которые, кстати, запоминаются не так свободно, т.к. наша структура данных, судя по всему, заточена именно на запись комплексных восприятий (кто хоть немного пользовался мнемотехниками, знает, что детально воображаемые истории запоминаются многократно лучше символьных рядов).
Итого: идентифицируя вокруг себя различные объекты, мы поднимаемся от уровня непосредственного восприятия к его интерпретации в соответствии со стихийно (в детстве мы этим процессом не управляли, и не факт, что взрослые способны его существенно контроллировать) складывающейся классификационной схемой — от предметной области к модели. В предметной области существует текущее восприятие. Мир вокруг себя мы привыкаем рассматривать на уровне модели, которая настолько критична для нашего выживания, что мы именно эту модель склонны рассматривать как реальность в последней инстанции. (Отсюда, имхо, массовая склонность искать в физических теориях какие-то онтологические истины, хотя их реальная ценность — в математическом аппарате и предсказательной силе относительно эмпирических явлений.) Потом мы (правда, не все в одинаковом объёме) начинаем пытаться осмысливать эту самую модель, и начинается метафизика и, вообще, философия.
Но опыт показывает, что естественные ключи не особо хороши. У человека может не быть паспорта, может меняться паспорт. Бывает, что ИНН у разных людей совпадает. Такие ключи не подходят для идентификации. А суррогатные ключи — это вообще что-то искусственное, не существующее в реальности.
ДНК подходит? :) Хотя, если серьёзно, и ДНК в некоторый момент могут научиться изменять достаточно сильно, чтобы затруднить однозначную идентификацию. А ещё в более отдалённом будущем, вполне возможно, индивидуальность не будет привязана к конкретному телу. Как тогда придётся большому брату?.. :)
Если в 4-мерном пространстве-времени условно представить траекторию развития и движения человека от рождения до смерти, то это будет некая непрерывная линия. И поэтому мы понимаем, что это один и тот же человек. Представьте, что вы фотографируете человека на долгой выдержке или снимаете его на видео, а потом просматриваете в ускоренном режиме. Человек как бы размазывается в такого 4-мерного червяка. И мы понимаем, что всё это один человек в разные моменты времени.
Надеюсь, Вы согласны с тем, что в реальности мы не так идентифицируем знакомых людей. Кроме того, такая модель исходит из допущения, что всегда человеческая идентичность будет привязана к конкретному телу и к некоторому телу внешнего мира вообще. Что в общем случае не факт.
В таком подходе определённо что-то есть.
Имхо, в любом подходе что-то есть, пока он способствует достижению бизнес-целей. Просто я не уверен, что возможен и, вообще, нужен некий сферический универсальный подход, решающий задачи любого бизнес-процесса. Такие универсальные идеи, красивые на бумаге, часто выливаются в очень громоздкую и дорогостоящую реализацию и поддержку.
Правда, телепортация, если она возможна, рушит эту теорию. Хотя, фиг знает, наверное при телепортации 1) либо создаётся точная копия старого объекта и это уже новый объект, 2) либо этот объект перемещается в новое место через какие-то не воспринимаемые нами измерения и при этом сохраняется непрерывность этого многомерного «червяка».
Телепортацией 1) я бы пользоваться не стал. :)
В любом случае, такой способ определения идентичности объектов через их непрерывность в многомерном пространстве — это уже лучше, чем идентификация по естественным или суррогатным ключам — по каким-то атрибутам. Кстати, про атрибуты в BORO тоже много написано. Мы привыкли воспринимать всё через сито сущностей, атрибутов. А они говорят, что никаких атрибутов нет, есть состояния.
Отследить и записать непрерывность ("червяк") объекта само по себе видится неподъёмной задачей при существующих технологиях. Но даже если абсолютно везде понатыкают качественных камер слежения, то мы окажемся в мире абсолютно тотальной слежки. Или я чего-то не понял?
А они говорят, что никаких атрибутов нет, есть состояния.
А правда, как обычно, где-то посередине.
В реальности есть факт принадлежности сотрудника к классу/группе программистов или РП.
Это в модели, которая функциклирует в голове у менеджеров. В реальной реальности есть множество людей в здании. В ещё более реальной реальности это всё волны вероятностей и флуктуации вакукума. А в самой реальной реальности всё это тоже модель у кого-то в голове, а фактом является существование некоторой группы восприятий, что общаются друг с другом посредством интерфейса, который между собой называют внешним миром, и думают друг о друге в терминах "программист" и "руководитель проекта". Ну а в самой-самой реальной реальности… :)
Согласно авторам BORO, это признак того, что сам язык моделирования неправильный! Одни и те же реальные объекты, факты, события разные люди могут моделировать по-разному. Это значит, что они моделируют не реальность как она есть, а какие-то частные сведения о реальности.
Была когда-то, если мне не изменяет память, в Венском кружке пограмма логического позитивизма. Было такое мнение, что можно взять и зафиксировать некоторый список эмпирически проверенных фактов (т.н. "протокольные предложения") и строить на нём всю науку посредством экспериментального (эмпирический опыт) расширения и логического вывода. Вкратце: затея породила много интересных идей и направлений в развитии аналитической мысли, но в целом с треском провалилась. И имхо, "моделировать реальность как она есть" — чересчур амбициозный проект, который при буквальной интерпретации сводится чуть ли не к копированию самой реальности.
Пересказать всю книгу невозможно, это просто для затравки.
Благодарю за рассказ. Думаю, что общее представление получил. Надо будет как минимум полистать.Ares_ekb
07.01.2017 16:40+1Авторы BORO так глубоко не копают. Про флуктуации вакуума, про разницу между физической реальностью и тем, что мы воспринимаем. Прямо реальной физики там нет. Всё рассматривается на гораздо более приземленном уровне. Хотя рассматриваются и философские проблемы — различные парадоксы.
У них используется «бытовое» представление о пространстве и времени. Все люди более менее сходятся в том, что мы живем в 3-мерном пространстве, что существует ход времени, чтобы это ни значило. Я имею в виду обычных людей — ИТшников, бизнесменов и т.п. Квантовая физика, супер-струны, 10-мерные пространства и т.п. — это уже за рамками BORO.
И даже с учетом такого «примитивизма» BORO, на мой взгляд, сложна для понимания. Если бы они копали глубже, то вообще никто ничего не понял. В качестве практического использования BORO можно посмотреть ISO 15926, он позволяет создавать очень сложные модели различных промышленных установок (состоящих из множества компонентов), моделировать их жизненный цикл. Видимо, без 4-мерных объектов эти модели были бы хуже.
Насчет логического позитивизма интересная мысль. Я в своё время даже писал реферат по Логико-философскому трактату Витгенштейна и т.п., Венский кружок меня зацепил в философии сильнее всего. Наверное, идеальный, полностью непротиворечивый язык моделирования невозможен. Хотя ИТшники пытаются делать всякие универсальные верхне-уровневые онтологии. Наверное это невозможно. Короче, философия — это жесть. Если кто-нибудь уверен в том, что хорошо разбирается в моделировании, понимает, что такое свойство, событие, отношение часть-целое, то может почитать по ссылкам, что думают об этом философы :)maxstroy
07.01.2017 16:50+2Событие имеет очень точное определение (сам дал). Это пространственно-временной объект, ширина которого во времени с точки зрения наблюдателя равна нулю. Это я слизал из определения геометрической точки у Колмогорова. Точка — это материальное тело, размеры которого с точки зрения наблюдателя равны нулю.
Про свойство — это отдельный разговор, но я думаю, что скоро мы получим его определение
отношение часть целое, являющееся частным случаем отношения пересечения для 4-х мерных объектов сформулировать несложно.
Надеюсь, что мой оптимизм оправдан)
Danov
07.01.2017 17:35+1Может так:
Это пространственно-временной объект, продолжительностью которого можно пренебречь.
maxstroy
07.01.2017 17:42+2да, но только с точки зрения наблюдателя, потому что с точки зрения другого наблюдателя, пренебречь уже будет нельзя. Без указание на субъекта, определение становится бессмыслицей.
a1111exe
07.01.2017 17:59+1Не уверен, что понимаю, почему так важно считать событие атомарным по времени. Бывают ведь сценарии, в которых вход и выход из события различаются. Да и события нередко состоят из последовательности других событий. Т, е., можно мониторить некоторое событие, если только оно происходит в контексте какого-то другого события.
maxstroy
07.01.2017 18:50+1Вы говорите про операцию. Событие — мгновенно. Хотя, мне лично не важно, мгновенно или нет, но мне нужен объект с такими свойствами и этот объект должен отличаться от другого, который имеет протяженность во времени. Для себя я назвал это событием и операцией, но не настаиваю на своем
VolCh
07.01.2017 23:22+12) Сделать одну сущность «сотрудник» с атрибутом «роль», «должность» или «вид» и объединением всех атрибутов программистов и РП? 3) Сделать базовую сущность «сотрудник», от которой унаследовать программиста и РП?
По сути эти способы мало отличаются, создаётся сущность «сотрудник» и способ определения является ли сотрудник программистом или РП, а остальное низкоуровневые детали реализации.
1) Сделать две отдельные сущности: программист и РП?
Всё зависит от задачи. Не люди могут моделировать по разному (они, конечно, могут), а задача может «вынуждать» моделировать определенным образом. Далеко не всегда лучшим способом моделирования является максимальное приближение модели к объективной реальности, данной нам в ощущениях. Собственно моделирование и заключается в том, чтобы из этой реальности выявить важные для решения задачи аспекты и хорошо сгруппировать их, вообще игнорируя неважные. Если важные для задачи атрибуты программиста и РА практически не пересекаются, а даже если пересекаются, то никакого особого значения этот факт не имеет, то вполне можно не городить иерархическую модель с сотрудниками, а то и физлицами и даже животными и способами их идентификации, а просто сделать две сущности.michael_vostrikov
08.01.2017 05:27+1Если важные для задачи атрибуты программиста и РА практически не пересекаются, то вполне можно не городить иерархическую модель с сотрудниками и способами их идентификации, а просто сделать две сущности.
А потом у вас требования поменяются, и окажется, что для внешне небольшого изменения надо переделывать пол-системы)
Кмк, делать надо максимально близко к реальности, особенно это касается связей между сущностями, вопрос только в степени детализации.
VolCh
08.01.2017 11:32Прогнозирование возможных направлений изменений требований — важная часть моделирования.
lair
08.01.2017 12:49+1Кмк, делать надо максимально близко к реальности, особенно это касается связей между сущностями, вопрос только в степени детализации.
Дорого же.
Есть у вас, скажем, система, которая учитывает обращения людей. В ее рамках вам нужно учитывать и самих заявителей (физических лиц; например, чтобы знать, сколько обращений в год поступило от одного заявителя). Вот у вас появилась сущность заявитель (физическое лицо). С другой стороны, у вас есть пользователи, которые в системе работают, и их, конечно, тоже надо учитывать. Вот у вас появилась сущность "пользователь". Но в "реальности" пользователи — это те же физические лица (даже иногда могут быть заявителями, только для учета это не важно).
Казалось бы, было бы круто сделать сущность "физическое лицо", и две ее, скажем так, специализации — "заявитель" и "пользователь". Но немедленно возникают проблемы: во-первых, у этих сущностей нет общих полей (пользователь — это учетка AD + display name, заявитель — это ФИО, документ и так далее), так что базовая сущность будет вырожденной, а во-вторых, вы получите дополнительные накладные расходы с выражением этой иерархии в РСУБД.
Так что в подобном случае получается, что "максимально близко к реальности" — это накладные расходы без каких-либо преимуществ. А закладываться на "требования поменяются, все придется переделывать", конечно, хорошо, но не всегда есть ресурсы.
Ares_ekb
08.01.2017 13:51Это две разные модели: 1) модель, где есть сущность «физ. лицо» с в двумя ролями «заявитель» и «пользователь» и 2) схема данных в РСУБД.
Допустим, сейчас у пользователей указывается только display name. А в будущем понадобится указывать ФИО, дату рождения, пол, адрес электронной почты, телефонный номер и т.д. Причём, аналогичные поля могут быть и у заявителя. Вполне возможна ситуация, что сейчас атрибуты пользователей и заявителей практически не пересекаются, а в будущем они будут пересекаться очень сильно. Вполне возможно, что даже в этом случае из соображений производительности, безопасности или ещё каких-то в РСУБД сведения о пользователях и заявителях должны храниться в разных таблицах. Это не проблема.
Проблема в том, что фамилия пользователя может храниться в поле LastName и дата рождения в поле BirthDate, а у заявителя эти же поля могут называться соответственно FamilyName и DateOfBirth. На логическом уровне, на уровне РСУБД в зависимости от требований можно хранить все эти сведения и в 1 таблице, и в 2, и в 3, и в большем количестве таблиц (отдельно обычные заявители, отдельно — vip). Но если над логической моделью нет концептуальной модели (или Computation-Independent Model (CIM), модели бизнес-объектов и т.д. — можно по-разному их называть), т.е. модели, которая не завязана на технические детали (типа AD, РСУБД и т.п.), то неизбежно 1) будет возникать подобное дублирование, расхождения и 2) возможны существенные изменения модели (вчера считали пользователя и заявителя отдельными сущностями, а завтра наследуем их от физ. лица).
На концептуальном уровне хочется модель, которую один раз согласовали, утвердили и дальше только дополняем, без существенных переделок. В обсуждаемой книге как-раз и предлагается способ построения таких моделей. Будет класс «физ. лицо». Физ. лица могут играть роли пользователей, заявителей и т.п. В будущем могут появляться новые роли, могут появляться новые атрибуты. Но каких-то существенных изменений в физ. лицах, заявителях и пользователях уже не будет. Уже невозможна ситуация, при которой мы будем перелопачивать какие-то иерархии, ломать уже утвержденные классы и т.п.
Безусловно, разрабатывать такую полностью «правильную» концептуальную модель на десятилетия вперед очень дорого. Более того, как говорит Патридж (автор книги про бизнес-объекты), в терминах сущностей, атрибутов и связей такую модель невозможно построить в принципе. Значит, нужны методологи, которые прочитают Патриджа и другие книги, выберут из множества подходов оптимальный, как-то адаптируют его, разработают ядро будущей концептуальной модели, напишут методику, как эта модель должна дорабатываться. Это не пустые слова, я видел такие проекты. Всё это не то, что дорого, а очень дорого. Но если этого не делать, то расходы на перелопачивание модели, на переписывание кода будут ещё больше.
Короче, всё зависит от проекта, от требований. Часто можно сразу делать схему РБД и не заморачиваться с «объектами реального мира» и т.п. Но есть проекты, где никак не обойтись без «реального мира». Например, проекты, в которых используются ISO 15926, UN/CEFACT CCTS, ISO 20022 и др.
Вопрос в том, что дороже: 1) вносить изменения в модель и код или 2) изначально делать максимально «правильную» модель, которая в будущем будет только дополняться.lair
08.01.2017 13:56-2Допустим, сейчас у пользователей указывается только display name. А в будущем понадобится указывать ФИО, дату рождения, пол, адрес электронной почты, телефонный номер и т.д. Причём, аналогичные поля могут быть и у заявителя. Вполне возможна ситуация, что сейчас атрибуты пользователей и заявителей практически не пересекаются, а в будущем они будут пересекаться очень сильно.
Вот это "будущее" — оно неизвестно. Строить систему на неизвестных допущениях — опасно.
Вопрос в том, что дороже: 1) вносить изменения в модель и код или 2) изначально делать максимально «правильную» модель, которая в будущем будет только дополняться.
Во всех проектах, в которых я участвовал, дороже было второе — если, конечно, под "правильным" вы понимаете "как в реальности", а не "как оптимально для бизнеса".
Ares_ekb
08.01.2017 14:16+1Вот, примеры моделей, которые делаются из расчета, что они будут использоваться десятилетия без революционных изменений, любые изменения в этих областях влекут большие расходы:
1) ISO 20022, можно её скачать в Ecore-формате, в ней определены сотни сущностей, сведения о которых передаются в этих сообщениях.
2) NIEM тоже можно скачать, это относительно большая модель. Безусловно в неё вносятся изменения, но это требует обоснований, согласований. Переход на новую версию модели тоже влечет расходы.
3) UN/CCL можно скачать.
4) Но по сравнению с ISO 15926 все эти модели — просто детский сад. Она основана на 4-мерных бизнес-объектах Патриджа.
Бизнесу нужны только структуры сообщений. Верхний уровень, описывающий реальность им не нужен. Особенно верхний уровень ISO 15926 настолько далек от потребностей бизнеса, что наверное мало кто вообще понимает что там и зачем. Но чтобы структуры сообщений не менялись по каждому чиху, чтобы бизнес не тратил деньги на эти изменения, приходится привязывать модели к реальности, потому что она более устойчивая и надежная чем структуры документов или ещё какие-то частности.lair
08.01.2017 14:28-2Я очень рад, что где-то там есть такие модели, которые десятилетиями не меняются. Дело, однако же, в том, что в моем личном опыте эти модели пока не были востребованы. Хуже того, например, обработчик платежей, с которым я сталкиваюсь, слышать не хотел про ISO 20022, так что пользы мне от этой модели совершенно никакой.
А при этом, с другой стороны, в конкретной прикладной задаче, которую я решаю сейчас, стоимость любого изменения модели все равно меньше, чем потери, которые я несу от задержки выпуска первой версии — поэтому мне намного выгоднее примитивная модель (или вообще ad-hoc решение) и выпуск завтра, чем попытка построить полную модель домена (с учетом потенциальных будущих требований) и выпуск через месяц.
Ares_ekb
08.01.2017 14:53+1слышать не хотел про ISO 20022
Это сейчас. В долгосрочной перспективе во многих областях единые модели постепенно заменяют ad hoc решения. Правда появляются новые ad hoc решения. Не знаю придём ли мы когда-нибудь к единой модели всего, такой, что ad hoc модели уже не понадобятся.
в конкретной прикладной задаче, которую я решаю сейчас, стоимость любого изменения модели все равно меньше, чем потери, которые я несу от задержки выпуска первой версии
Я последние несколько лет тоже решаю совершенно конкретные прикладные задачи. Но опыт прямо противоположный: быстрые ad hoc решения потом дорого обходятся. Хотя истина где-то посередине: за сверх-гениальную модель, первая версия которой будет сделана через 10 лет, тоже уже не заплатят.lair
08.01.2017 14:56-2Это сейчас. В долгосрочной перспективе во многих областях единые модели постепенно заменяют ad hoc решения.
Ну так мне интегрироваться-то надо прямо сейчас, так что долгосрочная перспектива — это круто, но писать ради нее адаптер несколько накладно.
VolCh
08.01.2017 15:12+2Тут вопрос «дороже» неоднозначный. Если делать изначально максимально «правильную» модель, то могут быть (вернее будут) большие затраты на начальном этапе и минимальные при развитии, а если делать согласно текущим требованиям, то наоборот. Плюс, как правило, разработка модели особо не масштабируется, а это значит сроки выхода на рынок с «правильной» моделью будут в разы выше. То есть нужно смотреть не только на общую стоимость разработки, но и на распределение затрат по времени, на сроки выхода на окупаемость, возврата начальных инвестиций и прочие бизнес-метрики. А если размер доступных начальных инвестиций в принципе не покрывает стоимость «правильной» разработки, то выбирать приходится между «делаем неправильно» и «вообще не делаем».
VolCh
08.01.2017 13:52+1Но в «реальности» пользователи — это те же физические лица даже иногда могут быть заявителями, (только для учета это не важно)
Выделил ключевую информацию для принятия решения создавать сущность «физическое лицо» или нет.
Более того, даже если это для учёта важно, то дешевле может быть, например, делать поиск по двум множествам, чем, скажем, вводить сложную систему поиска с учетом прав пользователя, когда непривилегированный пользователь не должен видеть ни при каких условиях данных других пользователей, кроме данных относящихся к ним как к заявителям, если они выступали в этом качестве.lair
08.01.2017 13:57-1Ну да, мы опять возвращаемся к тому тезису, что "правильная" модель определяется задачей, а не тем, как "в реальности".
michael_vostrikov
08.01.2017 14:34Накладные расходы можно регулировать степенью детализации. Смысл не в том, чтобы спроектировать все заранее, а чтобы была возможность расширить систему без глобальных изменений. Вернее, глобальное изменение в реальности должно приводить к глобальным изменениям модели, мелкое к мелким.
Учетная запись для входа в систему и физическое лицо с ФИО это разные сущности. Это следует из вашего описания, так как может быть заявитель без учетки и учетка, обладатель которой не является заявителем. Между ними связь один к одному (как правило). Можно не обозначать эту связь, пока она не понадобится. Но если нам вдруг будет важно, кто из заявителей работает в системе, мы сможем ее добавить.
lair
08.01.2017 14:43-1Вернее, глобальное изменение в реальности должно приводить к глобальным изменениям модели, мелкое к мелким.
Не "в реальности", я подозреваю, а в требованиях. Реальность обычно меняется редко.
Учетная запись для входа в систему и физическое лицо с ФИО это разные сущности. Это следует из вашего описания, так как может быть заявитель без учетки и учетка, обладатель которой не является заявителем.
Но "в реальности" и то, и другое — это просто человек, один и тот же "объект". Когда мы вводим "учетную запись" (вообще абстракцию) и что-то, под названием "заявитель" — мы как раз отходим от реальности.
Так что в итоге мы все равно балансируем компромисы — что нам легко реализовать сейчас, какие потенциальные изменения мы предвидим и хотем сделать их легкими, какие потенциальные изменения мы не боимся сделать тяжелыми.
Ares_ekb
08.01.2017 15:02+1Физ. лицо — это класс объектов. Заявитель — это роль, которую может играть физ. лицо. У физ. лица есть свойства ФИО, дата рождения и т.д. У заявителя не могу придумать свойства, пусть будет связь с заявлением.
Например, в будущем в качестве заявителя может выступать ещё и юр. лицо. В этом случае мы ничего не перелопачиваем, а просто добавляем новый класс юр. лицо и отмечаем, что его экземпляры могут играть роль заявителя.
Если в будущем нам понадобятся роли водитель, перевозчик и т.п., то мы просто их добавим в модель, не ломая того, что уже есть.
А, вот, если бы мы сделали ФИО и дату рождения атрибутом заявителя. То появление заявителей-юр.лиц потребовало бы существенных изменений модели.lair
08.01.2017 15:07-1Физ. лицо — это класс объектов. Заявитель — это роль, которую может играть физ. лицо. У физ. лица есть свойства ФИО, дата рождения и т.д. У заявителя не могу придумать свойства, пусть будет связь с заявлением.
Угу, только для физлица ничто из (фамилия, имя, отчество) в модели обязательно быть не может, а для заявителя — по закону, каким бы глупым он ни был — обязательны фамилия и имя. Удачи в выражении этого в модели.
В этом случае мы ничего не перелопачиваем, а просто добавляем новый класс юр. лицо и отмечаем, что его экземпляры могут играть роль заявителя.
… стоимость реализации этого "просто отмечаем, что связь теперь может быть не с одним классом, а с двумя" вы, конечно, не учитываете?
То появление заявителей-юр.лиц потребовало бы существенных изменений модели.
Знаете, когда появление заявителей-юрлиц в бизнесе требует изменений законодательства, существенные изменения модели в этом случае уже никого не пугают.
Ares_ekb
08.01.2017 15:50+1А в этой модели и не нужно отмечать, что у заявителя ФИО обязательно. В одном случае оно обязательно, а в другом случае обязателен какой-нибудь ИНН, а ФИО наоборот нельзя указывать.
Мы говорим о разных моделях. Я о концептуальных, для которых требуется максимальный охват и минимум ограничений. А вы — о логических, где появляются все эти ограничения на обязательность заполнения атрибутов и т.п. В одном сценарии/процессе ограничения будут одни, в другом — другие. А концептуальная модель во всех случаях единая.
Добавить в модель связь между юр.лицом и заявителем дешевле, чем переименовывать ФИО в «название» и переносить дату рождения в какой-то другой класс. Переименовывания, переносы и прочие изменения уже существующего обходятся безусловно дороже, чем добавление нового.
Я согласен с тем, что сделать идеальную модель на все случаи в жизни невозможно. Если юр.лица или, скажем, марсиане :) в принципе не могут выступать в качестве заявителя, то наверное такие ситуации и не стоит рассматривать. Если есть какой-то документ, в котором уже всё описано, что может быть, чего не может быть, тогда и моделировать особо нечего, нужно просто реализовать как написано.
Представьте, что вы находитесь по другую сторону законодательства. Кто-то же придумывает все эти структуры документов, схемы данных для предоставления отчетности. Я имею в виду ИТшную составляющую, а не бюрократическую. Если вы вдруг скажете, ой, вот, тут мы в схеме данных что-то не учли, давайте переделаем. Представляете какие это расходы для бизнеса. Для вас сейчас (по эту сторону) это конечно доходы, вам платят за изменение моделей и кода в соответствии с изменениями законодательства. Но для бизнеса-то — это расходы и «законодателей» за частые и существенные изменения могут и премии лишить.lair
08.01.2017 15:56-1Мы говорим о разных моделях. Я о концептуальных, для которых требуется максимальный охват и минимум ограничений.
Эмм, я, возможно, сейчас задам глупый вопрос, но зачем мне эта концептуальная модель?
Добавить в модель связь между юр.лицом и заявителем дешевле, [...] Переименовывания, переносы и прочие изменения уже существующего обходятся безусловно дороже, чем добавление нового.
А "заявитель" — это уже существующая сущность. Более того, раньше у нее была обязательная связь с физлицом, а теперь у нее обязательна одна (и только одна) связь из (юрлицо, физлицо). Это изменение, причем не очень дешевое.
Представьте, что вы находитесь по другую сторону законодательства. Кто-то же придумывает все эти структуры документов, схемы данных для предоставления отчетности. Я имею в виду ИТшную составляющую, а не бюрократическую.
Ну так — в РФ, по крайней мере — ИТ-шная составляющая долго была подчинена бюрократической. Если в законе (или подзаконном акте) описан состав данных для конкретного учета, то ИТ-шная часть вынуждена его отражать, даже если этот состав данных давно устарел и бессмысленнен вне бумаги.
Если вы вдруг скажете, ой, вот, тут мы в схеме данных что-то не учли, давайте переделаем. Представляете какие это расходы для бизнеса
Представляю: рутинные. А представляете себе, какие расходы для государства, если из-за того, что вы пытаетесь все учесть в схеме данных, бизнес не может подавать налоговые декларации в электронной форме еще два года?
Ares_ekb
08.01.2017 16:19+1Эмм, я, возможно, сейчас задам глупый вопрос, но зачем мне эта концептуальная модель?
Вы сами ответили на этот вопрос:
Ну так — в РФ, по крайней мере — ИТ-шная составляющая долго была подчинена бюрократической. Если в законе (или подзаконном акте) описан состав данных для конкретного учета, то ИТ-шная часть вынуждена его отражать, даже если этот состав данных давно устарел и бессмысленнен вне бумаги.
Если как есть перевести бумажные документы в электронную форму, то в них будут бессмысленные поля. Например, полное наименование страны вместо указания кода. Но это ерунда по сравнению с тем, что количество форм бумажных документов в некоторых областях исчисляется сотнями. Причем, сведения во всех этих документах передаются примерно обо одних и тех же объектах реального мира. Только в одном документе обязательны одни атрибуты, а в другом — другие. И если из этой сотни бумажных форм сделать сотню электронных форм, то жизнь у законодателей и бизнеса станет немного лучше, но не так как хотелось бы. А хотелось бы превратить эту условную сотню бумажных документов в единую концептуальную модель данных, в которой описаны все реальные объекты, о которых передаются сведения в документах. А потом, имея эту единую КМ, просто отмечать, что в этом процессе или сценарии мне нужны такие-то свойства таких-то объектов, а в этом процессе — такие-то.
Я понимаю, что перевод бумажных документов в электронную форму сам по себе безусловно даёт преимущества. Не нужно стоять в очередях, быстрее всё будет обрабатываться. В качестве первого шага — это замечательно. Но документо-ориентированный подход порочен сам по себе и неважно бумажный он или электронный. Я всё время возвращаюсь к книге Патриджа про бизнес-объекты. Он ровно про это и пишет. Что тысячелетиями мы придумывали новые формы документов, но сейчас настало время полностью отказаться от этого подхода.lair
08.01.2017 16:24-1Вы сами ответили на этот вопрос:
О нет. То, что вы приводите дальше — это как раз объяснение нужности хорошей модели. Но зачем нужна концептуальная?
А хотелось бы превратить эту условную сотню бумажных документов в единую концептуальную модель данных, в которой описаны все реальные объекты, о которых передаются сведения в документах. А потом, имея эту единую КМ, просто отмечать, что в этом процессе или сценарии мне нужны такие-то свойства таких-то объектов, а в этом процессе — такие-то.
В таком случае, опять-таки, я не понимаю, чем ваша "концептуальная модель" отличается от нормальной унифицированной прикладной.
тысячелетиями мы придумывали новые формы документов, но сейчас настало время полностью отказаться от этого подхода.
Это все круто, но когда заказчик просит автоматизировать его деятельность согласно текущему законодательству, это немного неприменимо.
Ares_ekb
08.01.2017 16:37+1А что вы имеете в виду под нормальной унифицированной прикладной моделью? Вы не сможете в ней зафиксировать обязательность атрибутов и связей. Потому что в одном документе нужны одни атрибуты и связи, а в другом — обязательны другие. Поэтому единственный способ сделать единую модель — это описать в ней все возможные сущности со всеми возможными атрибутами и связями. Причём, всё они будут опциональные, потому что в разных документах/процессах нужны разные.
lair
08.01.2017 16:42-1А что вы имеете в виду под нормальной унифицированной прикладной моделью?
Модель, которая охватывает всю моделируемую область безотносительно конкретных сценариев использования.
Вы не сможете в ней зафиксировать обязательность атрибутов и связей.
Смогу — хотя бы взяв пересечение обязательностей во всех моделируемых процессах. Это самое простое решение, но даже оно уже работает. Другой вопрос — надо ли мне это.
Собственно (если я ничего не путаю), мы сейчас обсуждаем то, что у Эванса называется bounded contexts — когда одна и та же сущность предметной области в разных контекстах называется по-разному и имеет разные свойства.
Ares_ekb
08.01.2017 16:49+1Модель, которая охватывает всю моделируюмую область безотносительно конкретных сценариев использования.
Это и есть концептуальная модель. Или в терминологии OMG — это Computation-Independent Model (CIM), а в терминологии Патриджа — это бизнес-модель из 4-мерных бизнес-объектов. Другие авторы называют такие модели онтологиями. UN/CEFACT называет такую модель вообще библиотекой ключевых компонентов.
Везде разные названия, разная специфика, разные акценты, но фактически имеется в виду именно то, что вы написали.lair
08.01.2017 16:51-1Однако, как говорилось выше, нужность такой модели в каждом конкретном проекте неочевидна.
VolCh
08.01.2017 16:11Я о концептуальных, для которых требуется максимальный охват и минимум ограничений.
Создать такую модель для физлица практически нереально. Даже для фиксации чисто документарных фактов. Как минимум потому, что документарные факты могут отражать факты порядка 200 государственных юрисдикций. Иной раз противоречащие друг другу даже в одной юрисдикции. Скажем, два паспорта с разными ФИО без факта изменения ФИО.
Да даже без этого. Вот беру популярную модель Person со schema.org — даже беглое пробегание глазами показывает, что её недостаточноAres_ekb
08.01.2017 16:29+1На все случаи в жизни не реально. Но, скажем, взять десяток бумажных документов в какой-нибудь конкретной предметной области, посмотреть какие сведения о физ. лице в них указываются и сделать единую модель вполне реально.
Модель на schema.org безусловно не идеальна. Например, у человека может быть несколько jobTitle в разных организациях и в разные периоды времени. Возможно, есть смысл определить отдельную роль «Работник», у которого будет jobTitle, период времени, в течении которого человек играл эту роль, привязка к организации и т.п. И соответственно в разные моменты времени человек может играть роли разных работников.
В этом и проблема. Не всегда ясно делать ли jobTitle атрибутом человека или выносить отдельно. Однозначного, универсального ответа нет. Но Патридж в книге про бизнес-объекты предлагает один из возможных вариантов. В книге как-раз есть примеры про должности.
michael_vostrikov
08.01.2017 15:18+1Да, требования более точное слово)
Учетная запись — это не человек, хотя бы потому что у человека может быть 2 учетных записи. Человек пользуется учетной записью для входа. Даже если у нас требование не иметь более одной учетной записи, они не перестают быть разными сущностями со связью между ними.
Под реальностью я имею в виду в том числе и понятия, используемые в реальной деятельности. Так что "заявитель" это тоже реальность. Или требования, если хотите. То есть, есть некоторая реальность, и есть ее отображение в информационной системе.
Компромиссы конечно есть, и я говорю о том, что они в первую очередь должны касаться степени детализации, а не принципа моделирования. То есть, не делать две сущности там, где она одна, но делать одну, если их две, но вторая нам пока не нужна. И если мы по каким-то техническим причинам отходим от этого, то должны понимать, к чему это приведет.
lair
08.01.2017 15:26-1Учетная запись — это не человек, хотя бы потому что у человека может быть 2 учетных записи.
Вот именно поэтому у меня изначально было написано "пользователь".
Компромиссы конечно есть, и я говорю о том, что они в первую очередь должны касаться степени детализации, а не принципа моделирования.
Ну так объединение или разделение сущностей — это тоже "степень детализации".
michael_vostrikov
08.01.2017 16:01+1Я бы сделал так. User — используется для входа в систему, имеет логин и пароль. Person — имеет ФИО. Applicant — имеет ссылку на Person (поле person_id), и остальные поля, необходимые для бизнеса — цель обращения и т.д. Если разрешается иметь только одну учетную запись, то в User тоже есть поле person_id. Если несколько, либо мы не можем менять User по техническим причинам, то связь выносится отдельно (в промежуточную таблицу). Требование обязательности ФИО для Applicant осуществляется бизнес-логикой приложения — нельзя зарегистрировать заявителя, если у связанной с ним Person оно не заполнено.
Ну так объединение или разделение сущностей — это тоже "степень детализации".
Скажем так, введение новых сущностей — это не всегда степень детализации. Иногда это неправильное проектирование.
lair
08.01.2017 16:03Требование обязательности ФИО для Applicant осуществляется бизнес-логикой приложения — нельзя зарегистрировать заявителя, если у связанной с ним Person оно не заполнено.
Вот это и есть дополнительные накладные расходы. Ну и вообще схема сложнее, чем можно было бы обойтись, а полезность этого усложнения не очевидна.
VolCh
08.01.2017 16:16А что будете делать, если нужно создать технического пользователя? ФИО «Админ Админович Админов» заполнять?
Или поиск среди заявителей по ФИО должен отображать только заявителей, а поиск среди пользователей только пользователей — вероятность того, что где-то кто-то опустит условие и покажет то, что нельзя показывать, очень велика.michael_vostrikov
08.01.2017 16:58А зачем ФИО заполнять? Вот если бы у нас ФИО было свойством User, тогда и надо было бы заполнять.
Поиск среди заявителей делается в таблице сущности Applicant, среди пользователей в таблице User, и там и там будет inner join с таблицей Person.
Если мы для производительности сделаем денормализацию, то это не значит, что у нас по задаче нет сущности Person, а значит что мы намеренно отошли от соответствия реальности для технических целей, и понимаем, к чему это может привести.VolCh
08.01.2017 18:16+1Чтобы отобразить имя пользователя. При разделении сущностей мы для пользователей делаем поле типа showName, в котором в подавляющем большинстве случаев пишем ФИО пользователя, но в целом не ограничены ничем семантически. Если мы привязываем Person, то логично от showName избавиться, как у дублирующего поля в подавляющем большинстве случаев.Но вот исключения остаются. Можно обойти, да, например, проверяя заполненность showName и только если пустое, то выбирать ФИО из Person, но это усложнение логики, особенно если добавляем условие, что заполнено должно быть одно и только одно из полей.
В том-то и дело, что искать мы будем в таблице Person, а inner join с User/Applicant будет условием, ограничивающим выборку из множества физлиц подмножеством пользователей или заявителем. И про это условие можно легко забыть. Или прийти в такой проект, получить задачу, посмотреть схему БД и не понять, что «поиск физлиц» в интерфейсе пользователя означает только поиск среди заявителей.michael_vostrikov
08.01.2017 18:57Если мы сразу выделим сущность Person, то никакого showName не будет.
Если есть задача по поиску заявителя по ФИО, то искать надо в таблице Applicant, если физлица, то Person. Проектировать систему исходя из текста будущих задач как-то не очень правильно.
VolCh
08.01.2017 22:33showName — это простая реализация требования показывать имя пользователя (реальное ФИО для аккаунтов сотрудников или абстрактное «Администратор» для технических) в случае разделения сущностей.
В таблице Applicant у нас ФИО нет, оно в Person: «Person — имеет ФИО. Applicant — имеет ссылку на Person (поле person_id), и остальные поля, необходимые для бизнеса — цель обращения и т.д.»michael_vostrikov
09.01.2017 05:00Ага, то есть в требованиях есть разделение на технические и нетехнические аккаунты. Оно может быть не прописано явно, но вызовет вопрос у программиста/проектировщика.
Вообще, логичнее выдавать права администратора на аккаунт сотрудника. В этом случае в интерфейсе будет ФИО пользователя, а под ним название группы прав "Администратор". Но если делать так, как вы сказали, то можно сделать поле "тип аккаунта" — администратор/пользователь, и для пользователей выводить ФИО.
А теперь представьте, что у вас многоязычная система. Слово "Администратор" переводить надо, а ФИО нет. Как их отличать, если они хранятся в поле showName?
Так вот именно, искать надо в таблице Applicant, но так как там ФИО нет, то мы никак не забудем сделать join с таблицей Person. Так же как если надо найти заказы на определенную категорию товаров, то искать надо в таблице Order, а не Product, сделать join с Product, и отфильтровать по Product.categoryId. Кроме того, нам нужно не ФИО само по себе, а какие-то данные, связанные с ним — цель обращения например, которые в Person точно не хранятся.
VolCh
08.01.2017 15:28«Заявитель» не существует в реальности, это абстракция, вводимая бизнесом, независимо от того автоматизирован он или нет с помощью вычислительных систем, для, с одной стороны, выделения интересующего подмножества из множества всех лиц, и, с другой, для акцента в модели на нужные для взаимодействия с этим подмножеством свойства и игнорирования ненужных. В реальности есть только человек, физическое лицо. Роли, которые он «играет» в разных процессах — это уже абстракции.
maxstroy
08.01.2017 16:09Человек — тоже абстракция, как и роли. Это — один уровень абстракции, просто разные методы учета применяются для учета людей и для учета ролей.
VolCh
08.01.2017 16:25+1Конкретный человек — объективно существующая реальность, а не абстракция. Его модель «физлицо» — абстракция. Его роли в процессах — абстракция. Но вот уровни этих абстракций совсем не обязательно одинаковы. Роли могут быть наследниками физлица, физлицо может быть агрегатором ролей, и вообще может не быть явной сущности физлица и/или роли. Всё зависит от задачи, выделенных ресурсов и квалификации проектировщика.
maxstroy
08.01.2017 18:22+1Я делал доклад на конференции Нефтегазстандарт-2016 по моделированию активов предприятия, будь то физлиц, машин, техмест, ролей… В статье Моделирование активов предприятия: современные стандарты и практика попытался изложить этот доклад тезисно. Там я попытался изложить симметричный подход к моделированию любых активов
michael_vostrikov
08.01.2017 16:27Практически любое слово языка — это абстракция. Например, "дерево". Деревьев нет в реальности, есть сосны, ели, и т.д. Да и их нет, сосна и ель это тоже абстракции, обозначающие некий обобщенный набор признаков, а в лесах растут конкретные экземпляры.
Возможно, слово "реальность" тут не очень подходит, но я обозначаю им то, что происходит вне информационной системы. А внутри нее есть модель этого. Получается, что какая-то другая внешняя информационная система, в том числе и система человеческих понятий, это тоже реальность, которая существует независимо от рассматриваемой (проектируемой) ИС. Это не физическая реальность, а информационная, если можно так выразиться.
VolCh
08.01.2017 18:21Ваша реальность называется «принятая у экспертов предметной области модель это области, обычно слабоформализованная»?
michael_vostrikov
08.01.2017 18:39Реальность — это все то, что находится вне информационной системы. Внутри нее есть модель некоторой части этой реальности. Предметная область — тоже часть этой реальности.
Ares_ekb
08.01.2017 09:52+1Согласен с Вами и Михаилом, что дело не в людях, которые моделируют, а в требованиях.
Вообще эта идея не нова. Есть деление на концептуальный, логический, физический уровни. В архитектуре, управляемой моделями, деление на CIM, PIM, PSM — очень рекомендую прочитать документ по ссылке тем, кто интересуется моделированием. В какой-нибудь модели Захмана уже другие уровни. Но идея везде одна — на верхнем уровне моделируем реальность, независимо от технических деталей, от того как именно будет реализована ИС. На следующих уровнях моделируем уже саму ИС.
В BPMN, кстати, основная идея такая же (у Makhinko был вопрос по моделированию процессов). Если вы сомневаетесь правильно ли спроектировали процесс, то представьте, что он будет выполняться не с помощью разрабатываемой программы, а посредством бумажных документов или вручную. Или представьте, что он выполняется 100 лет назад или спустя 100 лет при совершенно других технических возможностях. Если процесс при этом не нужно перерисовывать, если вы не указали в нём лишние технические детали (типа нажать на кнопку, отправить сообщение и т.п.), значит процесс спроектирован нормально. Иначе кнопку заменят на ссылку, отправку текстового сообщения — на голосовое управление, и модель процесса станет уже не актуальной. Лишние технические детали и усложняют понимание моделируемого процесса, и ограничивают людей, которые будут разрабатывать под него ИС.
Короче, в обсуждаемой книге накомпилировано много разных идей про разницу между моделированием объектов реального мира и моделированием ИС. 4-мерное пространство-время они взяли у физиков. То, что модели сущность-связь имеют ограничения тоже придумано не ими — есть объектно-ролевое моделирование, позже появились всякие RDF, OWL.
В вузе нас учили, что логические модели отличаются от концептуальных только степенью детализации. Типа на концептуальном уровне мы выделяем сущности, определяем отношения между ними. А на логическом уровне добавляем атрибуты, указываем ключи и т.п. Разница между концептуальными моделями и логическими была какая-то мутная. Скажем, почему атрибуты нельзя указать сразу на концептуальном уровне? И зачем вообще такое деление? Чтобы не грузить заказчика лишними деталями? А если ему важны эти детали? Короче, в вузе я это не понимал.
А в этой книге говорится, что на концептуальном и логическом уровнях (можно эти уровни называть иначе) моделируются в принципе разные вещи. На верхнем уровне моделируется, скажем, человек, автомобиль. А на уровне ИС моделируются сведения об этих объектах, представленные в виде каких-нибудь документов (паспорт, технический паспорт и т.п.). Т.е. ты должен чётко понимать моделируешь ты объект или документы и т.п.
Кстати, я писал на эту тему статью, там наверное много наивных вещей и заблуждений, но может кому-то будет интересно. Там приводится пример про перевозку креветок. Есть три стороны, которые задействованы в этом процессе — производитель, перевозчик, таможня. Каждая из сторон смотрит на одни и те же креветки (объект реального мира) через призму своих документов (таможенная декларация, транспортные документы и т.п.). Идея в том, что если мы моделируем креветок как они есть, абстрагируясь от документов и ИС (в которых будут учитываться сведения о креветках), то модель будет более универсальная, более устойчивая. Скажем, если изменится структура таможенной декларации, то такую модель это либо вообще не затронет, либо модель будет просто немного дополнена. Каких-то кардинальных изменений в ней не будет.maxstroy
08.01.2017 10:10на концептуальном уровне мы выделяем сущности, определяем отношения между ними
Я с удивлением обнаружил ошибку в определении концептуальной модели. Я всегда думал, что на концептуальной модели мы моделируем концепты объектов и концепты отношений между объектами. Но не концепты объектов и отношений между ними. Кто-то попутал и концепт отношений назвал отношениями. Из этого получилось, что на модели мы видим концепты объектов и отношения между концептами! Но это неверно.Ares_ekb
08.01.2017 10:39Это вопрос терминологии и определений. Например, тут пишут, что концептуальная модель состоит из концептов (понятий), как вы и говорите, но потом:
Entity-relationship modeling (ERM) is a conceptual modeling technique used primarily for software system representation. Entity-relationship diagrams, which are a product of executing the ERM technique, are normally used to represent database models and information systems. The main components of the diagram are the entities and relationships.
Ну, т.е. они пишут просто «сущность» и «отношение», а не «концепт сущности» или «концепт отношения».
Блин, короче тут вообще путаница. Сначала они говорят, что концептуальные модели обычно про реальный мир:
Conceptual models are often abstractions of things in the real world whether physical or social.
А потом говорят, что ER-модели концептуальные, но про информационные системы, а не реальный мир (см. первую цитату).
Огромное количество разных подходов к моделированию. Они вроде про одно и то же, но везде разная терминология.maxstroy
08.01.2017 10:52Путаница возникла из недисциплинированности. Эту путаницу я расковырял и описал в статье Моделирование объектов учета. Цитата оттуда:
Я часто слышу термины, которые у меня как у предметника вызывают непонимание: экземпляр стула, экземпляр процесса, экземпляр класса. Отдельно от контекста эти термины совершенно безобидны, потому что имеют вполне устоявшееся значение: экземпляр стула – это объект типа стул, или просто стул. Экземпляр процесса – это объекта типа процесс, или просто процесс. Экземпляр класса – это объект типа класс, или просто класс. Однако в контексте эти термины звучат совершенно невозможно. Например, ИТ специалист может сказать: экземпляр этого стула, или экземпляр этого процесса, или экземпляр этого класса. При этом, если он говорит экземпляр этого стула, то он показывает на стул. А, если он говорит экземпляр этого класса стульев, то он опять показывает на тот же стул. Человеку, далекому от ИТ, это кажется невозможным.
Впервые подобное искажение терминов я встретил в теории реляционных баз данных. Вместо термина тип объектов там был применен термин entity (сущность), а вместо термина объект — instance of entity (экземпляр этой сущности). Почему так получилось, — можно только гадать, но, видимо, потому что авторы этой теории плохо разбирались в терминах, а спросить у специалистов либо постеснялись, либо поленились. Если переводить с терминов реляционной модели в термины русского языка, то выражение экземпляр этого стула в переводе звучало бы так: экземпляр стульев этого типа. Термин экземпляр этого процесса в переводе звучал бы: экземпляр процессов этого типа.
Накопленные ошибки перекочевали в ООП, но теперь тип объектов был заменен на другой термин class (класс), а термин объект на instance of class (экземпляр этого класса). Поскольку значение термина класс в русском языке отличается от значения термина тип, то высказывание экземпляр этого класса процессов теперь уже можно перевести двумя способами: экземпляр процессов этого типа, или (что реже, но также встречается) элемент этого класса процессов.
Если ИТ специалист говорит в терминах реляционных баз данных экземпляр этого процесса, то, я успеваю перевести его слова, но, если он говорит в терминах ООП экземпляр этого класса процессов, то я уже не успеваю. Во-первых, потому что есть два способа перевода, и надо понять из контекста, какой способ перевода сейчас более подходит по смыслу. А во-вторых, автор, не различая термины тип и класс, может незаметно для себя менять смысл высказывания прямо на лету, иногда в одном предложении! Тогда рождаются тезисы, лишенные всякого смысла и невозможные для перевода.sand14
08.01.2017 12:25Накопленные ошибки перекочевали в ООП, но теперь тип объектов был заменен на другой термин class (класс), а термин объект на instance of class (экземпляр этого класса).
А во-вторых, автор, не различая термины тип и класс, может незаметно для себя менять смысл высказывания прямо на лету, иногда в одном предложении! Тогда рождаются тезисы, лишенные всякого смысла и невозможные для перевода.
Можно предположить, откуда взялся ошибочный термин class для обозначения ОО-типа данных:
до появления ООП программист не мог определять свои типы данных, за исключением, возможно, записей (Record) в Паскале и Си и объединений (Union) (как частный случай Record) в Си,
а также множеств (Set) в Паскале.
Кстати, уже тут закралась путаница — в данном случае «множество» это не множество, а прообраз перечислений (Enum) — ограниченного набора именованных целочисленных значений.
Но записи эти и не были полноценными типы данных, скорее это средства группировки более чем одной переменной — кортежи.
Когда с появлением ООП программисты смогли определять свои типы данных, почему то такие типы решили классифицировать как класс (class).
Вероятно, потому, что экземпляры таких типов по понятным причинам назывались объектами (имеющих состояние и поведение).
А раз объекты создаются по шаблону, определенному в типе, то значит, объекты одного типа образуют множество (класс).
Ошибка именно здесь — множество (класс) объектов это в свою очередь отдельная сущность (тип + его экземпляры).
Но такие сущности средствами ООП нужно конструировать отдельно, т.к. встроенной поддержки множеств в синтаксисе/модели ООП не сделали.
В результате ошибочного названия ОО-типа данных класс происходит много ошибок, начиная от заведения в псевдо-«классе» статических полей для подсчета количества созданных объектов «класса».
Кроме того, «класс» не единственный используемый термин.
В Паскале ОО-тип данных назывался… объект — object. Интересно, как тогда называть экземпляры такого типа данных — объект объекта (если просто сказать «объект» — непонятно, речь об экземпляре или типе)?
Кроме того, например в .NET, ОО-типы данных, позволяющие создавать объекты, размещаемые не в куче, а на стеке, называются структурами (struct).
Но с точки зрения OO-модели (инкапсуляция данных, поведение и полиморфизм этого поведения, etc) это такие же объекты.
Получается большая путаница — объекты, классы, структуры, множества, много чего еще — и что есть что?
В C++ есть хороший подход, когда есть термины ref class и value class — в первом случае речь идет о типе данных, объекты которого создаются в куче, во втором случае — на стеке.
Т.е. ключевые слова ref/value играют роль технического модификатора, но при этом благодаря слову class остается понятным, что идет речь о типах данных одной природы — т.е., это именно «сущностный» тип данных, а не, к примеру, делегат (delegate).
Осталось заменить class на более подходящий термин — datatype, entity и т.д.
В случае .NET ref и value могли бы быть не ключевыми словами, а атрибутами:
[RefEntity] entity MyEntity1 и [ValueEntity] entity MyEntity2 смотрелись бы гораздо понятнее, чем class MyEntity1 и struct MyEntity2.
На мой взгляд, путаница терминологии в ООП — одна из самых больших проблем в индустрии.michael_vostrikov
08.01.2017 12:51Класс (от лат. classis — группа) в классификации — группа предметов или явлений, обладающих общими признаками.
Как описать эту группу предметов? Очевидно — перечислить общие признаки. Где тут противоречие с классом в языках программирования?
maxstroy
08.01.2017 13:11Перечисление общих признаков- это по определению типа — тип. Класс по определению — множество объектов, который описывается только одним способом — перечислением объектов данного класса. Класс не обязательно содержит однотипные объекты. Это может быть класс объектов разных типов, описываемых разными атрибутами. Поэтому одна из вещей, которые попутало ООП, — это термин класс и термин тип.
lair
08.01.2017 13:34Класс по определению
Похоже, пришла пора снова напомнить, что у понятий в разных областях знания бывают разные определения.
michael_vostrikov
08.01.2017 14:02По определению откуда? Из тех, что я нашел в интернете, элементы, объединенные общим признаком, это одно из определений многозначного слова "класс". И нет никакой проблемы в том, чтобы в определенной области использовать этот термин в одном из его значений. У вас ведь не вызывает проблем использование его для описания качества (ресторан первого класса).
maxstroy
08.01.2017 16:05Если тип объектов (перечисление свойств) назвать классом объектов (множеством объектов), то вполне реально возникает проблема, потому что можно услышать: экземпляр этого процесса. Вас не пугает высказывание: экземпляр этого слона? А меня пугает, потому что это непонятное сочетание слов.
michael_vostrikov
08.01.2017 16:39Класс объектов означает множество только в изучаемой вами области. Высказывание "экземпляр типа слон" или "экземпляр класса слон" меня не пугает. А вас не пугает высказывание "ресторан первого множества"?)
maxstroy
08.01.2017 17:02Я спросил: не «Экземпляр ТИПА слон», я сказал «Экземпляр ЭТОГО слона» вас не пугает? Потому что именно так звучит этот тезис из уст программиста
lair
08.01.2017 17:07-1Потому что именно так звучит этот тезис из уст программиста
Я ни разу не слышал, чтобы программист так говорил. А если вы слышите не то, что люди говорят, то, возможно, дело и не в тех, кто говорит.
michael_vostrikov
08.01.2017 17:27Обычно никто не говорит "экземпляр этого слона" или "экземпляр этого пользователя". Говорят "экземпляр этого класса" или "экземпляр класса Пользователь".
Я могу представить, что на какой-нибудь схеме есть понятие "процесс", который периодически повторяется. Тогда "экземпляр этого процесса" имеет смысл и означает конкретный запуск. Но связано это с динамической и повторяющейся природой действия, а "процесс" со схемы в коде будет классом (типом). А выражение "периодически повторяющийся слон" действительно непонятное сочетание слов.
maxstroy
08.01.2017 17:33Действия никогда не повторяются. Каждое действие уникально, как и каждый слон. Они (действия) могут быть похожи друг на друга, как похожи слоны. И тогда мы можем сказать: эти действия принадлежат одному классу действий. Как и слоны принадлежат одному классу слонов. Тогда мы можем сказать про слона: элемент класса «слоны», или действия класса «действия». Но е можем сказать экземпляр этого действия. Но это еще не все. Экземпляр слона — слон, экземпляр класса «слоны» — класс «слоны» по правилам русского языка, но не слон! Иначе получается, что и экземпляр слона и экземпляр класса слон — это все одно и тоже — слон, но это же бред! Получается, что класс слонов — это экземпляр класса классов! Короче, полный бред. А все потому что слова элемент и экземпляр созвучны друг другу. Но их смысл совсем разный
michael_vostrikov
08.01.2017 18:12+1Действия никогда не повторяются. Каждое действие уникально, как и каждый слон.
Правильно, это и есть экземпляры.
Они (действия) могут быть похожи друг на друга, как похожи слоны. И тогда мы можем сказать: эти действия принадлежат одному классу действий.
Вот мы и подошли к выделению набора признаков, по которым определяем похожесть.
Но не можем сказать экземпляр этого действия.
Тут вопрос шире, чем вам кажется. Есть общее понятие "процесс" как некоторая последовательность действий. Есть более конкреные понятия с последовательностью конкретных действий, например, "процесс дефрагментации жесткого диска". И есть экземпляры запуска этих процессов. Так вот, "экземпляр этого процесса" будет синонимом "экземпляр этого типа процессов". Это просто особенность языка, второй вариант более правильный.
Экземпляр слона — слон
Нет. Экземпляр типа "Слон" — слон. Экземпляр типа "Класс слонов" — класс слонов. Экземпляр слона — так не говорят. А если и говорят, то подразумевают правильный вариант.
maxstroy
08.01.2017 19:04Правильно, это и есть экземпляры.
Нет, это разные действия, если экземпляры, то чего? действия? так это и есть действия.
Тут вопрос шире, чем вам кажется. Есть общее понятие «процесс» как некоторая последовательность действий.
Я не говорил про процессы, мы говорили про действие.
Экземпляр типа «Класс слонов» — класс слонов.
Да, но получается, что экземпляр класса «слон» — это класс, а программисты считают, что это — слон!michael_vostrikov
08.01.2017 20:16+2Нет, это разные действия, если экземпляры, то чего? действия? так это и есть действия.
Не экземпляры действия, экземпляры типа "Действие". Есть тип действия "Удалить файл", которое принимает на вход имя файла. И есть конкретный экземпляр "Удалить файл (1.txt)", который выполнился в 20:00.
Нет экземпляров числа 2, есть экземпляры типа "Целое число".
Экземпляр это представитель типа с конкреными значениями параметров. Никогда не встречали, как про щенка говорят "хороший экземпляр"?
Я не говорил про процессы, мы говорили про действие.
Мы говорили про процессы.
потому что можно услышать: экземпляр этого процесса
Но про действие будет то же самое.
Да, но получается, что экземпляр класса «слон» — это класс
Экземпляр класса "слон" — это конкретный слон, с конкретной длиной хобота и ушей.
maxstroy
09.01.2017 06:30Я дал вам все, чтобы вы сами сделали вывод о том, что в природе нет экземпляров этого процесса, но есть процессы. Как и то, что экземпляр класса слон в русском языке означает класс слона, а не слона. Но для большинства программистов это не понятно. О чем я и говорю постоянно. Потому что ООП немного покосило их сознание. И поэтому ООП так вредно. Для тех, кто решил этот ребус, становится ясно, что преподаватели ООП сами не знают, что говорят. И это становится сначала смешно, а потом не очень — поголовная болезнь программистов — это не смешно. Однако, есть надежда, что кто-то из них поймет простую детскую головоломку и тогда станет ему ясно, что ООП не про предметную область, а про код. И тогда больше не будет моделировать предметную область в терминах ООП, а перейдет к нормальному человеческому языку, в котором нет места экземплярам этого процесса, а термин экзампляр класса указывает на класс, а не на элемент этого класса.
michael_vostrikov
09.01.2017 08:59+1Еще раз. В программировании "класс" — синоним слова "тип", набор общих признаков. Это одно из значений этого слова. Если оно у вас вызывает трудности, мысленно заменяйте его во всех случаях на слово "тип".
Я дал вам все, чтобы вы сами сделали вывод о том, что в природе нет экземпляров этого процесса, но есть процессы.
Я вам во всех случаях показал, где именно вы не правы, и привел примеры. Есть разные виды процессов, которые являются абстракциями с определенным названием, и есть их конкретные воплощения в пространственно-временном промежутке. Как их называть, решайте сами, но обычно их называют "тип" и "экземпляр".
Как и то, что экземпляр класса слон в русском языке означает класс слона, а не слона.
Экземпляр — отдельный предмет (или животное, растение) из ряда подобных.
По вашей же терминологии "класс слонов" означает множество слонов.
"Экземпляр класса слон" это "экземпляр множества слон". Это какая -то непонятная для меня игра слов. Подозреваю, что имеется в виду "экземпляр типа 'Класс слонов'".
Экземпляр множества слонов означает конкретного слона (слон Джек).
Экземпляр множества "Тип слонов" означает конкретный тип слонов (индийский слон).
Экземпляр множества "Множество слонов" означает конкретное множество слонов (слоны Джон, Джек, Джейн).
Множество можно задать либо перечислением его элементов, либо заданием определяющего свойства.
Тип — это способ задания множества.
Экземпляр типа "Слон" — экземпляр множества слонов — конкретный слон (слон Джек).
Вы придумали какой-то свой русский язык, свои обозначения терминов, и сетуете, что вас никто не понимает. Не используйте термин "класс" в разговорах со специалистами из других областей, используйте термины "тип" и "множество". И лучше писать название множества или типа в кавычках с большой буквы в именительном падеже, а название экземпляра или элемента с маленькой. Так вас поймет больше людей.
maxstroy
09.01.2017 09:01Экземпляр — отдельный предмет (или животное, растение) из ряда подобных.
Абсолютно точно! Следите за руками внимательно:
Экземпляр типа слон (экземпляр слона) — слон
Экземпляр типа класс (экземпляр класса) — класс
просто ранее никому в голову не могло прийти сказать: экземпляр класса, говорят: элемент класса. И только программисты в рамках ООП говорят экземпляр классаlair
09.01.2017 09:44… потому что программисты говорят не "экземпляр типа класс", а "экземпляр класса Слон". И говорят они так потому, что класс — это частный случай типа. При этом, иногда, программисты говорят "экземпляр типа Класс", имея в виду именно конкретный класс, и происходит это в платформах с рефлексией.
А еще программист может сказать "экземпляр типа Тип", и это тоже будет понятно.
maxstroy
09.01.2017 09:52Экземпляр слона — слон, экземпляр класса — класс.
lair
09.01.2017 11:55Экземпляр слона — слон
"Экземпляр слона" — это коллоквиализм, который, в зависимости от области, разворачивается в разное формальное выражение. Скажем, в биологии это будет "представитель семейства слоновых" (класса млекопитающих, типа хордовых, кстати). В программировании это может быть "экземпляр типа Слон" (для языков, в которых есть понятие типа).
экземпляр класса
Это, аналогично, коллоквиализм — только на этот раз однозначно "развернуть" его нельзя. Чтобы получилось "экземпляр класса — класс", формальное выражение должно выглядеть (например) как "экземпляр типа Класс". Но если формальное выражение выглядит как "экземпляр класса X", то результатом будет "экземпляр класса X — X" (опять-таки, не во всех терминологических системах).
maxstroy
09.01.2017 12:31Получается, что экземпляр класса слон и экземпляр слона — это обозначение одного и того же — слона. Поэтому я не понимаю программистов, которые везде тащут термин экземпляр, если можно обойтись без него. Можно сказать процесс, вместо экземпляр процесса. можно сказать стул, вместо экземпляра стула, или экземпляра класса стул. Обычные люди именно так и говорят, я никогда не слышал от мастера участка слов: пойдем и выполним экземпляр работы! Он говорит просто — пойдем и выполним работу. И только программисты говорят на непонятном другим сленге.
lair
09.01.2017 12:37Получается, что экземпляр класса слон и экземпляр слона — это обозначение одного и того же — слона.
… только в том случае, если вы раскрываете коллоквиализм "экземпляр слона" до "экземпляр класса Слон". Это не всегда так.
Поэтому я не понимаю программистов, которые везде тащут термин экземпляр, если можно обойтись без него.
А программисты в общем этого и не делают. Я употребляю термин "экземпляр" только когда мне надо подчеркнуть какое-то конкретное различие (в частности, между "все объекты этого класса" и "конкретный объект этого класса").
И только программисты говорят на непонятном другим сленге.
Но снова нет. В каждой профессии есть непонятный другим сленг, это вообще нормально.
maxstroy
09.01.2017 12:43Именно поэтому я постоянно повторяю: Сленг программистов не подходит для моделирования предметных областей. Этот слег про код, про что угодно, но не про предметную область. При помощи ООП нельзя моделировать предметную область, а те, кто пытаются это делать, обманывают себя и заказчика.
lair
09.01.2017 12:47+1Сленг программистов не подходит для моделирования предметных областей
Никакой сленг не подходит для моделирования предметных областей, для этого подходят контролируемые языки (например, ubiquitous language), которые, в свою очередь, становятся новым сленгом в рамках проекта.
При помощи ООП нельзя моделировать предметную область
А вот это уже неправда. ООП != сленг, ООП — это методология. Любой код программы представляет собой ту или иную модель предметной области (если, конечно, разработчик ставил себе такую цель) — и если этот код был написан в рамках ОО-парадигмы, значит, мы имеем ОО-модель предметной области. Это не единственная возможная модель, но это — модель.
maxstroy
09.01.2017 12:51Модель, построенная в терминах ООП, отличается от модели, построенной в терминах предметной области, хотя бы потому что языки у них разные. В предметной области наследование означает связь родителя и ребенка, а не тип растения и тип кустарника. В предметной области нет экземпляров процесса и нет экземпляров класса слонов, но есть процессы и слоны
lair
09.01.2017 12:56Модель, построенная в терминах ООП, отличается от модели, построенной в терминах предметной области, хотя бы потому что языки у них разные.
Да, отличается. Она при этом не перестает быть моделью предметной области.
VolCh
10.01.2017 17:57В предметной области наследование означает связь родителя и ребенка
Зависит от предметной области. А вернее от принятого в команде сленга.
maxstroy
09.01.2017 09:56В книге, что я привел в статье, очень хорошо объясняется, в чем разница между типом объектов и классом объектов. То, что это одно и то же придумали только программисты ООП, для остальных людей — это разные вещи.
lair
09.01.2017 12:04В книге, что я привел в статье, очень хорошо объясняется, в чем разница между типом объектов и классом объектов.
… в рамках терминологии, принятой в этой книге.
То, что это одно и то же придумали только программисты ООП
Для "программистов ООП" тип и класс — не одно и то же (за исключением простого бытового дискурса). Я уже неоднократно говорил, что в мейнстримном классовом ООП класс — частный случай типа (т.е., все классы — типы, но не обязательно все типы — классы).
Этот принцип, кстати, совпадает с организацией биологической систематики, где класс — это таксон, входящий в тип, или с (русскоязычной) классификацией кораблей, где тип (проект) — это группа кораблей, входящая в более крупную группу подкласс, которая, в свою очередь входит в более крупную группу класс. Ну и так далее, можно продолжать приводить примеры из (в основном технических) областей знания, где термин "класс" употребляется в том же значении, что и в class-based ООП.
То, что в какой-то области терминология отличается от той, которая вам нравится, еще не повод считать, что эта терминология ошибочна.
maxstroy
09.01.2017 12:21Класс — это множество объектов, тип — это модель этих объектов, не может быть множество и модель объектов как-то связаны. класс объектов, которые попались мне по дороге на работу, не имеют общих свойств, кроме одного — они попались мне на глаза. Это класс, объекты которого имеют совершенно разную природу. Я классифицировал эти предметы по признаку: попались на глаза, а не по признаку наличия у них одинаковых атрибутов. Так понимают термин класс все, кроме программистов. Тип — это модель объектов, похожих друг на друга. Так понимают этот термин все, возможно и программисты, я не знаю.
lair
09.01.2017 12:32Класс — это множество объектов, тип — это модель этих объектов
… в рамках конкретной терминологической системы, принятой среди вас. Нет никаких оснований считать, что эта терминологическая система верна для всех (например, явно видно, что для биологов она не верна).
Тип — это модель объектов, похожих друг на друга. Так понимают этот термин все
… но нет.
maxstroy
09.01.2017 13:08Созданием языка для моделирования предметной области заняты не биологи, и не музыканты. Это раздел математики — матлогика. Именно там вырабатываются термины для мета-мета-моделей. Именно оттуда мы берем термины.
lair
09.01.2017 13:24Созданием языка для моделирования предметной области заняты не биологи, и не музыканты. Это раздел математики — матлогика.
Возможно, математикам было бы приятно так думать, но это совершенно не обязательно так.
(мне, конечно, всегда нравилась присущая некоторым технарям и некоторым представителям некоторых точных наук непоколебимая уверенность в превосходстве их области знания над другими)
Именно оттуда мы берем термины.
Вы — берете. Другие люди — нет.
maxstroy
09.01.2017 13:35Просто никто кроме математиков не озадачился вопросом описания предметной области так основательно, как это сделали они. Ни программисты, ни юристы, ни кто-либо еще. Поэтому в программах так много ошибок, поэтому в законах так много противоречий. Можно использовать любой сленг, но его границы не задокументированы, область применения неизвестна. Математический аппарат задокументирован, границы описаны, область применения известна. Надо только уметь пользоваться этим языком.
lair
09.01.2017 13:42Просто никто кроме математиков не озадачился вопросом описания предметной области так основательно, как это сделали они. Ни программисты, ни юристы, ни кто-либо еще.
Это громкое утверждение неплохо бы подтвердить авторитетными источниками. Причем прямо начиная с пункта "математики занимаются вопросами описания предметной области", который, прямо скажем, вызывает у меня некоторые сомнения.
Математический аппарат задокументирован, границы описаны, область применения известна.
… и я искренне считаю, что эти описанные границы лежат в области математики, а не произвольной предметной области.
Надо только уметь пользоваться этим языком.
Я с удовольствием верну этот аргумент вам, сказав, что существующими языками описания предметной области (скажем, по Эвансу или по Вигерсу) тоже "надо только уметь пользоваться".
А самое главное — даже если вам удастся доказать, что какой-то язык описания предметной области более мощен, чем другие, это все равно не докажет, что все остальные языки неправильны.
maxstroy
09.01.2017 13:48Я не говорю про неправильность, я говорю про анализ любого языка. Анализ производится математиками и описывается в терминах матлогики. Если такой анализ не проведен, то пользоваться таким языком можно только на свой страх и риск, что и делает множество программистов, плохо разбирающаяся в теории языков. Но время не стоит на месте и все меняется. Проблемы ООП описаны, они преодолеваются в новых языках
lair
09.01.2017 13:52Я не говорю про неправильность,
Говорите. Я могу вам привести кучу цитат из только этой дискуссии, где вы говорите, что "ООП вредно", "при помощи ООП нельзя моделировать предметную область" и так далее.
я говорю про анализ любого языка. Анализ производится математиками и описывается в терминах матлогики.
Филологи и лингвисты с вами не согласятся.
Проблемы ООП описаны, они преодолеваются в новых языках
… я даже не буду обсуждать этот утвеждение, поскольку вы неоднократно признавали, что в программировании не разбираетесь. Так что я просто сделаю вид, что вы этого не говорили.
maxstroy
09.01.2017 14:39таки я даже не пытаюсь говорить о программировании. Я не совсем понимаю, зачем вы тут? Мы из разных областей деятельности. Я не имею отношения к программированию, вы — к моделированию предметных областей. Поэтому я не понимаю, о чем разговор. Я лишь пытаюсь объяснить, почему термины ООП не подходят для моделирования предметных областей. Но они отлично подходят для программистов ООП. Опять же — плохо для программистов, работающих с другими языками. Но аналитик работает на языке, универсальном для всех языков программирования. Поэтому его язык другой и никак не пересекается с сленгом программистов.
lair
09.01.2017 14:46+1таки я даже не пытаюсь говорить о программировании
Оу, серьезно? "Проблемы ООП описаны, они преодолеваются в новых языках", "ООП вредно" — это не о программировании, значит?
Я не имею отношения к программированию, вы — к моделированию предметных областей
Вам, конечно, виднее, к чему я имею отношение… Но, как уже говорилось выше, программы часто содержат модель предметной области, так что даже будучи "просто программистом" я вполне себе занимаюсь моделированием предметной области.
А раз вы признали — очередной раз — что вы не имеете отношения к программированию, пожалуйста, перестаньте упоминать по поводу и без повода ООП. Оно не в вашей области знания.
Я лишь пытаюсь объяснить, почему термины ООП не подходят для моделирования предметных областей.
См. выше про "программа содержит модель". Вы, действительно, не имеете отношения к программированию, это хорошо заметно.
Поэтому его язык другой и никак не пересекается с сленгом программистов.
… именно поэтому пора бы (вам) уже наконец перестать говорить, что термин "класс" в ООП неверен. Просто это разные терминологические домены.
maxstroy
09.01.2017 14:56ООП я поминаю только в разрезе терминологической каши. которую заварили программисты. Мне больно слышать, как они общаются с предметниками. Если бы это было герметичное сообщество людей, не выходящих наружу, все было бы ок, но мне надо объяснить предметникам, что программисты под термином класс понимают не множество объектов, а тип объектов, а для моделирования множеств у них нет встроенных в язык конструкций, поэтому говорить с ними о множествах — нельзя. Они обязательно скажут что-то типа коллекция, список и проч… Но это все будет не описание множества и понять это программисты не смогут никогда. Все это было очень смешно, если бы не было грустно. Если бы программисты могли формализовать свой язык и отмаппить его на язык матлогики, я бы не возражал.
lair
09.01.2017 15:03Мне больно слышать, как они [программисты] общаются с предметниками
Ну так не слушайте.
Но вообще, создается ощущение, что вы просто имели дело с плохо поставленным процессом сбора требований/разработки/общения с заказчиком. В хорошо поставленном процессе таких казусов не случается.
мне надо объяснить предметникам, что программисты под термином класс
А зачем вы объясняете предметникам термин "класс"? В предметной области его либо нет вообще, либо оно имеет значение, отличное от вашего.
Милая картина: вы считаете, что навязывание вашего языка моделирования предметнику — это нормально, а навязывание программистского — ненормально.
Но это все будет не описание множества и понять это программисты не смогут никогда
Ну да, конечно, программисты такие умственно неполноценные, что не могут понять простую терминологическую разницу… серьезно?
Если бы программисты могли формализовать свой язык и отмаппить его на язык матлогики, я бы не возражал.
А программисты, я думаю, не возражали бы, если бы вы перестали наконец требовать от них язык матлогики, ибо нафига?
maxstroy
09.01.2017 15:14Давайте еще раз попробуем определить наши цели. Я много лет общаюсь с программистами и с адептами процессного подхода. Это две категории людей, которые плохо слышат, что вокруг них происходит. Мне понадобилось более десяти лет, чтобы разобраться в каше, которую они заварили и в каше, которую они выливают на головы новым студентам, коим был я, когда меня пыьтались учить в тех же терминах. Наконец, я разобрался. И теперь всем, кому интересно, я предлагаю пройти тот же путь и понять, что же имели ввиду те парни, которым было лень создать формальную теорию.Тем, у кого все хорошо, и кто не видит проблем, я не нужен. Например, вам. У вас все хорошо! Но это не значит, что другим хорошо. Вот для тех, кому плохо, я и пытаюсь донести, что же говорят те или что говорят другие, когда произносят сакральные фразы, смысл которых они, к сожалению, сами не понимают(.
lair
09.01.2017 15:18Я много лет общаюсь с программистами и с адептами процессного подхода. Это две категории людей, которые плохо слышат, что вокруг них происходит.
Ничего не знаю про "адептов процессного подхода", но в случае программистов вы радикально не правы в этом утверждении. Просто посмотрите на скорость появления новых технологий, о которых принято быть "в курсе".
Мне понадобилось более десяти лет, чтобы разобраться в каше, которую они [программисты] заварили и в каше, которую они выливают на головы новым студентам, коим был я, когда меня пыьтались учить в тех же терминах.
А зачем вы учитесь у программистов не программированию, а чему-то другому?
И теперь всем, кому интересно, я предлагаю пройти тот же путь и понять, что же имели ввиду те парни, которым было лень создать формальную теорию.
Ну да, попутно опуская "тех парней" и утверждая, что их методики не позволяют делать то, чем они, собственно и занимаются.
Вот для тех, кому плохо, я и пытаюсь донести, что же говорят те или что говорят другие, когда произносят сакральные фразы, смысл которых они, к сожалению, сами не понимают
Вам, конечно, виднее, что говорят и что понимают другие люди.
maxstroy
09.01.2017 16:03Просто посмотрите на скорость появления новых технологий, о которых принято быть «в курсе».
Лично меня и моих друзей программистов пугает скорость нарастания ошибок в этих технологиях. Вместо количества новых технологий лучше бы занялись их качеством.
А зачем вы учитесь у программистов не программированию, а чему-то другому?
Потому что программисты говорили, что с помощью ООП можно моделировать предметные области. Я поверил, но это было ошибкой.
Ну да, попутно опуская «тех парней» и утверждая, что их методики не позволяют делать то, чем они, собственно и занимаются.
Я никого не опускаю, со мной ведут работу много программистов, и не только программистов. Все мы уважаем друг друга. А вот зазнаек никто не любит — это точно. Мои преподаватели были немного зазнайками — они верили в то, что они что-то знают, но я пока не видел никого, кто знал бы достаточно, чтобы авторитетно сказать — я знаю предмет. Хотя есть, но они, как правило, скромно работают.
Вам, конечно, виднее, что говорят и что понимают другие люди.
Преподаватель, который не может ответить на вопрос студента — плохой преподаватель. И ничему хорошему он не научит. К сожалению, у нас не учат программистов, у нас учат ремесленников. Поэтоум и говорят они на своем птичьем языке(
lair
09.01.2017 16:11Вместо количества новых технологий лучше бы занялись их качеством.
Ну так этим и занимаются тоже.
Потому что программисты говорили, что с помощью ООП можно моделировать предметные области. Я поверил, но это было ошибкой.
Как неоднократно показано выше, с помощью ООП можно моделировать предметные области. Просто для этого — как минимум, в ряде случаев — нужно быть программистом. Поскольку вы не программист, вам такое моделирование недоступно. Не надо из этого делать вывод, что оно недоступно остальным.
Я никого не опускаю
Перечитайте свои тексты. Это просветляет.
Мои преподаватели были немного зазнайками — они верили в то, что они что-то знают, но я пока не видел никого, кто знал бы достаточно, чтобы авторитетно сказать — я знаю предмет.
Если вам не повезло с преподавателями — это еще не проблема индустрии.
Поэтоум и говорят они на своем птичьем языке
Нет, на своем птичьем языке они говорят потому, что профессиональный жаргон удобнее общего.
VolCh
10.01.2017 18:09+1Потому что программисты говорили, что с помощью ООП можно моделировать предметные области. Я поверил, но это было ошибкой.
Нельзя? Все ООП-программы мира делают, что угодно кроме моделирования своей предметной области? Даже если эта предметная область — само ООП? :)
А программисты, кстати, в модели образования и классификаторов профессий, пускай не ремесленники, но техники, выпускники техникумов.
michael_vostrikov
09.01.2017 16:16не может быть множество и модель объектов как-то связаны
Может. Я вам выше приводил ссылку, что способов задания множества больше одного. Модель объектов задает множество возможных объектов. Тип "Целое число" задает множество возможных целых чисел.
maxstroy
09.01.2017 16:29Да, это частный случай, но множество объектов, которые я сегодня увидел, не имеют общих атрибутов. У каждого этого объекта — свои модели, но они связаны в множество. Поэтому я утверждаю, что нет связи между множеством и типом объектов
michael_vostrikov
09.01.2017 17:06Если это частный случай, то связь есть. Вы задаете свое множество другим способом — перечислением. Общий признак у них есть, но это не свойство самих объектов, а свойство их связи с событием "Увидел". И вы не сможете задать таким образом множество объектов, которые увидите завтра, потому что еще не знаете, что именно увидите. А с использованием типа можно создавать новые, еще не знакомые объекты, и даже заранее создавать для них определенную обработку в информационной системе. Мы не знаем, как будут звать клиентов, которые придут завтра, но сможем зарегистрировать их имена.
michael_vostrikov
09.01.2017 16:06Вы снова играете словами. Если вам лень писать кавычки, пишите названия типов на английском. Это поможет избежать игры слов из-за падежей.
Экземпляр типа "Тип слонов" — это например "индийский слон", "африканский слон". Элементы множества, кстати. Здесь нет никакого противоречия вашим словам, за исключением неоднозначных выражений в скобках.
Я вам советую изучить программирование и разобраться, в чем отличие переменной и ее типа. Заодно и сможете объяснить программистам, в чем они не правы, на их языке. А заодно и подумаете, как уложить понятия "тип переменной" и "переменная" в вашу всеобъемлющую теорию.
maxstroy
09.01.2017 16:40Разбор переменной — это как раз то, что мы делаем, когда начинаем разбирать код. Как и метод. Моделируя тип объектов (как говорят программисты, создавая класс), мы можем моделировать тип переменной. В простейшем случае в каждом объекте данного типа создаются переменные, которых столько, сколько объектов данного типа создал движок. Я специально говорю тип объектов, потому что по определению мы моделируем тип данных.
lair
09.01.2017 16:49Моделируя тип объектов (как говорят программисты, создавая класс), мы можем моделировать тип переменной. В простейшем случае в каждом объекте данного типа создаются переменные, которых столько, сколько объектов данного типа создал движок.
… все-таки, вам лучше не рассуждать о программировании.
maxstroy
09.01.2017 17:00Я, собственно и не претендую на понимание программистами. Я работаю с предметниками. А они, как раз, очень хорошо это понимают
lair
09.01.2017 17:03Вот только ваш коммент выше — это была попытка рассказать программистам, что такое переменная и ее тип. Неудачная.
Ну и да, если вы не претендуете на то, что ваша система моделирования будет понятна программистам, то каково ее предназначение?
maxstroy
09.01.2017 08:21Возможно, статья про сценарии вам немного поможет. Я специально не употребляю термин процесс, потому что насчитал около 40-ка разных смыслов этого термина. При этом обсуждать что-либо с употреблением этого термина почти невозможно, потому что в одном предложении часто употребляется этот термин в разных смыслах одновременно. При этом сценарию соответствует в языке программистов экземпляр процесса, а типовому сценарию — процесс.
VolCh
08.01.2017 13:41На мой взгляд, путаница терминологии в ООП — одна из самых больших проблем в индустрии.
А вы знакомы с концепциями, принятыми в Smalltalk — родоначальнике ООП, где всё, включая классы, является объектом?maxstroy
08.01.2017 16:08Язык программирования — это герметичная штука, она не про модель реальности. При моделировании реальности мы пользуемся двумя подходами: Аристотелевским и теорией множеств. Более пока не придумано. В теории множеств есть классы, у Аристотеля — типы. Если язык моделирует класс при помощи объекта языка, я не против, но от этого множество не становится объектом. Разделяйте объект, который моделируется, от объектов, при помощи которых происходит моделирование
maxstroy
08.01.2017 11:13Цитата из моей статьи про концептуальные модели:
Допустим, что наша модель состоит из некоторого числа объектов, такого же числа типов – по одному на каждый объект. Если количество типов в модели равно количеству объектов, — это просто множество концептов без всяких закономерностей. Я предлагаю простое правило: чем больше отношение количества моделируемых объектов к количеству типов, тем более «концептуальна» модель.
Концептуальная модель — это модель классов и/или типов объектов учета. Под объектами учета мы понимаем все перечисленные ранее виды объектов учета, в том числе и связи. Отношение количества моделируемых объектов к количеству типов (или классов) демонстрирует нам степень «концептуальности» модели. Чем больше это отношение, тем «концептуальнее» модель.
Например, количество мужчин определяет «концептуальность» класса мужчин. Это очень большое число, поэтому понятие мужчина – это очень «концептуальное» понятие. В то же время, количество гравицап – ограничено, — их всего одна штука. Поэтому «концептуальность» понятия «гравицапы» — ничтожна. Это всего одна гравицапа на один тип объектов. В таком случае нет необходимости в моделировании типа, достаточно моделирования объекта.
Для тех, кто читал определение концептуального моделирования в русскоязычных источниках, рекомендую почитать литературу на английском языке, или воспользоваться моим определением. Дело в том, что определения на русском языке, — неверны. Например, в русскоязычной Википедии концептуальной называют модель, которая якобы содержит «понятия и отношения между понятиями». Понятие – это то, что существует в воображении человека, то есть, модель. Если автора такого определения интересуют отношения между моделями в сознании у субъекта, то для этого он должен создать модель для понятий, то есть, модель модели. Но на самом деле автора интересуют не отношения между понятиями, а отношения между объектами, которые обозначают эти понятия! Так что, если вы встретите подобное определение, то имейте в виду, — оно ложное.
lair
Серьезно?
Любимое всеми разработчиками abstract syntax tree: модель синтаксической структуры кода, не имеющая ни пространственных, ни временных измерений.
Банковский счет (точнее, приход-уход): модель денежных сумм, не имеющая пространственных измерений.
Модели нотного текста (не путать с версткой) тоже не имеют пространственных измерений, да и время там, прямо скажем, весьма условное.
Модель зрительских предпочтений (и вообще рекомендательные системы): никаких пространственных измерений. Зато там может быть n-мерное пространство, моделирующее признаки.
Продолжать, или и так уже понятно?
Опять? Вы придумали какое-то свое определение операции, требующее от актора разумности, а теперь на его основании говорите, что нельзя говорить, что неразумное не может совершать операции? Но почему вы думаете, что ваше определение операции верно?
Ares_ekb
На 51-ой странице как-раз немного говориться про счета:
На сколько я понимаю, банковский счет не является «бизнес-объектом» или объектом реального мира. Это просто набор записей в информационной системе о событиях происходящих в реальности. Иными словами, при использовании такого подхода мы моделируем владельца счета, события, связанные с изменением счета. А сам счет в реальности не существует и в «бизнес-модели» мы его вообще не моделируем.
Аналогично, AST и т.п. — это сугубо информационные сущности, которые с помощью данного подхода не моделируются. В книге очень часто встречается слово «physical». На сколько я понимаю, авторы материалисты :) У них на первом месте физический мир, а на втором — его отображение в информационных системах.
maxstroy
Я не могу сказать, что книга понятная. Ее можно прочитать, чтобы потом сделать свои выводы самостоятельно. Мне на это понадобился не один год. Однако, счет — это довольно простая вещь — это запись в договоре на обслуживание, не более того. То есть, это информационный объект, ярлык, который вешается на каждую транзакцию, моделируя контрагента, к которому относится транзакция. То есть, это модель предприятия с точки зрения банка.
VolCh
Контрагент и счет в транзакции — это разные ярлыки обычно. Как минимум у одного контрагента может быть несколько счетов, а операции по счёту могут осуществлять разные контрагенты.
maxstroy
Да, конечно. Тогда можно сказать, что счет — это номер в договоре на обслуживание, что к этому номеру привязаны транзакции. Но сам по себе счет, как и сама по себе фамилия человека — лишь записи в документах
VolCh
В общем случае счёт — абстрактная сущность с каким-то суррогатным идентификатором, агрегирующая транзакции с ней связанные, и, как правило, связанная с конкретным контрагентом-владельцем счёта.
maxstroy
абстрактная — существующая в воображении? Это определение абстрактного. Связать что-то с тем, что существует в воображении можно только то, что существует там же. То есть нельзя связать абстрактное с транзакцией.
VolCh
Транзакция — тоже абстракция, если что :)
michael_vostrikov
Можно сделать модель реального объекта в воображении, и уже эту модель связывать с другими абстракциями. А потом сделать отображение всех абстракций и их связей в объекты реального мира. Что, собственно, и делается в программировании.
lair
Мне не интересны "объекты реального мира", мне интересен бизнес, с которым пришел клиент. И в его терминологии, в его бизнесе — банковский счет является бизнес-объектом.
Ну так, события, связанные с изменением — это и есть "приход-уход", о котором я говорю, и это все равно объекты, не имеющие пространственных измерений, только временное. А владелец счета может вообще не иметь значащих для модели характеристик физического объекта. Собственно, если владелец счета — предприятие, то оно тоже не является физическим объектом.
Это, опять-таки, ошибка — счет есть (потому что приход-уход происходит по счету), и в модели он, как следствие, тоже есть.
Это значит, что подход из BORO — как вы его описываете, я не уверен, что это полностью верно — не применим для описания чисто информационных сущностей, но подход из BORO, опять-таки, не единственный. Поэтому утверждение "все модели, которые мы строим, должны так или иначе моделировать 4-х мерное пространство-время" — неверно.
Ares_ekb
Да, так и есть. Клиенты часто мыслят информационными сущностями. Например, документами: платежка, чек, кассовый ордер, паспорт, свидетельство о регистрации и т.п. Если вы начнёте им что-то рассказывать о том, что документы — это всего-навсего набор сведений о неких объектах реального мира, то вас не поймут. Например, в реальности есть человек. Сведения о нём могут указываться в свидетельстве о рождении, паспорте, военном билете, страховом свидетельстве, водительских правах и т.д.
Для «клиента» существуют только эти документы. Если нет документа, то для них нет и человека. Авторы же BORO говорят, что это неправильный подход. В первую очередь должны моделироваться реальные объекты. При этом человека они представляют в виде такого 4-мерного червяка, растянутого во времени от рождения до смерти. А затем уже можно моделировать документы, структуру записей в БД и т.п. В этом и заключается «Re-Engineering»: забудьте о документах и прочих частностях, думайте о реальных объектах. А «Re-Use» заключается в том, что такие модели меньше подвержены изменениям, их проще повторно использовать при разработке разных информационных систем.
Насчет событий. С точки зрения BORO, как-раз наоборот, у них нулевая временная протяженность и не нулевая пространственная (см. раздел 8.3.1.1). Например, событие «я отправил комментарий» произошло, скажем, в 19:19 моментально. Ну, на самом деле, конечно не моментально — сначала я подумал, что надо отправить комментарий, навел курсор на кнопку, нажал на кнопку, браузер обрабатывал какое-то время нажатие и т.д. Если нам важна такая детализация, то мы можем разбить событие «отправка комментария» на несколько более мелких событий. Но с точки зрения BORO все эти события моментальные, а значит и составное событие тоже моментальное. Пространственная протяженность этого события включает меня, компьютер, т.е. все объекты, вовлеченные в это событие. Возможно это звучит как бред :) Но там так написано, можете сами убедиться.
На сколько я понимаю BORO, они претендуют на создание совершенно новой парадигмы моделирования. Типа со времен Аристотеля человечество сформировало какую-то не очень правильную парадигму моделирования, из-за которой модели получаются «плохие» (в книге это детально описано, долго приводить примеры). А они предлагают лучшую парадигму. Т.е. они замахиваются не на какие-нибудь RUP, ARIS и иже с ними, а на парадигму моделирования, которая формировалась тысячелетия. В этом отношении они наверное единственные.
lair
Почему же, прекрасно поймут. Но заодно они очень удивятся, почему вы не понимаете, что их интересуют не объекты реального мира, а сведения о них.
Проблема, однако же, в том, что у меня уже давно "вторая" очередь, в которой я моделирую информационные объекты. Например, литературные произведения. У них нет никаких физических характеристик (именно у литературных произведений, не книг, в которых они выпущены).
Да мне, по большому счету, все равно, что там написано — меня не устраивает утверждение в посте о том, что все модели обязаны быть привязаны к четырехмерному пространству.
Ares_ekb
Мне самому интересно узнать как согласно BORO моделировать тот же Хабр. Он, очевидно, существует в реальности. На BORO основан ISO 15926, вот классы верхнего уровня. Там есть класс Thing, включающий в себя всё, что угодно. Есть класс AbstractObject, экземпляры которого как-раз не существуют в пространстве-времени. И, видимо, Хабр, литературные объекты и т.п. — это AbstractObject. Но в книге BORO я не помню, чтобы где-то шла речь о таких объектах.
Я бы не стал рассматривать BORO как какой-нибудь очередной UML, BPMN, ARIS, модель Захмана или что-то подобное. Они говорят об изменении парадигмы, о том, что нужно иначе мыслить, и эта идея вполне понятна. Но когда копаешь глубже, то возникает много вопросов. К слову, зря вы так плохо думаете о «клиентах». Они в последнее время всё чаще говорят об уходе от моделирования сведений об объектах к моделированию самих объектов, к чему и призывает BORO. Правда, в основном в крупных интеграционных проектах. Та же единая информационная среда госданных.
lair
Я как раз хорошо думаю о клиентах — они представляют себе, что именно им нужно, а не идут к обобщенному моделированию всего без особой необходимости.
Ares_ekb
Я и не спорю. Проекты бывают разные от написания shell-скрипта, где вообще не нужно никакое моделирование, до каких-нибудь крупных интеграционных проектов, где 99% времени уходит на моделирование. Причём, бывают проекты, где до создания модели нужно ещё запилить язык моделирования и методику моделирования, потому что существующие не подходят. Тогда приходится вникать в BORO и т.п. Таких проектов относительно мало, но они есть.
lair
Вот поэтому я и говорю, что утверждения класса "все модели обязаны блаблабла" — как минимум непрактичны, а как максимум — бессмысленны.
Danov
Вы чрезмерно категоричны, как лесник, которому «пилить нужно, а ему мешают консультанты, видите ли пилу хотят заточить». В посте речь не о текущем, а о философском, для тех кто в этом видит смысл, а не для тех, кто это отрицает.
Вы глянули бы в CAD/CAM/CAE/PLM/BIM/… системы, как там мэпятся объекты между несколькими слоями, сразу бы на философию потянуло. Даже сегодня многим вручную приходится редактировать объекты сразу в нескольких слоях (view, view-model, model, DB).
Поднятая тема как кубик-Рубика, головоломка, для одних удовольствие, а для других пустая трата времени.
PS: Автор интригует. Всё обещает, обещает самое интересное. А пока метафорично про плотные болты и рыхлые операции…
Посмотрим что дальше будет :)
lair
Мне почему-то кажется, что чрезмерно категорично как раз утверждение "Все модели, которые мы строим, должны так или иначе моделировать 4-х мерное пространство-время". А вот утверждение "некоторые модели не обязаны моделировать пространство-время" — не категорично.
Danov
Слово «модель» очень многозначное. Вот я дочке объяснял лет в пять про зиму и осень. Взял яблоко (модель Земли) и лампу (модель Солнца) и вращая яблоко по орбите вокруг лампы (урезанная модель солнечной системы) показывал, где зима/лето, где день/ночь. Модель? Модель. А какие картинки гугл выдаст на слово модель? :)
Собственно, отсюда и разные интерпретации утверждений автора. У вас своё представление модели, а автора своё. Посмотрим, что дальше будет.
lair
… что является лишним аргументом против всеохватывающих утверждений.