Comments 51
Есть нотация BPMN. Эта нотация предназначена для моделирования типовых сценариев, но в ней нельзя создать модель индивидуального сценария.
Чем отличается моделирование типового сценария от индивидуального в вашем понимании?
конкретный индивидуальный сценарий отличается от типового тем же, чем индивидуальный проект дома от типового. Я постарался очень подробно описать это различие в тексте. Поэтому вопрос: что именно было плохо объяснено?
Проекты домов будут отличаться только спецификой реальзации. Нотации описания данных проектов будут абсолютно одинаковы: Чертежи, сметы и т.д. Или вы считаете что для каждого индивидуального проекта дома будут изобретены новые правила выполнения чертежей и смет?
Поэтому вопрос по нотации и вызывает столько вопросов.
Поэтому вопрос по нотации и вызывает столько вопросов.
Нотации описания данных проектов будут абсолютно одинаковы: Чертежи, сметы и т.д. Или вы считаете что для каждого индивидуального проекта дома будут изобретены новые правила выполнения чертежей и смет?
Условные обозначения в документах действительно одинаковые для всех документов. Иначе мы не смогли бы их читать. Но количество документов, которые можно построить на основе этих обозначений, — бесконечно много.
Так в нашем случае — правила описания сценариев — одни для всех сценариев, но разные для каждого сценария. При этом в типовом сценарии могут быть элементы, которых нет в индивидуальном, например, указание различий в исполнении в зависимости от времени года, а в индивидуальном есть элементы, которых нет в типовом, например, дата начала выполнения сценария
Я понимаю вроде бы чем отличаются сценарии, я не понимаю чем отличается их моделирование, тем более в BPMN. В BPMN не хватает каких-то сущностей или связей между ними, чтобы моделировать индивидуальные сценарии? Или вам не хватает чего-то вроде наследования, что бы указать «этот сценарий является индивидуальным. базовый у него такой-то, отличия от него такие-то?», чтобы индивидуальные сценарии автоматически изменялись с базовым, если, скажем, мы поменяли тип какого-то этапа с ручного на автоматический?
А в целом я не вижу в BPMN проблем держать типовой процесс как шаблон для индивидуальных. Наметились отличия — скопипастили и правим. Можно даже заводить глобальный объединяющий типовой с индивидуальными с анализом какого-то условия типа номера договора для выбора или типового или одного из десятков-сотен-тысяч-… индивидуальных (а-ля switch {case: case: default:}).
А в целом я не вижу в BPMN проблем держать типовой процесс как шаблон для индивидуальных. Наметились отличия — скопипастили и правим. Можно даже заводить глобальный объединяющий типовой с индивидуальными с анализом какого-то условия типа номера договора для выбора или типового или одного из десятков-сотен-тысяч-… индивидуальных (а-ля switch {case: case: default:}).
Я понимаю вроде бы чем отличаются сценарии, я не понимаю чем отличается их моделирование
Атрибуты у них разные. Если у сценария есть правило для ветвления, то в типовом — правило для создания правил ветвления. То есть в первом случае это будет звучать так: если сумма сделки больше 100 рублей, то пойдешь направо, если меньше — налево. Во втором кейсе это звучит так: Каждый раз, когда вы столкнетесь с подобной ситуацией, рекомендация следующая: Если сумма текущей сделки больше 100, то ходите направо, где бы вы не находились при этом, но следите, чтобы не упасть. В противном случае ходите налево, но также смотрите по сторонам. Если налево или направо пойти нельзя, используйте все свои знания и опыт, чтобы адаптировать типовой сценарий под конретные нужды.
Мы используем нотацию BPMN2 для написания сценариев. В BPMN2 есть понятие UserTask для организации интерфейса с пользователем. UserTask могут быть назначены в явном виде как для конкретного пользователя системы, так и для группы пользователей. Также вместо явного указания пользователя или группы можно указать переменную процесса, значение которой можно менять в самом процессе в зависимости от различных событий. Так что мне также не совсем понятно Ваше утверждение по поводу того, чем типовой сценарий отличается от индивидуального.
Пусть у нас есть база данных, в которой хранятся данные о произошедших событиях: операциях. Пусть есть база, хранящая информацию о типовых сценариях — там, где хранятся модели в нотации BPMN2. Пусть мы потеряли информацию о типовых сценариях в нотации BPMN2. Как на восстановить индивидуальные, не имея типовых? Если индивидуальные сценарии хранятся в БД, то труда это не составит — вот они. Если же не хранятся, то мы их не восстановим. Вопрос: можно ли увидеть модели сценариев в БД, если из нее убрать все модели всех типовых сценариев?
BPMN2 — это описание сценария. Нет такого понятия как типовой или индивидуальный. Это зависит от контекста выполнения. В хранилище (БД, либо в памяти, либо еще где...) по каждому выполняющемуся сценарию хранится его контекст. Перед продолжением выполнения любого процесса из хранилища поднимается его контекст и берется описание BPMN процесса и… поехали. Если чего-то нет, то, соответственно, и выполнить невозможно
Нет такого понятия как типовой или индивидуальный.
Я привел пример из строительства. Он широко распространен
Вы предлагаете хранить дельты: есть типовой сценарий, есть индивидуальные отличия между типовым и индивидуальными сценариями (то, что Вы называете «контекст») Индивидуальный сценарий при таком моделировании получается путем суммирования типового сценария с дельтой. Так он строится, но не хранится. Вопрос о том, как хранить сценарии — вторичен, главное, что есть возможность построения типового сценария. Но встает вопрос: насколько велика эта дельта теоретически? Ведь в реальных ситуациях индивидуальный сценарий может перестать быть даже похожим на типовой. Есть ли возможность хранить такие дельты?
Чем вариант глобального процесса, в которой типовой сценарий исполняется как путь для значений различных параметров по умолчанию, а индивидуальные на основе других значений их и их сочетаний?
Вы повторили идею хранения «дельт». Да, это работает, если дельты покрывают все нужные нам кейсы, например, если мы в итоге на основании типового сценария построили нечто. что совершенно не похоже не типовой: разное количество операций, разные названия операций, порядок другой. Если при помощи «других значений и их сочетаний» можно замоделировать любой сценарий, отличный от типового, то задача решена.
Насколько я понимаю, вам нужно перед каждым выполнением процесса ( сценария ):
— взять типовой процесс
— отредактировать его
— запустить на исполнение.
если пользователи у вас достаточной квалификации, чтобы выполнять подобную процедуру — в чем проблема?
храните типовой сценарий — копируйте в новый и редактируйте.
хранится будет типовой, а исполнятся, хранится и анализироваться будет то что реально исполняется.
кто мешает хранить «кучу» сценариев в базе? — вопрос что вы с этим потом делать будете.
— взять типовой процесс
— отредактировать его
— запустить на исполнение.
если пользователи у вас достаточной квалификации, чтобы выполнять подобную процедуру — в чем проблема?
храните типовой сценарий — копируйте в новый и редактируйте.
хранится будет типовой, а исполнятся, хранится и анализироваться будет то что реально исполняется.
кто мешает хранить «кучу» сценариев в базе? — вопрос что вы с этим потом делать будете.
храните типовой сценарий — копируйте в новый и редактируйте.
Я бы рад копировать, но некуда, потому что нет возможности их хранить. Есть возможность хранить только типовые. И да, когда накапливается много (очень много) типовых сценариев, то с ними действительно уже нечего не сделать. Именно поэтому хранить их надо порознь
— взять типовой процесс
— отредактировать его
— запустить на исполнение.
тут одно из двух
— если отредактировать = «поменять параметры типового» = изменить производительность, количество исполнителей, материалы — хорошо опишите типовой процесс с параметрами, и храниться параметры будут в конкретных экземплярах типового процесса
— если отредактировать — изменить логику процесса, фактически " картинку модели" — то придется хранить каждый процесс ( он в вашей терминологии станет типовым ) — иначе нечего запускать на исполнение.
— отредактировать его
— запустить на исполнение.
тут одно из двух
— если отредактировать = «поменять параметры типового» = изменить производительность, количество исполнителей, материалы — хорошо опишите типовой процесс с параметрами, и храниться параметры будут в конкретных экземплярах типового процесса
— если отредактировать — изменить логику процесса, фактически " картинку модели" — то придется хранить каждый процесс ( он в вашей терминологии станет типовым ) — иначе нечего запускать на исполнение.
Запуск типового сценария невозможен. Типовой сценарий надо посадить на временную ось, а коль скоро это произошло, типовой сценарий перестал быть типовым. а стал индивидуальным.
Хранение индивидуальных сценариев позволяет мне делать диаграмма Ганта, но BPMN — нет.
Я не хочу редактировать типовой сценарий. Это документ. который лежит в сейфе и абы кто его не трогает. Вот создавай свой чертеж и там делай, что хочешь в рамках дозволенного. Поэтому надо так: создать на основе типового сценария свой личный, адаптировать его и запустить
Хранение индивидуальных сценариев позволяет мне делать диаграмма Ганта, но BPMN — нет.
Я не хочу редактировать типовой сценарий. Это документ. который лежит в сейфе и абы кто его не трогает. Вот создавай свой чертеж и там делай, что хочешь в рамках дозволенного. Поэтому надо так: создать на основе типового сценария свой личный, адаптировать его и запустить
Вы не ответили на вопрос — что значит отредактировать. Изменить параметры или изменить процесс ( логику )
Не сохранив процесс его невозможно запустить ( на любом движке ), если вы сохранили процесс — получаете кучу процессов и не важно как вы их назовете, типовыми или личными.
Если меняются только параметры — все хранится в исполняемых экземплярах.
Гант позволяет хранить промежуточные состояния исполнения «проекта», изменяемого в процессе исполнения. Собственно никакого индивидуального сценария здесь нет. Можете добавлять/убирать любые этапы в процессе выполнения.
В BPMN — изменение логики экземпляра БП не предусмотрено, у него другие цели.
Не сохранив процесс его невозможно запустить ( на любом движке ), если вы сохранили процесс — получаете кучу процессов и не важно как вы их назовете, типовыми или личными.
Если меняются только параметры — все хранится в исполняемых экземплярах.
Гант позволяет хранить промежуточные состояния исполнения «проекта», изменяемого в процессе исполнения. Собственно никакого индивидуального сценария здесь нет. Можете добавлять/убирать любые этапы в процессе выполнения.
В BPMN — изменение логики экземпляра БП не предусмотрено, у него другие цели.
Отредактировать можно индивидуальный сценарий. Типовой редактированию не подлежит, потому что делал его технолог и никто, кроме него не может править типовые сценарии. Итак, на основе типового создается индивидуальный. Далее он адаптируется под конкретные нужды конкретных людей в конкретное время и конкретные ресурсы. При этом может измениться все: последовательность операций, их состав, длительность, участники, короче, все, что угодно.
Я хочу хранить индивидуальные сценарии отдельно от типовых — это все-таки разные документы.
Если меняются параметры, то индивидуальный сценарий строится на основе типового при помощи «дельт», то есть, хранение индивидуальных настроечных параметров — это хранение «дельт». Но можно хранить не «дельты» а «снимки». И второе — именно то, что нам надо.
Как пример, диаграмма Ганта хранит сценарий как есть — без дельт. И нельзя путать планируемый Гант и реальный — это разные документы
Я хочу хранить индивидуальные сценарии отдельно от типовых — это все-таки разные документы.
Если меняются параметры, то индивидуальный сценарий строится на основе типового при помощи «дельт», то есть, хранение индивидуальных настроечных параметров — это хранение «дельт». Но можно хранить не «дельты» а «снимки». И второе — именно то, что нам надо.
Как пример, диаграмма Ганта хранит сценарий как есть — без дельт. И нельзя путать планируемый Гант и реальный — это разные документы
The client’s pool is the black box. It means
that we will not describe the client’s process.
that we will not describe the client’s process.
Це про другое)). Мы не моделируем сценарий работ клиента, потому что мы о нем ничего не знаем. М ыже моделируем те сценарии, про которые нам все известно
Почему тогда у вас на пуле клиента присутствуют события и задачи? Согласно стандарту и рекомендациям пул клиента должен быть чистым, как вот здесь:
Потому что BPMN имеет три уровня для описания сценариев. Первый — обычная блок-схема, второй — это полновесный инструмент аналитика и третий уровень — уровень автоматизации. Книга Брюса Сильвера начинается с описания этих трех уровней и для каждого уровня он дает свои правила моделирования. Вы указали на правило для уровня автоматизации, но для уровня блок-схем это правило не действует. Мы можем наэтом уровне моделировать в том числе и действия клиента
А вам какой уровень нужен?
На деле нам нужен уровень автоматизации. Картинка — лишь картинка. Строить модели на основе картинок, скорее всего, не удастся. Если строить модель, то на основе языка BPMN, но не нотации. То есть, понадобится та часть, которая называется Model, но не понадобится та часть, которая называется Notation.
Если вы переходите в уровень автоматизации.
Вы вынужденно переходите к сохранению индивидуальных процессов, иначе процесс не запускается
и соответственно к хранению в базе экземпляра процесса ( те действия пользователей( системы ) которые выполняются в процессе исполнения процесса ). Так как, в вашей терминологии, не бывает 2-х одинаковых индивидуальных процессов — храните все с разными наименованиями(атрибутами). с вытекающими отсюда проблемами большого количества процессов.
Храните Типовые процессы в одном месте ( разделе общей БД, или другой БД, или на флэшке в сейфе ) Копируйте и создавайте новый индивидуальный процесс каждый раз когда вам это нужно в рабочей БД. Редактируйте ( если квалификация пользователя это позволяет )
И не важно, что это — Гант, BPMN. — количество индивидуальных процессов в связи с вашими требованиями будет одинаково.
Просто для Ганта есть возможность менять процесс в процессе исполнения, для BPMN — нет.
Если нужно как то упорядочивать структуру хранения процессов — любое файлохранилище, которое для вас удобно
Вы вынужденно переходите к сохранению индивидуальных процессов, иначе процесс не запускается
и соответственно к хранению в базе экземпляра процесса ( те действия пользователей( системы ) которые выполняются в процессе исполнения процесса ). Так как, в вашей терминологии, не бывает 2-х одинаковых индивидуальных процессов — храните все с разными наименованиями(атрибутами). с вытекающими отсюда проблемами большого количества процессов.
Храните Типовые процессы в одном месте ( разделе общей БД, или другой БД, или на флэшке в сейфе ) Копируйте и создавайте новый индивидуальный процесс каждый раз когда вам это нужно в рабочей БД. Редактируйте ( если квалификация пользователя это позволяет )
И не важно, что это — Гант, BPMN. — количество индивидуальных процессов в связи с вашими требованиями будет одинаково.
Просто для Ганта есть возможность менять процесс в процессе исполнения, для BPMN — нет.
Если нужно как то упорядочивать структуру хранения процессов — любое файлохранилище, которое для вас удобно
Я бы сказал так (разделяя объект и его модель, чтобы не путаться): мы вынужденно переходим к моделированию индивидуальных процессов и хранению этих моделей в БД, Но это делает и обычный движок BPMN: он хранит модели операций, но не хранит информацию о связях межу ними. Эту информацию можно найти только в моделях типовых процессов в виде моделей типовых связей, но нельзя в моделях процессов в виде моделей связей. И модель процесса я все-таки называю сценарием, иначе нам трудно понять, о чем мы говорим: о процессе, или о его модели. Ведь в БД не хранятся объекты предметной области, там хранятся модели этих объектов, поэтому стоит различать процессы и их модели
«он хранит модели операций, но не хранит информацию о связях межу ними» — я не ГУРУ — но это нонсенс — как тогда движок исполняет операции ??
Для БД ( движок BPMN ) — объект предметной области — последовательность выполнения операций c конкретными атрибутами
ничего другого там хранить нельзя.
Если «объект предметной области» — изделие которое выходит с производства, то оно точно не хранится в БД.
Для БД ( движок BPMN ) — объект предметной области — последовательность выполнения операций c конкретными атрибутами
ничего другого там хранить нельзя.
Если «объект предметной области» — изделие которое выходит с производства, то оно точно не хранится в БД.
как тогда движок исполняет операции ??
Движок воспринимает стартовые события. Как только возникает стартовое событие из того класса событий, на который ссылается модель типового сценария, движок создает модель этого события и запускает сканирование типового сценария, который связан с классом таких событий (но не с данным событием). Сканируя типовой сценарий, движок создает модели операций, решений, и проч… Но не создает модели связей! Что ему мешает это делать, не понятно.
Объектом не может быть «выполнение», потому что объект — это существительное, а выполнение — глагол. Объектом может быть сценарий, — это да.
В БД хранятся только модели. Сама модель может стать объектом для моделирования, но тогда мы строим модель модели
движок исполняет тот «сценарий» — который хранится в БД, в предыдущем посте я предложил вам хранить в БД индивидуальные сценарии. Других вариантов не существует.
Да, нам надо найти ИС, которая хранит индивидуальные сценарии. Только я бы поправил терминологию, потому что выражение «движок исполняет сценарий» не верное Сценарий исполняют исполнители. — люди, машины и проч., а движок лишь диспетчерирует работы — указывает в какой последовательности и кто должен выполнять сценарий.
Проект дома и проект БП конечно в чем-то похожи, но есть и существенные отличия. Дом мы построили один раз, и наш проект будь он типовой или индивидуальный ушел в архив. БП же выполняется регулярно, поэтому мы его и автоматизируем. И фактически при каждом запуске могут произойти более или менее существенные отклонения от зафиксированного сценария, я так понимаю проблематика публикации где-то тут: как моделировать бизнес процессы таким образом, чтобы их было удобно автоматизировать, а также модернизировать и оптимизировать? Действительно, универсального решения так пока и не придумали, хотя методологий существует масса, и каскад с Гантом, и Agile со Scrum, и BPMS с BPMN и SOA с массой технологий вокруг, и все они с большим или меньшим успехом применяются.
Дом мы построили один раз, и наш проект будь он типовой или индивидуальный ушел в архив. БП же выполняется регулярно, поэтому мы его и автоматизируем.
Будьте внимательны и следите за руками. Итак, вы говорите, что индивидуальный проект дома ушел в архив. Типовой, на основе которого он был создан, тоже в архиве. Но именно этого мне не хватает. Мне не хватает того, чтобы индивидуальный проект БП хранился в базе. Типовой там есть. а вот индивидуального нет. На мой взгляд причина в некорректной терминологии, которой пользуются Б-аналитики. Вы говорите, что БП выполняется регулярно. Но в моей терминологии это значит, что БП много и все они основаны на одном типовом процессе. Проблема в том, что многие называют процессы «реализациями» процесса, «инстансами» процесса, «экземплярами процесса». Но, следуя тогда этой аналогии, конкретный дом — это экземпляр дома, а типовой проект — это дом. Что звучит дико, но в ИТ отрасли это я слышу постоянно. У меня есть статья на тему неправильных терминов и истории их происхождения. Надо — сброшу
Для типовых процессов может существовать множество экземпляров, а для индивидуальных только один. Этакий синглтон.
А по аналогии: конкретный типовой дом — это результат исполнения экземпляра типового процесса описанного в типовом проекте. Проект — это не дом и даже не процесс. Это (вкупе с остальной документацией) — описание процесса. Процесс — работы по проекту. Экземпляр процесса — работы по конкретному адресу. Дом — результат работ.
А по аналогии: конкретный типовой дом — это результат исполнения экземпляра типового процесса описанного в типовом проекте. Проект — это не дом и даже не процесс. Это (вкупе с остальной документацией) — описание процесса. Процесс — работы по проекту. Экземпляр процесса — работы по конкретному адресу. Дом — результат работ.
Это тот вопрос, почему я расположил эту статью в разделе «семантика».
Начнем с того, что такое конкретный типовой дом? Что такое конкретный типовой слон? Я знаю, что все слоны, так же как и все дома уникальны. Что такое типовой дом, или типовой слон с вашей точки зрения, и чем типовой дом отличается от конкретного типового дома?
Начнем с того, что такое конкретный типовой дом? Что такое конкретный типовой слон? Я знаю, что все слоны, так же как и все дома уникальны. Что такое типовой дом, или типовой слон с вашей точки зрения, и чем типовой дом отличается от конкретного типового дома?
Типовой дом — дом, построенный по типовому проекту. Класс домов. Конкретный типовой дом — дом, построенный по типовому проекту по конкретному адресу.
Тогда что такое типовой слон? Или типовой ландыш? Ведь проекта для строительства слона не существует
Нельзя давать определение объекта через термин, который не введен в рассмотрение ранее. Получается, что типовой дом водится через термин типовой проект, но тогда надо дать определение термина типовой проект))
Я бы попробовал так. Типовой — значит принадлежит типу. Тип — это то же, что и вторичная сущность по-Аристотелю, то есть, идея. Идея хранится в сознании. У этой идеи есть элементы, Аристотель называл их атрибуты.
Сбрасывайте, конечно, интересно. Я думаю, с терминологией надо определиться в рамках решаемых проблем, иначе можно уйти в глубокую философию. Б-аналитики, как вы их называете, на мой взгляд являются по большей части интерфейсом между ИТ и бизнесом. Бизнесу важно достигать целей, а ИТ важно все автоматизировать. В данном случае не совсем понятно, в каком контексте вы работаете. Если в ИТ — то описание бизнес-процесса например в BPMN — это модель, в строительстве домов аналог — проект дома, это тоже модель. Дом — это инстанс, реализация модели, если вы строите для себя — будет в единственном экземпляре, если это П44Т — их будут тысячи. Можно создать реализацию безо всякого моделирования вообще — так природа поступает. С бизнес процессами то же самое, можете их описывать или нет, они происходят. Если их описать и привязать ключевые события к какой-то системе, можно попытаться ими управлять. Что из этого вы хотите хранить и зачем — мне пока не очень понятно.
Я специально написал требования к ИС языком пользователя. У пользователя (пусть собирает паровые котлы) есть технология производства котла — типовой сценарий работ и есть конкретные работы по изготовлению конкретного котла — сценарий производства котла номер 123. Понятно, что сценарии производства котла номер 123 и номер 124 — разные. Но ИТ сразу скажет, что это:
1. не сценарии, а экземпляры сценария
2. типовой сценарий — это просто сценарий.
И вот тут ИТ специалист сильно расходится с общепринятой терминологией. Он считает, что есть дом и экземпляр дома, в то время, как в общепринятой терминологии есть дом и тип домов (в логике Аристотеля) или класс домов (в математической логике).
Причины смешения терминов я объяснил в статье Моделирование объектов учета параграф 12.5. Приложение E: терминологические коллизии
1. не сценарии, а экземпляры сценария
2. типовой сценарий — это просто сценарий.
И вот тут ИТ специалист сильно расходится с общепринятой терминологией. Он считает, что есть дом и экземпляр дома, в то время, как в общепринятой терминологии есть дом и тип домов (в логике Аристотеля) или класс домов (в математической логике).
Причины смешения терминов я объяснил в статье Моделирование объектов учета параграф 12.5. Приложение E: терминологические коллизии
Статья немаленькая, за 5 минут не освоить, спасибо, поизучаю. То, что терминология ИТ специфична, это нормально — вы же не станете требовать от хирурга чтобы он «по-человечески» в своей среде изъяснялся, а не на латыни, а то не всем понятно о чем это он ;). Если мы говорим о ТЗ, ФТ и прочих интерфейсах с заказчиком (или общении хирурга о предстоящей операции с родственниками пациента), то это конечно совсем другая история.
Я бы не рекомендовал читать статью. Она — лишь вершина айсберга и мы недавно засекали время, которое нужно для погружение в нее: 20 часов лекций и 80 часов самостоятельной работы с литературой. Я лишь сослался на параграф, который самодостаточный
Главное, чтобы было интересно. Если действительно будет интересно так долго, то это круто. Но я конечно сомневаюсь. Проверим :)
Если не затруднит, буду признателен за отзыв после прочтения.
Хорошо, пока что действительно интересно, но следуя вашим советам не тороплюсь :). А вы читали «Сумму технологий» Лема? Он в этой тематике очень глубоко копнул, а книга 1963 года выпуска, так что не совсем согласен с вашим утверждением в начале статьи, что моделирование реальности слабо исследовано. Вассерман еще рекомендует «Структуру реальности», «Слепой часовщик» и «Анти-Дюринг» для формирования целостной картины мира, но я еще даже «Сумму технологий» не осилил, уже второй месяц читаю.
Я не встречал еще ни одной книги, которая бы описывала точно наш опыт восприятия и моделирования результатов восприятия. Всякий раз я наблюдаю одну и ту же картину: дается гипотеза, а затем части этой гипотезы превращаются автором в «реальность». Например, допустим, что пространство — это граф, получим из этого выводы о том, что граф описывает все наблюдаемые нами явления, из чего автор делает вывод: пространство — граф! Так или иначе, во всех книгах это присутствует. Всегда можно найти это место, где автор сам себя обманул. Поэтому мне сложно читать много литры, — заранее известен конец. Хотелось бы найти такого автора, который не погрешит перед истиной. Книги такие есть, но они рядом, не про моделирование предметной области. Например, «Бах, Эшер, Гедель». Недавно в учебнике матлогики я нашел ошибку. Показал ее преподавателю матлогики, а он ее не понял. Так что надо иметь очень тренированный ум и дисциплину, чтобы двигаться, не увязнув в иллюзиях
Sign up to leave a comment.
Зачем нужно моделировать индивидуальные и типовые сценарии?