Термины
Начнем с термина «есть часть». В быту мы встречаем следующие высказывания: слоны – есть часть млекопитающих. Речь идет о том, что множество слонов есть подмножество множества млекопитающих. В этой статье термин «есть часть» будет употребляться в другом смысле. Мы будем употреблять этот термин только в отношении конкретных объектов. Например, конкретная ветка дерева – есть часть конкретного дерева. При этом не надо думать, что речь идет о любой ветке дерева, как тогда, когда мы даем определение понятию: ветка дерева – есть часть дерева. В терминах матлогики это утверждение читается так: для любой ветки дерева найдется такое дерево, что данная ветка есть часть этого дерева. Такое утверждение относится уже не к конкретному объекту, а к понятию, определяющему объекты. Если в статье понадобиться сказать так, я скажу явно. В противном случае я буду говорить о конкретных объектах.
Следующий термин «включает в себя». Если я говорю, что дерево включает в себя ветку, то это значит, что конкретная ветка – это часть конкретного дерева. И речь по-прежнему идет о конкретных объектах, а не о множествах или понятиях.
Еще один термин, разобраться с которым будет немного сложнее. Это термин «состоит из» Кажется, что он близок к термину «включает в себя», но мы будем их различать. Мы говорим, что дерево состоит из веток, ствола и корней. При этом подразумеваем, что части дерева перечислены полностью, чтобы дать нам полное представление о строении дерева. То есть, термин «состоит из» употребляется в отношении строений (конструкций) объектов. Если взять часть из этих объектов, то сказать, что над-объект состоит из этих под-объектов уже не получится (что-то упущено). Поэтому правильна такая иерархия: над-объект, конструкция над-объекта, элементами которой являются под-объекты и из которых она состоит, под-объект, являющийся частью над-объекта и являющийся элементом конструкции над-объекта.
Парадигмы конструкций
Один над-объект может быть представлен в виде разных конструкций. Над-объект может быть поделен на части в соответствии с разными принципами деления (разными основаниями). Есть принцип деления, сохраняющий компактность пространственных частей — пространственное деление. Пример: здание состоит из помещений. Напомню, что тезис «здание состоит из помещений» равносилен утверждению: есть здание, есть конструкция здания, выполненная в рамках пространственной парадигмы, элементами которой (конструкции) являются помещения. Другое основание – функциональное. Пример: здание состоит из ограждающих конструкций, кровли и инженерных подсистем. Другими словами, можно сказать, что основание для деления над-объекта – это парадигма конструкции.
Конструкции человеческого тела часто рассматривается в двух парадигмах: одна называется внешнее строение человека, вторая — внутреннее строение. Внешнее строение описывает части человеческого тела: руки, ноги, голову, туловище. Внутреннее строение описывает подсистемы человека: кровеносную, пищеварительную, нервную и проч. Внешнее строение равносильно пространственному делению здания на помещения. Внутреннее строение равносильно функциональному делению здания по подсистемы.
Классификация конструкций
Обычно мы рассматриваем конструкцию просто: вот над-объект, вот под-объекты, вот связи между под-объектами, которые объясняют нам свойства над-объекта. Мы будем классифицировать конструкции через классификацию элементов конструкции.
Элементы конструкции принадлежат тому же классу, что и объект
Рассмотрим конструкцию, в которой элементы принадлежат тому же классу, что и над-объект. Например, вода состоит из частей, каждая из которых – тоже вода. Или куча песка, элементы которой – тоже кучи песка. Если объект делится подобным образом, то для него зачастую можно ввести меру. Это — особенность такого рода конструкций. Например, масса объекта равна сумме масс ее частей, площадь фигуры равна сумме площадей ее частей, объем материи равен сумме объемов ее частей и тд. Рассмотрим пример менее очевидный. Пусть есть операция и ее части – под-операции. Тогда мерой может стать ее четырехмерный объем. Пример: человек выполнял операцию 4 часа. Объем операции– 4 человеко-часа. Пусть мы разделили операцию на 4 под-операции. Каждая под-операция пусть имеет объем – 1 человеко-час. Таким образом, сумма объемов под-операций равна объему над-операции.
Заблуждение
Замечу, что многие здесь сделают ошибку и подумают, что я говорил о понятии операции. Нет, в данном контексте речь шла о конкретной операции, совершенной Васильевым с 12-00 по 16-00 12-го апреля 2016 года. Если же говорить о понятии операции, то нельзя сказать, что понятие длится 4 часа. Можно сказать, что операции подобного типа длятся в среднем 4 часа. Я же часто (даже от ведущих аналитиков) слышу ошибочные высказывания на эту тему. Они говорят, что операция, которую они обозначили в нотации BPMN в виде прямоугольника длится 4 часа. Но нотация BPMN не моделирует операции, она моделирует понятие операции. Поэтому в этой нотации нельзя сказать, сколько длится конкретная операция. В свойствах объекта, созданного в нотации BPMN может быть атрибут: средняя длительность операций данного типа, но не может быть атрибута длительность операции. В продукте Businessstudio именно так и сделано. В свойствах объекта, созданного в нотации EPC или в нотации можно указать распределение длительностей операций определенного типа. И это верно.
Примеры конструкций первого типа
Примеры подобных конструкций: операция по постройке дома представлена в виде конструкции, состоящей из операций, которую мы наблюдаем на сетевом графике строительства дома. Диаграмма в нотации IDEF0 моделирует конструкцию функции, состоящую из функций.
Ошибочный пример: некоторые могут подумать, что на диаграмме BPMN подпроцесс – это конструкция операции, но это не так. На диаграмме BPMN нет моделей операций. Там есть концептуальные модели операций. Очень похоже на определение понятия, и так оно и есть. Квадратик в BPMN моделирует не операцию, а понятие об операции. Диаграмма в нотации BPMN – концептуальная модель, а не модель объекта.
Класс конструкций, в котором элементы принадлежат одному классу
Конструкция такого рода состоит из элементов, относящихся к одному классу в то время, как над-объект относится к другому классу.
Например, конкретная будка состоит из конкретных четырех досок. Понятно, что объем будки не равен сумме объемов досок, поэтому ввести меру не удастся. Пример из описания активности: операция состоит из участников. Мы воспринимаем участников как материальные, либо как функциональные объекты, но не воспринимаем их как операции. В данном случае я опять хочу подчеркнуть, что мы говорим не о концептах операций, модель которых можно найти в нотациях BPMN, а об операциях, модели которых можно найти на диаграммах Ганта. Например, участниками операции «забить гвоздь», которая состоялась в 9-00 13-го мая 2011 года были: Сидоров, молоток, гвоздь, две доски, табуретка, лампа, стол, помещение.
Если кто-то попытается сказать что-то подобное об объектах, созданных в нотации BPMN, то это должно звучать так: каждая операция данного типа, модель которого (типа) мы видим в нотации BPMN, имеет участников перечисленных далее типов:… Например, в каждой операции типа «забить гвоздь» будут участвовать объекты следующих типов: «исполнитель», «гвоздь» и «молоток». Правда, есть исключения. Например, иногда в определении типа операции можно встретить ссылку не на тип участника, а на модель конкретного ресурса. Тогда речь идет о том, что в любой операции данного типа участником будет конкретный объект, а не объект какого-то типа, например, в каждой операции класса «получить согласование на постройку здания» указан участник: администрация города Москвы (объект).
Все объекты конструкции принадлежат разным классам
Следующий кейс наиболее распространен: объекты над- и под- относятся к разным классам. Например, трансформатор состоит из сердечника и двух обмоток. В применении к описанию активности можно рассмотреть предыдущий пример в разрезе того, что исполнители относятся к разным классам. Сидоров – к людям, молоток – к инструментам, а гвоздь – к материалам. Все зависит от того, как мы классифицируем объекты.
Описание конструкции без перечисления ее элементов
Следующий кейс посложнее. Мы говорим о конструкции, в которой нет перечисления ее элементов, но есть упоминание о типах объектов, из которых состоит конструкция. Например, здание состоит из кирпичей. Конкретное здание состоит из объектов типа «кирпич». Нет перечисления конкретных кирпичей, но есть указание типа, к которому относятся эти объекты. Моделирование таких конструкций довольно затруднено в современных языках моделирования. Дело в том, что для моделирования таких утверждений нужны предикаты второго порядка. Но языков, которые были бы заточены для моделирования предикатов второго порядка, нет. Причина этого в том, что, если модель, созданная в предикатах первого порядка вычислима, то модель в предикатах второго порядка — нет. То есть, на основе фактов, записанных в предикатах первого порядка, можно строить однозначные выводы. Если же модель построена в предикатах второго порядка, то выводы могут быть только с некоторой долей вероятности. Например, если мы говорим, что лес состоит из осин на 60 процентов и из берез на 30 процентов (остальные деревья относятся к другим породам), то сказать наверняка о породе произвольно взятого дерева в этом лесу можно будет только с некоторой долей вероятности.
Создание ИС ставит перед собой задачу автоматизации некоторых операций. Чаще всего, это детерминированные операции, в которых нет места вероятностным исходам. Программисты в большинстве своем решают именно такие задачи. Поэтому все их инструменты заточены под моделирование предикатов первого порядка, ООП в частности. Поэтому там, где надо моделировать предикаты второго порядка, ООП не справляется.
Примеры
Можно подумать, что такой кейс и правда редкий, однако, моделирование активности предприятия напрямую связано с моделированием такого рода отношений между объектами. Например, мы моделируем конструкцию бизнес-функции. Есть три распространенных способа представить ее конструкцию (парадигмы конструкции). Первый способ был упомянут выше – над-функция представляется в виде конструкции, состоящей из под-функций (нотация IDEF0). Второй способ – конструкция функции состоит из набора ее участников (например, функция продаж состоит из продавца, потенциального покупателя и товара). Этот тип конструкции моделируется в нотации IDEF0 при помощи стрелок, входящих в квадрат «снизу». Третий тип конструкций соответствует текущему кейсу: функция состоит из операций определенного типа. Например, функция продаж состоит из операций по продаже товаров. Функция – объект, операция – объект. Операции по продаже – объекты одного типа. То есть тезис о том, что здание состоит из кирпичей похож на тезис: функция состоит из операций определенного типа. Языка для моделирования такого рода утверждений нет. Как я уже говорил, причина в том, что это утверждение в предикатах второго порядка. Еще один пример такого рода утверждений: кристалл состоит из атомов. Через аналогию с кристаллом мы перейдем к самому сложному для понимания кейсу, связанному с описанием конструкций.
Конструкция из ячеек с объектами разных типов
Пусть есть кристалл. До сего момента мы не рассматривали связи между элементами конструкции как часть конструкции. С этого момента связи нам понадобятся. Понятно, что разделение объекта на части требует описания связей между элементами. При делении на перечисляемые элементы мы можем перечислить и все связи между элементами. Однако, при делении на объекты одного типа без перечисления всех элементов возникает вопрос о том, как описать связи между элементами конструкции? Например, в здании большинство кирпичей имеют связи с другими кирпичами через кладочный раствор. Тогда мы говорим, что здание состоит из кирпичей, каждый кирпич имеет связи с соседними кирпичами. При этом 60 процентов кирпичей имеют 5 соседей, 30 процентов – 4 соседа, 5 процентов – 3 соседа и 5 процентов- 2 соседа. Таким образом, для любого выбранного кирпича из первой группы найдется пять, которые тоже являются частью здания и которые связаны с выбранным кирпичом через кладочный раствор. Теперь напишем то же утверждение относительно бизнес-функции. Функция по продаже состоит из операций по продаже. Предположим, что операции следуют одна за другой. Тогда мы можем сказать, что для любой операции существует предшествующая ей операция того же типа и существует последующая ей операция того же типа. Так мы смоделировали тип связи в конструкции, которая описана типами объектов, но не объектами. Теперь представим себе кристалл более сложного строения, в котором участвуют атомы разных элементов и расположены в сложной кристаллической решетке. Как описать строение такого кристалла? Те, кто занимается описанием и классификацией кристаллов, знают, что способов описания такого рода решетки – бесконечно много. Например, пусть есть одномерная цепочка атомов двух разных типов А и В, чередующихся друг с другом с шагом в один ангстрем. Можно сказать, что кристалл состоит из ячеек, каждая из которых состоит из атомов типа А и В, расположенных через 1 ангстрем, сдвиг между ячейками — 2 ангстрема. (Также верным будет утверждение о том, что кристалл состоит из ячеек, каждая из которых состоит из атомов типа А и В, расположенных через 3 ангстрема. Сдвиг между ячейками – 2 ангстрема и ячейки пересекаются в пространстве. Каждая такая регулярная структура видна на ренгенограмме кристалла. Чтобы ограничить количество вариантов обычно берут наиболее близко расположенные атомы). С другой стороны, можно сказать, что кристалл состоит из атомов двух типов: А и В. Это утверждение похоже на предыдущее, но отличается от него тем, что в первом случае конструкция кристалла состоит из ячеек, а конструкция ячеек, в свою очередь, — из атомов. Во втором случае конструкция кристалла напрямую состоит из атомов. Другой пример: пусть в функции продаж выполняются два типа операций: согласование условий и отгрузка товара. Можно сказать, что функция состоит из ячеек, в каждой из которых есть операция по согласованию условий и операция по отгрузке товара. А можно сказать: функция состоит из операций по согласованию условий и операций по отгрузке товаров. Это два разных утверждения.
Выбор последовательности элементов в типовой ячейке
Посмотрим на последовательность операций: АВАВАВАВ… Мы видим, что цепочка бесконечная и начинать выделение ячеек можно с любого места. Например, сначала птица Феникс родилась из пепла, затем она сгорела, затем родилась из пепла, затем сгорела. Или: сначала птица Феникс сгорела, затем родилась из пепла, затем снова сгорела. Ячейку можно начать в любом месте. Поэтому, чтобы иметь основания для начала, выбирают некоторое условие, которое выполняется для всех операций ячейки. Например, все операции относятся к одной сделке. Условия могут быть любыми, и в общем случае ячейка может начинаться с операции любого типа. Аналитики обычно этого не знают и, чтобы как-то оправдать выбор начальной операции в ячейке, гипнотизируют себя мыслями о том, что цепочка должна иметь мистическую цель. Вместо того, чтобы сказать, что операции в цепочке могут быть объединены в группу по какому-то (в общем случае произвольному) признаку, аналитики придумывают алхимические формулы. Более того, эта алхимия присутствует в определении процесса.
Моделирование предикатов второго порядка при помощи OWL
Стандарт OWL Full позволяет моделировать высказывания второго порядка благодаря тому, что в роли предметов высказывания в нем могут выступать как объекты, так и классы (множества объектов) и даже типы связей, которые могут существовать между объектами (предикаты). Все эти виды сущностей для OWL являются узлами графа, ребра в котором – конкретные утверждения.
Высказывания второго порядка, записанные в виде OWL, как правило, не обеспечивают вычислимости (возможности получения выводов средствами машин логического вывода). Однако не стоит считать это препятствием для реализации автоматизированных систем. В большинстве случаев работа с OWL-моделями происходит в прикладном программном коде и учитывает особенности и ограничения конкретной задачи, а не претендует на «вычисление всего». На практике полностью полагаться на стандартный логический вывод не получается даже при работе даже с высказываниями первого порядка – при большом объеме и разнообразии данных такие задачи требуют слишком больших вычислительных ресурсов.
Существует несколько способов моделирования высказываний о классах на языке OWL. Один из наиболее практически удобных способов состоит в введении специальных классов, объекты которых представляют собой высказывания о классах или предикатах. Приведем пример (для не знакомых со стандартом запишем его на естественном языке):
- Существует класс «Здание»
- Существует класс «Кирпич»
- Существует класс «Требование к составу объекта»
- Существует связь «Относится к объектам класса» между объектами класса «Требование к составу объекта» и классами
- Существует связь «Должны иметь в составе» между объектами класса «Требование к составу объекта» и классами
- Существует объект A, относящийся к классу «Требование к составу объекта», имеющий следующие связи:
- Требование А – относится к объектам – класс «Здание» (это высказывание можно записать как предикат: Относится к объектам (Требование А, класс «Здание») ).
- Требование А – должны иметь в составе – класс «Кирпич»
Можно обобщить функционал требований – изъять из названия класса слова «… к составу объекта», а в число связей класса «Требование» включить указание на предикат, к которому оно относится («Состоит из», «Расположен в»). Таким же способом можно исключить из названия класса и модальность («должен», «может» и др.). Тогда класс будет называться даже не «Требование», а «Утверждение» или «Аксиома». Это добавит полноценный второй уровень к структуре модели, представленной в виде графа. Выбор уровня формализма зависит исключительно от решаемой прикладной задачи.
Автоматизированная система считывает и интерпретирует приведенные выше высказывания, например, таким образом: в составе каждого объекта класса «Здание» должен присутствовать хотя бы один объект класса «Кирпич». Можно и не опускаться на уровень конкретных кирпичей, интерпретируя высказывание по-другому – как утверждение о том, что здание в принципе состоит из объектов класса «Кирпич» (каких именно – не известно). В таком случае могут использоваться другие высказывания о классе «Кирпич» – например о том, что кирпичи (то есть все объекты класса «Кирпич») имеют определенную плотность, массу, теплопроводность и др. Из этого программа сможет сделать вывод о свойствах здания.
В любом случае эта логика – способность интерпретировать объекты класса «Требование к составу объекта» как требования – должна быть заложена в коде, что допустимо в рамках решения конкретных прикладных задач.
Можно пойти немного другим путем – ставить классы не только на вторую позицию в предикате, но и на первую, то есть делать высказывания о классах как таковых:
- Существует класс «Здание»
- Существует класс «Кирпич»
- Существует связь (предикат) «Должен включать объекты, имеющие в составе только объекты класса» между классами и классами
- Класс «Здание» – должен включать объекты, имеющие в составе только объекты класса – класс «Кирпич»
Интерпретация утверждений такого рода, конечно, тоже остается на прикладном программном обеспечении.
Заметим, что некоторые утверждения о классах можно делать и в рамках более строгого формализма OWL, не теряя вычислимости модели при помощи стандартных машин логического вывода. Это достигается использованием ограничений значений свойств (кардинальностей) с квантификаторами: some, only, exactly и др. Еще один способ записи нашего примера таков:
- Существует класс «Здание»
- Существует класс «Кирпич»
- Существует связь «Состоит из»
- Класс «Здание» есть подкласс анонимного класса, для объектов которого значением связи «Состоит из» являются объекты класса «Кирпич»
При сохранении такого высказывания в граф образуются так называемые «пустые узлы». В данном случае пустым узлом будет анонимный класс, для которого задано ограничение. В соответствии с замыслом стандарта OWL, пустые узлы представляют собой утверждения с квантором существования – то есть, в нашем случае, утверждение о том, что существуют такие объекты, которые состоят из кирпичей. Подклассом таких объектов являются здания.
Такая конструкция довольно громоздка, а правила логического вывода – медленны и капризны в применении, поэтому на практике обычно проще обойтись первым или вторым способом.
Заметим, что все это время мы обсуждали высказывание «Здание состоит из кирпичей», смысл которого с логической точки зрения не слишком точен. Не понятно, что мы хотели сказать:
- Что все, что состоит из кирпичей, есть здание,
- Что здание должно состоять только из кирпичей,
- Что здание состоит в том числе и из кирпичей,
и так далее. При реализации автоматизированной системы такие смысловые «люфты» необходимо устранять. Именно поэтому в начале статьи я сразу дал определения терминам, которые буду употреблять в рамках текущей статьи.
Смешанные конструкции
Вернемся к конструкции дерева и посмотрим на тезис: дерево состоит из ветвей, ствола и корней. Этот тезис говорит о том, что конструкция дерева состоит из объекта – ствола и объектов двух разных типов — ветвей и корней.
Пример псевдоконструкции
Рассмотрим частый случай, когда строится диаграмма в нотации IDEF0. Затем одна из функций на этой диаграмме, как часто говорят, «декомпозируется» на диаграмму в нотации BPMN. Это можно встретить в упомянутой мной ранее программе Businessstudio. Поскольку функция – это объект в предметной области, а диаграмма в нотации BPMN – это модель понятия, то мы видим, что происходит ошибка: функция делится на понятие. Этого быть не может. Функция может делиться на ячейки с операциями. В каждой ячейке несколько операций, связанных между собой темпоральными связями. Для всех ячеек вводится понятие ячейки подобного типа. Это понятие моделируется в нотации BPMN. Так будет правильно.
Корреляция конструкций в двух разных парадигмах
Часто встречающийся способ описания объекта выглядит так: рассмотрим конструкцию объекта в двух разных парадигмах, например в парадигме «внешнего» и «внутреннего» строения. Тогда мы пойдем делить объект на части двумя совершенно разными способами. Например, здание будем делить с одной стороны на помещения, а с другой — на технические подсистемы. И вот тут срабатывает очень важный фактор, который мы, как правило, не замечаем, но он работает на уровне интуиции. Мы делим объект на части в двух разных парадигмах таким способом, что между элементами конструкций в двух разных парадигмах тоже можно установить соответствие. Например, после деления здания на помещения и подсистемы мы можем сказать, что и помещения можно поделить на части — части тех подсистем, которые находятся в этих помещениях. То есть, деление на части в двух разных парадигмах интуитивно делается зависимым друг от друга образом. И это отнюдь не очевидно. Современные стандарты инженерного проектирования основаны именно на таком делении объекта, хотя, я уверен, что в них нет прописанного требования о подобном ограничении на моделирование.
Комментарии (52)
maxstroy
02.05.2017 17:03+1Функция «Продажи телефонов в магазине номер 7 по улице Бр. Грин» делится на две под-функции: «Достижение договоренностей с покупателями» и функцию «Отгрузки телефонов». Функция «Продажи..» делится на множество операций класса «Продажа конкретного телефона», каждая из которых (операций) делится на операции:«договориться с конкретным покупателем» и «отгрузить конкретный телефон». Пока нет противоречий
Как здание состоит из кирпичей, так и функция — из операций. Однако, я привел пример коррелированного деления на части, о котором я говорил в конце статьи, потому что функция «Отгрузка телефонов» тоже делится на операции «Отгрузка конкретного телефона», что произошло, потому что мы так сделали намеренно.
vvagr
04.05.2017 23:00Вы сказали то же самое, что написал я. На уровне классов есть только два уровня:
Функция «Продажи телефонов в магазине номер 7 по улице Бр. Грин» делится на две под-функции: «Достижение договоренностей с покупателями» и функцию «Отгрузки телефонов».
Не надо тут про конкретный магазин, это просто про «Продажи телефонов в магазине». Два уровня.
На уровне индивидов — три уровня, образующие однородную холархию:
Функция «Продажи телефонов в магазине номер 7 по улице Бр. Грин» делится на множество операций класса «Продажа конкретного телефона», каждая из которых (операций) делится на операции:«договориться с конкретным покупателем» и «отгрузить конкретный телефон».
Нет никакой сложной ситуации трёх уровней, о которой напсиано в исходной статье.maxstroy
05.05.2017 09:02Не надо тут про конкретный магазин, это просто про «Продажи телефонов в магазине»
Я рассматриваю конкретный магазин и его функцию — продажи телефонов. Что мешает мне назвать функцию магазина, как «продажа телефонов в магазине номер 7»? Затем эту функцию представить в виде конструкции, состоящую из двух функций: «Достижение договоренностей с покупателями в магазине номер 7» и функцию «Отгрузки телефонов в магазине номер 7». Затем каждую из этих функций поделить на операции. Нет ничего странного и необычного в этом. Это называется описание деятельность (активности) конкретного предприятия. Есть возражения к тому, что я сказал?vvagr
05.05.2017 14:40Что мешает мне назвать функцию магазина, как «продажа телефонов в магазине номер 7»? Затем эту функцию представить в виде конструкции, состоящую из двух функций: «Достижение договоренностей с покупателями в магазине номер 7» и функцию «Отгрузки телефонов в магазине номер 7». Затем каждую из этих функций поделить на операции.
Это обычная декомпозиция функции на подфункции, два уровня. Почему вдруг «функции» поменялись на «операции» на втором шаге? Или разверните пример дальше — что там за «операции»?maxstroy
05.05.2017 14:49Любую функцию можно поделить на части как минимум, шестью разными способами, описанными мной далее. На любом шаге декомпозиции.
vvagr
05.05.2017 14:55Ладно, разговор становится не очень осмыслен. Могу лишь повторить основные мысли за ISO 15926 —
Для принципиального моделирования систем на уровне индивидов достаточно двух основных типов 4D объектов — функциональные и физические. И одного отношения — часть-целое. На уровне классов и классов классов объектов и отношений достаточно обычных теоретико-множественных отношений.
Далее можно придумывать сотни разных полезных бизнесу разбиений. Задача модельера данных — уметь определять их в рамках ограничений методологии, а не критиковать методологию и отказываться от стандарта, расширяя его до этой сотни и далее.maxstroy
05.05.2017 15:11Допустим, что объектов два типа: функциональные и физические, хотя я знаю еще как минимум, — материальные активы, а как максимум, каждая область человеческой деятельности порождает свои типы объектов.
При этом каждый функциональный объект можно поделить на части, каждый из которых является функциональным объектом. Количество таких разбиений — бесчисленное множество. Каждое разбиение необходимо для решения какой-то конкретной задачи. И здесь нет противоречия с ИСО. Количество конструкций объекта ограничено лишь нашим воображением. Насколько я помню, в ИСО нет ограничения на количество конструкций?
maxstroy
05.05.2017 15:19Свои тезисы я сформулировал в рамках обычных теоретико-множественных отношений. При помощи предикатов первого и второго порядков. Именно задача формулировки тезисов в таком виде и привела меня к задаче классификации конструкций.
maxstroy
05.05.2017 10:08Возможно, вас смущает название функции и вы думаете, что разные магазины обладают одинаковой функцией под названием «продажа телефонов». Назовите тогда функцию магазина номер 7 как-то бессмысленно: "%: ПОи шгмнишрл". Функцию другого магазина также бессмысленно: «ПЛОИИПЛОоилоил». а потом скажите, что функция "%: ПОи шгмнишрл" и функция «ПЛОИИПЛОоилоил» похожи, потому что и там и там участвуют объекты одного типа — телефоны! И вот ура! мы нашли нечто, что позволяет нам классифицировать две разные функции как похожие. Дальнейшее изучение их привело к тому, что мы придумали им общее название: «ПОРДОРТЛОР». и теперь обе функции называются одинаково, но от этого они не перестают быть разными. Затем мы можем объединить эти две функци в одну (построить из них конструкцию назвать эту большую функцию тем же именем. Получается ровно то же, что когад мы две части воды сливаем вместе и получаем одну большую часть воды.
maxstroy
05.05.2017 14:21Итак, мы можем привести пример уже четырех разных способов деления функции «продажи телефонов в магазине номер 7» на части.
Первый способ: функция «продажи телефонов в магазине номер 7» делится на две части: «продажи телефонов в отделе номер 1 магазина номер 7» и «продажи телефонов в отделе номер 2 магазина номер 7». Это как две части воды смешать вместе и получить снова воду.
Второй способ: функция «продажи телефонов в магазине номер 7» делится на две части: «согласование договоренностей с покупателями» и «отгрузка телефонов». Это все равно, что сказать: вода состоит из водорода и кислорода.
Третий способ: функция «продажи телефонов в магазине номер 7» делится на операции: «Продать телефон». Это все равно, что сказать: вода состоит из молекул воды.
Четвертый способ: функция «продажи телефонов в магазине номер 7» состоит из последовательностей операций: «договориться об условии продажи» и «отгрузить телефон». Это все равно, что сказать: вода состоит из молекул, каждая из которых состоит из атомов водорода и атомов кислорода, связанных между собой связями.
таким образом, мы получили четыре разных типа конструкций одного объекта.
maxstroy
05.05.2017 14:47Да, конечно, есть и другие способы деления, например:
Пятый способ: функция «продажи телефонов в магазине номер 7» делится на части: телефоны (одна часть, где телефоны объединены в один объект и воспринимаются нами как одно целое — поток телефонов), исполнители (другая часть, в которой все исполнители — одно целое. Здесь мы не видим поток, но видим один механизм) и клиенты (третья часть, в которой все клиенты воспринимаются как одно целое, или как поток клиентов). Это как сказать, что фонтан состоит из трех потоков воды.
Шестой способ: функция «продажи телефонов в магазине номер 7» делится на части: телефоны, которые не воспринимаются нами как единое целое (поток телефонов), а видятся наблюдателю отдельно, из исполнителей, которые тоже видятся индивидуально и клиентов, которые тоже воспринимаются отдельно. Этот способ деления похож на деление функции на операции, только деление тут происходит на объекты другого типа. Аналогия с водой та же.
Примеров деления теоретически неограниченное количество. Можно придумывать свои. Просто я описал лишь те, с которыми я встречался
michael_vostrikov
03.05.2017 21:06-1Они говорят, что операция, которую они обозначили в нотации 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. Начальная операция это та, без результата которой не могут выполниться другие операции. Таких операций может быть несколько, и тогда несколько процессов могут идти параллельно.
Современные стандарты инженерного проектирования основаны именно на таком делении объекта, хотя, я уверен, что в них нет прописанного требования о подобном ограничении на моделирование.
Потому что например часть кабелей может идти по стенам снаружи, между помещениями, или по воздуху от другого здания.
maxstroy
03.05.2017 23:31Про начальную операцию я придумал пример. Пусть у нас есть стиральная машинка, в которой мы стираем вещи клиентов. На входе у нас очередь клиентов с грязными вещами, на выходе — клиенты с чистыми. Мы принимаем заказ, стираем, отдаем клиенту белье. Какая операция начальная? Кажется, что прием заказа, ан нет! когда мы начали работать с системой, мы начали с того, что у нас в барабане уже были вещи клиента и первая операция, которую мы автоматизировали, — мы отдали клиенты его вещи, затем взяли новые и постирали. Начало было другим. Объединяет эти операции — пустое место, которое мы взяли у одного клиента и передали второму. Все зависит от объекта учета — учитываем ли мы вещи, или свободное пространство. Склад — пример такого рода учета, где учитывать можно как вещи, так и свободные места, торгую, фактически свободными местами. Просто инерция и привычка заставляют нас мыслить шаблонно. А иногда смена парадигмы сильно упрощает задачу.
michael_vostrikov
04.05.2017 07:44-1когда мы начали работать с системой, мы начали с того, что у нас в барабане уже были вещи клиента и первая операция, которую мы автоматизировали, — мы отдали клиенты его вещи, затем взяли новые и постирали
Откуда в барабане возьмутся вещи, если клиент первый и до него клиентов не было? Это и есть точка отсчета, от нее и надо считать.
Если вы будете считать операции от середины заказа, вам в пределах группы операций надо будет работать с 2 клиентами, 2 их заказами, и 2 наборами вещей. Кроме того, вам надо будет вводить особый вид "неполная операция", чтобы сделать учет первого и последнего заказа.
Склад — пример такого рода учета, где учитывать можно как вещи, так и свободные места, торгую, фактически свободными местами.
На складе важно то, что в нем хранится. От того, что вы будете знать, что у вас 10 мест свободно, вы не сможете узнать, можно ли утвердить заказ на отгрузку 20 ящиков гвоздей. Поэтому надо учитывать и товар и свободные места. То есть делать модель склада.
maxstroy
04.05.2017 17:25Мой склад — это множество пустых мест, которыми я торгую. Я предоставляю клиентам свободные места. Предварительно в склад были загружены 100 свободных мест. далее я распределяю их по клиентам. Я меняю пустое место на контейнер. За это клиент платит мне деньги. Предварительная загрузка свободными местами — есть запуск моего бизнеса. Если бы я начал с полного склада, я не смог бы продать свободные места и не смог бы вести бизнес. Поэтому начал я с того, что оборудовал склад пустыми местами. Я учитываю пустые места, а не контейнеры. Эта точка зрения распространена в морских перевозках. И именно так там построена модель управления складом. Если кому-то и надо учитывать клиентов, то не мне. Потому что мне все равно, кто придет за контейнером. Главное — он отдаст мне мое свободное место. Я рассказал точку зрения укладчика контейнеров. И она имеет место быть. С этой точки зрения начало работы — это разгрузка склада, или стиральной машинки. Все относительно, нет абсолютных начал и абсолютных точек зрения. Время, когда склад полон местами — он полон товаром и это плохо! Я должен сделать так, чтобы товар не залеживался на полках и у меня не было пустых мест
michael_vostrikov
04.05.2017 18:35-1Так это уже не столько склад, сколько аренда места. А склад это, место на складе, или участок на берегу, это уже неважно. Естественно, модель будет отличаться. Только начало все равно сдача места конкретному клиенту, а не выдача товара предыдущему. Потому что в случае первого клиента вы не можете разгрузить склад, так как он еще пустой.
maxstroy
04.05.2017 18:41У нас на физтехе было правило: если вы не можете придумать 50 разных способов посмотреть на одно и то же, значит, вы не физик. Стандартное мышление сильно нас ограничивает и заставляет видеть то, чего нет — начальные операции. Тот, кто может позволить себе фантазию, понимает, что нет ничего, что могло бы ограничить ее. Я придумал один пример, но могу много. Попробуйте просто допустить возможность разных точек зрения.
michael_vostrikov
04.05.2017 19:01Я вам на вашем примере и объяснил, что от зависимости по данным вы никуда не денетесь. На словах вы можете сделать вид, что ее нет, но программы от этого работать в соответствии с ними не будут. И смоделировать первую операцию таким образом вы не сможете.
maxstroy
04.05.2017 21:06Программа будет работать так, как мы ей скажем. Наличие начальной и конечной операции — ограничение тех нотаций, которые мы имеем, возьмем другую нотацию и ограничение уйдет. Такую нотацию мы разработали и она позволяет строить различные представления в зависимости от точек зрения.
maxstroy
03.05.2017 23:15Спасибо за комментарий! Начнем с того, что все примеры, которые вы привели мне знакомы, и потому я бы не сказал, что мне они неизвестны. Просто они не решают задачу. Объясню почему:
А подразумевают, что операции подобного типа длятся в среднем 4 часа.
Запомним этот тезис — он не мой, а ваш!
Поздравляю, вы начали понимать, чем отличается тип и экземпляр. Только называете их по-своему.
Вы только что сказали нечто, что противоречит предыдущему тезису. Если вы вводите понятие «экземпляр этой операции», то прежнее утверждение должно было звучать так:
А подразумевают, что экземпляры этой операции длятся в среднем 4 часа.
Почему это не имеет смысла в русском языке, я писал неоднократно ранее. Либо вы говорите, что мы моделируем операции, либо экземпляры этой операции. Но в предметной области есть операции, но нет экземпляров этой операции. Экземпляры появились в ООП и не надо тащить их в предметную область.
А это передача объекта по ссылке. В отличие от передачи по значению, например, строки с названием документа «Акт строительства здания N».
Вообще не понятно, что вы сказали. В моем кейсе нет ссылок, нет значений. При чем тут код и программирование — не ясно.
Зато довольно несложно в современных языках программирования.
Нет, я ни разу не видел в коде конструкций. Ни один программист мне не смог показать этот объект. Построить конструкцию — могут, но только с одной точки зрения, построить множество конструкций одного объекта с учетом множественности точек зрения — пока не видел.
Пример кода — пример того, как можно смоделировать лес только эта модель нерасширяема, выглядит как костыль, потому что не понятно, как класс осин связан с 'osina'? Или 'osina' — это обозначение класса объектов? Вроде нет.
Почему вы упорно утвержаете факты о вещах, которых толком не знаете?
Обо всех этих ограничениях я знаком от программистов, которые пытались построить подобные системы и обожглись на ООП. Пример я привел выше — 'osina' — это не класс.
Операции объединяются в группу по принадлежности какой-либо сделке. В терминах баз данных это внешний ключ deal_id. Начальная операция это та, без результата которой не могут выполниться другие операции. Таких операций может быть несколько, и тогда несколько процессов могут идти параллельно.
Принадлежность сделки — один из множества возможных критериев объединения объектов. Начальная операция не существует — мы автоматизируем лишь часть операций. ни одна из них не может быть сделана без включения компьютера в сеть. Просто наше окно на экране ограничено. Я же говорю об операциях, которые существуют в природе, а не на экране монитора, включая операцию по включению компьютера.
Потому что например часть кабелей может идти по стенам снаружи, между помещениями, или по воздуху от другого здания.
Это значит, что мы либо потеряем эти части, либо введем в модель пространства, по которому они идут. А введение модели пространства и есть необходимость сделать его частью модели.michael_vostrikov
04.05.2017 08:41-1Запомним этот тезис — он не мой, а ваш!
Вы только что сказали нечто, что противоречит предыдущему тезису. Если вы вводите понятие «экземпляр этой операции», то прежнее утверждение должно было звучать так:
А подразумевают, что экземпляры этой операции длятся в среднем 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), поэтому сложение здесь не может быть начальной операцией.
Я же говорю об операциях, которые существуют в природе, а не на экране монитора, включая операцию по включению компьютера.
Причем здесь включение компьютера? На принцип моделирования оно не влияет. Клиент и менеджер могут совершить сделку вообще без участия компьютера. Компьютер это просто средство моделирования, в модели предметной области он не участвует. Сторонний наблюдатель может строить модель предметной области в голове.
Вы можете группировать операции в природе как угодно, но зависимость между операциями, определяющая их порядок, от этого никуда не денется. Закрыть сделку (экземпляр) нельзя до ее открытия. Поэтому и в концептуальной модели сделки закрытие будет после открытия.
Это значит, что мы либо потеряем эти части, либо введем в модель пространства, по которому они идут. А введение модели пространства и есть необходимость сделать его частью модели.
Это относится только к пространственной парадигме, а не к любым парадигмам. Естественно, раз мы учитываем физические объекты, они занимают какое-то пространство. Но из этого не следует факт, что одна парадигма напрямую отображается в другую. Потому что у них могут быть разные физические размеры или они могут рассматривать не связанные друг с другом характеристики.
Помещение может быть вообще без освещения, и у электрической сети не будет участка, который ему соответствует.
Цвет окраски собаки от головы до хвоста никак не отображается на характеристики ее характера или пищеварительную систему.maxstroy
04.05.2017 17:35А подразумевают, что модели объектов (конкретные операции), соответствующие концептуальной модели (этому типу операций), длятся в среднем 4 часа.
Отлично! Вы только что сказали: операции данного типа в среднем длятся 4 часа. Именно это я и сказал. Так что в нашем тезисе не понадобилось вводить странный термин «экземпляр этого процесса».
«операции подобного типа» и «экземпляры этой операции»
Я никогда не говорю экземпляр операции, потому что незачем говорить масло масляное, если экземпляр операции указывает на операцию, то это и есть операция. Термин «экземпляр ввели вы, вы и объясните, что он значит. Операции подобного типа — это однотипные операции, похожие друг на друга. Например, два венских стула за номером 1213 и 356 похожи друг на друга и потому оба они — венские стулья. Две операции „забить гвоздь в 9-00“ и „забить гвоздь в 10-00“ — похожи, потому что и там и там присутствуют гвозди (объекты, похожие друг на друга), какие-то субъекты (биологические объекты, похожие друг на друга), и тд. Поэтому обе эти операции и называются: „забить гвоздь“. Поэтому обе эти операции похожи, или относятся к одному типу операций.michael_vostrikov
04.05.2017 18:57Так что в нашем тезисе не понадобилось вводить странный термин «экземпляр этого процесса».
Потому что он уже введен. Экземпляр это конкретная произведенная операция. Вы его называете по-другому, но само понятие от этого никуда не девается. По нескольким экземплярам мы можем построить статистику "длятся в среднем 4 часа". Выделяя одинаковые действия и свойства в некоторое описание мы задаем тип. Тип определяет множество возможных экземпляров. Значит, тип может иметь характеристику "средняя длительность", потому что средняя длительность считается как раз на основе экземпляров. Все сходится.
Поэтому обе эти операции и называются: „забить гвоздь“
Вот это и есть тип операций. Вы и сами это пишете. А "забить гвоздь в 9-00" и "забить гвоздь в 9-00" это экземпляры. И используются эти термины как раз чтобы избежать тавтологии типа "операция "забить гвоздь в 9-00" это операция "забить гвоздь"".
maxstroy
04.05.2017 21:11конкретная произведенная операция — это операция. По операциям мы делаем статистику, а не по экземплярам, потому что в предеметной области есть операции, но нет экземпляров. Экземпляр — это термин ООП, и его не надо тащить в предметную область. Тип определяет не множество экземпляров, а множество операций, Тип слона определяет слонов, а не экземпляры. Да — понятие, концепт, тип, — это все фактически синонимы, но все они определяют объекты, а не экземпляры объектов. Мы не говорим «операция „забить гвоздь в 9-00“ это операция „забить гвоздь“», мы говорим: «операция „забить гвоздь в 9-00“ относится к ТИПУ (классу) операций „забить гвоздь“. Потому что ваше утверждение равносильно следующему: Вот этот слон — это тип слонов. Но это оксюморон! Слон не может быть типом. Слон может принадлежать типу
michael_vostrikov
04.05.2017 21:57-1Это вы их называете просто операциями. А другие люди называют это экземплярами. Это одно понятие с разными названиями.
Потому что ваше утверждение равносильно следующему: Вот этот слон — это тип слонов.
У меня нет таких утверждений. Можно сказать, что этот слон — экземпляр (представитель) такого-то типа слонов (экземпляр типа "Слон Такой-то"). Или что это слон имеет тип такой-то. Или относится к типу такому-то.
И нет, "индийский" это не экземпляр типа слонов (не экземпляр типа "Индийский Слон"). Это экземпляр типа "ТипСлонов". Есть тип понятий "ТипСлонов", есть экземпляры этого типа "Индийский", "Африканский". Они в свою очередь тоже являются типами, типами слонов, и могут быть экземпляры этих типов, конкретные слоны. Такая терминология позволяет описывать иерархии любой сложности без путаницы типа "индийский слон это слон или нет". Есть типы и есть экземпляры.maxstroy
04.05.2017 22:26Говоря, что слон — это представитель такого-то типа слонов, вы говорите совершенно другой тезис, нежели сказал я. Вы говорите, что конкретный слон относится к подмножеству (специализированному) слонов, а я говорю: объект относится к типу слонов, что означает, что он из класса слонов, а не из его подмножества
michael_vostrikov
04.05.2017 23:06-1Так специализированные типы слонов обозначают подмножества более общего типа "Слон". Говоря что объект относится к типу "Индийский слон" мы тем самым говорим, что он относится и к типу "Слон". Разве нет?
maxstroy
05.05.2017 08:41Лучше вообще не вводить понятие Индийский слон, потому что в начале не было класса и подкласса, типа и подтипа, не надо было его и вводить что только запутало дискуссию. Надо вынырнуть на уровень слонов без каких-то индийских и начать сначала
maxstroy
04.05.2017 17:38Экземпляры это то, что вы называете «модель объекта».
Модель объекта не имеет отношения к экземпляру, потому что экземпляр всегда относится к понятию, а модель объекта еще не классифицирована, не названа и потому не может быть экземпляром какого-то типа объектов. Классификацию мы делаем потом, или не делаем вовсе.
maxstroy
04.05.2017 17:41Типы и экземпляры есть в любой предметной области, именно поэтому они и появились в ООП.
Типы и экземпляры есть в ООП, потому что она построена на MOF. MOF отражает логику Аристотеля и потому страшно устарела. Современные языки моделирования основаны на матлогике и оперируют предикатами и классами.michael_vostrikov
04.05.2017 19:09-1Тем не менее, в прошлой статье вы с помощью матлогики не смогли смоделировать регистрацию клиентов в ситуации "завтра открываем бизнес, придут клиенты, надо сделать модель их регистрации и по ней написать программу".
maxstroy
05.05.2017 08:44Вопрос содержал в себе противоречие. Мы не знаем придут ли клиенты, потому что мы ими не командуем и потому бессмысленно делать то, чего не будет. Придет первый клиент и мы создадим регистрацию этого факта в ИС, что он будет делать потом, снова зарегистрируем и запишем. Вот в чем была идея прошлого поста. Кейс был другой — у нас нет определенности в бизнесе. Когда определенность есть и все прозрачно, когда мы уже много раз проходили типовой сценарий и его откатали, мы можем создать его модель в ИС. Я же говорю про кейс, когда ничего этого не было и перед нами неизвестность. Статья рассматривала именно такой кейс.
michael_vostrikov
05.05.2017 19:02-1Но программы такие пишут и они работают. Раз работают, значит правильно моделируют будущие события. Будущие на момент написания программы.
maxstroy
04.05.2017 17:44Я показал, как термины программирования соотносятся с понятиями реальных ситуаций. Из чего следует, что при помощи программирования можно смоделировать эти ситуации.
Я хочу видеть в модели утверждение в предикатах. Я могу сделать костыль любого качества, но это все равно костыль. В языке моделирования нет возможности произнести это утверждение и потому он не предназначен для этого. А про костыли я знаю. Именно они помогают закрыть дыры в модели.michael_vostrikov
04.05.2017 19:16С чего вы взяли, что это костыль? Почему в программной модели должны быть предикаты, если в вашем описании их нет? ("администрация города Москвы (объект)")
maxstroy
04.05.2017 21:19Мое описание строится строго в предикатах. Определяется предикат: «участвует в» Предикат может связывать объекты, классы объектов. Например, предикат «участвует в» в контексте администрация «участвует в» «Любой операции данного множества» связывает объект (администрацию) с классом объектов «Операции данного типа» с квантором «Для любого объекта данного множества». Если перекладывать на код, мы должны создать класс операций, связать его с объектом и квантором. Но это невозможно, потому что ООП не работает с предикатами второго порядка — не может связать объект с классом семантической связью.
michael_vostrikov
04.05.2017 22:03"Объект участвует в любой операции данного множества" моделируется объявлением типа и объявлением объекта как составной части этого типа. В любых экземплярах этого типа будут участвовать эти объекты. Тип определяет множество, характеристики типа влияют на все объекты данного множества. Можно сказать, тип сам по себе подразумевает квантор "для всех" [объектов данного типа (экземпляров)].
maxstroy
04.05.2017 22:35Хорошо, этот кейс мы смогли решить, но только для конкретно этого случая, потому что не был смоделирован квантор. Он должен существовать отдельно от операций и от здания. Иначе мы смоделировали не квантор, а высказывание. А мне помимо высказывания нужна модель квантора, чтобы я мог использовать его в других моделях. Например, в модели тезиса: в операциях класса Б участвует служба ЧС. Повторюсь, квантор должен быть смоделирован отдельно.
michael_vostrikov
04.05.2017 22:56Если квантор будет смоделирован отдельно, то и его обработка будет смоделирована отдельно. Нет никаких проблем объявить типы для кванторов и задать их специализированную обработку. Язык программирования для того и предназначен. В конце концов, языки моделирования написаны на языках программирования.
maxstroy
05.05.2017 08:46Конечно, именно так и костылят на языках ООП, в самом языке этих конструкций нет. А создать все что угодно при помощи чего угодно — мы можем. Именно так мы и поступаем.
michael_vostrikov
05.05.2017 19:03Зачем вводить это в язык, если можно создать это существующими средствами языка?
maxstroy
04.05.2017 18:05Приведите конкретный пример. Те, которые вы уже привели, я показал, как можно смоделировать в программировании.
Пусть есть задача: есть объект, который с разных точек зрения может иметь разные конструкции. Эти конструкции разработаны разными специалистами и отражают строение объекта с разных точек зрения. При этом один и тот же вопрос относительно конструкции объекта должен возвращать разные значения в зависимости от того, кто задал этот вопрос и в какой из парадигм. Это трудоемкая задача и потому не решается в рамках стандартного фреймворка. Конечно, я могу построить его сам, но точно знаю, что в языке нет стандартных способов реализации этого класса задач. При этом решение простое — надо ввести объект класса «конструкция, связать ее с моделью субъекта — автора этой конструкции и начать строить модели в привязке к субъектам, которые постулировали наличие тех или иных объектов, тех или иных конструкций, тех или иных связей.michael_vostrikov
04.05.2017 19:43Вы считаете, что в программировании нельзя задать связь между объектами? Или ввести тип "Конструкция" со всеми необходимыми экземплярами? Или что в процедуру определения конструкции нельзя передать контекст или субъект? В языках программирования есть средства для реализации всего указанного.
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
maxstroy
04.05.2017 18:09osina это семантически значимое обозначение того, что означает число 0.6. И не употребляйте пожалуйста слово «класс», пишите «тип» или «множество» вы имеете в виду.
Если у нас в модели есть тип «Осина», и нам надо смоделировать эту связь, можно задать и по-другому:
В модели есть обозначение типа — это class of OSINA. Мне надо сказать, что лес состоит из объектов типа осина, то есть связать объект Лес с классом OSINA. Языковыми средствами я это сделать не могу.michael_vostrikov
04.05.2017 19:48-1Можете. Чем вас не устраивает связь 'type' => 'Osina'? Osina это обозначение типа. Видимо вы используете class в значении множество. Я вам в очередной раз напоминаю, что тип задает множество без перечисления всех элементов.
maxstroy
04.05.2017 21:24Мне не надо перечислять элементы множества, если мне неизвестны его элементы, но мне надо связать тип объектов с объектом, чтобы сказать — в лесу объекты такого типа. В ООП тип объектов моделируется при помощи конструкции Class of, например. Это значит, что в своем высказывании я должен связать этот clsss и объект. Поскольку это невозможно сделать, приходится моделировать это иначе — путем создания еще одного объекта «Osina». Получается, что мы дважды моделируем тип объектов.
michael_vostrikov
04.05.2017 22:07-1путем создания еще одного объекта «Osina»
Я не знаю, почему вы так решили, у меня ни в одном из примеров объект типа Osina не создается. Osina это название типа. Возможно, вы сталкивались с ООП на примере C++ или другого статического языка, там действительно нельзя сделать такую ссылку на тип. В динамических языках это несложно.
maxstroy
05.05.2017 08:47Как осина — название типа связано с осиной — объявлением класса?
michael_vostrikov
05.05.2017 19:04Если вы имеете в виду, что класс это множество, то тип определяет множество. Описываем тип, даем ему название, и тем самым обозначаем множество объектов такого типа.
maxstroy
04.05.2017 18:11Причем здесь включение компьютера? На принцип моделирования оно не влияет.
Да, верно тут я ошибся. Пример со складом лучше характеризует субъективность нашего представления о правильной последовательности, которая с разных точек зрения может быть разной. Главное — ее обозначить, понять причину, по которой выбрана точка нулевого отсчета и внести это в модель. Но тогда сильно меняется определение процесса, о чем я сказал в статье.
maxstroy
04.05.2017 18:15Но из этого не следует факт, что одна парадигма напрямую отображается в другую.
Да, верно. Спасибо! Надо поглубже покопать, зачем же все-таки люди делают коррелированные конструкции непроизвольно.
vvagr
А Вы правда не видите ошибки в рассуждении:
«Есть три распространенных способа представить ее конструкцию (парадигмы конструкции). Первый способ был упомянут выше – над-функция представляется в виде конструкции, состоящей из под-функций (нотация IDEF0).… Третий тип конструкций соответствует текущему кейсу: функция состоит из операций определенного типа. Например, функция продаж состоит из операций по продаже товаров.»
?
Если мы находимся на уровне индивидов (Ваших «конкретных объектов»), то первый и третий — это разные уровни холархии. Сперва индивид «функция» разбивается на индивиды «операции», потом индивиды «операции» — на индивиды «подфункции».
Если мы находимся на уровне классов", то никакого «третьего способа» нет.
А если перескакивать между уровнями, то можно найти много трудностей на ровном месте.