Pull to refresh

Comments 222

Давайте, пожалуй, начнем с простого вопроса: что именно вы понимаете под ООП?

Я не понимаю, что такое ООП в применении к моделированию предметных областей. Я нигде не встречал определения этого понятия. Но ООП как подход к написанию кода, известен, ему даны определения и проч. Но меня, как аналитика смущает.что программисты путают написание кода и моделирование предметных областей. Понятно, что код имеет отношение к предметной области, но какое — нам неведомо, потому что никто этого не знает и нигде нет этому описания.
Похоже, что вы собственную некомпетенцию (в определённых областях знаний) интерпретируете как «у них у всех неправильные словари, они не способны мне передать знания напрямую, кратким текстом».

Вы сначала найдите это чужое описание, поймите его, поймите причины его возникновения и существования, а затем уже только начинайте критиковать (с предложением вариантов, улучшающих решение конкретных задач). Пока вы критикуете только собственное незнание терминов.
Объясните мне тогда смысл термина экземпляр этого процесса? Программисты часто употребляют этот термин, но никто пока не дал внятного определения термину процесс, экземпляр и как так получилось, что у процесса может быть его собственные экземпляры? Нигде, кроме как от программистов я не слышал этих терминов.
Попробуйте погуглить сами варианты определений, или спросите у тех программистов, от которых вы это слышали, на какое определение они ссылаются. Не нужно обременять социальную группу «программисты» коллективным долгом вам что-то объяснить. Это ваша проблема, а не проблема «программистов», и вы, вроде как, заинтересованы в её решении, а не программисты.

Можете начать с https://ru.wikipedia.org/wiki/Процесс_(информатика).
Программисты часто употребляют этот термин ["экземпляр этого процесса"]

Я вот не употребляю. И нигде, кроме как в дискуссиях с вами, его не слышал.

Ниже в обсуждении: https://habrahabr.ru/post/319442/#comment_10013912

Так это и есть дискуссия с вами.

Ну или в стандартах OMG, да? Например, BPMN является частью UML.
Ну или в стандартах OMG, да?

Ничего не могу сказать поэтому поводу, я не пользуюсь стандартами OMG.


Например, BPMN является частью UML.

Ээээ, правда?


Прямо вот главную страницу открываем и читаем:


The unified modelling language (UML) takes an object-oriented approach to the modeling of applications, while BPMN takes a process-oriented approach to modelling of systems. Where BPMN has a focus on business processes, the UML has a focus on software design and therefore the two are not competing notations but are different views on systems. The BPMN and the UML are compatible with each other.

Ладно, возьмем спеку — так там про это тоже ни слова.


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

В en wiki есть такая картинка с подписью:
image
History of object-oriented methods and notation

BPMN явно в стандарт UML не входит, BPMN диаграммы, условно, можно разложить на UML.

… что как бы подтверждает мое высказывание.

Главное — не важно, входит, или не входит. Мы говорим совсем о разном. Я говорю о моделировании предметных областей, lair же думает, что моделируя код, он моделирует предметную область. Может да, а может нет — не важно, потому что для решаемых нами задач — это не важно. Модели, которые мы строим, можно воплотить на любом языке, в любой парадигме и без привязки к ООП. Поэтому бессмысленно обсуждать ограничения ООП, если нам оно не нужно. Я лишь говорю об опасности моделирования предметных областей, имея для этого один очень частный и довольно специфический по своим качествам подход — ООП,
lair же думает, что моделируя код, он моделирует предметную область

Спасибо, но нет. Я так не думаю — и нигде такого не писал, кстати.


для решаемых нами задач — это не важно

И я снова спрошу: кто эти "вы", которые решают какие-то задачи, и какие конкретно задачи "вы" решаете?


Поэтому бессмысленно обсуждать ограничения ООП

… но вы это постоянно зачем-то делаете.

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

vs


Обсуждение ограничений ООП в качестве методологии моделирования предметных областей — очень полезная тренировка для аналитиков.
Когда я изучал BPMN права на него были куплены (переданы и проч.., я не знаю) OMG с целью заменить нотацию «плавательные дорожки». Чем закончилось, не знаю, но что «плавательные дорожки», что BPMN — суть об одном и том же. Поэтому выяснять мелочи бессмысленно. И в той и в другой нотации — серьезные логические ошибки, о которых я рассказывал ранее, и расскажу далее.
В поддержку:
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/

Там нет нигде выражения "экземпляр этого процесса". Слово "Process" там используется как название типа сущностей. "Экземпляр определенного типа" это корректное выражение.

То есть процесс «забить гвоздь» на самом деле тип процессов «Забить гвоздь» и BPMN не моделирует процессы, а моделирует типы процессов?

Я вам уже много чего сказал про типы и экземпляры. Лучше вы мне скажите.
Вот есть некоторый список действий "взять молоток, взять гвоздь, стучать по шляпке гвоздя пока он не зайдет в дерево на необходимую глубину". Я беру список, беру конкретный гвоздь и молоток, выполняю все действия следуя списку. Потом беру другой гвоздь и снова повторяю все действия.
Что в вашей терминологии здесь является процессом, что из них соответствует термину "забить гвоздь", и как называется другое понятие.

Итак, вы берете гвоздь и забиваете его, совершая при этом операцию «забить гвоздь» Другой чел на другом конце света делает то же самое, совершая операцию «забить гвоздь. Но выражение „то же самое“ не значит, что это та же операция, а означает — похожая операция. В русском языке „то же самое“ имеет два смысла: тот же объект и похожий объект. Программисты просто путают эти два смысла. Обе эти операции похожи друг на друга только в сознании субъекта. Потому что другой субъект может сказать, что ни хрена они не похожи. Итак, мы спрашиваем у того субъекта, что сказал, что эти операции похожи: Почему они похожи? Он отвечает: потому что их модели одинаковые. Мы смотрим и видим, что модели этих двух операций с его точки зрения — одинаковые. Тогда для этих двух моделей мы строим одну модель моделей. И каждый раз, когда встречаем модель операции, которая описывается этой моделью моделей, мы говорим, что встречаем похожую операцию. Модель моделей — это тип операций. Я не сказал про последовательность, потому что это следующий шаг, сначала давайте обсудим эту часть.
Аналогия и эквивалентность в любых языках имеет явные или неявные границы применимости (границы задачи), критерии сравнения, при которых делается заключение об аналогичности или эквивалентности. В контексте физической задачи о взвешивании, например, две монетки достоинством в один рубль — это два отдельных, но аналогичных (по весу) объекта, а в контексте экономической задачи эти объекты уже могут быть полностью эквивалентными (являются одной и той же стоимостью). Русский язык совсем не мешает говорить об этом.
Два объекта имеют одинаковую стоимость, но не равны. То, что их стоимость равна, не значит, что они равны. Это все равно что сказать, будто все объекты одинаковой высоты, — один объект. Возможно, что для решения конкретной задачи нам все равно, какой из этих объектов использовать.
В экономической задаче этих двух объектов не будет, будет объект ЛицевойСчёт, в котором запись единички никак не будет указывать на одну из конкретных моделей монеты. Просто потому, что они там не нужны, непринципиальны.

> Возможно, что для решения конкретной задачи нам все равно, какой из этих объектов использовать.

Возможно, что вопрос выбора объекта даже не ставится. Т.е., монеток-объектов в экономической задаче просто нет.
Два объекта имеют одинаковую стоимость, но не равны.

Это зависит от решаемой задачи.


(кстати, прекрасно описано у все того же Эванса, в рассуждениях о "сущностях" и "значениях")

То есть два разных объекта, имеющие одинаковую стоимость, могут быть одним объектом??
БИНГО! Дейсвтительно, два объекта, выделенных по критериям одной задачи, в другой задаче могут быть неотличимыми, быть одним и тем же объектом или вообще не иметь смысла.
неотличимы, то есть у нас нет возможности их отличить? А если есть? Например, операция, совершенная вчера отличается от операции, совершенной завтра тем, что у них время разное, участники разные и тому подобное и мы знаем, что они разные. И для бизнеса важно, что они разные, потому что во второй операции был допущен брак, который вылез через полгода и только благодаря различению этих операций, мы смогли вычислить того бракодела, который его допустил. Это задача, которую обязана решать любая воркфло система.
Всё верно, для бизнес-задачи объекты, выделенные по критериям другой бизнес-задачи, могут быть различимы, могут быть неразличимы, а могут вообще не существовать. Не очень понятно, чему и в чём вы возразили.

Да. Если уж совсем точно следовать терминологии DDD, то оба они будут объектами-значениями, для которых нет понятия "один и тот же", потому что нет понятия "идентичность", есть только понятие "равенство".


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

Ещё хорошим примером, наверное, будет сравнение суммового и партионного учёта.

Ответьте на вопрос, пожалуйста. И не вводите новых терминов наподобие "операция", вы говорили про процессы.

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

Какое отношение это имеет к вопросу? Там не надо определять, из чего состоит процесс. Просто скажите, как вы называете эти сущности.

Инструкция — это типовой сценарий (модель процессов, типовой процесс, регламент), последовательность ваших действий — это сценарий, процесс.

Понятие "забить гвоздь" из вашего коммента это что? Инструкция или последовательность?

Инструкция — это типовой сценарий, последовательность это сценарий.

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


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

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

Ну это банально не так.


"Процесс приема заявок состоит из" — имеется в виду (в ваших терминах) "регламент процесса приема заявок состоит из".
"В процессе приема заявок создается описание заявки" — имеется в виду, что каждый раз, когда принимают заявку, создается описание заявки.
"Вчера, в процессе приема заявок от Х, было создано описание заявки Y" — имеется в виду конкретная ситуация.


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

Нет. Понятие "стул" (или "слон", "сосна", "забить гвоздь") обозначает некоторые общие свойства. И это не то же самое, что "чертеж стула". Спросите у двух людей, как они представляют себе стул, какой у него цвет? Вряд ли они вам опишут один и тот же конкретный стул.


А когда имеют в виду конкретный объект, говорят "вот этот стул", "вон та сосна". Обычно это понятно из контекста ("стул скрипит" = "этот стул скрипит", "собака друг человека" = "животные типа 'собака' друзья человека"). А если непонятно, люди задают уточняющие вопросы ("твоя собака или вообще?"). Поскольку компьютер или модель на бумаге понимать контекст не умеют, то надо использовать более точные термины — например, тип и экземпляр.

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

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

Спросите у двух людей, что такое "a chair". Вряд ли они вам опишут один и тот же конкретный "the chair", но в их описании будут некоторые общие свойства. Общие свойства — это тип.

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

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

Стул Икс будет означать любой стул из множества однотипных, а не тип стульев. В английском — артикль a означает любой объект данного типа, а не тип объектов
Стул Икс будет означать любой стул из класса, а не тип стульев

Эти понятия, как я уже писал выше, в обыденном сознании взаимозаменимы. Причем взамозаменимы в понимании "тип стульев — это такая [...], характеристики которой применимы ко всем стульям этого типа".


В английском — артикль a означает любой объект данного типа, а не тип объектов

Кстати, нет. Не "любой", а "неопределенный".

то, что в миру называется процесс, у программистов называется — экземпляр процесса. То, что в миру называется регламентом процессов, у программистов называется — процесс.

Вы никогда "в миру" не слышали фразы "процесс регистрации документа состоит из..."?

Я слышал: регламент регистрации документов. И регламент — это модель тех последовательностей операций, которые будут совершать сотрудники. Один регламент — много последовательностей.

То есть вы правда никогда не слышали приведенной мной фразы?

Я слышал эту фразу много раз, но каждый раз спрашивал: что вы имеете ввиду под термином процесс? Я насчитал более 30-ти разных смыслов этого термина и потому для меня эта фраза без определения понятия процесс выглядит бессмысленной. А в своей конторе я вообще запретил это слово к употреблению как слово-паразит
Я слышал эту фразу много раз, но каждый раз спрашивал: что вы имеете ввиду под термином процесс? Я насчитал более 30-ти разных смыслов этого термина и потому для меня эта фраза без определения понятия процесс выглядит бессмысленной.

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


(а "регламентом процесса" у тех же людей называлась еще более третья, отдельная сущность, со своими развлечениями)


Это к тому, что людям вообще свойственно в (обыденной) речи заменять "тип" и "экземпляр" — как раз по метонимическому переносу "частное-общее" (точнее говоря, по синекдохе, но не важно). И те люди, которым по каким-то причинам надо отделять одно, от другого, придумывают разные способы борьбы. Кто-то — слово "instance". Кто-то — слово "тип". Кто-то — слово "прототип". И так далее, далее, далее. Нет никаких оснований говорить, что один способ правильнее другого.

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

А не дали вы никакого определения операции, кстати. И уж тем более — строгого. Хуже того, для всех используемых вами терминов вы не определили границу применимости.

Я не понимаю, что такое ООП в применении к моделированию предметных областей

… но продолжаете утверждать, что оно не может того и того. Как это вообще сочетается — вы что-то утверждаете о том, о чем — вы же — говорите, что не понимаете?


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

А программисты не путают. Может это вы что-то путаете?


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

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

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

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

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

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

Но, нужна принципиальность и строгость, а не частные рассуждения, претендующие на общность и глубину, которых в них пока нет.

Надеюсь, со временем, Вы свяжете эти идеи в теорию.
Собственно, еще нет языка или нотации для моделирования предметных областей. Попытки создать такие языки есть, но они, на мой взгляд, провалились. Поэтому я пишу для того, чтобы потом можно было построить язык, или нотацию, которая смога бы реализовать возможности, которые так нужны.
Это не первая проблема. Вы полагаете основной метрикой пространство-время, а к ним список объектов, без других связей. Но другие связи есть и их много и это проблема как классической, так и современной физики. Объектность это допущение, с ограниченной применимостью. И в эти границы Вы будете упираться снова и снова. Дополнение объектов процессами не снимает ограничения, Вы лишь повторяете то, что уже сформулировано Геродотом.
сначала разберемся с объектами, затем займемся связями. Проблема в том, что объекты, между которыми надо моделировать связи, пока не названы и им не даны определения.
Объекты определяются исключительно своими связями с другими объектами (возможностью влиять на другие объекты). Никакого иного смысла при моделировании прикладной области вложить в объект не получится (т.е., при моделировании важнее формализация каузальности, а онтология вторична, следует из выделенных каузальных связей).
Поскольку это всё-таки IT-шный сайт, не могли бы Вы свою идею представить в виде кода (м.б. псевдокода), или некой схемы? Иначе всё как-то воспринимается слишком академично. Т.е. как ваша идея может быть воплощена на практике, хотя бы в общих чертах?
проблема в том, что существующие инструменты не заточены под моделирование тех объектов, о которых я рассказываю. я бы хотел увидеть такие инструменты.
Ок, тогда попробуйте описать именно инструменты, с чего-то же надо начинать.
UFO just landed and posted this here
Ваш любимый semantic web имеет ту же проблемы с формулировками и названиями. По факту, это не семантика, а синтаксис. А семантическая модель не задана. А без семантической модели никакой речи о строгости и сравнении точности подходов вести нельзя.
Я не говорю, что уже существуют удовлетворительные языки для моделирования предметных областей. Есть попытки их создать, но до сих пор нет удовлетворительных. OWL моделирует предикаты первого порядка, что уже гораздо лучше, чем то, что позволяет сделать MOF, на основе которого построены нотации семейства UML. Но и OWL недостаточно для построения утверждений относительно множеств объектов, или типов. Поэтому это тоже половинчатое решение.
OWL — это не язык моделирования, это язык программирования, очередная инкарнация пролога. Об этом я и говорю — программировать на OWL можно, использовать RDF базы данных — можно. Но самого того факта, что какой-то язык годится для программирования, не означает, что на нём сподручно моделировать.

Предварительно нужно связать синтаксис этого языка с некоторой семантической моделью. Тогда программа на таком языке будет не просто «компьютер получил данные на вход, выполнил алгоритм, выплюнул выходные данные», а описанием (с доказательством!) некоторой сущности, которой придан смысл, семантика.
В текущей статье я определю следующие термины: объект, состояние, событие, операция, функция.

Каковы границы применимости ваших определений?


В качестве мета-метамодели для моделирования мы возьмем теорию множеств, а не MOF.

Я несколько раз прочитал всю статью, и не нашел в ней ни одного использования аппарата теории множеств. Сам термин "множество" используется, но в общеупотребительном смысле. Так что никакие свойства теории множеств (как то: математическая основа и границы применимости) на подход, описанный в посте, переносить нельзя. Но это так, ремарка на всякий случай.


В качестве примера такого ограничения можно представить себе моделирование высоты у объектов класса слон и объектов класса вагон. Эти два атрибута в [какой-то парадигме] никак не связаны между собой, поэтому понять, что слон поместится в вагон можно только, обратившись к программисту, создавшему эти атрибуты.

Давайте просто запомним этот пример, нам еще придется к нему вернуться.


Коль скоро мы определили объект как модель 4-объема в 4-пространстве

Это самое близкое к "определению" утверждение об объектах в этом посте. Итак, повторюсь: объект — это (субъективная) модель четырехмерного объема в четырехмерном пространстве.


Вернемся к задаче выше: у нас есть слон и вагон, нам надо понять, влезает ли слон в вагон. При их моделировании мы получаем объекты (для простоты считаем, что их временные координаты полностью совпадают, и дальше будем говорить о трехмерных объектах): объект "слон" и объект "вагон", у обоих этих объектов есть объемы.


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


Первый подход: слон влезает в вагон, если все измерения его объема меньше, чем (соответствующие) измерения объема вагона. Это, однако, противоречит тезису про плотность: два плотных объекта не могут пересекаться в одном объеме.


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


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


(Ну и на самом деле, слон не влезает в этот вагон. Почему? Потому что там уже есть бегемот. Не забывайте уменьшать "пустое пространство" при каждом помещении в него "плотного" объекта.)


Ладно, чуть-чуть видоизменим задачу: у нас есть слон, массой X тонн, и вагон, рассчитанный на нагрузку в Y тонн (и ж/д путь, рассчитанный на нагрузку в Z тонн). Сможем ли мы довезти до точки назначения слона в вагоне (по пути)? Объекты, являющиеся моделями четырехмерного пространства, никак не помогут нам в ответе на этот вопрос. Опять надо идти к программисту.


Что получилось в итоге? Предлагаемое в статье определение объекта в общем случае не решает те проблемы, которые автор приводит как ограничения [других подходов].


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

Немедленно возникает вопрос: униформен ли предлагаемый автором подход? Иными словами:


  1. Является ли объект (модель четырехмерного объема) четырехмерным объемом? Как, следствие,
  2. Является ли тип объектов объектом?

Выглядит так, как если бы ответ на оба этих вопроса был "нет". В принципе, это логично: существующая в сознании модель не имеет измерений в четырехмерном пространстве (кроме единственной координаты "время начала существования"), поэтому ее модель не является объектом. Далее аналогично.


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


Такое описание объекта соответствует описанию бизнес-функции, и говорят, что это функция по выпуску веников.

"Бизнес-функция" и "функция" — это одно и то же?


Бизнес-функция – это 4-х мерный объект,

Какова протяженность этого объекта во времени?


Бизнес-функция – это 4-х мерный объект, который имеет описание в виде набора типов событий с указанием плотности этих событий во времени

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


Или просто "превращение бумаги в мишуру" — это не бизнес-функция?


Или подойдем с другой стороны: какую задачу решает модель бизнес-функции?

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

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

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

нет, функция — это не набор, это 4-х мерный объект, имеющий описание в виде и далее по тексту
Не, фазовое пространство имеет произвольное количество измерений. Например, 6, или 12, кроме того, пространство и его описание — разные вещи. Я не говорю про пространство, я говорю про описание пространства
Да, у вас оригинальные критерии наделения терминов смыслами.
Я бы описал все же через состояния: до момента 0 шредер находится в состоянии покоя, с момента 0 до момента T в состоянии пережевывания бумаги, с момента T и далее в состоянии покоя.
При этом бумага до встречи со шредером находилась в одном состоянии, во время пережевывания — в соответствующем состоянии измельчения, а после — уже не существует вовсе (заменена множеством полосок).
А вот события в определении автора тут есть: включение и выключение шредера, они же начало уничтожения и прекращение существования соответственно для бумаги.
Это не решает других вопросов и даже добавляет: что делать с такими совокупными событиями? Являются ли они единым событием (маловероятно, ведь они показывают изменения совершенно разных состояний разных объектов) или жестко связанными различными событиями (тогда не помешало бы модели по отношениям событий).
вы описываете те события, которые считаете нужным описывать. правильных описаний не существует. каждый видит свое, но в рамках отраслевых стандартов принято видеть определенные события, имеющие ценность для моделирования
Функция шредера — превращать бумагу в мишуру. Мы должны определиться с событиями, которые мы регистрируем у этой функции. Например, событие — превращено 10 листов в мишуру. Таким образом, мы формулируем значимые для моделирования события. Далее мы включаем счетчик и считаем, сколько таких событий на отрезке времени, который много дольше расстояния между событиями, но при этом средняя скорость на этом отрезке неизменна. Это похоже на статфизику. Мы там тоже пытаемся определить стат систему, но сталкиваемся с теми же трудностями. Сивухин потратил не одну страницу, пытаясь объяснить, что такое стат объект. Ландау в своем стиле много не разглагольствовал, потому что итак ясно, что дело темное. Вот с таким объектом мы имеем дело, когда говорим про бизнес-функцию.

BTW, вот один из подходов к решению задачи о слоне и вагоне:


IShippable elephant;
IShippingContainer carriage;

elephant.CouldBeShippedIn(carriage);

И это, заметим, модель конкретной предметной области.

В своей модели вы нагружаете слона некой семантикой (интерфейс IShippable), может ли слон быть отправлен в неком вагоне.
Но слон в силу своей природы не может знать, может ли он поместиться в тот или иной вагон.
И в динамическом языке при получении такого сообщения, объект "слон" возвратил бы ошибку.
В случае статического языка можно генерировать InvalidOperationException, а лучше вообще не добавлять такой интерфейс.


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

В своей модели вы нагружаете слона некой семантикой (интерфейс IShippable), может ли слон быть отправлен в неком вагоне.

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


И в динамическом языке при получении такого сообщения, объект "слон" возвратил бы ошибку.

А кто вам сказал, что это сообщение получил именно слон?

В ООП есть термин наследование. Это инструмент моделирования иерархии тип-подтип. Это значит, что ООП построено на логике Аристотеля.

Этот вывод кажется мне странным. Разве любой инструмент моделирования иерархии тип-подтип обязан подчиняться логике Аристотеля?

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

Ой ли? А классическая логика предикатов таковой не является? В конце концов, теория множеств — это частный случай логической теории. Тут правильнее было бы сказать «единственный известный мне способ».
До предикатов мы еще не дошли, хотя, верно, что теория множеств — единственно мне известный способ. Я хотел бы разобраться с моделированием в предикатах как первого так и второго уровня, но пока мы не можем сдвинуться с места и буксуем на том, что цепляемся к ООП.
А стоит ли рассматривать процесс с тех же позиций, что и объект?
Не кажется ли вам, что это по природе своей это разные вещи, и для изучения и моделирования их используются разные инструменты и описательные категории?
Можно оставить все как есть, но лично меня это не устраивает, потому что ответ на то, что такое операция мне до сих пор не дал ни один аналитик. А это значит, что никто не знает, что это такое. Кроме того, очень хороший коммент дал мой знакомый, который занимается подобной задачей. Вот его слова: на мой взгляд проблема заключается не в автоматизации управления чем-либо, с этим аналитики и программисты неплохо справляются. Проблема же в интеграции систем управления разных направлений (например, ERP, MES, SCADA, CAD, ...), так в них используются свои, несовместимые с другими, подходы к моделированию одних и тех же физических «объектов учета» (как называет их Марк). Универсальный подход, на мой взгляд, должен позволить объявить каждую из этих моделей частным случаем более общей модели, пусть даже сама универсальная модель будет иметь ограниченное применение для создания новых информационных систем. Если получится «отмапить» существующие модели (UML, BPMN, ...) на одну общую, то это позволит семантически «бесшовно» интегрировать данные из самых разных информационных систем.
объект, состояние, событие, операция, функция — это категории восприятия и их использование для моделирования приводит к моделированию восприятия природы, а не самой природы.
Мы вообще не заняты моделированием природы. Мы заняты моделирование своих представлений о природе. Сама природа непостижима и не моделируема.
расскажите это химикам, с их молями и периодической системой. Кстати, пока они оперировали представлениями восприятия — сухостью, маслянистостью, огнем, водой и землей — их наука называлась алхимией.
я сам физик, и как физик утверждаю, что физика не про природу, а про наше ее представление. Никому нет дела до природы, как программистам нет дела до того, что такое операция. Лишь бы работало
Вы путаете задачи физика и лаборанта
Нет, физика давно смирилась с тем, что наблюдатель является неотъемлемой частью эксперимента. Получается, что трактовка наблюдателем наблюдаемых событий и есть то, что изучает физика.
Объектами, которыми оперирует теория множеств, являются, как это ни странно, множества. Не очень понятно, множеством чего тут предлагается считать объект? Множеством точек в 4-мерном объеме? Множеством точек на границе этого объема? Как перейти от описания винта через шаг резьбы к описанию винта в теории множеств?

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

Как в этом подходе смоделировать клиента с неизвестным на данный момент именем, который придет завтра в неизвестное время с неизвестной на данный момент целью?

Для моделирования такого объекта, четырех измерений мало. Как я уже говорил, самым сложным для меня было моделирование именно такого кейса, когда размерность будущих исходов определяется вероятностью, а прошлых — точностью знаний о них. В текущей статье я не касаюсь столь сложных объектов, потому что это выходит за рамки популярной статьи.
Для моделирования такого объекта достаточно определить тип «Клиент» со свойствами (имя, цель_обращения). И когда клиент придет, достаточно создать новый объект такого типа и указать конкретные значения свойств. Объектно-ориентированное программирование/проектирование уже позволяет смоделировать то, что для вашего подхода является сложным случаем. Как же вы будете моделировать случаи, которые являются сложными для ООП.
Вы решили не ту задачу, о которой говорили в постановке. Вы смоделировали уже прошедшие события, а в постановке речь шла о будущих
Где именно там модель прошедших событий? Как в таком случае звали клиента, который пришел?) И вы считаете, что послезавтра программа не сможет повторить эти действия, когда придет другой клиент?

Здесь опять торчат уши понятий «тип процессов» и «экземпляр этого типа процессов» (которые для краткости называют «тип процесса» и «экземпляр процесса»).
Модель клиента я описал, она задается типом «Клиент».
Модель регистрации нового клиента, задается типом процессов «Регистрация клиента», который представляет собой список действий, одно из которых это моделирование создания экземпляра типа «Клиент», и указание его конкретного имени.

Экземпляр типа процессов «Регистрация клиента» создается в момент прихода клиента. Экземпляр типа объектов «Клиент» с конкретным именем создается во время выполнения этого экземпляра процесса.

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

Кстати, раз уж я прояснил постановку задачи, то как в вашем подходе смоделировать эти «прошедшие» события и клиента в них?
Будущее неизвестно. Мы не можем смоделировать то, что завтра придет клиент, потому что может придет, а может не придет, может клиент, может не клиент… Мы понятия не имеем, что произойдет завтра. Вы же говорите о моделировании уже прошедших событий, когда мы знаем, что был клиент, что он пришел. Моя модель не ведает будущего, но с некоторой степенью точности моделирует прошлое, потому что знать прошлое мы не можем абсолютно точно. Но рассказ об этой модели займет страниц 30 текста, да и является комм тайной, которую я не имею права раскрывать. Поэтому я рассказываю те условия, которые привели нас к этой модели, но саму модель я показывать не буду.
Пока вы не расскажете цель, к которой вы пришли, описание пути до этой цели не будет содержать для слушателей особой осмысленности. Смысл решения (пути) всегда зависит от задачи (цели).

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

Ментальная ловушка «хочу формализовать всё, что возможно во вселенной, даже чего мы пока не знаем» приводит к попыткам формализовать процесс формализации (к попыткам моделировать мышление человека), что получается пока не очень (strong AI до сих пор не создан). Но попавшиеся в эту ловушку, как правило, не осознают глубину проблемы и ничтожность своих амбиций, им кажется, что всё решается Самой Правильной Абсолютной Онтологией :).
*ничтожность->чрезмерность
Вы же говорите о моделировании уже прошедших событий, когда мы знаем, что был клиент, что он пришел.

Как это он пришел, если он еще не пришел? Да ладно, прошедшие, будущие, не суть. Как с вашим подходом их смоделировать? Почему вы снова уходите от ответа?


Мы не можем смоделировать то, что завтра придет клиент, потому что может придет, а может не придет, может клиент, может не клиент…

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


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

А, то есть практической ценности для других специалистов у нее нет. Ок.

Почему вы снова уходите от ответа?

Будущее неизвестно! Модель должна это учитывать. Если модель будущего этого не учитывает, она плохая модель. Мы моделируем вероятностное будущее. Это значит, что у нас клиент может прийти, может не прийти, может не клиент, может налоговик, не важно, потому что мы готовы ко всему. А, когда нам станет известно, кто пришел, вот тогда мы занесем это в модель. Но и то — мы же можем обмануться. Пришел, представился клиентом, а на самом деле налоговик. Мы тогда сможем переклассифицировать пришедшего в новый класс, и сделать новую интерпретацию прошедшим событиям. Я исчерпывающе ответил?
Я исчерпывающе ответил?

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

Нет, задача была не такая — задача была:

Как смоделировать клиента с неизвестным на данный момент именем, который придет завтра в неизвестное время с неизвестной на данный момент целью?


Если нужно решить задачу регистрации новых клиентов, то — это совсем другая задача.

Для этого регистрируется новой лицо, физическое, юридическое, предприниматель и проч… А затем указывается, что это лицо — клиент. Клиент одновременно может быть и поставщиком, не забываем про это. Но это простая задача регистрации, а не попытка смоделировать события будущего. Будущее, как я сказал, неизвестно, но вероятностно. Мы с какой-то вероятностью можем о нем рассуждать. И моделирование будущего — это моделирование вероятных исходов.
Для этого регистрируется новой лицо, физическое, юридическое, предприниматель и проч… А затем указывается, что это лицо — клиент.

Во-первых, вы переусложнили — нет никаких ФЛ, ЮЛ и ИП в задаче. А во-вторых, "регистрируется" где? В системе. Система написана без модели? Без требований? В ней нет внутренней модели (хотя бы на уровне БД)?


Клиент одновременно может быть и поставщиком, не забываем про это.

… особенно это круто для той системы, где вообще нет поставщиков.

Клиент — это представление одного субъекта (юрлица, физлица и проч.) как потребителя (покупателя) услуг (товаров) с точки зрения другого субъекта (юрлица, физлица и проч.) Без моделирования точки зрения субъекта, бессмысленно говорить о клиенте, потому что не понятно: клиент кого? Надо указать, как минимум, двух субъектов, чтобы понять, кто поставщик, а кто клиент. Как иначе? Ведь «клиент» — это отношение между субъектами, а не сами субъекты
Надо указать, как минимум, двух субъектов, чтобы понять, кто поставщик, а кто клиент. Как иначе?

Да легко. Если поставщиком выступает та организация, которая владеет/заказывает информационную систему, то этот субъект в ИС может существовать неявно.


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

Мы опять ходим по кругу. Я говорю про моделирование предметной области (про концептуальную модель), а вы про информационную систему, которая воплощает эту модель (она моделируется физической моделью). Для создания концептуальной модели я считаю невозможным использование UML, но для создания физической использование UML — обязательно, если мы кодим на ООП языках. Разведите по разные стороны моделирование предметной области и моделирование кода, тогда вам станет ясно, что мои модели не про код, а про предметную область, а как конкретная ИС реализует эту модель, решает не аналитик, а архитектор ИС. Я не лезу в задачи архитектора, он не лезет в задачи аналитика — это правильный расклад. Иначе — беда
Я говорю про моделирование предметной области (про концептуальную модель

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


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

Кто "она"? Информационная система? Тогда я не понимаю, что вы называете физической моделью.


но для создания физической использование UML — обязательно, если мы кодим на ООП языках

При использовании ОО-языков использование UML необязательно.


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

Код — он тоже про предметную область. И код — обычно — не моделируют.

Я так понял, что вы умеете моделировать предметную область только одним способом? при помощи кода? Другие способы, которыми пользуются непрограммисты, вам известны?

Вы поняли неправильно. Другие способы мне тоже известны.

Если нужно решить задачу регистрации новых клиентов, то — это совсем другая задача.

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


Так все-таки, вы сможете сделать модель для этой задачи? Фразы типа "Для регистрации клиента регистрируется лицо, а потом указывается что оно клиент" моделью не являются, так как и в левой и в правой частях используется понятие "регистрация". Как тогда смоделировать регистрацию физического лица?

А, когда нам станет известно, кто пришел, вот тогда мы занесем это в модель.

Мы это должны занести не в модель, а в информационную систему. Которая построена по модели. Для которой приход находится в далеком будущем.

Я занесу в модель, а будет ли ИС на этот момент, мне неизвестно. Я могу записать это на бумажке, на магнитофонной ленте голосом, не имеет значения. При чем тут ИС? Вы привязываетесь к ИС, как будто только с ее помощью можно моделировать предметную область. Но это далеко не так. В течении тысячелетий люди моделировали без ИС и справлялись с этой задачей.
Я занесу в модель, а будет ли ИС на этот момент, мне неизвестно. Я могу записать это на бумажке, на магнитофонной ленте голосом, не имеет значения.

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


При чем тут ИС?

При том, что мы на хабрахабре.


Вы привязываетесь к ИС, как будто только с ее помощью можно моделировать предметную область.

ИС — обычно — используется не для моделирования предметной области, а для ее автоматизации.

Если не секрет, в теории множеств есть понятие "атрибут множества"?

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

Ну то есть ответ на мой вопрос — "нет". Что возвращает нас к тезису об корректности использования теории множеств.

Если не загоняться на тему математических извратов, то границей 4-х мерного объекта будет 3-х мерный объект.

С чего бы это? Разве что только для визуализации проще рассматривать 2 оси координат в декартовой системе координат, а 3-ю ось обозначить как время.
под извратами я понимал сапог Клейна, например
Понятия объекта или функции существуют в лишь рамках отдельных дисциплин и методологий. Сами методологии не “подвешены в воздухе”, а созданы для определённых целей и именно эти цели влияют на то, как будет определены понятия в методологии. Зачем давать новое определение объекту, если у вас нет методологии которая будет его использовать, нет когнитивной отрасли которой нужна новая методология, и не определены цели всей этой деятельности.

К примеру мерность объектов не имеет смысла сама по себе, зачем находить 4-х мерный объект для операции подтверждения покупки в интернет сайте? Любой бухгалтер запросто добавит вашему объекту несколько новых измерений, которые на поверку будут более бизнес-значимы чем ваша модель. А задача точно определить 4-х мерные координаты моего остатка на счету в банке может оказаться любопытной, но сложно-достижимой и уж точно эти знания не важны для пользования остатком.

Так что сначала ответьте на вопрос: “Зачем нужна новая методология и какие задачи она будет решать?” А из ответа на этот вопрос сами собою последуют определения объекта, события и всего остального.

Я не занимаюсь методологией, я просто пытался ответить на вопрос: что такое перечисленные объекты. Ни в одной из нотаций я не встречал определений, что же такое операция, функция и объект. Теперь я могу представить себе их и могу моделировать их легко и непринужденно. Как сказал мой знакомый, который также занимается этой задачей:
на мой взгляд проблема заключается не в автоматизации управления чем-либо, с этим аналитики и программисты неплохо справляются. Проблема же в интеграции систем управления разных направлений (например, ERP, MES, SCADA, CAD, ...), так в них используются свои, несовместимые с другими, подходы к моделированию одних и тех же физических «объектов учета» (как называет их Марк). Универсальный подход, на мой взгляд, должен позволить объявить каждую из этих моделей частным случаем более общей модели, пусть даже сама универсальная модель будет иметь ограниченное применение для создания новых информационных систем. Если получится «отмапить» существующие модели (UML, BPMN, ...) на одну общую, то это позволит семантически «бесшовно» интегрировать данные из самых разных информационных систем.
> Я не занимаюсь методологией, я просто пытался ответить на вопрос: что такое перечисленные объекты [в абсолюте].
Объекты имеют смысл только в рамках какой-либо задачи (или методологии решения конкретных типов задач). Абсолюта не существует (см. [нео/пост]позитивизм в научном методе).
Давать определения, это уже часть построения методологии, так что хотите вы или нет, но вы занимаетесь методологией.

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

Решать же задачу интеграции заочно в отсутствие самих субъектов слишком трудоёмко, так как предполагает фиксацию абсолютно всех доступных данных в неком представлении с минимумом искажений, то есть в трактовках максимально близких к природе самих данных. В то же время, люди придумывают методологии именно для того чтобы избавить себя от необходимости такой плотной фиксации, выделяя в потоке данных лишь значимые сведения. Случайное противоречие? Не думаю…
Я утверждаю, что реального мира нет, есть лишь наши модели, выраженные языком, образами, запахами, которые являются не более чем интерпретацией сущего, но не самим су3щим. Поэтому мы учимся передавать друг другу модели и никогда не можем передать реальность. А вот как раз этому и посвящена статья — что стоит за словесными патернами, которыми мы пользуемся при передаче моделей?
Ваша позиция (в том числе и по отношению вашего понимания методов физики как метода изучения сознания в комментариях выше) называется солипсизмом. Самым наивульгарнейшим. (И платонизм у вас радикальный: мол, мира нет, но реально существуют лишь мыслимые концепции Идеальной Онтологии.)
Вы действительно считаете, что границы между объектами существуют реально? а не в воображении? Я писал статью на эту тему. О том, что нет никаких объективных способов выделить объекты из 4-х мерного объема, кроме, как волюнтаристского. Назовите критерии объекта, и мы поговорим.
Нет, не считаю. И не очень понимаю, как вы сделали вывод о том, что считаю.
>Если получится «отмапить» существующие модели (UML, BPMN, ...) на одну общую, то это позволит
> семантически «бесшовно» интегрировать данные из самых разных информационных систем.
Я новичок в этой области, но вынужден в нее погружаться, поэтому простите за возможную наивность, но…

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

И откуда эта «шовность» берется?
Не из авторства ли, не из того, что модели пишутся людьми под определенные — индивидуальные по факту — цели, опираясь на индивидуальный же частный (дискретный) опыт в дискретном же (в виде предложений, слов, букв)?..

Вот, говорят, по тексту, описывающему одно и то же событие, можно опознать автора.
Как обстоят дела в моделировании мира — возможно здесь «отстроиться» от автора, его целей, опыта и т.д.?
Всё верно, любая модель локальна и отражает структуру явной или неявной задачи, для которой её и создали (и в контексте которой может быть оценена полезность модели — по предсказательной силе модели). Ваша интуиция верна, прежде чем рассматривать модель, необходимо понять цели автора модели (задачи, которые он решает этой моделью) и его опыт (объём учтённых в модели проблем). И прежде чем самому строить модель, нужно определиться с целями её построения. «Бесшовыный» холизм и противоположный ему «лоскутный» редукционизм — две недостижимые в абсолюте идеализации (как невозможно однозначное обобщение всей вселенной до «всего сущего», так и невозможно разложение всей вселенной на однозначный набор элементарных принципов), и все реальные (полезные) теории всегда находятся где-то между ними.
Вы ссылаетесь на очень странную книгу, я бы сказал что к современному состоянию ООП она не имеет ни какого отношения, ни проблем ни решений. ООП разнообразен, автор же почему то проигнорировал почти все что было написано до него. Йордон и Код не могут служить основой для критики ООП т.к. представляют только один из вариантов, и некоторые считают этот вариант не правильным.
Яне критиковал ООП, целью статьи было дать определение объектов, не прибегая к ООП с объяснением, почему я это сделал. Просто часто ООП считают способом моделирования предметных областей, но для меня очевиден вред тех терминов, которые произносят программисты, плохо разбирающиеся в моделировании предметных областей, но хорошо — в моделировании кода.
DDD как логическое развитие идей ООП требует соответствия модели и кода 1 в 1, в противном случае ад поддержки обеспечен. Все это подробно описал Эрик Эванс в своей книге. И если предметная область оценивается как сложная, то есть все основания использовать ООП для реализации, что в свою очередь подталкивает использовать объектную декомпозицию и моделирование.
Вы с какой частью не согласны?
Я не согласен с тем, что ООП способно смоделировать предметную область и неоднократно писал почему.

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

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

Ну да. Вы просто пишете "ООП не может x и y" (или, что не менее весело, "в ООП так и так") но тех, кто с этим не согласен, "к диспуту не приглашаете". Прекрасная, прекрасная политика.

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

… а каждое публично высказанное мнение может быть обсуждено (публично или частно — второй вопрос).

Конечно, я с удовольствием почитал статью, в которой был бы описан хотя бы терминологический аппарат ООП. Потому что то, что я читал — это аппарат описания кода, а не предметных областей. UML — нотации, моделирующие код (кроме кастрированной диаграммы использования), а не предметную область. И пока никто не дал мне ссылок на источники, в которых было бы сказано обратное

был бы описан хотя бы терминологический аппарат ООП

… давайте начнем с ответа на вопрос "что вы понимаете под ООП".


Потому что то, что я читал — это аппарат описания кода, а не предметных областей.

Программа содержит в себе модель предметной области (качество ее оставим за скобками). Соответственно, парадигма, использованная для написания этой программы, была использована для создания модели предметной области.


И пока никто не дал мне ссылок на источники, в которых было бы сказано обратное

Вы Эванса уже прочитали? Ссылки на него вам давали неоднократно. Вот вам цитата:


Object-oriented programming is powerful because it is based on a modeling paradigm, and it provides implementations of the model constructs.
Меня не устраивает даже такая мелочь, как перепутать тип данных в коде с классом объектов в природе, как наделение неживого возможностью что-то делать, как подмена отношения тип-подтип на родитель- ребенок. Ну а апофеозом стала путаница, когда вместо элемента класса стали говорить экземпляр класса. С таким количеством багов ничего смоделировать невозможно, но это мое мнение
Меня не устраивает

Ну вот видите. Стоит вам дать ссылку, как вы немедленно ее игнорируете и переходите к тому, что лично вас не устраивает (не по ссылке, а вообще). Ну и какой смысл был просить ссылку?


наделение неживого возможностью что-то делать

А в этом тоже ООП виновато? Я думал, это мир таков.


подмена отношения тип-подтип на родитель- ребенок.

А это и вовсе что-то, что вы придумали. Нет, вы вольны придумывать себе что-то, что вас не устраивает, конечно.


а апофеозом стала путаница, когда вместо элемента класса стали говорить экземпляр класса

Не вижу никакой путаницы. Путаница возникает у тех, кто пытается одновременно использовать термины из нескольких областей знания, но кто же их заставляет это делать?


С таким количеством багов ничего смоделировать невозможно

Ну то есть программ не существует. Крутое мнение, да.

Вот мы и пришли к выводу, о котором я говорю постоянно: Кому-то ООП нравится, кому-то нет, у тех и других есть аргументы. Но спорить на эту тему бессмысленно. Кому-то нравится курица, кому-то утка

Понимаете ли, в чем дело… есть разница между "мне не нравится Х" и "Х не способно". Вы постоянно заменяете первое на второе.

Лично мне не нравится, потому что не способно. Я не хочу видеть методы, привязанные к объектам. Для меня — это дикость. Для тех, кому это нормально, объяснить, почему это неверно, сложно. Была статья на эту тему, и вы отказались принять рассмотренные там аргументы. Вы отказались, а я согласен. Так что все ок. Кому-то кажется, что солнце светит, а кому-то известно, что солнце не является живым организмом и не может светить. Про то, откуда в наш язык пришли эти странные для нашего сегодняшнего мировосприятия вещи — из мистического сознания. Я об этом писал. И опять — игнор. Так что, я считаю, диспут закрыт
Лично мне не нравится, потому что не способно.

Вот это "не способно" — это ваше ничем не подтвержденное утверждение.


Кому-то кажется, что солнце светит, а кому-то известно, что солнце не является живым организмом и не может светить.

Тем не менее, общеизвестен тот факт, что солнце светит. Ваши попытки утверждать, что это не так, выглядят, скажем так, странно.


Про то, откуда в наш язык пришли эти странные для нашего сегодняшнего мировосприятия вещи — из мистического сознания.

Раньше вы писали, что из мифологического (это не одно и то же). И нет, в мифологическом сознании это тоже не так.


Кстати, эти "странные" вещи странны лишь для вашего мировосприятия. Для мировосприятия обычного человека — включая филологов — ничего странного в этих вещах нет. Зато филологам очень странно, что трансформатор не может преобразовывать, но может быть участником. И вообще может.


Я об этом писал. И опять — игнор.

"Игнор" — это ваша реакция на аргументы к вашим постам о том, что солнце не может светить, хотя оно (и это очевидно) светит.


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


BTW, нет никакой связи между "методы привязаны к объектам" и "солнце светит". Объект — это модель, и метод — это модель, и там могут быть любые соглашения, до тех пор, пока они приняты в модели.

Уважение к чужому мнению никак не вяжется с преподношением своего мнения в статьях, как единственно верного. Тут надо или продолжать диспут до признания одной из сторон поражения, или честно писать: «большинство со мной не согласно, но я считаю вот так». Вот тогда это будет уважением чужого мнения.

Если бы вместо слова "class" в ООП использовалось слово "type", что-то бы принципиально изменилось?

да. поменялось бы. но это не спасло бы без других изменений
Вот теперь стало совсем понятно, то что вы ставите в упрек отсутствие полного соответствия модели и реальности, на самом деле важный элемент для того чтобы ООП было успешным. С другой стороны таким образом вы любой методологии отказываете в абстракции — важнейшем элементе управления сложностью. Как вы себе представляете подход который будет требовать моделировать все вплоть до элементарных частиц и законов природы?
На самом деле не это хотел сказать. Любая модель это упрощение, ваша в то числе. И в любое упрощение можно ткнуть пальцем и сказать что тут оно не соответствует реальности. К примеру, я буду утверждать, что резьба болта это не отдельный объект и болт резьбу не имеет, он вообще ничего не имеет, в лучшем случае содержит молекулы но ни как не резьбу. Вопрос только в том где перестать придираться к модели. И ОО моделирование прошло большой путь в своем развитии, те элементы которые вам не очень нравятся на самом деле делают его пригодным к использованию.
Вы сказали очень интересный тезис — любая модель не соответствует реальности. Но реальность непознаваема, поэтому у нас нет никакого способа узнать, что это такое. Мы опираемся только на наши ощущения и моделируем только их. Поэтому не стоит говорить о моделировании реальности, а стоит говорить об описании наших ощущений. Для описания ощущений существует язык. Язык влияет на спектр наших ощущений, ощущения влияют на язык — это замкнутый круг. Я не моделирую мир и не призываю к его моделированию. Я был бы очень благодарен тем, кто сможет смоделировать наш способ излагать свои ощущения. Собственно, этому посвящена статья. Я пытаюсь сказать. что ООП совсем не годится для передачи наших ощущений. И что теория множеств, или, как меня поправили, теория предикатов, позволяет это. При этом использование формализма теории множеств позволяет избежать глупых ошибок, которые легко делаются программистами, которые опираются на ООП. Например, программисты называют процесс экземпляром процесса. И переучить их обратно на человеческий язык невозможно. А раз так, то они слишком далеки от нашего языка, чтобы моделировать что-либо.
У вас солипсизм в терминальной стадии. Все шагают не в ногу, только вы в ногу. Чтобы выразить ощущения, способы мышления (а почему именно ваши?) или ещё какие торсионные поля нужно предварительно придумать задачу — а зачем выразить? Чтобы после того, как мы выразили, мы смогли бы проверить, хорошо ли у нас получилось (решили ли мы поставленную задачу, достигли ли цели). Программисты называют нечто экземпляром процесса потому, что это удобно в их задачах, в задачах моделирования прикладной области средствами вычислительной техники. И это конкретные объекты с конкретными свойствами из конкретной прикладной области, а не какие-то ссылки на Абсолютную Истину, существующую вне человеческих задач (существующую в вашем солипсистском сознании под ярлыком «процесс»).
Ни один программист пока не дал определение процесса, а также определение экземпляра. Если человек не может дать определение употребляемым им терминам, то говорить с ним бесполезно.
Так а программисту-то от вас какая польза? С чего вы вообще взяли, что это он должен объяснять вам свои термины, а не вы ему? В интернете хватает определений процесса для разных задач и областей знаний, выбирайте сами задачу, в которой вы хотите опровергнуть какую-то формулировку процесса (с доказательством того, что задача стала решаться эффективнее и проще). Но вы же ничего не даёте полезного, ничего не улучшаете, вы просто пытаетесь онтологию из вашей головы (ваши собственные формализации того, как вы якобы мыслите) объявить Главным Стандартом (что нелепо не только потому, что этот стандарт ваш субъективный, а потому даже, что и среди своих субъективных вы его считаете статичным и абсолютным).
Пока никто не сможет дать строгое определение процесса, экземпляра и экземпляра этого процесса, ниша будет свободна и первый, кто даст определение, ее займет. Я просто дал определение тем терминам, которым никто еще не давал строгие определения. Покажите мне другие — буду благодарен. Только прошу, строгие, то есть, опирающиеся на аксиоматику, а не бла-бла-бла.
Я просто дал определение тем терминам, которым никто еще не давал строгие определения.

(а) нет, не дали
(б) определения давали до вас
(ц) про границы применения термина помните?


Только прошу, строгие, то есть, опирающиеся на аксиоматику

А на какую аксиоматику опираются ваши определения?

Ни один программист пока не дал определение процесса, а также определение экземпляра.

Ну здрасьте-приехали.


Объект (программирование)


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


Инстанцирование (англ. instantiation) — создание экземпляра класса.


(слово "класс" заменяйте на слово "тип", а не на слово "множество", ибо такая терминология)


BPMN


Множественные экземпляры (multiple instances) действия показывают, что одно действие выполняется многократно, по одному разу для каждого объекта. Например, для каждого объекта в заказе клиента выполняется один экземпляр действия. Экземпляры действия могут выполняться параллельно или последовательно.


BPMN 2.0.PDF


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


Это ссылки только на мои комменты, а вам на ваши ошибки указывали многие.

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

Если создавать объекты в памяти компьютера, соответствующие объектам некоторой пространственно-временной области, то получится модель этой области. И BPMN это все-таки не про компьютеры.


отличной от моделирования кода

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


Действия не могут выполняться многократно.

Вы снова путаете тип и экземпляр. Причем упорно не желаете это признавать.


Поэтому экземпляр процесса не моделирует экземпляр действия, но моделирует действие.

Экземпляр не может ничего моделировать. Экземпляр это уже конкретное воплощение. И вообще, он же не живое существо.

Я бы поверил, что BPMN не про код, если бы вместо термина экземпляр действия он бы употреблял термин действие. Вы где-то от мастера участка слышали: пойди и выполни экземпляр точения детали? он говорит: пойди и выточи деталь. Но только от программистов я слышу о выполнении экземпляра процесса. В быту мы говорим об исполнении процесса. А другой процесс — это уже другой процесс, хоть и похожий. Программисты же говорят вместо процесса — экземпляр процесса.
Т.е., программист — не авторитет, а мастер участка — авторитет? Ну, допустим, задачи мастера участка вам ближе, чем задачи программистов. Но зачем из этого делать столь глобальные выводы о несостоятельности терминологии программистов? Их терминология не о чистой философии, их терминология о программировании, прикладная. Т.е., ваши процессы, концепты, действия и прочие философские материи программист «упакует» в соответствующие сущности языка программирования (например, в классы C++, прототипы JS, процессы ОС), ибо это практическая онтология, онтология его инструментов описания вычислений на кремниевом вычислителе. И термины из философии и программирования если совпадут побуквенно, то останутся всего лишь омонимами, а не противоречием двух областей знаний.
мы, аналитики моделируем мир мастера участка, берем у него термины, выработанные столетиями, и формулируем требования к ИС, а не учим его птичьему языку
Вот и программистов не пытайтесь учить своему птичьему, очень может оказаться, что он им совсем не нужен. Учитесь ваш птичий язык переводить в программистский, именно в этом ваша задача как аналитика и состоит — в переводе прикладной проблематики мастера участка в одну из формальных систем программистов, разрабатывающих систему для автоматизации его работы. И лучше откажитесь от веры в существование Абсолютной Универсальной Онтологии, за десятки тысяч лет люди пока не придумали ничего лучше плюрализма, релятивизма и прагматизма.

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

Действия не могут выполняться многократно

Это ваше личное мнение.

ну это как одна и та же чашка одновременно была сразу в шести местах))

Нет, это как если бы из одной чашки пили шесть раз.

одновременно)). Разные люди в разное время пили из чашки чай. Это были разные действия, или скажете, что одно?)))

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

ТМ (или ТП) тоже не годится для передачи наших ощущений.

не надо моделировать атомы. Мы же не моделируем положение ротора двигателя, если того не требует модель
Я примерно такого ответа и ожидал, поэтому сформулировал вопрос по другому, Но вы почему то предпочли уточненный вопрос не заметить :(
Продолжать смысла не вижу.
Понятно, но смотрите какое следствие из вашего мнения возникает, я полностью согласен с Эвансом по поводу важности соответствия модели и кода, я это видел своими глазами. Если вы отрицаете ОО моделирование то и пригодность ООП надо ставить под сомнение.

Да автор, прямо скажем, не может ответить на вопрос, что за "ООП" он критикует. Так что вполне возможно, что это какие-то однократно-обобщенные пудели.

ООП перепутало классы и типы. То, что называется типами у Аристотеля, в ООП назвали классами

Есть ОО-языки, где путаницы с терминами в части названия типов данных нет.
Например, современный Visual Basic — являющийся по сути, тем же C#, но с синтаксисом Basic:
Data Type Summary (Visual Basic)


Любой тип данных — это тип данных.
И от того, что он является ссылочным (экземпляры размещаются в куче) или его экземпляры размещаются на стеке, он не перестает быть типом данных, и не превращается в класс или структуру.
Если в описании увидите слово class — из контекста сразу будет видно, что это проведение соответствия между ссылочным типом VB (reference data type) и ссылочным типом исполняющей среды (там это по-прежнему называется "класс").

а то, что математики называют классами, в ООП не имеет названия

Скорее, есть определенная недосказанность.


Если то, что математики называют классами это множество, то множества в ОО-нужно соответственно моделировать, создавая тип данных, описывающий множество.


В общем случае алгоритм создания типа данных "Множество":


  • Создается тип данных (в терминах большинства языков — класс) "Множество" с добавлением необходимых атрибутов и операций для этого множества (в зависимости от предметной области).
  • Тип данных "Множество" должен инкапсулировать в себе данные — поле, указывающее непосредственно на множество объектов.
    В качестве типа данных для такого поля лучше выбрать один из многочисленных типов данных для работы с множествами, которые есть во всех современных платформах — хеш-таблицы (ближе всего к понятию "множество"), словари, многочисленные виды списков ("просто" списоки, связные списки, etc), очереди FIFI/LIFO, и даже обычные массивы.
Извините, но я никак не могу понять предмет обсуждения статьи. Автор пытается обосновать некоторую метамодель для описания мира кодом так, чтобы в программировании явно не использовались абстракции, описывающие «железо», а только те, что описывают предметную область? Тогда я полностью согласен с napa3um
Ментальная ловушка «хочу формализовать всё, что возможно во вселенной, даже чего мы пока не знаем» приводит к попыткам формализовать процесс формализации (к попыткам моделировать мышление человека), что получается пока не очень

Пытаясь в очередной раз вникнуть в ООП, прочёл книгу «Software Factories: Assembling Applications with Patterns, Frameworks, Models & Tools», где во вступительных главах описываются слои абстракции от предметной области к железу, и почему UML не позволит аналитикам с менеджерами создавать нормальный код без программистов.

Или Вы пытаетесь создать инструмент для универсальной модели бизнеса? Так получается тоже нечто странное, плодятся божественные объекты, менеджеры менеджеров и фабрики фабрик. Люди пытаются всё распихать по объектам-существительным, и отказываются выносить действия в отдельные сущности.
Если удастся создать некоторый единый обобщенный подход к описанию мира, то будет отлично, но поскольку на естесственных языках такого до сих пор не случилось, я не верю, что такое в принципе возможно, если не использовать массовые расстрелы единообразное высшее образование
я пытаюсь, делаю попытку разобраться и поставить задачу к программистам так, чтобы они придумали язык более подходящий для аналитиков, а не для программистов. Пока же беда — аналитики пользуются UML и это калечит их разум

(а) это не задача программистов
(б) кому не хочется калечиться об UML, могут его не использовать
(ц) есть прекрасная книга Вигерса о том, как писать требования, и которая UML только упоминает мимоходом


А вообще, конечно, "подходящий для аналитиков язык" давно придумали. И это, в большей части случаев, их родной язык (оставшиеся случаи — это ситуации, когда надо писать, скажем, на общем языке команды, английском, например). Ну да, этот язык формализуется и ограничивается для уменьшения неоднозначностей, но он уже есть. И это работает.

нет, не работает, потому что, когда я слышу термин «экземпляр этого процесса», хочется спросить определение процесса, определение экземпляра, а эти определения мне еще ни один программист так и не дал. В русском языке нет термина экземпляр этого процесса. Есть термин процесс, типовой процесс, класс процессов и так далее. Но только программисты смогли родить этот замысловатый термин.

А когда я слышу ваши "термины", мне тоже много чего хочется спросить — и я спрашиваю, — но вы тоже не даете определений (начиная с определения "ООП"). Ну и в чем разница?


И вообще, в русском языке нет термина "процесс", есть только слово "процесс". Термином оно становится, оказавшись в конкретной системе.

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

Тем не менее, получившийся результат все еще является моделью предметной области. А то, что модель не похожа на то, по чему она строилась, так это (в зависимости от цели моделирования) нормально...

даже не знаю как ответить, вроде написал все понятно, ладно повторю — зачастую «ООП» понятие не имеет о предметной области, в исходниках нету классов покупатель и товар, а есть рекорсеты с полями и правила отношений между ними ну и формы для ввода данных, это и есть моделирование производной от предметной области, конечно можно сделать такие классы но необязательно, а так как речь идет о времени появления ООП то и очень трудоемко, это сейчас в скриптовых языках или в языках с развитой рефлексией можно легко генерить датаобъекты, а 40 лет (или сколько там) назад было не все так однозначно.
зачастую «ООП» понятие не имеет о предметной области, в исходниках нету классов покупатель и товар, а есть рекорсеты с полями и правила отношений между ними

Эмм. Во-первых, то, что вы описываете (рекордсеты и отношения) — это не то ООП, которое описывает автор поста (описанные им недостатки просто не совмещаются с вашим описанием).


Во-вторых, что важнее, это все равно модель предметной области.


Давайте на минуту отойдем от ООП и посмотрим на реляционную базу данных. В ней как раз есть наборы записей (с колонками-атрибутами) и отношения между записями. Модель ли это предметной области? Конечно (более того, я видел много аналитиков, которые других моделей и не умели строить). Просто это не объектно-ориентированная модель (в обычном понимании объектно-ориентированности), ну так никто же и не требовал.


А теперь давайте вернемся в код из вашего примера. В нем та же самая модель, просто реализованная не средствами реляционной БД, а средствами ОО-языка. И что? Модель от этого изменилась? Да нет.


Так что, хотя это и контринтуитивно, но объектно-ориентированная программа может содержать не-объектно-ориентированную модель предметной области.


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


а так как речь идет о времени появления ООП

Э, где? Я думал, речь идет о текущем состоянии дел.


(не говоря уже о том, что и "во время появления" ситуация тоже была… другой)

перечитайте начало, Автор именно рассматривает ООП на уровне «основных понятий» из вики, т.е. «вообще» а не современное состояние\подход к применению, что позиционирует во времени в прошлое (и это неудивительно ведь он не программист), Автор именно думает (ну или не знаю почему) что ООП описывает предметную область непосредственно, задается вопросом что везет, и у него это метод, предлагает отделить метод от объекта, ирония в том что программист сделает объект «транспортное средство», у него будет список объектов (условно) «действия», сделает объект «везти» (ну или -«транспортировка», наследник «действия») с методом «начать» (ну или как там), да возможно он сделает метод «везти» (у «транспортное средство») но внутри все равно будет объект, т.е. произойдет тоже что жаждет Автор, таким образом, его представления не соответствуют действительности, что собственно я назвал — неудачным началом.

Рекордсеты я привел в пример как производная отличается непосредственной предметной области.
перечитайте начало, Автор именно рассматривает ООП на уровне «основных понятий» из вики,

Автор вообще отказывается сказать, что именно он называет ООП. Я склонен думать, что это обособленные одиночные пикеты, если честно.


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

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

А, я понял что вас зацепило, я там просто пропустил слово _непосредственного_ моделирования, ожидая что это и так будет понятно из контекста, после переваривают, вы не так поняли, так что все нормально, моделировать, в вашем понимании, нужно :)

А что такое "непосредственное моделирование"?

перенос предметной области в код как есть, без каких либо обобщений\изменений и т.п.

например у Автора действия над объектом жестко транслируются в методы класса (смутно припоминаю что в теории (не ООП) так принято, хотя могу врать)
перенос предметной области в код как есть, без каких либо обобщений\изменений

Это в общем случае невозможно (вне зависимости от выбранной парадигмы разработки и моделирования); какой смысл это вообще обсуждать и упоминать?

опять двадцать пять, это делает Автор в начале и сетует что криво выходит.

Не "Автор", а вы пишете, что "ООП можно использовать для моделирования, но не нужно". Так вот, для "непосредственного моделирования" (в вашем понимании), ООП использовать нельзя, потому что эта задача не имеет решения.


(автор, кстати, утверждает, что он пишет не про код, а про моделирование предметных областей, а код тут ну вообще ни при чем)

Вы надо перечитать что пишет Автор, потом мои комменты, а то на второй круг заходим.

Да я читал, что пишет автор, беда в том, что он себе противоречит. Вы тоже не помогаете.

ООП сделало небольшую подтасовку фактов. Сначала ввело свои собственные термины, но из слов, похожих на те, которыми пользуются предметники. В итоге смысл слов был изменен. Затем они пришли к предметникам с этими словами, которые очень похожи на обычные слова, но имеют совсем другой смысл. Предметники слушают ООПэшников, но понять не могут, что они воркуют. В итоге либо посылают их в одно место, либо пытаются приспособиться к их птичьему языку. Я просто строю переводную таблицу смыслов. Если ООПэшник сказал «экземпляр процесса», то на русском языке — это план-график работ. Если он сказал «процесс», то это на русском языке — регламент. Такая табличка не помешает при общении с программистами.

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

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

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

:), Вы так написали как будто программисты спят и видят как они моделируют предметную область, это не так, как раз наоборот, они мечтают максимально отдалится от нее, создать максимально универсальные решения, что-то вроде «Теории Всего» программирования и отдать полученные инструменты предметникам, дабы не слушать их птичий язык.
Сначала ввело свои собственные термины, но из слов, похожих на те, которыми пользуются предметники

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


Если ООПэшник сказал «экземпляр процесса», то на русском языке — это план-график работ. Если он сказал «процесс», то это на русском языке — регламент.

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


Ну и неплохо было бы помнить программистам, что код они пишут для машины и код — это описание процессов, происходящих внутри ВМ, а не в предметной области

Код — не описание процессов, происходящих внутри машины (как уже неоднократно говорилось, вы не программист, и не понимаете в программировании, и это очередная иллюстрация).


зря они себя тешат иллюзией о том, что они моделируют предметную область.

Угу. Попробуйте формально доказать утверждение "ни одна программа не содержит модели предметной области".

Мне как проектировщику утопического общества интересен такой момент — было бы круто законодательство оформить в машиночитаемом виде и например автоматически валидировать законы на непротиворечивость, выводить новые утверждения, проверять судебные решения на соответствие.
Не было ли таких попыток?
Такие мысли приходят в голову только математикам. Все остальные слои населения не доверяют математикам «да что эта ваша математика знает»? Или «кибернетика — буржуазная лженаука для эксплуатации рабочих». А зря.
Такие мысли приходят наивным редукционистам, а не математикам. Математики как раз знают, что аксиоматических систем может быть бесконечное множество. А так же математики помнят теорему Гёделя о неполноте.
Во-первых, приходит в голову — не значит признаётся рабочей после обдумывания.

Во-вторых, как соотносится теорема Гёделя со сводом законов? Мы же не пытаемся опереть их сами на себя, мы используем более сложную математику для верификации. Математики давно уже пережили этот шок и способны двигаться дальше, заниматься интересными вещами и находить новые законы. Печально, что многие школьники, не разбираясь особо даже в существе вопроса, используют теорему Гёделя как индульгенцию для того, чтобы забросить математику. «Если абсолютная строгость не достижима, то зачем математика нужна». Нужна. Она приносит и практическую пользу и эстетическое наслаждение.

В-третьих, можно вспомнить о другой полноте — имени Тьюринга. Которая не мешает существованию различных верификаторов программного кода. Да, есть множественные ограничения на использование. Но хоть какие-то автоматические проверки лучше чем совсем ничего, даёт больше уверенности.

Но всё это никогда будет применено на практике. Потому что простой люд полагает компьютер чем-то магическим. «Я ничего не делал — оно само случилось». Мало до кого доходит, что компьютер безжалостен как природа и делает в точности то, что ему приказал человек. Но люди не готовы брать на себя ответственность. Они предпочитают думать, что внутри компьютера живут волшебные гномики, а разве можно доверять гномикам?

С другой стороны чиновники тоже в недоумении. Где у компьютерного алгоритма верификации находится купюроприёмник? Как заносить ему взятки? Хотя попытки подкупить компьютер — это всё равно что попытки отменить законодательно физику. Она работать будет в любом случае, безотносительно желания человека
Аксиоматика в одной отрасли должна быть одна, иначе, получается где играем, где не играем, где рыбу заворачиваем, то есть, полная чушь. Насчет теоремы о неполноте: это касается только тех утверждений, которые относятся к самим утверждениям. Для чего создавать такие в законотворчестве — не совсем ясно и я таких не встречал.

Совсем недавно нам поступил запрос именно на такую работу — создание верифицированной модели в области законодательства. Это нормально и возможно. Правда, это касается нормативных отраслевых актов, но лиха беда начало.

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

Трудятся люди над этим.
Например, здесь — https://github.com/RinkeHoekstra/lkif-core
Здесь главная проблема не в противоречивости норм (см., например, паранепротиворечивость), а в неформализуемости. Уже давно известно, что понятия типа «жизни» или «здоровья» не поддаются точной формализации. В частности, оптимизация систем жизнеобеспечения для космонавтов при оптимизации по любому формальному параметру в пределе приводит к смерти. Поэтому же для суда, даже при полной ясности обстоятельств дела, не всегда очевидно, какое решение будет наилучшим из возможных законных.
То что аксиоматические понятия не определяются, а поясняются, это не новость и в принципе не мешает строить строгие системы, если вдруг суд затруднится с определением, то привлечёт суд присяжных.
Я отвечал на вопрос о возможности автоматической проверки системы законов на корректность, а суд был лишь примером внешнего проявления неформализуемости. Потенциальному верификатору надо предъявлять не просто строгую, а точную формальную запись законов. А неформализуемость понятий именно этому и препятствует, причем в большей степени, чем противоречивость.
Что такое точка в геометрии? Колмогоров дает определение — это материальный объект, размерами которого можно пренебречь в рамках решаемой задачи. Что такое точка в математике? Это — неопределимое понятие, которое вводится аксиоматически. Я сторонник определения Колмогорова. Такое определение мною понимается и легко применяется. В такой постановке есть смысл в вопросе: сколько точек на отрезке? И количество точек на отрезке становится возможным посчитать, если есть реестр точек
Only those users with full accounts are able to leave comments. Log in, please.

Articles