Comments 52
«Есть три распространенных способа представить ее конструкцию (парадигмы конструкции). Первый способ был упомянут выше – над-функция представляется в виде конструкции, состоящей из под-функций (нотация IDEF0).… Третий тип конструкций соответствует текущему кейсу: функция состоит из операций определенного типа. Например, функция продаж состоит из операций по продаже товаров.»
?
Если мы находимся на уровне индивидов (Ваших «конкретных объектов»), то первый и третий — это разные уровни холархии. Сперва индивид «функция» разбивается на индивиды «операции», потом индивиды «операции» — на индивиды «подфункции».
Если мы находимся на уровне классов", то никакого «третьего способа» нет.
А если перескакивать между уровнями, то можно найти много трудностей на ровном месте.
Как здание состоит из кирпичей, так и функция — из операций. Однако, я привел пример коррелированного деления на части, о котором я говорил в конце статьи, потому что функция «Отгрузка телефонов» тоже делится на операции «Отгрузка конкретного телефона», что произошло, потому что мы так сделали намеренно.
Функция «Продажи телефонов в магазине номер 7 по улице Бр. Грин» делится на две под-функции: «Достижение договоренностей с покупателями» и функцию «Отгрузки телефонов».
Не надо тут про конкретный магазин, это просто про «Продажи телефонов в магазине». Два уровня.
На уровне индивидов — три уровня, образующие однородную холархию:
Функция «Продажи телефонов в магазине номер 7 по улице Бр. Грин» делится на множество операций класса «Продажа конкретного телефона», каждая из которых (операций) делится на операции:«договориться с конкретным покупателем» и «отгрузить конкретный телефон».
Нет никакой сложной ситуации трёх уровней, о которой напсиано в исходной статье.
Не надо тут про конкретный магазин, это просто про «Продажи телефонов в магазине»
Я рассматриваю конкретный магазин и его функцию — продажи телефонов. Что мешает мне назвать функцию магазина, как «продажа телефонов в магазине номер 7»? Затем эту функцию представить в виде конструкции, состоящую из двух функций: «Достижение договоренностей с покупателями в магазине номер 7» и функцию «Отгрузки телефонов в магазине номер 7». Затем каждую из этих функций поделить на операции. Нет ничего странного и необычного в этом. Это называется описание деятельность (активности) конкретного предприятия. Есть возражения к тому, что я сказал?
Что мешает мне назвать функцию магазина, как «продажа телефонов в магазине номер 7»? Затем эту функцию представить в виде конструкции, состоящую из двух функций: «Достижение договоренностей с покупателями в магазине номер 7» и функцию «Отгрузки телефонов в магазине номер 7». Затем каждую из этих функций поделить на операции.
Это обычная декомпозиция функции на подфункции, два уровня. Почему вдруг «функции» поменялись на «операции» на втором шаге? Или разверните пример дальше — что там за «операции»?
Для принципиального моделирования систем на уровне индивидов достаточно двух основных типов 4D объектов — функциональные и физические. И одного отношения — часть-целое. На уровне классов и классов классов объектов и отношений достаточно обычных теоретико-множественных отношений.
Далее можно придумывать сотни разных полезных бизнесу разбиений. Задача модельера данных — уметь определять их в рамках ограничений методологии, а не критиковать методологию и отказываться от стандарта, расширяя его до этой сотни и далее.
При этом каждый функциональный объект можно поделить на части, каждый из которых является функциональным объектом. Количество таких разбиений — бесчисленное множество. Каждое разбиение необходимо для решения какой-то конкретной задачи. И здесь нет противоречия с ИСО. Количество конструкций объекта ограничено лишь нашим воображением. Насколько я помню, в ИСО нет ограничения на количество конструкций?
Первый способ: функция «продажи телефонов в магазине номер 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 ящиков гвоздей. Поэтому надо учитывать и товар и свободные места. То есть делать модель склада.
Так это уже не столько склад, сколько аренда места. А склад это, место на складе, или участок на берегу, это уже неважно. Естественно, модель будет отличаться. Только начало все равно сдача места конкретному клиенту, а не выдача товара предыдущему. Потому что в случае первого клиента вы не можете разгрузить склад, так как он еще пустой.
Я вам на вашем примере и объяснил, что от зависимости по данным вы никуда не денетесь. На словах вы можете сделать вид, что ее нет, но программы от этого работать в соответствии с ними не будут. И смоделировать первую операцию таким образом вы не сможете.
А подразумевают, что операции подобного типа длятся в среднем 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" это операция "забить гвоздь"".
Это вы их называете просто операциями. А другие люди называют это экземплярами. Это одно понятие с разными названиями.
Потому что ваше утверждение равносильно следующему: Вот этот слон — это тип слонов.
У меня нет таких утверждений. Можно сказать, что этот слон — экземпляр (представитель) такого-то типа слонов (экземпляр типа "Слон Такой-то"). Или что это слон имеет тип такой-то. Или относится к типу такому-то.
И нет, "индийский" это не экземпляр типа слонов (не экземпляр типа "Индийский Слон"). Это экземпляр типа "ТипСлонов". Есть тип понятий "ТипСлонов", есть экземпляры этого типа "Индийский", "Африканский". Они в свою очередь тоже являются типами, типами слонов, и могут быть экземпляры этих типов, конкретные слоны. Такая терминология позволяет описывать иерархии любой сложности без путаницы типа "индийский слон это слон или нет". Есть типы и есть экземпляры.
Так специализированные типы слонов обозначают подмножества более общего типа "Слон". Говоря что объект относится к типу "Индийский слон" мы тем самым говорим, что он относится и к типу "Слон". Разве нет?
Экземпляры это то, что вы называете «модель объекта».
Модель объекта не имеет отношения к экземпляру, потому что экземпляр всегда относится к понятию, а модель объекта еще не классифицирована, не названа и потому не может быть экземпляром какого-то типа объектов. Классификацию мы делаем потом, или не делаем вовсе.
Типы и экземпляры есть в любой предметной области, именно поэтому они и появились в ООП.
Типы и экземпляры есть в ООП, потому что она построена на 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 в значении множество. Я вам в очередной раз напоминаю, что тип задает множество без перечисления всех элементов.
путем создания еще одного объекта «Osina»
Я не знаю, почему вы так решили, у меня ни в одном из примеров объект типа Osina не создается. Osina это название типа. Возможно, вы сталкивались с ООП на примере C++ или другого статического языка, там действительно нельзя сделать такую ссылку на тип. В динамических языках это несложно.
Причем здесь включение компьютера? На принцип моделирования оно не влияет.
Да, верно тут я ошибся. Пример со складом лучше характеризует субъективность нашего представления о правильной последовательности, которая с разных точек зрения может быть разной. Главное — ее обозначить, понять причину, по которой выбрана точка нулевого отсчета и внести это в модель. Но тогда сильно меняется определение процесса, о чем я сказал в статье.
Но из этого не следует факт, что одна парадигма напрямую отображается в другую.
Да, верно. Спасибо! Надо поглубже покопать, зачем же все-таки люди делают коррелированные конструкции непроизвольно.
Классификация конструкций: примеры и заблуждения