Pull to refresh

Comments 52

А Вы правда не видите ошибки в рассуждении:

«Есть три распространенных способа представить ее конструкцию (парадигмы конструкции). Первый способ был упомянут выше – над-функция представляется в виде конструкции, состоящей из под-функций (нотация IDEF0).… Третий тип конструкций соответствует текущему кейсу: функция состоит из операций определенного типа. Например, функция продаж состоит из операций по продаже товаров.»

?

Если мы находимся на уровне индивидов (Ваших «конкретных объектов»), то первый и третий — это разные уровни холархии. Сперва индивид «функция» разбивается на индивиды «операции», потом индивиды «операции» — на индивиды «подфункции».

Если мы находимся на уровне классов", то никакого «третьего способа» нет.

А если перескакивать между уровнями, то можно найти много трудностей на ровном месте.
Функция «Продажи телефонов в магазине номер 7 по улице Бр. Грин» делится на две под-функции: «Достижение договоренностей с покупателями» и функцию «Отгрузки телефонов». Функция «Продажи..» делится на множество операций класса «Продажа конкретного телефона», каждая из которых (операций) делится на операции:«договориться с конкретным покупателем» и «отгрузить конкретный телефон». Пока нет противоречий
Как здание состоит из кирпичей, так и функция — из операций. Однако, я привел пример коррелированного деления на части, о котором я говорил в конце статьи, потому что функция «Отгрузка телефонов» тоже делится на операции «Отгрузка конкретного телефона», что произошло, потому что мы так сделали намеренно.
Вы сказали то же самое, что написал я. На уровне классов есть только два уровня:

Функция «Продажи телефонов в магазине номер 7 по улице Бр. Грин» делится на две под-функции: «Достижение договоренностей с покупателями» и функцию «Отгрузки телефонов».


Не надо тут про конкретный магазин, это просто про «Продажи телефонов в магазине». Два уровня.

На уровне индивидов — три уровня, образующие однородную холархию:

Функция «Продажи телефонов в магазине номер 7 по улице Бр. Грин» делится на множество операций класса «Продажа конкретного телефона», каждая из которых (операций) делится на операции:«договориться с конкретным покупателем» и «отгрузить конкретный телефон».


Нет никакой сложной ситуации трёх уровней, о которой напсиано в исходной статье.
Не надо тут про конкретный магазин, это просто про «Продажи телефонов в магазине»

Я рассматриваю конкретный магазин и его функцию — продажи телефонов. Что мешает мне назвать функцию магазина, как «продажа телефонов в магазине номер 7»? Затем эту функцию представить в виде конструкции, состоящую из двух функций: «Достижение договоренностей с покупателями в магазине номер 7» и функцию «Отгрузки телефонов в магазине номер 7». Затем каждую из этих функций поделить на операции. Нет ничего странного и необычного в этом. Это называется описание деятельность (активности) конкретного предприятия. Есть возражения к тому, что я сказал?
Что мешает мне назвать функцию магазина, как «продажа телефонов в магазине номер 7»? Затем эту функцию представить в виде конструкции, состоящую из двух функций: «Достижение договоренностей с покупателями в магазине номер 7» и функцию «Отгрузки телефонов в магазине номер 7». Затем каждую из этих функций поделить на операции.


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

Для принципиального моделирования систем на уровне индивидов достаточно двух основных типов 4D объектов — функциональные и физические. И одного отношения — часть-целое. На уровне классов и классов классов объектов и отношений достаточно обычных теоретико-множественных отношений.

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

При этом каждый функциональный объект можно поделить на части, каждый из которых является функциональным объектом. Количество таких разбиений — бесчисленное множество. Каждое разбиение необходимо для решения какой-то конкретной задачи. И здесь нет противоречия с ИСО. Количество конструкций объекта ограничено лишь нашим воображением. Насколько я помню, в ИСО нет ограничения на количество конструкций?
Свои тезисы я сформулировал в рамках обычных теоретико-множественных отношений. При помощи предикатов первого и второго порядков. Именно задача формулировки тезисов в таком виде и привела меня к задаче классификации конструкций.
Возможно, вас смущает название функции и вы думаете, что разные магазины обладают одинаковой функцией под названием «продажа телефонов». Назовите тогда функцию магазина номер 7 как-то бессмысленно: "%: ПОи шгмнишрл". Функцию другого магазина также бессмысленно: «ПЛОИИПЛОоилоил». а потом скажите, что функция "%: ПОи шгмнишрл" и функция «ПЛОИИПЛОоилоил» похожи, потому что и там и там участвуют объекты одного типа — телефоны! И вот ура! мы нашли нечто, что позволяет нам классифицировать две разные функции как похожие. Дальнейшее изучение их привело к тому, что мы придумали им общее название: «ПОРДОРТЛОР». и теперь обе функции называются одинаково, но от этого они не перестают быть разными. Затем мы можем объединить эти две функци в одну (построить из них конструкцию назвать эту большую функцию тем же именем. Получается ровно то же, что когад мы две части воды сливаем вместе и получаем одну большую часть воды.
Итак, мы можем привести пример уже четырех разных способов деления функции «продажи телефонов в магазине номер 7» на части.

Первый способ: функция «продажи телефонов в магазине номер 7» делится на две части: «продажи телефонов в отделе номер 1 магазина номер 7» и «продажи телефонов в отделе номер 2 магазина номер 7». Это как две части воды смешать вместе и получить снова воду.

Второй способ: функция «продажи телефонов в магазине номер 7» делится на две части: «согласование договоренностей с покупателями» и «отгрузка телефонов». Это все равно, что сказать: вода состоит из водорода и кислорода.

Третий способ: функция «продажи телефонов в магазине номер 7» делится на операции: «Продать телефон». Это все равно, что сказать: вода состоит из молекул воды.

Четвертый способ: функция «продажи телефонов в магазине номер 7» состоит из последовательностей операций: «договориться об условии продажи» и «отгрузить телефон». Это все равно, что сказать: вода состоит из молекул, каждая из которых состоит из атомов водорода и атомов кислорода, связанных между собой связями.

таким образом, мы получили четыре разных типа конструкций одного объекта.
Да, конечно, есть и другие способы деления, например:

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

Шестой способ: функция «продажи телефонов в магазине номер 7» делится на части: телефоны, которые не воспринимаются нами как единое целое (поток телефонов), а видятся наблюдателю отдельно, из исполнителей, которые тоже видятся индивидуально и клиентов, которые тоже воспринимаются отдельно. Этот способ деления похож на деление функции на операции, только деление тут происходит на объекты другого типа. Аналогия с водой та же.

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

А подразумевают, что операции подобного типа длятся в среднем 4 часа.


Там есть концептуальные модели операций. Очень похоже на определение понятия, и так оно и есть. Квадратик в BPMN моделирует не операцию, а понятие об операции. Диаграмма в нотации BPMN – концептуальная модель, а не модель объекта.

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


Тогда речь идет о том, что в любой операции данного типа участником будет конкретный объект, а не объект какого-то типа, например, в каждой операции класса «получить согласование на постройку здания» указан участник: администрация города Москвы (объект).

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


Конкретное здание состоит из объектов типа «кирпич»

Все здания такого типа тоже состоят из объектов типа "кирпич". Так же как и функции определенного типа состоят из операций определенного типа.


Моделирование таких конструкций довольно затруднено в современных языках моделирования.

Зато довольно несложно в современных языках программирования.


"Например, если мы говорим, что лес состоит из осин на 60 процентов и из берез на 30 процентов (остальные деревья относятся к другим породам)"


$forestInfo = ['osina' => 0.6, 'bereza' => 0.3, '*' => 0.1];

Даже никакого ООП не надо. Нужно смоделировать конкретный лес? Пожалуйста.


class Forest
{
    private $forestInfo;

    public __construct($forestInfo)
    {
        $this->forestInfo = $forestInfo;
    }
}
$forest = new Forest(['osina' => 0.6, 'bereza' => 0.3, '*' => 0.1]);

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


class Building
{
    private $material => ['type' => 'Brick'];
}

Поэтому там, где надо моделировать предикаты второго порядка, ООП не справляется.

Почему вы упорно утвержаете факты о вещах, которых толком не знаете?


Вместо того, чтобы сказать, что операции в цепочке могут быть объединены в группу по какому-то (в общем случае произвольному) признаку

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


Современные стандарты инженерного проектирования основаны именно на таком делении объекта, хотя, я уверен, что в них нет прописанного требования о подобном ограничении на моделирование.

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

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

Откуда в барабане возьмутся вещи, если клиент первый и до него клиентов не было? Это и есть точка отсчета, от нее и надо считать.
Если вы будете считать операции от середины заказа, вам в пределах группы операций надо будет работать с 2 клиентами, 2 их заказами, и 2 наборами вещей. Кроме того, вам надо будет вводить особый вид "неполная операция", чтобы сделать учет первого и последнего заказа.


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

На складе важно то, что в нем хранится. От того, что вы будете знать, что у вас 10 мест свободно, вы не сможете узнать, можно ли утвердить заказ на отгрузку 20 ящиков гвоздей. Поэтому надо учитывать и товар и свободные места. То есть делать модель склада.

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

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

У нас на физтехе было правило: если вы не можете придумать 50 разных способов посмотреть на одно и то же, значит, вы не физик. Стандартное мышление сильно нас ограничивает и заставляет видеть то, чего нет — начальные операции. Тот, кто может позволить себе фантазию, понимает, что нет ничего, что могло бы ограничить ее. Я придумал один пример, но могу много. Попробуйте просто допустить возможность разных точек зрения.

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

Программа будет работать так, как мы ей скажем. Наличие начальной и конечной операции — ограничение тех нотаций, которые мы имеем, возьмем другую нотацию и ограничение уйдет. Такую нотацию мы разработали и она позволяет строить различные представления в зависимости от точек зрения.
Спасибо за комментарий! Начнем с того, что все примеры, которые вы привели мне знакомы, и потому я бы не сказал, что мне они неизвестны. Просто они не решают задачу. Объясню почему:
А подразумевают, что операции подобного типа длятся в среднем 4 часа.

Запомним этот тезис — он не мой, а ваш!
Поздравляю, вы начали понимать, чем отличается тип и экземпляр. Только называете их по-своему.

Вы только что сказали нечто, что противоречит предыдущему тезису. Если вы вводите понятие «экземпляр этой операции», то прежнее утверждение должно было звучать так:
А подразумевают, что экземпляры этой операции длятся в среднем 4 часа.
Почему это не имеет смысла в русском языке, я писал неоднократно ранее. Либо вы говорите, что мы моделируем операции, либо экземпляры этой операции. Но в предметной области есть операции, но нет экземпляров этой операции. Экземпляры появились в ООП и не надо тащить их в предметную область.
А это передача объекта по ссылке. В отличие от передачи по значению, например, строки с названием документа «Акт строительства здания N».

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

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

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

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

Это значит, что мы либо потеряем эти части, либо введем в модель пространства, по которому они идут. А введение модели пространства и есть необходимость сделать его частью модели.
Запомним этот тезис — он не мой, а ваш!
Вы только что сказали нечто, что противоречит предыдущему тезису. Если вы вводите понятие «экземпляр этой операции», то прежнее утверждение должно было звучать так:
А подразумевают, что экземпляры этой операции длятся в среднем 4 часа.

Это вы ввели выражение "Можно сказать, что операции подобного типа длятся в среднем 4 часа.". Я лишь указал на то, что люди именно это и имеют в виду.
Если вводить понятия "концептуальная модель" и "модель объекта", то утверждение будет звучать так:
А подразумевают, что модели объектов (конкретные операции), соответствующие концептуальной модели (этому типу операций), длятся в среднем 4 часа.


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


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

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


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

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


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

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


потому что не понятно, как класс осин связан с 'osina'? Или 'osina' — это обозначение класса объектов? Вроде нет.
Пример я привел выше — 'osina' — это не класс.

osina это семантически значимое обозначение того, что означает число 0.6. И не употребляйте пожалуйста слово "класс", пишите "тип" или "множество" вы имеете в виду.
Если у нас в модели есть тип "Осина", и нам надо смоделировать эту связь, можно задать и по-другому:


$forestInfo = [['type' => 'Osina', 'amount' => 0.6], ['type' => 'Bereza', 'amount' => 0.3], ['type' => 'OtherTree', 'amount' => 0.1]];

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

Начальная операция существует, потому что существует термин "начальная", соответственно, им что-то обозначают. Вы не сможете вычислить значение sin(x) + cos(x) до вычисления sin(x), поэтому сложение здесь не может быть начальной операцией.


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

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


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

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

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

Отлично! Вы только что сказали: операции данного типа в среднем длятся 4 часа. Именно это я и сказал. Так что в нашем тезисе не понадобилось вводить странный термин «экземпляр этого процесса».
«операции подобного типа» и «экземпляры этой операции»

Я никогда не говорю экземпляр операции, потому что незачем говорить масло масляное, если экземпляр операции указывает на операцию, то это и есть операция. Термин «экземпляр ввели вы, вы и объясните, что он значит. Операции подобного типа — это однотипные операции, похожие друг на друга. Например, два венских стула за номером 1213 и 356 похожи друг на друга и потому оба они — венские стулья. Две операции „забить гвоздь в 9-00“ и „забить гвоздь в 10-00“ — похожи, потому что и там и там присутствуют гвозди (объекты, похожие друг на друга), какие-то субъекты (биологические объекты, похожие друг на друга), и тд. Поэтому обе эти операции и называются: „забить гвоздь“. Поэтому обе эти операции похожи, или относятся к одному типу операций.
Так что в нашем тезисе не понадобилось вводить странный термин «экземпляр этого процесса».

Потому что он уже введен. Экземпляр это конкретная произведенная операция. Вы его называете по-другому, но само понятие от этого никуда не девается. По нескольким экземплярам мы можем построить статистику "длятся в среднем 4 часа". Выделяя одинаковые действия и свойства в некоторое описание мы задаем тип. Тип определяет множество возможных экземпляров. Значит, тип может иметь характеристику "средняя длительность", потому что средняя длительность считается как раз на основе экземпляров. Все сходится.


Поэтому обе эти операции и называются: „забить гвоздь“

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

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

Это вы их называете просто операциями. А другие люди называют это экземплярами. Это одно понятие с разными названиями.


Потому что ваше утверждение равносильно следующему: Вот этот слон — это тип слонов.

У меня нет таких утверждений. Можно сказать, что этот слон — экземпляр (представитель) такого-то типа слонов (экземпляр типа "Слон Такой-то"). Или что это слон имеет тип такой-то. Или относится к типу такому-то.
И нет, "индийский" это не экземпляр типа слонов (не экземпляр типа "Индийский Слон"). Это экземпляр типа "ТипСлонов". Есть тип понятий "ТипСлонов", есть экземпляры этого типа "Индийский", "Африканский". Они в свою очередь тоже являются типами, типами слонов, и могут быть экземпляры этих типов, конкретные слоны. Такая терминология позволяет описывать иерархии любой сложности без путаницы типа "индийский слон это слон или нет". Есть типы и есть экземпляры.

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

Так специализированные типы слонов обозначают подмножества более общего типа "Слон". Говоря что объект относится к типу "Индийский слон" мы тем самым говорим, что он относится и к типу "Слон". Разве нет?

Лучше вообще не вводить понятие Индийский слон, потому что в начале не было класса и подкласса, типа и подтипа, не надо было его и вводить что только запутало дискуссию. Надо вынырнуть на уровень слонов без каких-то индийских и начать сначала
Экземпляры это то, что вы называете «модель объекта».

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

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

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

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

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

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

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

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

Мое описание строится строго в предикатах. Определяется предикат: «участвует в» Предикат может связывать объекты, классы объектов. Например, предикат «участвует в» в контексте администрация «участвует в» «Любой операции данного множества» связывает объект (администрацию) с классом объектов «Операции данного типа» с квантором «Для любого объекта данного множества». Если перекладывать на код, мы должны создать класс операций, связать его с объектом и квантором. Но это невозможно, потому что ООП не работает с предикатами второго порядка — не может связать объект с классом семантической связью.

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

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

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

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

Зачем вводить это в язык, если можно создать это существующими средствами языка?

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

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

Вы считаете, что в программировании нельзя задать связь между объектами? Или ввести тип "Конструкция" со всеми необходимыми экземплярами? Или что в процедуру определения конструкции нельзя передать контекст или субъект? В языках программирования есть средства для реализации всего указанного.


type Construction
{
   array elements;
};

type ElectricConstruction: Construction;
type AreaConstruction: Construction;

type Person
{
    string name;
    function getConstruction(Building building);
}

type ElectricSpecialist: Person
{
    function getConstruction(Building building)
    {
        return new ElectricConstruction(building.electricElements);
    }
}

type Builder: Person
{
    function getConstruction(Building building)
    {
        return new AreaConstruction(building.areaElements);
    }
}

var specialist1 = new ElectricSpecialist('Vasya');
var specialist2 = new Builder('Petya');
var construction1 = specialist1->getConstruction(building);  // ElectricConstruction
var construction2 = specialist2->getConstruction(building);  // AreaConstruction
osina это семантически значимое обозначение того, что означает число 0.6. И не употребляйте пожалуйста слово «класс», пишите «тип» или «множество» вы имеете в виду.
Если у нас в модели есть тип «Осина», и нам надо смоделировать эту связь, можно задать и по-другому:

В модели есть обозначение типа — это class of OSINA. Мне надо сказать, что лес состоит из объектов типа осина, то есть связать объект Лес с классом OSINA. Языковыми средствами я это сделать не могу.

Можете. Чем вас не устраивает связь 'type' => 'Osina'? Osina это обозначение типа. Видимо вы используете class в значении множество. Я вам в очередной раз напоминаю, что тип задает множество без перечисления всех элементов.

Мне не надо перечислять элементы множества, если мне неизвестны его элементы, но мне надо связать тип объектов с объектом, чтобы сказать — в лесу объекты такого типа. В ООП тип объектов моделируется при помощи конструкции Class of, например. Это значит, что в своем высказывании я должен связать этот clsss и объект. Поскольку это невозможно сделать, приходится моделировать это иначе — путем создания еще одного объекта «Osina». Получается, что мы дважды моделируем тип объектов.
путем создания еще одного объекта «Osina»

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

Как осина — название типа связано с осиной — объявлением класса?

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

Причем здесь включение компьютера? На принцип моделирования оно не влияет.

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

Да, верно. Спасибо! Надо поглубже покопать, зачем же все-таки люди делают коррелированные конструкции непроизвольно.
Only those users with full accounts are able to leave comments. Log in, please.

Articles