Прошлые статьи вызвали оживленную дискуссию среди тех, кто использует для моделирования предметных областей инструменты ООП: языки ООП, нотацию UML. Несмотря на то, что я постоянно подчеркиваю, что объекты учета, о которых я веду речь, не моделируются средствами UML, и объясняю почему, тем не менее, вопрос об их моделировании методами ООП поднимается снова и снова. Наверно, мне надо еще раз рассказать, чем так плох ООП для моделирования предметных областей.
- ООП перепутало классы и типы. То, что называется типами у Аристотеля, в ООП назвали классами, а то, что математики называют классами, в ООП не имеет названия.
- В ООП есть термин наследование. Это инструмент моделирования иерархии тип-подтип. Это значит, что ООП построено на логике Аристотеля. Ограничения этой логики в применении к моделированию предметных областей известны и описаны в книге Business Objects: Re-Engineering for Re-Use, которую я упомянул в прошлой статье. В качестве примера такого ограничения можно представить себе моделирование высоты у объектов класса слон и объектов класса вагон. Эти два атрибута в ООП никак не связаны между собой, поэтому понять, что слон поместится в вагон можно только, обратившись к программисту, создавшему эти атрибуты. Можно было бы ввести специализированные атрибуты, например, высота помещения как специализированный атрибут высота объектов, но и этого также сделать невозможно.
- В ООП методы принадлежат объектам класса. Возникает вопрос — кто везет машину: колеса или двигатель? Корректным был бы другой вопрос: кто или что является участником операции? Метод необходимо отделить от класса, а трактовку степени участия нужно оставить читателю модели. Но даже, если в ИС смоделировать трактовку такого участия, она никак не повлияет на анализ данных, поскольку на практике нас совершенно не интересует кто и что делал, но интересует, кто, когда и где был занят и что произошло с ним, а это как раз и есть ответ на первый вопрос.
Помимо проблем, связанных с ООП, существует еще одна проблема, связанная с модным ныне процессным подходом. В процессном подходе процесс называют экземпляром процесса, а тип процессов, функцию и функциональную структуру – процессом. Если ООП перепутало класс объектов с типом объектов, то процессный подход в одном флаконе смешал тип объектов и объекты, назвав одним словом разные по своей природе объекты. Я не знаю, как программисты выживают в этой терминологической каше, но, судя по тому, что я читаю, они стараются игнорировать эту проблему.
Решение по крайней мере части этих проблем предоставляют методики онтологического моделирования, в частности – технологии семантической сети, semantic web. Несмотря на неудачное название и сложную судьбу, они предоставляют куда лучший инструментарий для воплощения в электронной форме моделей частей реального мира, чем ООП или распространенные нотации моделирования бизнес-процессов. Познакомиться с особенностями этих технологий можно здесь.
Особое внимание стоит обратить на то, что с помощью этих технологий можно достаточно просто моделировать различные точки зрения на разные объекты, отражая и то общее, в чем согласны несколько субъектов, и частные взгляды каждого из них. Можно даже выражать в модели факты, противоречащие друг другу (с точки зрения разных людей), и получать логические выводы с учетом этих противоречий. С примером использования инструментария онтологий для работы с такими знаниями можно познакомиться здесь.
Рассмотрим моделирование объекта. Принято считать, что объект в пространстве имеет ясно выраженные границы. Однако, нам надо привыкнуть к тому, что не все объекты учета имеют такие границы. Например, операция. Представьте себе шарик с газом. Его пространственные границы ясны и понятны – это стенки шарика. Допустим, что шарик лопнул и газ, заключенный в нем, стал расширяться. После этого мы не можем точно описать поверхность, которая ограничивает объем области, в котором находится распространяющийся газ, но можем описать границы, за которые этот газ точно не вышел (пока не вышел). Точно также мы не можем описать точные границы операции, но очень легко можем описать те границы, за которые операция не выходит. Например, операция по точению болта на выходит за пределы цеха. Таким образом, мы можем сказать, что операция происходит (находится) в цехе. Кроме того, принято считать объект плотным объектом, который не может одновременно пересекаться с другими объектами. Однако, про операцию так сказать не получится. Две операции могут происходить в одном цехе одновременно. Если продолжить сравнение с шариком, то после того, как шарик лопнул, распространяющийся газ стал занимать объем, пересекающийся с другими газами. Про операцию можно сказать, во сколько она началась и во сколько она закончилась. Это – описание границ объекта во времени. Точно также можно обозначить временные границы не только операции, но и любого объекта. Например, болт существует с 1-го сентября 2016 года по 23 ноября 2017 года, когда он был переплавлен.
Для описания границ болта мы используем термины: в пространстве: где находится? Во времени: когда существует? Для описания границ операции мы используем термины: в пространстве: где произошло? Во времени: когда произошло? Нам непривычно было бы спросить про болт: произошел когда? А про операцию: существует где? Проблема в языке. Один и тот же вопрос для разных типов объектов учета формулируется по-разному. Это еще одна причина, по которой нам сложно представить себе операцию как 4-х мерный объект.
Поэтому для моделирования 4-х мерного объекта надо отделить описание его границ в 4-мерном пространстве-времени от трактовки этого описания. В дальнейших рассуждениях я расскажу, какие приемы мы используем для моделирования 4-х мерных объектов и с какими трактовками связаны эти способы описания.
Для описания объекта строятся границы, которые ограничивают моделируемый объект. Если не загоняться на тему математических извратов, то границей 4-х мерного объекта будет 3-х мерный объект. Знать эту 3-х мерного границу хочется максимально точно. Например, если сказать, что молоток (4-х мерный объект) находится на складе с 1-го декабря 2016 года по 1-го марта 2017, — это будет плохая модель молотка. Хочется знать про молоток немного больше. Например, можно задать точные координаты куба, в котором он находится. Точные границы куба могли бы выглядеть так: по оси X: с 10 до 20 см, по оси Y: с 30 до 35 см, по оси Z: с 120 по 135 см, по оси времени с 1-го декабря 2016 года по 1-го марта 2017 года. Теперь возьмем 4-х мерный объект, трактуемый как операция. Описание этого 4-х мерного объекта выглядит также, как и описание 4-х мерного объекта, трактуемого как молоток. Для этого 3-граница описывается при помощи места, где происходит происшествие, времени начала и времени завершения операции. Пока ничто не отличает описание операции от описания молотка. Что реально отличает операцию от молотка – так это наше представление о нем. Молоток в нашем представлении – плотный объект, не меняющий свою форму во времени. Операция же наоборот – рыхлая по составу и не имеющая постоянной выраженной формы. Но это знание не содержится в модели, а содержится в тех договоренностях, которые сопровождают эти модели. Чтобы подчеркнуть разницу между молотком и операцией используется языковые паттерны: операция происходит, молоток существует. Эти паттерны подчеркивают неизменность молотка и переменчивость операции.
Предположим, что мы изучаем молоток и движемся по его ручке. При таком движении фактура поверхности не меняется. Чтобы представить себе аналог такого движения по оси времени, надо понять, что поверхность 4-х мерного объекта при движении по оси времени описывается состояниями. Это значит, что, для проведения аналогии, необходимо, чтобы движение по оси времени не меняло состояние объекта учета. Например, молоток лежит на столе и им никто не пользуется. Состояние молотка не меняется.
Теперь представим, что ручка молотка покрашена краской и эта краска градиентная от красного до синего. Двигаясь по ручке, мы наблюдаем небольшие изменения в цвете. Аналогом такого движения по времени будет наблюдение смены состояний объекта, каждое из которых (состояний) ничтожно мало отличается от соседнего по времени состояния. Примером такой смены состояний может быть движение материального молотка в пространстве. Состояние тела меняется непрерывно и плавно. При этом изменения, накопленные за конечное время, могут быть достаточно сильными для их диагностики и наблюдения. Такое изменение за конечное время называется операцией.
Теперь представим, что, двигаясь вдоль по ручке молотка, мы наткнулись на боек. Это – скачкообразное изменение фактуры поверхности. Аналогом такого скачка при движении вдоль оси времени будет резкая смена состояния объекта учета, или событие. Если рассматривать движение молотка в пространстве, то это был бы неожиданный скачек его положения в пространстве. Для материального тела представить это сложно, потому что оно имеет инерцию, препятствующую такому скачку. Однако, если рассматривать классическую бизнес-операцию, то это событие могло быть поглощением ресурсов в операции, интеграцией двух функциональных объектов в один: токарь встал на рабочее место, выпуском продукции. Так или иначе, событие — это изменение состояния объекта учета за столь короткое время, что наблюдатель считает это время равным нулю. Понятно, что другой наблюдатель может более внимательно подойти к изучению состояний и найти, что изменения произошли не мгновенно, а постепенно. Поэтому событие – это субъективное восприятие изменения состояния объекта. Очень часто можно услышать, что объекты являются частью объективной реальности, модель которой мы строим. Однако, как мы недавно видели, сами объекты – это тоже субъективное представление некоторого 4-объема в 4-пространстве. Поэтому, что объекты, что события, что операции – это модели реальности, — результат субъективного восприятия.
Коль скоро мы определили объект как модель 4-объема в 4-пространстве, мы можем определить, что такое тип объектов. Допустим, что есть множество моделей 4-объемов, или множество объектов. Эти модели хранятся у субъекта в сознании. Если эти модели похожи друг на друга, то субъект может создать модель этих моделей. Эта модель также хранится в сознании субъекта. Эта модель моделей и есть тип объектов. Модель моделей – это второй уровень абстракции. Первым уровнем абстракции были модели 4-пространств, которые мы называем объектами.
Для моделирования 4-х мерного объектов через моделирование их поверхности требуется большой объем данных. Есть способы сократить этот объем, сделав определенные допущения.
Например, для описания операции можно сделать допущение, что в операции все события по поглощению ресурсов и интеграции функциональных объектов происходят в момент начала операции, а выпуск готового продукта – по окончанию операции. Понятно, что в общем это неверно, однако, такой способ описания позволяет все события свести либо к началу операции, либо к ее завершению.
Допустим, что требуется смоделировать болт, резьба которого имеет много витков. Для его моделирования достаточно указать шаг и длину резьбы. Это значит, что, если поверхность можно разделить на элементы, каждый из которых похож друг на друга, то для моделей всех этих элементов можно сделать одну модель (тип витка). Если затем указать количество этих элементов и способ их стыковки, то количество информации, необходимой для моделирования такой поверхности можно сильно сократить. Такое описание позволяет сократить объем модели посредством классификации элементов поверхности.
Если требуется смоделировать операцию, в которой события по выпуску веников, как витки резьбы у болта, следуют регулярно (но теперь уже не в пространстве, а во времени), то можно создать одну модель для всех этих событий (тип событий) и указать время, в течении которого выпускались веники. Это позволяет сократить объем модели операции посредством классификации событий.
Теперь допустим, что моделируется резьба, длина которой в рамках рассматриваемой модели заведомо неизвестна, но больше, чем моделируемая область. Этакая длинная бесконечная резьба. Для ее моделирования мы можем также создать модель моделей витков (тип витков), но указать их количество мы не можем, потому что их количество в рамках нашей модели бесконечно. Единственное, что мы можем сказать – это шаг резьбы, или количество витков на единицу длины. Таким образом, описанием такой бесконечной резьбы будет тип витков.
Аналогом описания бесконечной резьбы, при котором повторяются не геометрические объекты в пространстве, а события во времени, является описание, в котором через определенные промежутки времени случаются похожие события, например, выпускается очередной веник. Поскольку мы не знаем количество таких событий, можно сказать лишь об их частоте: например, один веник в час. Такое описание объекта соответствует описанию бизнес-функции, и говорят, что это функция по выпуску веников. То есть, описанием функции будет тип событий.
Мы подошли к моему определению понятия бизнес-функция. Бизнес-функция – это 4-х мерный объект, который имеет описание в виде набора типов событий с указанием плотности этих событий во времени (в вырожденном случае может содержать всего один тип, например, тип событий по выпуску веников). Замечу, что это определение сильно отличается о общепринятого, в котором функция определена как преобразование входных потоков в выходные. Но здесь нет никакого противоречия. Просто обычное определение функции является частным случаем моего. Все дело в том, что каждому множеству однотипных событий (классу событий), которые моделируют функцию, можно приписать поток материальных объектов учета. И тогда каждому типу событий можно будет приписать поток объектов и направление этого потока. Однако, такое понимание функции страдает тем же, что и описание операции при помощи акторов, совершающих действие. Это – невозможность посмотреть на модель с другой точки зрения. Если в моем определении каждому типу событий аналитик может приписать свои только ему необходимые объекты учета, то в классической модели сделать это не удастся. А это, в свою очередь, не позволит построить модель с учетом требований Трейсабилити. Кроме того, моделируя типы событий, я вообще не привязан к моделированию потоков. Бывают случаи, когда описать поток объектов невозможно, потому что трудно найти объекты учета, которые приходят, или покидают функцию. Например, если моделируется функция удержания вращающегося мячика на пальце клоуна, то смоделировать поток объектов в такой функции невозможно – ничто не покидает систему «клоун-шар» и ничто туда не втекает, а функция – вот она! Правда в системе «клоун-шар» события, которые происходят, носят не дискретный характер, а непрерывный.
Для понимания, что такое непрерывный поток событий, обратимся к электромотору. С одной стороны, электромотор легко представить себе в виде объекта. Очень часто так и делается. Если не нужно моделировать движение вала электромотора, аналитик просто пишет: электромотор такой-то. Это моделирование 4-х мерного объекта в виде 3-х мерного объекта. С другой стороны, можно попытаться смоделировать вращение вала электромотора. Вал электромотора вращается равномерно. Каждое положение вала в любой момент времени – это состояние. Все подобные состояния являются однотипными. Количество таких состояний зависит от дискреты, с которой производится замер. Это может быть дискрета временная, а может – угловая. Для целей моделирования удобно взять угловую дискрету, то есть, считать однотипными такие состояния, которые совпадают с поворотом вала на определенный угол, например, один оборот. Тогда плотность таких состояний на оси времени – количество оборотов в минуту, будет говорить о скорости вращения вала. Таким образом, вращающийся шар на пальце у клоуна будет описываться угловой скоростью вращения этого шара. Плотность состояний, распределенных по оси времени, говорит нам о скорости, с которой происходят переходы из одного однотипного состояния в другое. Там, где человеческое сознание сталкивается с огромным множеством однотипных состояний, аналитик вынужден переходить от моделирования состояний к моделированию плотности состояний, а это и есть описание объекта в виде функции. В случае с вращением вала электродвигателя – это функция вращения вала.
Замечу, что 4-х мерный объект может быть одновременно смоделирован:
- Как 3-объект – мотор.
- Как функция вращения вала.
Что в очередной раз подтверждает тезис о том, что объекты учета – это модели реальности, а не реальность. Однако, возможность моделировать 4-х мерный объект как функцию и объект одновременно – это не случайность. Это, как если бы мы смотрели на поток воды и видели сначала проплывающие мимо щепки, а потом глаза перестали бы различать отдельные щепки, но стали бы воспринимать их поток. Происходит это потому что сознание человека не способно перерабатывать большой объем информации и переходит от восприятия объектов к восприятию потока объектов. Этот переход и означает переход от восприятия 4-х мерного объекта как динамической системы к восприятию ее как статического объекта. Поэтому функция — это статический объект, порождающий однотипные события.
В следующей статье мы рассмотрим отношения «часть-целое» между 4-х мерными объектами и расскажу, какие понятия это позволит нам определить.
Комментарии (211)
aTwice
13.01.2017 10:22+5Если атрибут высота у слона больше, чем атрибут высота у вагона, то это не означает, что вагон поместится в слона.
realbtr
13.01.2017 10:54+6Тема, в общем, интересная, но хочется либо больше строгости и принципиальности, либо меньше претензий к инженерным дисциплинам. Инженерные дисциплины отрываются от породившей их онтологической концепции и представляют онтологию самостоятельную, которая может отражать другие, отражаться на другие, а может и не позволять взаимных отражений.
Проблемы, поднятые как серьезные — не так принципиальны практически. У вагона есть разные атрибуты габаритов и вместимости, как и у слона. Атрибуты всегда в жизни постулируются, а не извлекаются из непостулированного. Из-за этого атрибуты находятся в сложном взаимопорожденном отношении, зависимом от способа их определения. В мире нет безусловного сходства или безусловного различия, сходства и различия определяются критериями.
Стремление дать более удачные определения — похвальны. Нужно лишь помнить, что так рождается новая модель, конкурирующая с другими и не имеющая пока инженерного воплощения или хотя бы его спецификаций.
ООП — лишь спецификация к определенному кругу принципов, не являющихся даже теорией. Выстроить теорию на основе современных взглядов на онтологию — это круто.
Но, нужна принципиальность и строгость, а не частные рассуждения, претендующие на общность и глубину, которых в них пока нет.
Надеюсь, со временем, Вы свяжете эти идеи в теорию.
maxstroy
13.01.2017 15:34+1Собственно, еще нет языка или нотации для моделирования предметных областей. Попытки создать такие языки есть, но они, на мой взгляд, провалились. Поэтому я пишу для того, чтобы потом можно было построить язык, или нотацию, которая смога бы реализовать возможности, которые так нужны.
realbtr
13.01.2017 20:10+1Это не первая проблема. Вы полагаете основной метрикой пространство-время, а к ним список объектов, без других связей. Но другие связи есть и их много и это проблема как классической, так и современной физики. Объектность это допущение, с ограниченной применимостью. И в эти границы Вы будете упираться снова и снова. Дополнение объектов процессами не снимает ограничения, Вы лишь повторяете то, что уже сформулировано Геродотом.
maxstroy
14.01.2017 08:23сначала разберемся с объектами, затем займемся связями. Проблема в том, что объекты, между которыми надо моделировать связи, пока не названы и им не даны определения.
napa3um
14.01.2017 11:24+2Объекты определяются исключительно своими связями с другими объектами (возможностью влиять на другие объекты). Никакого иного смысла при моделировании прикладной области вложить в объект не получится (т.е., при моделировании важнее формализация каузальности, а онтология вторична, следует из выделенных каузальных связей).
claygod
13.01.2017 10:58+4Поскольку это всё-таки IT-шный сайт, не могли бы Вы свою идею представить в виде кода (м.б. псевдокода), или некой схемы? Иначе всё как-то воспринимается слишком академично. Т.е. как ваша идея может быть воплощена на практике, хотя бы в общих чертах?
maxstroy
13.01.2017 12:31проблема в том, что существующие инструменты не заточены под моделирование тех объектов, о которых я рассказываю. я бы хотел увидеть такие инструменты.
Saffron
13.01.2017 12:00Ваш любимый semantic web имеет ту же проблемы с формулировками и названиями. По факту, это не семантика, а синтаксис. А семантическая модель не задана. А без семантической модели никакой речи о строгости и сравнении точности подходов вести нельзя.
maxstroy
13.01.2017 15:37Я не говорю, что уже существуют удовлетворительные языки для моделирования предметных областей. Есть попытки их создать, но до сих пор нет удовлетворительных. OWL моделирует предикаты первого порядка, что уже гораздо лучше, чем то, что позволяет сделать MOF, на основе которого построены нотации семейства UML. Но и OWL недостаточно для построения утверждений относительно множеств объектов, или типов. Поэтому это тоже половинчатое решение.
Saffron
16.01.2017 18:44OWL — это не язык моделирования, это язык программирования, очередная инкарнация пролога. Об этом я и говорю — программировать на OWL можно, использовать RDF базы данных — можно. Но самого того факта, что какой-то язык годится для программирования, не означает, что на нём сподручно моделировать.
Предварительно нужно связать синтаксис этого языка с некоторой семантической моделью. Тогда программа на таком языке будет не просто «компьютер получил данные на вход, выполнил алгоритм, выплюнул выходные данные», а описанием (с доказательством!) некоторой сущности, которой придан смысл, семантика.
lair
13.01.2017 15:01+5В текущей статье я определю следующие термины: объект, состояние, событие, операция, функция.
Каковы границы применимости ваших определений?
В качестве мета-метамодели для моделирования мы возьмем теорию множеств, а не MOF.
Я несколько раз прочитал всю статью, и не нашел в ней ни одного использования аппарата теории множеств. Сам термин "множество" используется, но в общеупотребительном смысле. Так что никакие свойства теории множеств (как то: математическая основа и границы применимости) на подход, описанный в посте, переносить нельзя. Но это так, ремарка на всякий случай.
В качестве примера такого ограничения можно представить себе моделирование высоты у объектов класса слон и объектов класса вагон. Эти два атрибута в [какой-то парадигме] никак не связаны между собой, поэтому понять, что слон поместится в вагон можно только, обратившись к программисту, создавшему эти атрибуты.
Давайте просто запомним этот пример, нам еще придется к нему вернуться.
Коль скоро мы определили объект как модель 4-объема в 4-пространстве
Это самое близкое к "определению" утверждение об объектах в этом посте. Итак, повторюсь: объект — это (субъективная) модель четырехмерного объема в четырехмерном пространстве.
Вернемся к задаче выше: у нас есть слон и вагон, нам надо понять, влезает ли слон в вагон. При их моделировании мы получаем объекты (для простоты считаем, что их временные координаты полностью совпадают, и дальше будем говорить о трехмерных объектах): объект "слон" и объект "вагон", у обоих этих объектов есть объемы.
Вспомним так же и другой тезис из поста: "принято считать объект плотным объектом, который не может одновременно пересекаться с другими объектами". Оба наших объекта, в терминологии автора, "плотные" — два вагона не могут находиться в одном объеме, два слона — тоже.
Первый подход: слон влезает в вагон, если все измерения его объема меньше, чем (соответствующие) измерения объема вагона. Это, однако, противоречит тезису про плотность: два плотных объекта не могут пересекаться в одном объеме.
Второй подход: попробуем смоделировать вагон более детально — т.е., как набор объектов (стены, двери, пол, потолок). В этом случае слон помещается в вагон, если измерения его объема меньше, чем… хм, чем разница таких-то координат составляющих объектов (иными словами, расстояние от пола до потолка и от стены до стены). Можно ли это понять, не обращаясь к "программисту, создавшему эти объекты"? Нет, поэтому этот подход имеет те же ограничения, что и описанные в п.2 в начале статьи (откуда и взят пример).
Третий подход: окей, давайте попробуем смоделировать вагон как вагон и пустое пространство в нем — т.е., два объекта, один "плотный", другой "рыхлый" (по терминологии автора поста). Теперь слон помещается в вагон в том случае, если измерения "слона" меньше, чем соответствующие измерения "пустого пространства", связанного с интересующим вагоном. Что получилось? Во-первых, нам понадобилось ввести понятие связи между объектами, во-вторых, эта логика тоже не вытекает из модели — опять возвращаемся к программисту.
(Ну и на самом деле, слон не влезает в этот вагон. Почему? Потому что там уже есть бегемот. Не забывайте уменьшать "пустое пространство" при каждом помещении в него "плотного" объекта.)
Ладно, чуть-чуть видоизменим задачу: у нас есть слон, массой X тонн, и вагон, рассчитанный на нагрузку в Y тонн (и ж/д путь, рассчитанный на нагрузку в Z тонн). Сможем ли мы довезти до точки назначения слона в вагоне (по пути)? Объекты, являющиеся моделями четырехмерного пространства, никак не помогут нам в ответе на этот вопрос. Опять надо идти к программисту.
Что получилось в итоге? Предлагаемое в статье определение объекта в общем случае не решает те проблемы, которые автор приводит как ограничения [других подходов].
Допустим, что есть множество моделей 4-объемов, или множество объектов. Эти модели хранятся у субъекта в сознании. Если эти модели похожи друг на друга, то субъект может создать модель этих моделей. Эта модель также хранится в сознании субъекта. Эта модель моделей и есть тип объектов.
Немедленно возникает вопрос: униформен ли предлагаемый автором подход? Иными словами:
- Является ли объект (модель четырехмерного объема) четырехмерным объемом? Как, следствие,
- Является ли тип объектов объектом?
Выглядит так, как если бы ответ на оба этих вопроса был "нет". В принципе, это логично: существующая в сознании модель не имеет измерений в четырехмерном пространстве (кроме единственной координаты "время начала существования"), поэтому ее модель не является объектом. Далее аналогично.
А теперь снова вернемся к слонам. У нас есть типы контейнеров (десяти-, двадцати- и сорокафутовые). То есть где-то, несомненно, существуют конкретные контейнеры каждого типа, но мы не владеем ни одним из них, поэтому для нас их нет. Нам надо выбрать, контейнер какого типа мы закажем, чтобы перевезти в нем нашего слона. Поскольку выше мы предположили, что тип объектов (в данном случае — тип контейнеров) не является объектом, мы не можем применять к нему те же подходы по ответу на вопрос "влезает ли слон в", которые мы (условно) успешно применяли к вагону. Какой подход здесь рекомендует применять автор?
Такое описание объекта соответствует описанию бизнес-функции, и говорят, что это функция по выпуску веников.
"Бизнес-функция" и "функция" — это одно и то же?
Бизнес-функция – это 4-х мерный объект,
Какова протяженность этого объекта во времени?
Бизнес-функция – это 4-х мерный объект, который имеет описание в виде набора типов событий с указанием плотности этих событий во времени
Скажем, "бизнес-функция" шредера — это превратить бумагу в мишуру. Продолжительность этого превращения с точки зрения наблюдателя, которого интересует эта бизнес-функция — не равна нулю, поэтому такое превращение — это не событие (напомню определение из поста: "событие — это изменение состояния объекта учета за столь короткое время, что наблюдатель считает это время равным нулю"). Что в этом случае будет типом (типами) событий, которые описывают эту бизнес-функцию, и какова их плотность во времени?
Или просто "превращение бумаги в мишуру" — это не бизнес-функция?
Или подойдем с другой стороны: какую задачу решает модель бизнес-функции?
blanabrother
13.01.2017 16:42Интересный коммент. Вопрос к цитате:
Скажем, «бизнес-функция» шредера — это превратить бумагу в мишуру. Продолжительность этого превращения с точки зрения наблюдателя, которого интересует эта бизнес-функция — не равна нулю, поэтому такое превращение — это не событие (напомню определение из поста: «событие — это изменение состояния объекта учета за столь короткое время, что наблюдатель считает это время равным нулю»)
По словам автора, бизнес-функция — это «набор» типов событий с указанием плотности этих событий во времени. Если в мелких деталях разобрать каждую деталь механизма шредера, от валов, перемещающих бумагу, до лезвий, нарезающих ее, то можно вполне себе представить их теми самыми типами действий. Например вращение резинового вала, перемещающего бумагу, можно представить как стремящееся к бесконечному большому кол-ву мгновенных сдвигов на угол, стремящийся к бесконечно малому значению — что тоже стыкуется с «событием», которое «изменение состояние объекта за короткой время (бесконечно малое)». Короче говоря, весь шредер не может быть событием, но может состоять из бесконечного числа событий.lair
13.01.2017 16:44+1Модель шредера, состоящая из бесконечного числа событий, на мой взгляд, имеет бесконечно малую применимость.
maxstroy
13.01.2017 19:17нет, функция — это не набор, это 4-х мерный объект, имеющий описание в виде и далее по тексту
napa3um
16.01.2017 13:03Больше похоже на фазовое пространство, чем на функцию.
maxstroy
16.01.2017 13:18Не, фазовое пространство имеет произвольное количество измерений. Например, 6, или 12, кроме того, пространство и его описание — разные вещи. Я не говорю про пространство, я говорю про описание пространства
Gurklum
13.01.2017 19:18Я бы описал все же через состояния: до момента 0 шредер находится в состоянии покоя, с момента 0 до момента T в состоянии пережевывания бумаги, с момента T и далее в состоянии покоя.
При этом бумага до встречи со шредером находилась в одном состоянии, во время пережевывания — в соответствующем состоянии измельчения, а после — уже не существует вовсе (заменена множеством полосок).
А вот события в определении автора тут есть: включение и выключение шредера, они же начало уничтожения и прекращение существования соответственно для бумаги.
Это не решает других вопросов и даже добавляет: что делать с такими совокупными событиями? Являются ли они единым событием (маловероятно, ведь они показывают изменения совершенно разных состояний разных объектов) или жестко связанными различными событиями (тогда не помешало бы модели по отношениям событий).maxstroy
13.01.2017 19:20вы описываете те события, которые считаете нужным описывать. правильных описаний не существует. каждый видит свое, но в рамках отраслевых стандартов принято видеть определенные события, имеющие ценность для моделирования
maxstroy
14.01.2017 08:30Функция шредера — превращать бумагу в мишуру. Мы должны определиться с событиями, которые мы регистрируем у этой функции. Например, событие — превращено 10 листов в мишуру. Таким образом, мы формулируем значимые для моделирования события. Далее мы включаем счетчик и считаем, сколько таких событий на отрезке времени, который много дольше расстояния между событиями, но при этом средняя скорость на этом отрезке неизменна. Это похоже на статфизику. Мы там тоже пытаемся определить стат систему, но сталкиваемся с теми же трудностями. Сивухин потратил не одну страницу, пытаясь объяснить, что такое стат объект. Ландау в своем стиле много не разглагольствовал, потому что итак ясно, что дело темное. Вот с таким объектом мы имеем дело, когда говорим про бизнес-функцию.
lair
14.01.2017 11:20BTW, вот один из подходов к решению задачи о слоне и вагоне:
IShippable elephant; IShippingContainer carriage; elephant.CouldBeShippedIn(carriage);
И это, заметим, модель конкретной предметной области.
sand14
14.01.2017 15:08+1В своей модели вы нагружаете слона некой семантикой (интерфейс IShippable), может ли слон быть отправлен в неком вагоне.
Но слон в силу своей природы не может знать, может ли он поместиться в тот или иной вагон.
И в динамическом языке при получении такого сообщения, объект "слон" возвратил бы ошибку.
В случае статического языка можно генерировать InvalidOperationException, а лучше вообще не добавлять такой интерфейс.
В данном случае подходит анемичная модель, когда есть слон с минимально-необходимым набором атрибутов (вес, габариты) и сервис, который по значению атрибутов может вычислить, уместится ли слон в вагон.
lair
14.01.2017 15:26В своей модели вы нагружаете слона некой семантикой (интерфейс IShippable), может ли слон быть отправлен в неком вагоне.
Неа. Я нагружаю слона семантикой, что он вообще может быть куда-то отправлен (причем не обязательно, что эта семантика статична).
И в динамическом языке при получении такого сообщения, объект "слон" возвратил бы ошибку.
А кто вам сказал, что это сообщение получил именно слон?
FractalizeR
13.01.2017 16:54+2В ООП есть термин наследование. Это инструмент моделирования иерархии тип-подтип. Это значит, что ООП построено на логике Аристотеля.
Этот вывод кажется мне странным. Разве любой инструмент моделирования иерархии тип-подтип обязан подчиняться логике Аристотеля?
evkochurov
13.01.2017 17:29+3Потому что это единственный на сегодняшний день известный способ моделирования, который имеет математическую основу, границы применимости которого нам хорошо известны, достаточно широки и обоснованы.
Ой ли? А классическая логика предикатов таковой не является? В конце концов, теория множеств — это частный случай логической теории. Тут правильнее было бы сказать «единственный известный мне способ».maxstroy
14.01.2017 08:32До предикатов мы еще не дошли, хотя, верно, что теория множеств — единственно мне известный способ. Я хотел бы разобраться с моделированием в предикатах как первого так и второго уровня, но пока мы не можем сдвинуться с места и буксуем на том, что цепляемся к ООП.
aleexp
13.01.2017 17:29+1А стоит ли рассматривать процесс с тех же позиций, что и объект?
Не кажется ли вам, что это по природе своей это разные вещи, и для изучения и моделирования их используются разные инструменты и описательные категории?maxstroy
14.01.2017 08:35Можно оставить все как есть, но лично меня это не устраивает, потому что ответ на то, что такое операция мне до сих пор не дал ни один аналитик. А это значит, что никто не знает, что это такое. Кроме того, очень хороший коммент дал мой знакомый, который занимается подобной задачей. Вот его слова: на мой взгляд проблема заключается не в автоматизации управления чем-либо, с этим аналитики и программисты неплохо справляются. Проблема же в интеграции систем управления разных направлений (например, ERP, MES, SCADA, CAD, ...), так в них используются свои, несовместимые с другими, подходы к моделированию одних и тех же физических «объектов учета» (как называет их Марк). Универсальный подход, на мой взгляд, должен позволить объявить каждую из этих моделей частным случаем более общей модели, пусть даже сама универсальная модель будет иметь ограниченное применение для создания новых информационных систем. Если получится «отмапить» существующие модели (UML, BPMN, ...) на одну общую, то это позволит семантически «бесшовно» интегрировать данные из самых разных информационных систем.
panvartan
13.01.2017 17:30объект, состояние, событие, операция, функция — это категории восприятия и их использование для моделирования приводит к моделированию восприятия природы, а не самой природы.
maxstroy
14.01.2017 08:36Мы вообще не заняты моделированием природы. Мы заняты моделирование своих представлений о природе. Сама природа непостижима и не моделируема.
panvartan
14.01.2017 13:01расскажите это химикам, с их молями и периодической системой. Кстати, пока они оперировали представлениями восприятия — сухостью, маслянистостью, огнем, водой и землей — их наука называлась алхимией.
maxstroy
14.01.2017 14:27я сам физик, и как физик утверждаю, что физика не про природу, а про наше ее представление. Никому нет дела до природы, как программистам нет дела до того, что такое операция. Лишь бы работало
evkochurov
13.01.2017 18:34+2Объектами, которыми оперирует теория множеств, являются, как это ни странно, множества. Не очень понятно, множеством чего тут предлагается считать объект? Множеством точек в 4-мерном объеме? Множеством точек на границе этого объема? Как перейти от описания винта через шаг резьбы к описанию винта в теории множеств?
Я понимаю, что объем статьи таков, что в нее не удалось поместить все детали, но из имеющегося текста не удается восстановить ответы на эти вопросы.maxstroy
13.01.2017 18:57Не надо копать глубоко, хотя мне бы и хотелось). Канторовская модель множеств предполагает множества мощности континуум, которых в природе нет. Об этом хорошо сказано в основах математики: никто не знает, с чем имеют дело математики, но выводы и них верные. под множеством я понимал лишь множествовитков и множемво событий
evkochurov
13.01.2017 19:13+2Тогда непонятно, причем здесь теория множеств, если копать до нее не надо?
maxstroy
13.01.2017 19:24-1объект функция имеет описание в виде модели моделей и далее — плотности событий, а плотность — это атрибут множества событий, а не событий множества
michael_vostrikov
13.01.2017 19:53Как в этом подходе смоделировать клиента с неизвестным на данный момент именем, который придет завтра в неизвестное время с неизвестной на данный момент целью?
maxstroy
14.01.2017 08:38+1Для моделирования такого объекта, четырех измерений мало. Как я уже говорил, самым сложным для меня было моделирование именно такого кейса, когда размерность будущих исходов определяется вероятностью, а прошлых — точностью знаний о них. В текущей статье я не касаюсь столь сложных объектов, потому что это выходит за рамки популярной статьи.
michael_vostrikov
14.01.2017 10:09+1Для моделирования такого объекта достаточно определить тип «Клиент» со свойствами (имя, цель_обращения). И когда клиент придет, достаточно создать новый объект такого типа и указать конкретные значения свойств. Объектно-ориентированное программирование/проектирование уже позволяет смоделировать то, что для вашего подхода является сложным случаем. Как же вы будете моделировать случаи, которые являются сложными для ООП.
maxstroy
14.01.2017 10:25Вы решили не ту задачу, о которой говорили в постановке. Вы смоделировали уже прошедшие события, а в постановке речь шла о будущих
michael_vostrikov
14.01.2017 11:11Где именно там модель прошедших событий? Как в таком случае звали клиента, который пришел?) И вы считаете, что послезавтра программа не сможет повторить эти действия, когда придет другой клиент?
Здесь опять торчат уши понятий «тип процессов» и «экземпляр этого типа процессов» (которые для краткости называют «тип процесса» и «экземпляр процесса»).
Модель клиента я описал, она задается типом «Клиент».
Модель регистрации нового клиента, задается типом процессов «Регистрация клиента», который представляет собой список действий, одно из которых это моделирование создания экземпляра типа «Клиент», и указание его конкретного имени.
Экземпляр типа процессов «Регистрация клиента» создается в момент прихода клиента. Экземпляр типа объектов «Клиент» с конкретным именем создается во время выполнения этого экземпляра процесса.
Поскольку на момент моделирования я имя клиента не знаю, да он и не пришел еще, то это моделирование будущих событий.
Кстати, раз уж я прояснил постановку задачи, то как в вашем подходе смоделировать эти «прошедшие» события и клиента в них?maxstroy
14.01.2017 11:37Будущее неизвестно. Мы не можем смоделировать то, что завтра придет клиент, потому что может придет, а может не придет, может клиент, может не клиент… Мы понятия не имеем, что произойдет завтра. Вы же говорите о моделировании уже прошедших событий, когда мы знаем, что был клиент, что он пришел. Моя модель не ведает будущего, но с некоторой степенью точности моделирует прошлое, потому что знать прошлое мы не можем абсолютно точно. Но рассказ об этой модели займет страниц 30 текста, да и является комм тайной, которую я не имею права раскрывать. Поэтому я рассказываю те условия, которые привели нас к этой модели, но саму модель я показывать не буду.
napa3um
14.01.2017 11:50Пока вы не расскажете цель, к которой вы пришли, описание пути до этой цели не будет содержать для слушателей особой осмысленности. Смысл решения (пути) всегда зависит от задачи (цели).
lair
14.01.2017 11:57Извините, но высказанная вами позиция делает невозможной разработку любой прикладной программной системы — потому что на момент составления требований всё, что эта система призвана автоматизировать, находится в будущем.
napa3um
14.01.2017 12:09Ментальная ловушка «хочу формализовать всё, что возможно во вселенной, даже чего мы пока не знаем» приводит к попыткам формализовать процесс формализации (к попыткам моделировать мышление человека), что получается пока не очень (strong AI до сих пор не создан). Но попавшиеся в эту ловушку, как правило, не осознают глубину проблемы и ничтожность своих амбиций, им кажется, что всё решается Самой Правильной Абсолютной Онтологией :).
michael_vostrikov
14.01.2017 12:42+1Вы же говорите о моделировании уже прошедших событий, когда мы знаем, что был клиент, что он пришел.
Как это он пришел, если он еще не пришел? Да ладно, прошедшие, будущие, не суть. Как с вашим подходом их смоделировать? Почему вы снова уходите от ответа?
Мы не можем смоделировать то, что завтра придет клиент, потому что может придет, а может не придет, может клиент, может не клиент…
А как тогда по-вашему работают заранее написанные программы? Они именно что моделируют будущие события. И да, вы снова путаете тип и экземпляр. Это экземпляр находится в будущем. Но задав тип, мы можем работать со всеми экземплярами такого типа.
… является комм тайной. Поэтому я рассказываю те условия, которые привели нас к этой модели, но саму модель я показывать не буду.
А, то есть практической ценности для других специалистов у нее нет. Ок.
maxstroy
16.01.2017 08:13Почему вы снова уходите от ответа?
Будущее неизвестно! Модель должна это учитывать. Если модель будущего этого не учитывает, она плохая модель. Мы моделируем вероятностное будущее. Это значит, что у нас клиент может прийти, может не прийти, может не клиент, может налоговик, не важно, потому что мы готовы ко всему. А, когда нам станет известно, кто пришел, вот тогда мы занесем это в модель. Но и то — мы же можем обмануться. Пришел, представился клиентом, а на самом деле налоговик. Мы тогда сможем переклассифицировать пришедшего в новый класс, и сделать новую интерпретацию прошедшим событиям. Я исчерпывающе ответил?michael_vostrikov
16.01.2017 09:55+1Я исчерпывающе ответил?
Нет. Была простая задача — сделать модель регистрации новых клиентов, чтобы программист мог написать по ней программу. Вместо трех строк с описанием модели вы написали кучу текста про прошлое и будущее, упомянув мимоходом, что это сложный случай для вашего подхода. Задачу вы не решили.
maxstroy
16.01.2017 12:12Нет, задача была не такая — задача была:
Как смоделировать клиента с неизвестным на данный момент именем, который придет завтра в неизвестное время с неизвестной на данный момент целью?
Если нужно решить задачу регистрации новых клиентов, то — это совсем другая задача.
Для этого регистрируется новой лицо, физическое, юридическое, предприниматель и проч… А затем указывается, что это лицо — клиент. Клиент одновременно может быть и поставщиком, не забываем про это. Но это простая задача регистрации, а не попытка смоделировать события будущего. Будущее, как я сказал, неизвестно, но вероятностно. Мы с какой-то вероятностью можем о нем рассуждать. И моделирование будущего — это моделирование вероятных исходов.lair
16.01.2017 12:23Для этого регистрируется новой лицо, физическое, юридическое, предприниматель и проч… А затем указывается, что это лицо — клиент.
Во-первых, вы переусложнили — нет никаких ФЛ, ЮЛ и ИП в задаче. А во-вторых, "регистрируется" где? В системе. Система написана без модели? Без требований? В ней нет внутренней модели (хотя бы на уровне БД)?
Клиент одновременно может быть и поставщиком, не забываем про это.
… особенно это круто для той системы, где вообще нет поставщиков.
maxstroy
16.01.2017 12:37Клиент — это представление одного субъекта (юрлица, физлица и проч.) как потребителя (покупателя) услуг (товаров) с точки зрения другого субъекта (юрлица, физлица и проч.) Без моделирования точки зрения субъекта, бессмысленно говорить о клиенте, потому что не понятно: клиент кого? Надо указать, как минимум, двух субъектов, чтобы понять, кто поставщик, а кто клиент. Как иначе? Ведь «клиент» — это отношение между субъектами, а не сами субъекты
lair
16.01.2017 12:42Надо указать, как минимум, двух субъектов, чтобы понять, кто поставщик, а кто клиент. Как иначе?
Да легко. Если поставщиком выступает та организация, которая владеет/заказывает информационную систему, то этот субъект в ИС может существовать неявно.
Аналогично и с точкой зрения — она может быть единственной, и поэтому в модели явного выражения не иметь.
maxstroy
16.01.2017 12:51Мы опять ходим по кругу. Я говорю про моделирование предметной области (про концептуальную модель), а вы про информационную систему, которая воплощает эту модель (она моделируется физической моделью). Для создания концептуальной модели я считаю невозможным использование UML, но для создания физической использование UML — обязательно, если мы кодим на ООП языках. Разведите по разные стороны моделирование предметной области и моделирование кода, тогда вам станет ясно, что мои модели не про код, а про предметную область, а как конкретная ИС реализует эту модель, решает не аналитик, а архитектор ИС. Я не лезу в задачи архитектора, он не лезет в задачи аналитика — это правильный расклад. Иначе — беда
lair
16.01.2017 13:29Я говорю про моделирование предметной области (про концептуальную модель
Всякая ли модель предметной области будет концептуальной?
а вы про информационную систему, которая воплощает эту модель (она моделируется физической моделью).
Кто "она"? Информационная система? Тогда я не понимаю, что вы называете физической моделью.
но для создания физической использование UML — обязательно, если мы кодим на ООП языках
При использовании ОО-языков использование UML необязательно.
Разведите по разные стороны моделирование предметной области и моделирование кода, тогда вам станет ясно, что мои модели не про код, а про предметную область
Код — он тоже про предметную область. И код — обычно — не моделируют.
michael_vostrikov
16.01.2017 13:55Если нужно решить задачу регистрации новых клиентов, то — это совсем другая задача.
Я вас попросил об этом в следующем комменте, когда выяснилось, что у вас другое понимание исходной постановки. И понятие "новый клиент" подразумевает, что изначально мы не знаем его имени и цели обращения.
Так все-таки, вы сможете сделать модель для этой задачи? Фразы типа "Для регистрации клиента регистрируется лицо, а потом указывается что оно клиент" моделью не являются, так как и в левой и в правой частях используется понятие "регистрация". Как тогда смоделировать регистрацию физического лица?
lair
16.01.2017 11:23А, когда нам станет известно, кто пришел, вот тогда мы занесем это в модель.
Мы это должны занести не в модель, а в информационную систему. Которая построена по модели. Для которой приход находится в далеком будущем.
maxstroy
16.01.2017 13:25Я занесу в модель, а будет ли ИС на этот момент, мне неизвестно. Я могу записать это на бумажке, на магнитофонной ленте голосом, не имеет значения. При чем тут ИС? Вы привязываетесь к ИС, как будто только с ее помощью можно моделировать предметную область. Но это далеко не так. В течении тысячелетий люди моделировали без ИС и справлялись с этой задачей.
lair
16.01.2017 13:31Я занесу в модель, а будет ли ИС на этот момент, мне неизвестно. Я могу записать это на бумажке, на магнитофонной ленте голосом, не имеет значения.
На момент "кто пришел" вас уже не будет, система сдана заказчику. И по его требованиям заносить надо в ИС.
При чем тут ИС?
При том, что мы на хабрахабре.
Вы привязываетесь к ИС, как будто только с ее помощью можно моделировать предметную область.
ИС — обычно — используется не для моделирования предметной области, а для ее автоматизации.
lair
13.01.2017 21:18Если не секрет, в теории множеств есть понятие "атрибут множества"?
maxstroy
14.01.2017 08:42Про множества, атрибуты и их значения можно почитать в книге Мэтью Веста. Пока же можно сказать, что атрибут связан с классом классов классов. То есть первый класс — это атрибут, второй — шкалы, третий — значения шкал. Сейчас я не буду погружаться в детали, потому что это уведет нас от темы статьи, но как-нибудь я это опишу
lair
14.01.2017 11:11Ну то есть ответ на мой вопрос — "нет". Что возвращает нас к тезису об корректности использования теории множеств.
almazsr
13.01.2017 19:25Если не загоняться на тему математических извратов, то границей 4-х мерного объекта будет 3-х мерный объект.
С чего бы это? Разве что только для визуализации проще рассматривать 2 оси координат в декартовой системе координат, а 3-ю ось обозначить как время.
Shortki
13.01.2017 22:41+1Понятия объекта или функции существуют в лишь рамках отдельных дисциплин и методологий. Сами методологии не “подвешены в воздухе”, а созданы для определённых целей и именно эти цели влияют на то, как будет определены понятия в методологии. Зачем давать новое определение объекту, если у вас нет методологии которая будет его использовать, нет когнитивной отрасли которой нужна новая методология, и не определены цели всей этой деятельности.
К примеру мерность объектов не имеет смысла сама по себе, зачем находить 4-х мерный объект для операции подтверждения покупки в интернет сайте? Любой бухгалтер запросто добавит вашему объекту несколько новых измерений, которые на поверку будут более бизнес-значимы чем ваша модель. А задача точно определить 4-х мерные координаты моего остатка на счету в банке может оказаться любопытной, но сложно-достижимой и уж точно эти знания не важны для пользования остатком.
Так что сначала ответьте на вопрос: “Зачем нужна новая методология и какие задачи она будет решать?” А из ответа на этот вопрос сами собою последуют определения объекта, события и всего остального.
maxstroy
14.01.2017 08:47Я не занимаюсь методологией, я просто пытался ответить на вопрос: что такое перечисленные объекты. Ни в одной из нотаций я не встречал определений, что же такое операция, функция и объект. Теперь я могу представить себе их и могу моделировать их легко и непринужденно. Как сказал мой знакомый, который также занимается этой задачей:
на мой взгляд проблема заключается не в автоматизации управления чем-либо, с этим аналитики и программисты неплохо справляются. Проблема же в интеграции систем управления разных направлений (например, ERP, MES, SCADA, CAD, ...), так в них используются свои, несовместимые с другими, подходы к моделированию одних и тех же физических «объектов учета» (как называет их Марк). Универсальный подход, на мой взгляд, должен позволить объявить каждую из этих моделей частным случаем более общей модели, пусть даже сама универсальная модель будет иметь ограниченное применение для создания новых информационных систем. Если получится «отмапить» существующие модели (UML, BPMN, ...) на одну общую, то это позволит семантически «бесшовно» интегрировать данные из самых разных информационных систем.napa3um
14.01.2017 11:34> Я не занимаюсь методологией, я просто пытался ответить на вопрос: что такое перечисленные объекты [в абсолюте].
Объекты имеют смысл только в рамках какой-либо задачи (или методологии решения конкретных типов задач). Абсолюта не существует (см. [нео/пост]позитивизм в научном методе).
Shortki
14.01.2017 17:15Давать определения, это уже часть построения методологии, так что хотите вы или нет, но вы занимаетесь методологией.
Любая модель вносит свои “искажения” в представляемые данные, решать задачу интеграции построением некой новой “супермодели” спорная задача, так как супермодель уже существует — это наш реальный мир. В интеграционных задачах зачастую важно предавать между системами и методологиями только реальные данные, очищенные от трактовок различных подходов. Как правило, методика на входе имеет поток фактов, а на выходе получаются трактовки, при интеграции систем пытаются из трактовок восстановить поток исходных данных, дополнить его недостающими фактами (иногда даже домыслить их) и передать их другой системе. Основная проблема здесь, убедится что при передаче сами факты представлены адекватными переходными представлениями, которые строятся исходя из специфики каждой из систем и решаемой задачи интеграции.
Решать же задачу интеграции заочно в отсутствие самих субъектов слишком трудоёмко, так как предполагает фиксацию абсолютно всех доступных данных в неком представлении с минимумом искажений, то есть в трактовках максимально близких к природе самих данных. В то же время, люди придумывают методологии именно для того чтобы избавить себя от необходимости такой плотной фиксации, выделяя в потоке данных лишь значимые сведения. Случайное противоречие? Не думаю…maxstroy
14.01.2017 17:30Я утверждаю, что реального мира нет, есть лишь наши модели, выраженные языком, образами, запахами, которые являются не более чем интерпретацией сущего, но не самим су3щим. Поэтому мы учимся передавать друг другу модели и никогда не можем передать реальность. А вот как раз этому и посвящена статья — что стоит за словесными патернами, которыми мы пользуемся при передаче моделей?
napa3um
14.01.2017 20:25Ваша позиция (в том числе и по отношению вашего понимания методов физики как метода изучения сознания в комментариях выше) называется солипсизмом. Самым наивульгарнейшим. (И платонизм у вас радикальный: мол, мира нет, но реально существуют лишь мыслимые концепции Идеальной Онтологии.)
maxstroy
16.01.2017 07:45Вы действительно считаете, что границы между объектами существуют реально? а не в воображении? Я писал статью на эту тему. О том, что нет никаких объективных способов выделить объекты из 4-х мерного объема, кроме, как волюнтаристского. Назовите критерии объекта, и мы поговорим.
vladob
16.01.2017 02:06>Если получится «отмапить» существующие модели (UML, BPMN, ...) на одну общую, то это позволит
> семантически «бесшовно» интегрировать данные из самых разных информационных систем.
Я новичок в этой области, но вынужден в нее погружаться, поэтому простите за возможную наивность, но…
А нет ли ощущения, что упомянутая бесшовность просто в принципе невозможна?
Примерно в том же смысле, как невлияние наблюдателя на результат измерения в физике.
И откуда эта «шовность» берется?
Не из авторства ли, не из того, что модели пишутся людьми под определенные — индивидуальные по факту — цели, опираясь на индивидуальный же частный (дискретный) опыт в дискретном же (в виде предложений, слов, букв)?..
Вот, говорят, по тексту, описывающему одно и то же событие, можно опознать автора.
Как обстоят дела в моделировании мира — возможно здесь «отстроиться» от автора, его целей, опыта и т.д.?napa3um
16.01.2017 02:22+2Всё верно, любая модель локальна и отражает структуру явной или неявной задачи, для которой её и создали (и в контексте которой может быть оценена полезность модели — по предсказательной силе модели). Ваша интуиция верна, прежде чем рассматривать модель, необходимо понять цели автора модели (задачи, которые он решает этой моделью) и его опыт (объём учтённых в модели проблем). И прежде чем самому строить модель, нужно определиться с целями её построения. «Бесшовыный» холизм и противоположный ему «лоскутный» редукционизм — две недостижимые в абсолюте идеализации (как невозможно однозначное обобщение всей вселенной до «всего сущего», так и невозможно разложение всей вселенной на однозначный набор элементарных принципов), и все реальные (полезные) теории всегда находятся где-то между ними.
Alew
14.01.2017 03:11Вы ссылаетесь на очень странную книгу, я бы сказал что к современному состоянию ООП она не имеет ни какого отношения, ни проблем ни решений. ООП разнообразен, автор же почему то проигнорировал почти все что было написано до него. Йордон и Код не могут служить основой для критики ООП т.к. представляют только один из вариантов, и некоторые считают этот вариант не правильным.
maxstroy
14.01.2017 08:49Яне критиковал ООП, целью статьи было дать определение объектов, не прибегая к ООП с объяснением, почему я это сделал. Просто часто ООП считают способом моделирования предметных областей, но для меня очевиден вред тех терминов, которые произносят программисты, плохо разбирающиеся в моделировании предметных областей, но хорошо — в моделировании кода.
Alew
14.01.2017 15:35DDD как логическое развитие идей ООП требует соответствия модели и кода 1 в 1, в противном случае ад поддержки обеспечен. Все это подробно описал Эрик Эванс в своей книге. И если предметная область оценивается как сложная, то есть все основания использовать ООП для реализации, что в свою очередь подталкивает использовать объектную декомпозицию и моделирование.
Вы с какой частью не согласны?maxstroy
14.01.2017 17:06Я не согласен с тем, что ООП способно смоделировать предметную область и неоднократно писал почему.
michael_vostrikov
14.01.2017 17:40+1И вам неоднократно писали, где вы не правы, и приводили примеры. Только вы их игнорируете и упорно продолжаете твердить одно и то же. Вы не знаете программирования, соответственно, это вы не можете смоделировать предметную область с помощью ООП. Это не значит, что ООП для моделирования не подходит.
maxstroy
14.01.2017 17:47Вот поэтому мы никогда не сойдемся с теми, кто моделирует в ООП. Да и не надо сходиться. Я не ставлю задачи моделирования в ООП, я не приглашаю тех, кто не видит ограничений ООП к диспуту, потому что мне не надо убеждать в этом кого-то. Просто есть достаточное количество людей, обжегшихся на ООП, им интересно, как можно смоделировать реальность другими способами.
lair
14.01.2017 17:52Ну да. Вы просто пишете "ООП не может x и y" (или, что не менее весело, "в ООП так и так") но тех, кто с этим не согласен, "к диспуту не приглашаете". Прекрасная, прекрасная политика.
maxstroy
14.01.2017 17:57Мы вроде уже обсудили наши позиции. То, что они не сходятся, — это нормально, потому что каждый имеет право на свое мнение.
lair
14.01.2017 17:59… а каждое публично высказанное мнение может быть обсуждено (публично или частно — второй вопрос).
maxstroy
14.01.2017 18:05Конечно, я с удовольствием почитал статью, в которой был бы описан хотя бы терминологический аппарат ООП. Потому что то, что я читал — это аппарат описания кода, а не предметных областей. UML — нотации, моделирующие код (кроме кастрированной диаграммы использования), а не предметную область. И пока никто не дал мне ссылок на источники, в которых было бы сказано обратное
lair
14.01.2017 18:10был бы описан хотя бы терминологический аппарат ООП
… давайте начнем с ответа на вопрос "что вы понимаете под ООП".
Потому что то, что я читал — это аппарат описания кода, а не предметных областей.
Программа содержит в себе модель предметной области (качество ее оставим за скобками). Соответственно, парадигма, использованная для написания этой программы, была использована для создания модели предметной области.
И пока никто не дал мне ссылок на источники, в которых было бы сказано обратное
Вы Эванса уже прочитали? Ссылки на него вам давали неоднократно. Вот вам цитата:
Object-oriented programming is powerful because it is based on a modeling paradigm, and it provides implementations of the model constructs.
maxstroy
14.01.2017 18:27-1Меня не устраивает даже такая мелочь, как перепутать тип данных в коде с классом объектов в природе, как наделение неживого возможностью что-то делать, как подмена отношения тип-подтип на родитель- ребенок. Ну а апофеозом стала путаница, когда вместо элемента класса стали говорить экземпляр класса. С таким количеством багов ничего смоделировать невозможно, но это мое мнение
lair
14.01.2017 18:31Меня не устраивает
Ну вот видите. Стоит вам дать ссылку, как вы немедленно ее игнорируете и переходите к тому, что лично вас не устраивает (не по ссылке, а вообще). Ну и какой смысл был просить ссылку?
наделение неживого возможностью что-то делать
А в этом тоже ООП виновато? Я думал, это мир таков.
подмена отношения тип-подтип на родитель- ребенок.
А это и вовсе что-то, что вы придумали. Нет, вы вольны придумывать себе что-то, что вас не устраивает, конечно.
а апофеозом стала путаница, когда вместо элемента класса стали говорить экземпляр класса
Не вижу никакой путаницы. Путаница возникает у тех, кто пытается одновременно использовать термины из нескольких областей знания, но кто же их заставляет это делать?
С таким количеством багов ничего смоделировать невозможно
Ну то есть программ не существует. Крутое мнение, да.
maxstroy
14.01.2017 18:39Вот мы и пришли к выводу, о котором я говорю постоянно: Кому-то ООП нравится, кому-то нет, у тех и других есть аргументы. Но спорить на эту тему бессмысленно. Кому-то нравится курица, кому-то утка
lair
14.01.2017 18:42Понимаете ли, в чем дело… есть разница между "мне не нравится Х" и "Х не способно". Вы постоянно заменяете первое на второе.
maxstroy
14.01.2017 18:50Лично мне не нравится, потому что не способно. Я не хочу видеть методы, привязанные к объектам. Для меня — это дикость. Для тех, кому это нормально, объяснить, почему это неверно, сложно. Была статья на эту тему, и вы отказались принять рассмотренные там аргументы. Вы отказались, а я согласен. Так что все ок. Кому-то кажется, что солнце светит, а кому-то известно, что солнце не является живым организмом и не может светить. Про то, откуда в наш язык пришли эти странные для нашего сегодняшнего мировосприятия вещи — из мистического сознания. Я об этом писал. И опять — игнор. Так что, я считаю, диспут закрыт
lair
14.01.2017 19:01Лично мне не нравится, потому что не способно.
Вот это "не способно" — это ваше ничем не подтвержденное утверждение.
Кому-то кажется, что солнце светит, а кому-то известно, что солнце не является живым организмом и не может светить.
Тем не менее, общеизвестен тот факт, что солнце светит. Ваши попытки утверждать, что это не так, выглядят, скажем так, странно.
Про то, откуда в наш язык пришли эти странные для нашего сегодняшнего мировосприятия вещи — из мистического сознания.
Раньше вы писали, что из мифологического (это не одно и то же). И нет, в мифологическом сознании это тоже не так.
Кстати, эти "странные" вещи странны лишь для вашего мировосприятия. Для мировосприятия обычного человека — включая филологов — ничего странного в этих вещах нет. Зато филологам очень странно, что трансформатор не может преобразовывать, но может быть участником. И вообще может.
Я об этом писал. И опять — игнор.
"Игнор" — это ваша реакция на аргументы к вашим постам о том, что солнце не может светить, хотя оно (и это очевидно) светит.
Вот я налил воду в кастрюлю, поставил кастрюлю на плиту, включил плиту. Вода закипела. Теперь докажите мне, что вода не может кипеть, хотя я своими глазами вижу, что она кипит, и любой находящийся на кухне человек согласен со мной в том, что она кипит.
BTW, нет никакой связи между "методы привязаны к объектам" и "солнце светит". Объект — это модель, и метод — это модель, и там могут быть любые соглашения, до тех пор, пока они приняты в модели.
evkochurov
14.01.2017 19:08+1Уважение к чужому мнению никак не вяжется с преподношением своего мнения в статьях, как единственно верного. Тут надо или продолжать диспут до признания одной из сторон поражения, или честно писать: «большинство со мной не согласно, но я считаю вот так». Вот тогда это будет уважением чужого мнения.
michael_vostrikov
14.01.2017 19:21+1Если бы вместо слова "class" в ООП использовалось слово "type", что-то бы принципиально изменилось?
Alew
14.01.2017 19:54Вот теперь стало совсем понятно, то что вы ставите в упрек отсутствие полного соответствия модели и реальности, на самом деле важный элемент для того чтобы ООП было успешным. С другой стороны таким образом вы любой методологии отказываете в абстракции — важнейшем элементе управления сложностью. Как вы себе представляете подход который будет требовать моделировать все вплоть до элементарных частиц и законов природы?
Alew
14.01.2017 20:44+1На самом деле не это хотел сказать. Любая модель это упрощение, ваша в то числе. И в любое упрощение можно ткнуть пальцем и сказать что тут оно не соответствует реальности. К примеру, я буду утверждать, что резьба болта это не отдельный объект и болт резьбу не имеет, он вообще ничего не имеет, в лучшем случае содержит молекулы но ни как не резьбу. Вопрос только в том где перестать придираться к модели. И ОО моделирование прошло большой путь в своем развитии, те элементы которые вам не очень нравятся на самом деле делают его пригодным к использованию.
maxstroy
15.01.2017 17:21-1Вы сказали очень интересный тезис — любая модель не соответствует реальности. Но реальность непознаваема, поэтому у нас нет никакого способа узнать, что это такое. Мы опираемся только на наши ощущения и моделируем только их. Поэтому не стоит говорить о моделировании реальности, а стоит говорить об описании наших ощущений. Для описания ощущений существует язык. Язык влияет на спектр наших ощущений, ощущения влияют на язык — это замкнутый круг. Я не моделирую мир и не призываю к его моделированию. Я был бы очень благодарен тем, кто сможет смоделировать наш способ излагать свои ощущения. Собственно, этому посвящена статья. Я пытаюсь сказать. что ООП совсем не годится для передачи наших ощущений. И что теория множеств, или, как меня поправили, теория предикатов, позволяет это. При этом использование формализма теории множеств позволяет избежать глупых ошибок, которые легко делаются программистами, которые опираются на ООП. Например, программисты называют процесс экземпляром процесса. И переучить их обратно на человеческий язык невозможно. А раз так, то они слишком далеки от нашего языка, чтобы моделировать что-либо.
napa3um
15.01.2017 17:36-1У вас солипсизм в терминальной стадии. Все шагают не в ногу, только вы в ногу. Чтобы выразить ощущения, способы мышления (а почему именно ваши?) или ещё какие торсионные поля нужно предварительно придумать задачу — а зачем выразить? Чтобы после того, как мы выразили, мы смогли бы проверить, хорошо ли у нас получилось (решили ли мы поставленную задачу, достигли ли цели). Программисты называют нечто экземпляром процесса потому, что это удобно в их задачах, в задачах моделирования прикладной области средствами вычислительной техники. И это конкретные объекты с конкретными свойствами из конкретной прикладной области, а не какие-то ссылки на Абсолютную Истину, существующую вне человеческих задач (существующую в вашем солипсистском сознании под ярлыком «процесс»).
maxstroy
15.01.2017 17:58Ни один программист пока не дал определение процесса, а также определение экземпляра. Если человек не может дать определение употребляемым им терминам, то говорить с ним бесполезно.
napa3um
15.01.2017 18:09Так а программисту-то от вас какая польза? С чего вы вообще взяли, что это он должен объяснять вам свои термины, а не вы ему? В интернете хватает определений процесса для разных задач и областей знаний, выбирайте сами задачу, в которой вы хотите опровергнуть какую-то формулировку процесса (с доказательством того, что задача стала решаться эффективнее и проще). Но вы же ничего не даёте полезного, ничего не улучшаете, вы просто пытаетесь онтологию из вашей головы (ваши собственные формализации того, как вы якобы мыслите) объявить Главным Стандартом (что нелепо не только потому, что этот стандарт ваш субъективный, а потому даже, что и среди своих субъективных вы его считаете статичным и абсолютным).
maxstroy
15.01.2017 18:17Пока никто не сможет дать строгое определение процесса, экземпляра и экземпляра этого процесса, ниша будет свободна и первый, кто даст определение, ее займет. Я просто дал определение тем терминам, которым никто еще не давал строгие определения. Покажите мне другие — буду благодарен. Только прошу, строгие, то есть, опирающиеся на аксиоматику, а не бла-бла-бла.
lair
15.01.2017 19:54Я просто дал определение тем терминам, которым никто еще не давал строгие определения.
(а) нет, не дали
(б) определения давали до вас
(ц) про границы применения термина помните?
Только прошу, строгие, то есть, опирающиеся на аксиоматику
А на какую аксиоматику опираются ваши определения?
michael_vostrikov
15.01.2017 19:16Ни один программист пока не дал определение процесса, а также определение экземпляра.
Ну здрасьте-приехали.
Экземпляр класса (англ. instance) — это описание конкретного объекта в памяти. Класс описывает свойства и методы, которые будут доступны у объекта, построенного по описанию, заложенному в классе. Экземпляры используются для представления (моделирования) конкретных сущностей реального мира.
Инстанцирование (англ. instantiation) — создание экземпляра класса.
(слово "класс" заменяйте на слово "тип", а не на слово "множество", ибо такая терминология)
Множественные экземпляры (multiple instances) действия показывают, что одно действие выполняется многократно, по одному разу для каждого объекта. Например, для каждого объекта в заказе клиента выполняется один экземпляр действия. Экземпляры действия могут выполняться параллельно или последовательно.
A Process can be executed or performed many times, but each time is expected to follow the steps laid out in the Process model. For example, the Process in Figure 10.1 will occur every Friday, but each instance is expected to perform Task “Receive Issue List”, then Task “Review Issue List”, and so on, as specified in the model.
A Process is instantiated when one of its Start Event soccurs. Each occurrence of a Start Event creates a new Process instance.
https://habrahabr.ru/post/319442/#comment_10012614
https://habrahabr.ru/post/319032/#comment_10001142
https://habrahabr.ru/post/319032/#comment_10000466
https://habrahabr.ru/post/319032/#comment_10000372
Это ссылки только на мои комменты, а вам на ваши ошибки указывали многие.
maxstroy
15.01.2017 19:25Да, вы говорите об объектах, создаваемых в памяти компьютера, а автор тезиса говорит о моделировании предметной области, отличной от моделирования кода. То, что эти термины значат в программировании, мне известно, но либо кодом они и ограничены, либо надо дать определения этим терминам в предметной области, отличной от кода. То, что объекты в памяти могут моделировать объекты предметной области, я согласен, но не всегда. Есть случаи, когда создаются объекты, не имеющие отражения в предметной области и пример таким сущностям приведен в упомянутой мной книге с критикой ООП. А, если и создаются объекты, которые моделируют предметную область, то им должны быть даны имена и определения. Вы попытались дать определение такого понятия как процесс из предметной области и тут же с первого взгляда в этом определении ошибка. Действия не могут выполняться многократно. Это из области фантастики, когда мы можем возвращаться назад во времени. Каждое действие уникально и неповторимо. Могут быть лишь похожие друг на друга действия. Поэтому экземпляр процесса не моделирует экземпляр действия, но моделирует действие. Вот с этим я уже соглашусь, но тогда надо отмаппить термины более корректно.
michael_vostrikov
15.01.2017 19:50+1Да, вы говорите об объектах, создаваемых в памяти компьютера
Если создавать объекты в памяти компьютера, соответствующие объектам некоторой пространственно-временной области, то получится модель этой области. И BPMN это все-таки не про компьютеры.
отличной от моделирования кода
При написании программы код не моделируется. Он пишется, то есть создается. В коде задана модель предметной области и некоторых технических объектов, необходимых для работоспособности программы.
Действия не могут выполняться многократно.
Вы снова путаете тип и экземпляр. Причем упорно не желаете это признавать.
Поэтому экземпляр процесса не моделирует экземпляр действия, но моделирует действие.
Экземпляр не может ничего моделировать. Экземпляр это уже конкретное воплощение. И вообще, он же не живое существо.
maxstroy
15.01.2017 20:22Я бы поверил, что BPMN не про код, если бы вместо термина экземпляр действия он бы употреблял термин действие. Вы где-то от мастера участка слышали: пойди и выполни экземпляр точения детали? он говорит: пойди и выточи деталь. Но только от программистов я слышу о выполнении экземпляра процесса. В быту мы говорим об исполнении процесса. А другой процесс — это уже другой процесс, хоть и похожий. Программисты же говорят вместо процесса — экземпляр процесса.
napa3um
15.01.2017 20:43Т.е., программист — не авторитет, а мастер участка — авторитет? Ну, допустим, задачи мастера участка вам ближе, чем задачи программистов. Но зачем из этого делать столь глобальные выводы о несостоятельности терминологии программистов? Их терминология не о чистой философии, их терминология о программировании, прикладная. Т.е., ваши процессы, концепты, действия и прочие философские материи программист «упакует» в соответствующие сущности языка программирования (например, в классы C++, прототипы JS, процессы ОС), ибо это практическая онтология, онтология его инструментов описания вычислений на кремниевом вычислителе. И термины из философии и программирования если совпадут побуквенно, то останутся всего лишь омонимами, а не противоречием двух областей знаний.
maxstroy
15.01.2017 21:29мы, аналитики моделируем мир мастера участка, берем у него термины, выработанные столетиями, и формулируем требования к ИС, а не учим его птичьему языку
napa3um
15.01.2017 21:47Вот и программистов не пытайтесь учить своему птичьему, очень может оказаться, что он им совсем не нужен. Учитесь ваш птичий язык переводить в программистский, именно в этом ваша задача как аналитика и состоит — в переводе прикладной проблематики мастера участка в одну из формальных систем программистов, разрабатывающих систему для автоматизации его работы. И лучше откажитесь от веры в существование Абсолютной Универсальной Онтологии, за десятки тысяч лет люди пока не придумали ничего лучше плюрализма, релятивизма и прагматизма.
lair
15.01.2017 21:19А еще мастер участка говорит "резец режет", хотя резец, очевидно, неодушевленный, и не может резать. Но в одном случае вам его словоупотребление авторитетно, а в другом — нет.
maxstroy
14.01.2017 22:03не надо моделировать атомы. Мы же не моделируем положение ротора двигателя, если того не требует модель
Alew
15.01.2017 16:39Я примерно такого ответа и ожидал, поэтому сформулировал вопрос по другому, Но вы почему то предпочли уточненный вопрос не заметить :(
Продолжать смысла не вижу.
Alew
14.01.2017 19:30Понятно, но смотрите какое следствие из вашего мнения возникает, я полностью согласен с Эвансом по поводу важности соответствия модели и кода, я это видел своими глазами. Если вы отрицаете ОО моделирование то и пригодность ООП надо ставить под сомнение.
sand14
14.01.2017 14:23+1ООП перепутало классы и типы. То, что называется типами у Аристотеля, в ООП назвали классами
Есть ОО-языки, где путаницы с терминами в части названия типов данных нет.
Например, современный Visual Basic — являющийся по сути, тем же C#, но с синтаксисом Basic:
Data Type Summary (Visual Basic)
Любой тип данных — это тип данных.
И от того, что он является ссылочным (экземпляры размещаются в куче) или его экземпляры размещаются на стеке, он не перестает быть типом данных, и не превращается в класс или структуру.
Если в описании увидите слово class — из контекста сразу будет видно, что это проведение соответствия между ссылочным типом VB (reference data type) и ссылочным типом исполняющей среды (там это по-прежнему называется "класс").
sand14
14.01.2017 14:35+1а то, что математики называют классами, в ООП не имеет названия
Скорее, есть определенная недосказанность.
Если то, что математики называют классами это множество, то множества в ОО-нужно соответственно моделировать, создавая тип данных, описывающий множество.
В общем случае алгоритм создания типа данных "Множество":
- Создается тип данных (в терминах большинства языков — класс) "Множество" с добавлением необходимых атрибутов и операций для этого множества (в зависимости от предметной области).
- Тип данных "Множество" должен инкапсулировать в себе данные — поле, указывающее непосредственно на множество объектов.
В качестве типа данных для такого поля лучше выбрать один из многочисленных типов данных для работы с множествами, которые есть во всех современных платформах — хеш-таблицы (ближе всего к понятию "множество"), словари, многочисленные виды списков ("просто" списоки, связные списки, etc), очереди FIFI/LIFO, и даже обычные массивы.
Gryphon88
14.01.2017 18:56+1Извините, но я никак не могу понять предмет обсуждения статьи. Автор пытается обосновать некоторую метамодель для описания мира кодом так, чтобы в программировании явно не использовались абстракции, описывающие «железо», а только те, что описывают предметную область? Тогда я полностью согласен с napa3um
Ментальная ловушка «хочу формализовать всё, что возможно во вселенной, даже чего мы пока не знаем» приводит к попыткам формализовать процесс формализации (к попыткам моделировать мышление человека), что получается пока не очень
Пытаясь в очередной раз вникнуть в ООП, прочёл книгу «Software Factories: Assembling Applications with Patterns, Frameworks, Models & Tools», где во вступительных главах описываются слои абстракции от предметной области к железу, и почему UML не позволит аналитикам с менеджерами создавать нормальный код без программистов.
Или Вы пытаетесь создать инструмент для универсальной модели бизнеса? Так получается тоже нечто странное, плодятся божественные объекты, менеджеры менеджеров и фабрики фабрик. Люди пытаются всё распихать по объектам-существительным, и отказываются выносить действия в отдельные сущности.
Если удастся создать некоторый единый обобщенный подход к описанию мира, то будет отлично, но поскольку на естесственных языках такого до сих пор не случилось, я не верю, что такое в принципе возможно, если не использоватьмассовые расстрелыединообразное высшее образованиеmaxstroy
14.01.2017 22:07я пытаюсь, делаю попытку разобраться и поставить задачу к программистам так, чтобы они придумали язык более подходящий для аналитиков, а не для программистов. Пока же беда — аналитики пользуются UML и это калечит их разум
lair
14.01.2017 22:56(а) это не задача программистов
(б) кому не хочется калечиться об UML, могут его не использовать
(ц) есть прекрасная книга Вигерса о том, как писать требования, и которая UML только упоминает мимоходом
А вообще, конечно, "подходящий для аналитиков язык" давно придумали. И это, в большей части случаев, их родной язык (оставшиеся случаи — это ситуации, когда надо писать, скажем, на общем языке команды, английском, например). Ну да, этот язык формализуется и ограничивается для уменьшения неоднозначностей, но он уже есть. И это работает.
maxstroy
15.01.2017 17:24нет, не работает, потому что, когда я слышу термин «экземпляр этого процесса», хочется спросить определение процесса, определение экземпляра, а эти определения мне еще ни один программист так и не дал. В русском языке нет термина экземпляр этого процесса. Есть термин процесс, типовой процесс, класс процессов и так далее. Но только программисты смогли родить этот замысловатый термин.
lair
15.01.2017 18:14-1А когда я слышу ваши "термины", мне тоже много чего хочется спросить — и я спрашиваю, — но вы тоже не даете определений (начиная с определения "ООП"). Ну и в чем разница?
И вообще, в русском языке нет термина "процесс", есть только слово "процесс". Термином оно становится, оказавшись в конкретной системе.
msts2017
19.01.2017 00:15В общем, начало неудачное, ООП не имеет отношение ни к Аристотелю ни к математике ни к моделированию предметной области, ООП это синтаксический сахар поверх процедурного программирования, обобщение различных подходов в программировании, и типы и классы в нем совершенно на своих местах (ну в зависимости от языка), его можно использовать для моделирования, но не нужно, предметную область сначала переваривают а потом результат моделируют и это слабо похоже на исходный предмет.
lair
19.01.2017 00:45предметную область сначала переваривают а потом результат моделируют и это слабо похоже на исходный предмет.
Тем не менее, получившийся результат все еще является моделью предметной области. А то, что модель не похожа на то, по чему она строилась, так это (в зависимости от цели моделирования) нормально...
msts2017
19.01.2017 09:25даже не знаю как ответить, вроде написал все понятно, ладно повторю — зачастую «ООП» понятие не имеет о предметной области, в исходниках нету классов покупатель и товар, а есть рекорсеты с полями и правила отношений между ними ну и формы для ввода данных, это и есть моделирование производной от предметной области, конечно можно сделать такие классы но необязательно, а так как речь идет о времени появления ООП то и очень трудоемко, это сейчас в скриптовых языках или в языках с развитой рефлексией можно легко генерить датаобъекты, а 40 лет (или сколько там) назад было не все так однозначно.
lair
19.01.2017 11:52зачастую «ООП» понятие не имеет о предметной области, в исходниках нету классов покупатель и товар, а есть рекорсеты с полями и правила отношений между ними
Эмм. Во-первых, то, что вы описываете (рекордсеты и отношения) — это не то ООП, которое описывает автор поста (описанные им недостатки просто не совмещаются с вашим описанием).
Во-вторых, что важнее, это все равно модель предметной области.
Давайте на минуту отойдем от ООП и посмотрим на реляционную базу данных. В ней как раз есть наборы записей (с колонками-атрибутами) и отношения между записями. Модель ли это предметной области? Конечно (более того, я видел много аналитиков, которые других моделей и не умели строить). Просто это не объектно-ориентированная модель (в обычном понимании объектно-ориентированности), ну так никто же и не требовал.
А теперь давайте вернемся в код из вашего примера. В нем та же самая модель, просто реализованная не средствами реляционной БД, а средствами ОО-языка. И что? Модель от этого изменилась? Да нет.
Так что, хотя это и контринтуитивно, но объектно-ориентированная программа может содержать не-объектно-ориентированную модель предметной области.
Ну и в-третьих, я описанного вами подхода к программированию не видел лет восемь, если не больше. У него есть недостатки, они описаны больше десяти лет назад (это только те книги, которые я лично читал, а скорее всего — и давнее), и люди перестают им пользоваться.
а так как речь идет о времени появления ООП
Э, где? Я думал, речь идет о текущем состоянии дел.
(не говоря уже о том, что и "во время появления" ситуация тоже была… другой)
msts2017
19.01.2017 12:34перечитайте начало, Автор именно рассматривает ООП на уровне «основных понятий» из вики, т.е. «вообще» а не современное состояние\подход к применению, что позиционирует во времени в прошлое (и это неудивительно ведь он не программист), Автор именно думает (ну или не знаю почему) что ООП описывает предметную область непосредственно, задается вопросом что везет, и у него это метод, предлагает отделить метод от объекта, ирония в том что программист сделает объект «транспортное средство», у него будет список объектов (условно) «действия», сделает объект «везти» (ну или -«транспортировка», наследник «действия») с методом «начать» (ну или как там), да возможно он сделает метод «везти» (у «транспортное средство») но внутри все равно будет объект, т.е. произойдет тоже что жаждет Автор, таким образом, его представления не соответствуют действительности, что собственно я назвал — неудачным началом.
Рекордсеты я привел в пример как производная отличается непосредственной предметной области.lair
19.01.2017 12:37перечитайте начало, Автор именно рассматривает ООП на уровне «основных понятий» из вики,
Автор вообще отказывается сказать, что именно он называет ООП. Я склонен думать, что это обособленные одиночные пикеты, если честно.
Рекордсеты я привел в пример как производная отличается непосредственной предметной области.
Любая модель предметной области отличается от предметной области, так что я не понимаю, на основании чего вы утверждаете, что ООП не нужно использовать для моделирования предметной области.
msts2017
19.01.2017 12:50А, я понял что вас зацепило, я там просто пропустил слово _непосредственного_ моделирования, ожидая что это и так будет понятно из контекста, после переваривают, вы не так поняли, так что все нормально, моделировать, в вашем понимании, нужно :)
lair
19.01.2017 12:51А что такое "непосредственное моделирование"?
msts2017
19.01.2017 13:01перенос предметной области в код как есть, без каких либо обобщений\изменений и т.п.
например у Автора действия над объектом жестко транслируются в методы класса (смутно припоминаю что в теории (не ООП) так принято, хотя могу врать)lair
19.01.2017 13:04перенос предметной области в код как есть, без каких либо обобщений\изменений
Это в общем случае невозможно (вне зависимости от выбранной парадигмы разработки и моделирования); какой смысл это вообще обсуждать и упоминать?
msts2017
19.01.2017 13:07опять двадцать пять, это делает Автор в начале и сетует что криво выходит.
lair
19.01.2017 13:10Не "Автор", а вы пишете, что "ООП можно использовать для моделирования, но не нужно". Так вот, для "непосредственного моделирования" (в вашем понимании), ООП использовать нельзя, потому что эта задача не имеет решения.
(автор, кстати, утверждает, что он пишет не про код, а про моделирование предметных областей, а код тут ну вообще ни при чем)
maxstroy
19.01.2017 10:29ООП сделало небольшую подтасовку фактов. Сначала ввело свои собственные термины, но из слов, похожих на те, которыми пользуются предметники. В итоге смысл слов был изменен. Затем они пришли к предметникам с этими словами, которые очень похожи на обычные слова, но имеют совсем другой смысл. Предметники слушают ООПэшников, но понять не могут, что они воркуют. В итоге либо посылают их в одно место, либо пытаются приспособиться к их птичьему языку. Я просто строю переводную таблицу смыслов. Если ООПэшник сказал «экземпляр процесса», то на русском языке — это план-график работ. Если он сказал «процесс», то это на русском языке — регламент. Такая табличка не помешает при общении с программистами.
Ну и неплохо было бы помнить программистам, что код они пишут для машины и код — это описание процессов, происходящих внутри ВМ, а не в предметной области, так что зря они себя тешат иллюзией о том, что они моделируют предметную область.msts2017
19.01.2017 10:55-1подтасовка фактов — это когда делают что-то специально, а тут просто взяли что рядом лежало, и вообще претензии совершенно необоснованны, различия в терминах в разных областях совершенно рядовое явление, а кто вам сказал что у предметников правильная терминология? может не к тем предметникам ходят? может надо поменять? хехе, да, причем здесь терминология математиков? как раз для математиков есть функциональные языки и там своя вполне математически соответствующая терминология, да и «подтасовку» надо еще проверить…
То что ООПешников не могут понять предметники это явно не их проблема, это проблема организации работ, т.е. рядовая ситуация, ООПешники как раз прекрасно понимают птичий язык предметников, и если все таки это переходит в ряд серьезных проблем то по вине предметников не желающих сотрудничать, как-то так.
msts2017
19.01.2017 11:32-1Ну и неплохо было бы помнить программистам, что код они пишут для машины и код — это описание процессов, происходящих внутри ВМ, а не в предметной области, так что зря они себя тешат иллюзией о том, что они моделируют предметную область.
:), Вы так написали как будто программисты спят и видят как они моделируют предметную область, это не так, как раз наоборот, они мечтают максимально отдалится от нее, создать максимально универсальные решения, что-то вроде «Теории Всего» программирования и отдать полученные инструменты предметникам, дабы не слушать их птичий язык.
lair
19.01.2017 11:59-1Сначала ввело свои собственные термины, но из слов, похожих на те, которыми пользуются предметники
С равным успехом про предметников можно сказать, что они ввели собственные термины из слов, похожих на те, которыми пользуются обычные люди. Профессиональный жаргон, вот это все.
Если ООПэшник сказал «экземпляр процесса», то на русском языке — это план-график работ. Если он сказал «процесс», то это на русском языке — регламент.
Не "на русском", а "на вашем". Вы почему-то считаете, что выбранная вами терминология корректна и универсальна, хотя вам неоднократно показывали, что это не так.
Ну и неплохо было бы помнить программистам, что код они пишут для машины и код — это описание процессов, происходящих внутри ВМ, а не в предметной области
Код — не описание процессов, происходящих внутри машины (как уже неоднократно говорилось, вы не программист, и не понимаете в программировании, и это очередная иллюстрация).
зря они себя тешат иллюзией о том, что они моделируют предметную область.
Угу. Попробуйте формально доказать утверждение "ни одна программа не содержит модели предметной области".
lair
Давайте, пожалуй, начнем с простого вопроса: что именно вы понимаете под ООП?
maxstroy
Я не понимаю, что такое ООП в применении к моделированию предметных областей. Я нигде не встречал определения этого понятия. Но ООП как подход к написанию кода, известен, ему даны определения и проч. Но меня, как аналитика смущает.что программисты путают написание кода и моделирование предметных областей. Понятно, что код имеет отношение к предметной области, но какое — нам неведомо, потому что никто этого не знает и нигде нет этому описания.
napa3um
Похоже, что вы собственную некомпетенцию (в определённых областях знаний) интерпретируете как «у них у всех неправильные словари, они не способны мне передать знания напрямую, кратким текстом».
Вы сначала найдите это чужое описание, поймите его, поймите причины его возникновения и существования, а затем уже только начинайте критиковать (с предложением вариантов, улучшающих решение конкретных задач). Пока вы критикуете только собственное незнание терминов.
maxstroy
Объясните мне тогда смысл термина экземпляр этого процесса? Программисты часто употребляют этот термин, но никто пока не дал внятного определения термину процесс, экземпляр и как так получилось, что у процесса может быть его собственные экземпляры? Нигде, кроме как от программистов я не слышал этих терминов.
napa3um
Попробуйте погуглить сами варианты определений, или спросите у тех программистов, от которых вы это слышали, на какое определение они ссылаются. Не нужно обременять социальную группу «программисты» коллективным долгом вам что-то объяснить. Это ваша проблема, а не проблема «программистов», и вы, вроде как, заинтересованы в её решении, а не программисты.
Можете начать с https://ru.wikipedia.org/wiki/Процесс_(информатика).
lair
Я вот не употребляю. И нигде, кроме как в дискуссиях с вами, его не слышал.
maxstroy
Ниже в обсуждении: https://habrahabr.ru/post/319442/#comment_10013912
lair
Так это и есть дискуссия с вами.
maxstroy
Ну или в стандартах OMG, да? Например, BPMN является частью UML.
lair
Ничего не могу сказать поэтому поводу, я не пользуюсь стандартами OMG.
Ээээ, правда?
Прямо вот главную страницу открываем и читаем:
Ладно, возьмем спеку — так там про это тоже ни слова.
(не то что бы это было важно для обсуждаемого вопроса, но просто показательно)
Danov
В en wiki есть такая картинка с подписью:
History of object-oriented methods and notation
BPMN явно в стандарт UML не входит, BPMN диаграммы, условно, можно разложить на UML.
lair
… что как бы подтверждает мое высказывание.
Danov
maxstroy
Главное — не важно, входит, или не входит. Мы говорим совсем о разном. Я говорю о моделировании предметных областей, lair же думает, что моделируя код, он моделирует предметную область. Может да, а может нет — не важно, потому что для решаемых нами задач — это не важно. Модели, которые мы строим, можно воплотить на любом языке, в любой парадигме и без привязки к ООП. Поэтому бессмысленно обсуждать ограничения ООП, если нам оно не нужно. Я лишь говорю об опасности моделирования предметных областей, имея для этого один очень частный и довольно специфический по своим качествам подход — ООП,
lair
Спасибо, но нет. Я так не думаю — и нигде такого не писал, кстати.
И я снова спрошу: кто эти "вы", которые решают какие-то задачи, и какие конкретно задачи "вы" решаете?
… но вы это постоянно зачем-то делаете.
maxstroy
Обсуждение ограничений ООП в качестве методологии моделирования предметных областей — очень полезная тренировка для аналитиков. Изучение отрицательного опыта — крайне полезная штука.
lair
vs
maxstroy
Когда я изучал BPMN права на него были куплены (переданы и проч.., я не знаю) OMG с целью заменить нотацию «плавательные дорожки». Чем закончилось, не знаю, но что «плавательные дорожки», что BPMN — суть об одном и том же. Поэтому выяснять мелочи бессмысленно. И в той и в другой нотации — серьезные логические ошибки, о которых я рассказывал ранее, и расскажу далее.
Danov
В поддержку:
https://en.wikipedia.org/wiki/Object_Management_Group
http://www.omg.org/spec/BPMN/2.0/
http://www.omg.org/spec/BPMN/2.0.2/
michael_vostrikov
Там нет нигде выражения "экземпляр этого процесса". Слово "Process" там используется как название типа сущностей. "Экземпляр определенного типа" это корректное выражение.
maxstroy
То есть процесс «забить гвоздь» на самом деле тип процессов «Забить гвоздь» и BPMN не моделирует процессы, а моделирует типы процессов?
michael_vostrikov
Я вам уже много чего сказал про типы и экземпляры. Лучше вы мне скажите.
Вот есть некоторый список действий "взять молоток, взять гвоздь, стучать по шляпке гвоздя пока он не зайдет в дерево на необходимую глубину". Я беру список, беру конкретный гвоздь и молоток, выполняю все действия следуя списку. Потом беру другой гвоздь и снова повторяю все действия.
Что в вашей терминологии здесь является процессом, что из них соответствует термину "забить гвоздь", и как называется другое понятие.
maxstroy
Итак, вы берете гвоздь и забиваете его, совершая при этом операцию «забить гвоздь» Другой чел на другом конце света делает то же самое, совершая операцию «забить гвоздь. Но выражение „то же самое“ не значит, что это та же операция, а означает — похожая операция. В русском языке „то же самое“ имеет два смысла: тот же объект и похожий объект. Программисты просто путают эти два смысла. Обе эти операции похожи друг на друга только в сознании субъекта. Потому что другой субъект может сказать, что ни хрена они не похожи. Итак, мы спрашиваем у того субъекта, что сказал, что эти операции похожи: Почему они похожи? Он отвечает: потому что их модели одинаковые. Мы смотрим и видим, что модели этих двух операций с его точки зрения — одинаковые. Тогда для этих двух моделей мы строим одну модель моделей. И каждый раз, когда встречаем модель операции, которая описывается этой моделью моделей, мы говорим, что встречаем похожую операцию. Модель моделей — это тип операций. Я не сказал про последовательность, потому что это следующий шаг, сначала давайте обсудим эту часть.
napa3um
Аналогия и эквивалентность в любых языках имеет явные или неявные границы применимости (границы задачи), критерии сравнения, при которых делается заключение об аналогичности или эквивалентности. В контексте физической задачи о взвешивании, например, две монетки достоинством в один рубль — это два отдельных, но аналогичных (по весу) объекта, а в контексте экономической задачи эти объекты уже могут быть полностью эквивалентными (являются одной и той же стоимостью). Русский язык совсем не мешает говорить об этом.
maxstroy
Два объекта имеют одинаковую стоимость, но не равны. То, что их стоимость равна, не значит, что они равны. Это все равно что сказать, будто все объекты одинаковой высоты, — один объект. Возможно, что для решения конкретной задачи нам все равно, какой из этих объектов использовать.
napa3um
В экономической задаче этих двух объектов не будет, будет объект ЛицевойСчёт, в котором запись единички никак не будет указывать на одну из конкретных моделей монеты. Просто потому, что они там не нужны, непринципиальны.
> Возможно, что для решения конкретной задачи нам все равно, какой из этих объектов использовать.
Возможно, что вопрос выбора объекта даже не ставится. Т.е., монеток-объектов в экономической задаче просто нет.
lair
Это зависит от решаемой задачи.
(кстати, прекрасно описано у все того же Эванса, в рассуждениях о "сущностях" и "значениях")
maxstroy
То есть два разных объекта, имеющие одинаковую стоимость, могут быть одним объектом??
napa3um
БИНГО! Дейсвтительно, два объекта, выделенных по критериям одной задачи, в другой задаче могут быть неотличимыми, быть одним и тем же объектом или вообще не иметь смысла.
maxstroy
неотличимы, то есть у нас нет возможности их отличить? А если есть? Например, операция, совершенная вчера отличается от операции, совершенной завтра тем, что у них время разное, участники разные и тому подобное и мы знаем, что они разные. И для бизнеса важно, что они разные, потому что во второй операции был допущен брак, который вылез через полгода и только благодаря различению этих операций, мы смогли вычислить того бракодела, который его допустил. Это задача, которую обязана решать любая воркфло система.
napa3um
Всё верно, для бизнес-задачи объекты, выделенные по критериям другой бизнес-задачи, могут быть различимы, могут быть неразличимы, а могут вообще не существовать. Не очень понятно, чему и в чём вы возразили.
lair
Да. Если уж совсем точно следовать терминологии DDD, то оба они будут объектами-значениями, для которых нет понятия "один и тот же", потому что нет понятия "идентичность", есть только понятие "равенство".
Типичный пример, кстати, это "а давайте посчитаем количество употреблений каждого слова в тексте". В тексте "объект покупки и объект продажи" есть два слова "объект", которые, с точки зрения модели, построенной для задачи, считаются одним словом "объект", употребленным два раза.
napa3um
Ещё хорошим примером, наверное, будет сравнение суммового и партионного учёта.
michael_vostrikov
Ответьте на вопрос, пожалуйста. И не вводите новых терминов наподобие "операция", вы говорили про процессы.
maxstroy
Процесс — это множество операций и связей между ними, как правило, темпоральных. Не дав определение операции, нельзя определить процесс
michael_vostrikov
Какое отношение это имеет к вопросу? Там не надо определять, из чего состоит процесс. Просто скажите, как вы называете эти сущности.
maxstroy
Инструкция — это типовой сценарий (модель процессов, типовой процесс, регламент), последовательность ваших действий — это сценарий, процесс.
michael_vostrikov
Понятие "забить гвоздь" из вашего коммента это что? Инструкция или последовательность?
michael_vostrikov
Так вот чтобы не путаться и не уточнять каждый раз, типовой это сценарий или нет (кстати, какой тогда?), и используют термин "экземпляр". А так как конкретный выполняемый экземпляр мало кого интересует (пришло миллион пользователей, выполнилось миллион процессов отдачи веб-страницы), то обычно рассматривают описание процесса (инструкция в вашем понимании), которое и называют для краткости просто "процесс".
Фразу "экземпляр этого процесса" обычно никто не использует, я просто предположил, что она могла бы означать, если вы услышали ее от кого-то из ваших программистов.
maxstroy
Нет, чтобы не путаться, стул называют стулом, а чертеж, по которому сделали этот стул называют чертежом. Процесс — это процесс, а регламент — это чертеж процесса. И никто не путает процесс и его чертеж. И только у программистов я наблюдаю, как модель называют тем же именем, что и объект, а объект — экземпляром чертежа)).
lair
Ну это банально не так.
"Процесс приема заявок состоит из" — имеется в виду (в ваших терминах) "регламент процесса приема заявок состоит из".
"В процессе приема заявок создается описание заявки" — имеется в виду, что каждый раз, когда принимают заявку, создается описание заявки.
"Вчера, в процессе приема заявок от Х, было создано описание заявки Y" — имеется в виду конкретная ситуация.
Повторюсь, в обыденной речи людям свойственно заменять общее и частное. "Никто не путает" только потому, что эта информация восстанавливается из контекста разговора.
michael_vostrikov
Нет. Понятие "стул" (или "слон", "сосна", "забить гвоздь") обозначает некоторые общие свойства. И это не то же самое, что "чертеж стула". Спросите у двух людей, как они представляют себе стул, какой у него цвет? Вряд ли они вам опишут один и тот же конкретный стул.
А когда имеют в виду конкретный объект, говорят "вот этот стул", "вон та сосна". Обычно это понятно из контекста ("стул скрипит" = "этот стул скрипит", "собака друг человека" = "животные типа 'собака' друзья человека"). А если непонятно, люди задают уточняющие вопросы ("твоя собака или вообще?"). Поскольку компьютер или модель на бумаге понимать контекст не умеют, то надо использовать более точные термины — например, тип и экземпляр.
maxstroy
Есть разница между объектом, любым объектом данного класса и моделью этих объектов — типом. Когда чел говорит собака, он может иметь ввиду конкретную собаку артикль the, любую собаку — артикль a, но никогда не тип собаки.
lair
Вот для "обычного человека" нет разницы между "любая собака" и "тип собаки". Ну не нужно ему в обыденной жизни это разделение.
michael_vostrikov
Спросите у двух людей, что такое "a chair". Вряд ли они вам опишут один и тот же конкретный "the chair", но в их описании будут некоторые общие свойства. Общие свойства — это тип.
lair
Кстати, если пойти в любой мебельный магазин, позиция "стул Х" будет обозначать тип стульев, а не конкретный стул.
maxstroy
Стул Икс будет означать любой стул из множества однотипных, а не тип стульев. В английском — артикль a означает любой объект данного типа, а не тип объектов
lair
Эти понятия, как я уже писал выше, в обыденном сознании взаимозаменимы. Причем взамозаменимы в понимании "тип стульев — это такая [...], характеристики которой применимы ко всем стульям этого типа".
Кстати, нет. Не "любой", а "неопределенный".
maxstroy
то, что в миру называется процесс, у программистов называется — экземпляр процесса. То, что в миру называется регламентом процессов, у программистов называется — процесс.
lair
Вы никогда "в миру" не слышали фразы "процесс регистрации документа состоит из..."?
maxstroy
Я слышал: регламент регистрации документов. И регламент — это модель тех последовательностей операций, которые будут совершать сотрудники. Один регламент — много последовательностей.
lair
То есть вы правда никогда не слышали приведенной мной фразы?
maxstroy
Я слышал эту фразу много раз, но каждый раз спрашивал: что вы имеете ввиду под термином процесс? Я насчитал более 30-ти разных смыслов этого термина и потому для меня эта фраза без определения понятия процесс выглядит бессмысленной. А в своей конторе я вообще запретил это слово к употреблению как слово-паразит
lair
Ну так зачем же вы теперь утверждаете, что "в миру процесс — это" и подсовываете что-то конкретное? Я вот больше одного раза слышал приведенную фразу, и каждый раз в ней имелся в виду "типовой процесс".
(а "регламентом процесса" у тех же людей называлась еще более третья, отдельная сущность, со своими развлечениями)
Это к тому, что людям вообще свойственно в (обыденной) речи заменять "тип" и "экземпляр" — как раз по метонимическому переносу "частное-общее" (точнее говоря, по синекдохе, но не важно). И те люди, которым по каким-то причинам надо отделять одно, от другого, придумывают разные способы борьбы. Кто-то — слово "instance". Кто-то — слово "тип". Кто-то — слово "прототип". И так далее, далее, далее. Нет никаких оснований говорить, что один способ правильнее другого.
maxstroy
Хорошо, много слов, но мало толку. Сейчас я дал определение операции. Строгое, заметим. В следующий раз я дам определение термина сценарий. И термин процесс я не буду употреблять, как ругательное слово-паразит. Будет желание, предлагайте определения. Но пока их нет, увы
lair
А не дали вы никакого определения операции, кстати. И уж тем более — строгого. Хуже того, для всех используемых вами терминов вы не определили границу применимости.
lair
… но продолжаете утверждать, что оно не может того и того. Как это вообще сочетается — вы что-то утверждаете о том, о чем — вы же — говорите, что не понимаете?
А программисты не путают. Может это вы что-то путаете?
Ну так вы почитайте того же Эванса, и вам станет "ведомо". Понимаете вот эти "мы", которым неведомо — это не мы, это вы. Вам неведомо. Но вы же не программист, почему вам вообще должно быть это понятно?