Я нередко слышу тезис о том, что есть термины: событие и экземпляр этого события, или переменная и экземпляр этой переменной. Уважаемые аналитики, у меня убедительная просьба к тем, кто использует эти термины, прочитайте конец статьи и подумайте над тем, что там написано. Возможно, вы поймете, что так говорить нельзя.
В данной статье я продолжаю рассказ про физические и функциональные события. На этот раз я свяжу физические события с теми объектами, которые моделируют их в информационных системах. В этой статье рассказ пойдет про физические и только физические события:
Для начала вспомним, что такое физическое и функциональное событие в предметной области.
Событие — это экстент плюс субъективная точка зрения на него.
В итоге мы имеем такую иерархию объектов:
Физическое событие часто используется для описания смены состояний физического объекта. Например: физическое событие «спускаемый аппарат в 10-00 вошел в плотные слои атмосферы» описывает начало того состояния аппарата, когда он тормозится. Функциональные события часто используются для описания смены состояния функционального объекта. Например: событие «Тушение костра завершено» из примера с маяком описывает наступление функционального состояния маяка «Розжиг костра». Однако, привязка к смене состояний отнюдь не обязательна. Например, физическое событие 12-00 не знаменует собой смену состояния объекта.
Как правило, заказчик ставит задачу перед аналитиком в терминах функционального события. На основе полученных данных аналитик формулирует требования к физическому событию. Помните фразу, которую мы часто слышим? «На самом деле заказчику надо вот это… И далее происходит описание физического события». Затем происходит выполнение этого физического события, сверка полученных параметров этого события с планируемыми параметрами и возврат к трактовке физического события как функционального. Например, мы видим некое событие (фейерверк), но как при этом создавались и разрушались вселенные, нас не интересует. Нам интересен только внешний вид фейерверка.
Физические события образуют множество или класс физических событий. Жалеющие вспомнить математику могут предположить, чему равна мощность множества физических событий. Далее из всего множества физических событий можно выбрать то подмножество, которое интересует аналитика. Например, пятисекундный интервал времени, сопровождаемый гудком, происшедший где-то в промежутке между 11 часов 45 минут и 12 часов 15 минут 12-го марта 2014 года может с точки зрения заказчика считаться физическим событием «12 часов 12-го марта 2014 года». Множество таких событий, происходящих в разные дни, образуют класс физических событий, который можно назвать так: «12 часов».
Таким образом, в описании предметной области появился новый объект – класс физических событий.
В нотации BPMN нет условного обозначения для класса физических событий. Есть только условное обозначение для событий класса, пример которого (условного обозначения) я привел в начале статьи. На будущее оставлю небольшую интригу. Есть нотация описания активности, в которой есть графический элемент для обозначения класса функциональных событий, но нет обозначений для событий этого класса.
Пусть стоит задача разработки программно-аппаратного комплекса Сириус -12 для подачи звукового сигнала длительностью 5 секунд в любой момент времени в интервале между 11-45 и 12-15. Эти события заказчиком рассматриваются как физические события класса «12-00». Я специально растянул шкалу времени, потому что многим может показаться, что 12-00 мы всегда определяем с абсолютной точностью. Но на самом деле всегда существует погрешность как измерения времени, так и подачи сигнала об измеренном времени. Давайте внимательно посмотрим, какие классы событий рассматриваются аналитиком при разработке информационной системы.
И тут очень важный момент, на котором я бы хотел заострить ваше внимание. Фактические происшедшие события могут быть из класса желанных событий, но могут при этом не быть событиями 12-00 в представлении заказчика! Потому что, например, два сигнала в один день могут посчитаться ложным срабатыванием. То есть, существуют два способа навредить заказчику: какой-то сигнал из класса фактических событий не будет удовлетворять требованиям заказчика (срабатывание в 18-00) или класс фактических событий не будет совпадать ни с одной из желаемых последовательностей (двойное срабатывание сигнала). То есть требования заказчика распространяются как на события класса, так и на класс событий. Напомню, что в BPMN нет возможности наложить требования на класс событий.
Давайте посмотрим на реализацию информационной системы комплекса. В базе данных комплекса создаются таблицы, записи которых моделируют что:
Понятно, что не в каждой информационной системе хранятся данные, которые я привел в качестве примера. Однако, по отдельности или все вместе они имеют право на существование.
Попутно заметим, что среднеквадратичное отклонение от заданной величины – это параметр класса, а вот распределение случайной величины – это параметр объектов класса.
Если у нас заполнены все таблицы, то мы можем проводить анализ статистических данных, применить метод под названием 6 сигм. И, если выяснится, что средняя длительность сигналов не 5 секунд, а 6, можно попытаться понять причины расхождения и устранить их. Заметим, что метод 6 сигм предназначен для исследования не только процессов, но для изучения любых параметров любого функционального или физического объекта.
В нашем кейсе мы дали очень точное и недвусмысленное определение понятия 12-00 в применении к моделируемой предметной области. Однако, очень часто мы видим на диаграммах вот такой символ:
Но определения того, что такое 12-00 в той области, которую моделировал аналитик, мы не видим. Дело в том, что априори это определение считается известным. Например, 12-00 определяется как системное время, точность измерения равна 1 мск и погрешность подачи сигнала определяется длиной подводящих к исполнительному устройству электрических линий и/или точностью синхронизации тактовых частот исполнительного и расчетного устройств. Все это не проговаривается нами только потому что кажется несущественным. Но на самом деле в самый неподходящий момент эта погрешность может сыграть с нами злую шутку, если мы ее не учтем. Например, транзакция будет завершена с ошибкой только потому что мы решили, что она мгновенна. Поэтому, когда на диаграмме вы видите этот элемент, то лучше уточните у аналитика, что он понимает под событиями «12-00».
Кратко повторю результаты, полученные нами в предыдущей статье. Для корректного рассуждения нам надо различать следующие объекты:
На рисунке я привел те сущности, которые нам придется рассмотреть в применении к модели физических событий:
Посмотрим, как эта картинка конкретизируется в нашем случае. Должен подчеркнуть, что нотация BPMN работает только с желаемыми событиями и не работает с фактическими событиями. Точнее, она может работать с предполагаемыми фактическими событиями. Те же события, которые происходят на самом деле, в общем случае невозможно уложить в модель. Например, событие, когда гудок по ошибке прогудел в 18-00, есть фактическое событие, но его нельзя назвать событие 12-00. Другое ограничение нотации состоит в том, что нотация не позволяет моделировать классы желаемых событий, а только желаемые события класса. Поэтому остальные объекты и классы объектов, если это необходимо, аналитику придется моделировать вручную.
Сначала появляется модель желаемых событий в голове у заказчика. Мы мало знаем о том, как эта штука возникает, и где она хранится. Но мы знаем, что именно эта модель становится основой для дальнейшей работы аналитика. Задача аналитика понять, в какой парадигме рассуждает заказчик, понять как в этой парадигме выглядит модель желаемых событий, взять в качестве основы свою более широкую и непротиворечивую парадигму, отмаппить представления заказчика вместе с его парадигмой на свою парадигму, создать модель желаемых событий в своей парадигме. При этом происходит дополнение модели заказчика до полноты и устранение внутренних противоречий. Затем аналитик должен отмаппить эту модель обратно в парадигму заказчика и сверить полученные данные. Если заказчик согласен с исправленной моделью желаемых событий, то можно либо научить его своей парадигме, что сэкономит силы на переводах с одной парадигмы в другую и обратно, либо придется каждый раз маппиться туда и обратно. Это породит трудности и риски перевода, но знание этих рисков поможет нам справиться с ними. В нашем случае я пользуюсь парадигмой, которая предполагает, что события бывают физические и функциональные, и все они – это экстенты 4-Д пространства-времени. Для моделирования желаемых событий я использую нотацию BPMN.
Утвердив модель объекта, можно переходить к согласованию модели класса объектов. Например, мы согласовали определение того, что такое любое событие 12-00. Это единственный звуковой сигнал, поданный в течении 5 секунд в промежутке времени с 11-45 по 12-15 любого дня. Теперь надо понять, а что есть класс таких событий. Классом таких событий будет множество всех таких сигналов. Однако, теперь у нас появляются новые требования. Например, можно указать среднеквадратичное отклонение от номинала. Пусть это будет среднеквадратичное отклонение в 7 минут относительно 12-00. Надеюсь, вам понятно, что этот параметр относится к классу желаемых событий, а не к желаемым событиям класса. (Те же параметры можно обсуждать с заказчиком постфактум относительно фактически происшедших событий). К сожалению, в нотации BPMN нет элемента для обозначения класса желаемых событий. Поэтому все, что касается класса желаемых событий, нам приходится моделировать самостоятельно вне нотации BPMN. То же касается фактических событий и класса фактических событий.
Рассмотрим представление модели любого желаемого события 12-00 на экране монитора. Это будет выглядеть так:
Заметим, что мониторов много и у каждого из вас будет свое изображение. У кого-то больше, у кого-то меньше, у кого-то в одних цветах, у кого-то в других. Это и есть множество различных представлений модели желаемых событий 12-00. Именно поэтому представлений одной модели много – у каждого из вас свое.
Когда я создавал на своем экране первое представление модели желаемых событий, программа одновременно сделала еще одну работу. Она создала и сохранила представление модели этого и других представлений в виде файла c расширением XPDL. Этот файл был создан на основе нашего представления о модели как об информационном объекте. При этом для создания файла была использована та же нотация BPMN. Дело в том, что в нотации есть две части. Одна описывает то, какими данными описывается модель (набор графических примитивов (условное обозначение события), создаваемые объекты и их параметры (объекты класса Event)), а в другой описан вид хранения этих данных (как производится запись в файле XPDL).
Представление нотации BPMN можно найти у меня на книжной полке. У вас она может быть представлена пикселями на мониторе.
Итак, для создания представления модели событий 12-00 я воспользовался нотацией BPMN, которая была у меня в голове. Я взял из нотации условное обозначение желаемых событий и на основе этого условного обозначения создал представление модели желаемых событий 12-00 у себя на экране. Одновременно у меня была создана модель представлений этой модели в виде файла с расширением XPDL.
Мы видим, что количество сущностей, которые участвуют в моделировании простого события, превосходит все ожидания. Но так оно и есть. Вспомните, сколько вам пришлось поработать только для того, чтобы написать первое слово!
Задача разработчиков нотаций сделать так, чтобы для аналитика разрыв между замысливанием объекта и его реализацией был минимальным. Это желание оправдано, и разработчики потрудились на славу. Однако, вместе с этим мы получили издержки: произошли деформации в сознании у аналитиков:
На последней деформации сегодня остановлюсь подробнее. Я нередко слышу тезис о том, что есть термины: событие и экземпляр этого события.
Например, на диаграмме:
аналитики видят событие. А событие 12-00 1-го января 2015 года они называют экземпляром этого события!
Я не знаю, как объяснить таким аналитикам, что они при этом, мягко говоря, проявляют свою неграмотность. Я понимаю, откуда взялась эта деформация, но почему-то она настолько сильна, что, даже показав ее явно, нельзя быть уверенным, что аналитик поймет свое заблуждение. Поэтому я попробую на этом остановиться подробно.
Итак, пусть у нас есть определение термина электрон, и пусть есть определение термина экземпляр электрона. Как вы думаете, эти два термина на что указывают? Правильно: на любой объект класса «электроны». Помимо этих терминов есть термины «класс электронов» и «тип электронов». Если мы ведем речь о типах частиц, то экземпляр электрона — это экземпляр частицы типа электрон (но не экземпляр этого электрона). Возможно, это экземпляр данного типа электронов. Точно также экземпляр события — есть экземпляр объекта типа событие, но не экземпляр этого события. Возможно, это экземпляр данного типа событий. Экземпляр лося – есть экземпляр животного типа лось, но не экземпляр этого лося. Возможно это экземпляр данного типа лосей. Прошу вас, запомните это! Если уж очень хочется вместо термина событие использовать термин экземпляр события, то запомните, что элемент диаграммы BPMN моделирует в таком случае любой экземпляр события. Итак, элемент диаграммы моделирует любое событие из класса событий, или любой экземпляр события из класса экземпляров событий. Никак по-другому.
Еще один термин-паразит, проникший в наши ряды, — это термин «экземпляр класса». Не забываем, что термин «экземпляр класса» указывает на класс, а не на объект этого класса. На объект указывает созвучный ему термин «элемент класса».
В следующих статьях мы рассмотрим моделирование функциональных событий в нотации BPMN.
В данной статье я продолжаю рассказ про физические и функциональные события. На этот раз я свяжу физические события с теми объектами, которые моделируют их в информационных системах. В этой статье рассказ пойдет про физические и только физические события:
Определение события
Для начала вспомним, что такое физическое и функциональное событие в предметной области.
Событие — это экстент плюс субъективная точка зрения на него.
- Экстент — это любая 4-Д область из 4-Д пространства-времени. Дело в том, что наше пространство четырехмерно. Просто одно из измерений мы переживаем специфическим образом – как нечто, что разворачивается перед нами в одном направлении. Но для моделирования такая особенность нашего восприятия не имеет значения.
- Считается, что экстент, который мы считаем событием, с точки зрения рассказчика имеет нулевую временную ширину. То есть с точки зрения рассказчика событие – это мгновение. Однако, всегда существует точка зрения, в которой шириной события уже нельзя пренебречь и нам понадобится рассмотреть временную ширину этого экстента.
- Событие имеет физический смысл – это факты и ничего, кроме фактов. Мы рассматриваем такое событие как набор фактов без их трактовок. Например, в примере с маяком есть событие смотритель сидит на дровне и отдыхает. Такое событие мы будем называть физическое событие.
- Кроме физического события существует множество трактовок этого физического события разными субъектами. Например, при описании маяка одно и то же физическое событие «Смотритель отдыхает» может быть описано как: «Розжиг закончен» и «Тушение начато». Такое событие мы будем называть функциональное событие.
В итоге мы имеем такую иерархию объектов:
Физическое событие часто используется для описания смены состояний физического объекта. Например: физическое событие «спускаемый аппарат в 10-00 вошел в плотные слои атмосферы» описывает начало того состояния аппарата, когда он тормозится. Функциональные события часто используются для описания смены состояния функционального объекта. Например: событие «Тушение костра завершено» из примера с маяком описывает наступление функционального состояния маяка «Розжиг костра». Однако, привязка к смене состояний отнюдь не обязательна. Например, физическое событие 12-00 не знаменует собой смену состояния объекта.
Использование физического события в проектировании систем
Как правило, заказчик ставит задачу перед аналитиком в терминах функционального события. На основе полученных данных аналитик формулирует требования к физическому событию. Помните фразу, которую мы часто слышим? «На самом деле заказчику надо вот это… И далее происходит описание физического события». Затем происходит выполнение этого физического события, сверка полученных параметров этого события с планируемыми параметрами и возврат к трактовке физического события как функционального. Например, мы видим некое событие (фейерверк), но как при этом создавались и разрушались вселенные, нас не интересует. Нам интересен только внешний вид фейерверка.
Определение класса физических событий
Физические события образуют множество или класс физических событий. Жалеющие вспомнить математику могут предположить, чему равна мощность множества физических событий. Далее из всего множества физических событий можно выбрать то подмножество, которое интересует аналитика. Например, пятисекундный интервал времени, сопровождаемый гудком, происшедший где-то в промежутке между 11 часов 45 минут и 12 часов 15 минут 12-го марта 2014 года может с точки зрения заказчика считаться физическим событием «12 часов 12-го марта 2014 года». Множество таких событий, происходящих в разные дни, образуют класс физических событий, который можно назвать так: «12 часов».
Таким образом, в описании предметной области появился новый объект – класс физических событий.
В нотации BPMN нет условного обозначения для класса физических событий. Есть только условное обозначение для событий класса, пример которого (условного обозначения) я привел в начале статьи. На будущее оставлю небольшую интригу. Есть нотация описания активности, в которой есть графический элемент для обозначения класса функциональных событий, но нет обозначений для событий этого класса.
Постановка задачи для разработки программно-аппаратного комплекса
Пусть стоит задача разработки программно-аппаратного комплекса Сириус -12 для подачи звукового сигнала длительностью 5 секунд в любой момент времени в интервале между 11-45 и 12-15. Эти события заказчиком рассматриваются как физические события класса «12-00». Я специально растянул шкалу времени, потому что многим может показаться, что 12-00 мы всегда определяем с абсолютной точностью. Но на самом деле всегда существует погрешность как измерения времени, так и подачи сигнала об измеренном времени. Давайте внимательно посмотрим, какие классы событий рассматриваются аналитиком при разработке информационной системы.
- Класс возможных событий «12-00 конкретного дня». Это упорядоченный класс возможных звуковых сигналов, которые только возможны в данный конкретный день. Любое событие из этого класса может считаться событием 12-00, однако тогда и только тогда, когда оно единственное в выборке. Если предположить, что было два звуковых сигнала в один день, то заказчик вправе посчитать один, или оба из них ложными.
- События всех классов возможных событий «12-00 конкретного дня» (для разных дней) образуют класс возможных событий «12-00».
- Мы можем выбрать из этого класса возможных событий «12-00» любую упорядоченную последовательность событий такую, что в каждый день будет одно и только одно желаемое событие. Любая, полученная таким образом, последовательность желаемых событий будет желанной с точки зрения заказчика. Назовем такую последовательность возможных событий – желанной последовательностью событий.
- Класс желаемых последовательностей желаемых событий.
- Класс фактических событий. Этот класс состоит из фактических событий, когда подавался звуковой сигнал. Понятно, что этот класс может не совпадать ни с одной из желаемых последовательностей событий. Цель бизнес-аналитика и разработчика комплекса обеспечить совпадение класса фактических событий с одной из желаемой последовательностью событий.
И тут очень важный момент, на котором я бы хотел заострить ваше внимание. Фактические происшедшие события могут быть из класса желанных событий, но могут при этом не быть событиями 12-00 в представлении заказчика! Потому что, например, два сигнала в один день могут посчитаться ложным срабатыванием. То есть, существуют два способа навредить заказчику: какой-то сигнал из класса фактических событий не будет удовлетворять требованиям заказчика (срабатывание в 18-00) или класс фактических событий не будет совпадать ни с одной из желаемых последовательностей (двойное срабатывание сигнала). То есть требования заказчика распространяются как на события класса, так и на класс событий. Напомню, что в BPMN нет возможности наложить требования на класс событий.
Структура данных программно-аппаратного комплекса
Давайте посмотрим на реализацию информационной системы комплекса. В базе данных комплекса создаются таблицы, записи которых моделируют что:
- Классы желаемых событий. Там создана одна запись 12-00, которая моделирует класс желаемых событий при помощи параметра «допустимое отклонение от 12-00». Это минимальное и максимальное отклонение от 12-00, достаточное, чтобы событие считалось событием 12-00. Пусть отклонение задано в 15минут. Также указаны требования к среднеквадратичному отклонению от 12-00. Указана требуемая длительность сигнала и допустимые отклонения от нее.
- Желаемые события. Запись в этой таблице моделирует желаемое событие путем указания даты и времени, когда необходимо подать сигнал.
- Фактические события. Запись в этой таблице моделирует фактически свершенное событие (подача сигнала) путем указания фактического времени подачи сигнала и фактической длительности сигнала.
- Классы фактических событий. Запись в этой таблице моделирует класс фактических событий путем указания минимального и максимального фактического отклонения от 12-00, фактического среднеквадратичного отклонения от 12-00, среднего времени подачи сигнала и среднеквадратичное отклонение от средней длительности.
Последняя нормальная форма
Надо помнить, что моделирование предметной области при помощи таблиц очень редко сохраняет соответствие между объектами предметной области и записями в таблицах. Чаще в одной записи хранятся данные сразу о множестве объектов предметной области. Структура данных, которая полностью удовлетворяет правилу – одна запись хранит данные по одному объекту, иногда называется полной или последней нормальной формой. Эта структура возникает, если рассматривать предметную область с точки зрения логической парадигмы, о которой я рассказываю вот уже много статей подряд, а не с точки зрения экземпляров и типов.
Комментарии к структуре данных
Понятно, что не в каждой информационной системе хранятся данные, которые я привел в качестве примера. Однако, по отдельности или все вместе они имеют право на существование.
Попутно заметим, что среднеквадратичное отклонение от заданной величины – это параметр класса, а вот распределение случайной величины – это параметр объектов класса.
Если у нас заполнены все таблицы, то мы можем проводить анализ статистических данных, применить метод под названием 6 сигм. И, если выяснится, что средняя длительность сигналов не 5 секунд, а 6, можно попытаться понять причины расхождения и устранить их. Заметим, что метод 6 сигм предназначен для исследования не только процессов, но для изучения любых параметров любого функционального или физического объекта.
Комментарии к определению термина событие 12-00
В нашем кейсе мы дали очень точное и недвусмысленное определение понятия 12-00 в применении к моделируемой предметной области. Однако, очень часто мы видим на диаграммах вот такой символ:
Но определения того, что такое 12-00 в той области, которую моделировал аналитик, мы не видим. Дело в том, что априори это определение считается известным. Например, 12-00 определяется как системное время, точность измерения равна 1 мск и погрешность подачи сигнала определяется длиной подводящих к исполнительному устройству электрических линий и/или точностью синхронизации тактовых частот исполнительного и расчетного устройств. Все это не проговаривается нами только потому что кажется несущественным. Но на самом деле в самый неподходящий момент эта погрешность может сыграть с нами злую шутку, если мы ее не учтем. Например, транзакция будет завершена с ошибкой только потому что мы решили, что она мгновенна. Поэтому, когда на диаграмме вы видите этот элемент, то лучше уточните у аналитика, что он понимает под событиями «12-00».
Моделирование активности программно-аппаратного комплекса
Общие замечания
Кратко повторю результаты, полученные нами в предыдущей статье. Для корректного рассуждения нам надо различать следующие объекты:
- Модель объекта (класса объектов) в голове у субъекта,
- Представление этой модели в виде информационного объекта,
- Класс представлений этой модели в виде класса информационных объектов
- Модель представлений этих информационных объектов в голове у субъекта
- Представление этой модели в виде информационного объекта
- Класс представлений этой модели в виде информационного объекта.
- Нотации
На рисунке я привел те сущности, которые нам придется рассмотреть в применении к модели физических событий:
Посмотрим, как эта картинка конкретизируется в нашем случае. Должен подчеркнуть, что нотация BPMN работает только с желаемыми событиями и не работает с фактическими событиями. Точнее, она может работать с предполагаемыми фактическими событиями. Те же события, которые происходят на самом деле, в общем случае невозможно уложить в модель. Например, событие, когда гудок по ошибке прогудел в 18-00, есть фактическое событие, но его нельзя назвать событие 12-00. Другое ограничение нотации состоит в том, что нотация не позволяет моделировать классы желаемых событий, а только желаемые события класса. Поэтому остальные объекты и классы объектов, если это необходимо, аналитику придется моделировать вручную.
Создание модели активности
Сначала появляется модель желаемых событий в голове у заказчика. Мы мало знаем о том, как эта штука возникает, и где она хранится. Но мы знаем, что именно эта модель становится основой для дальнейшей работы аналитика. Задача аналитика понять, в какой парадигме рассуждает заказчик, понять как в этой парадигме выглядит модель желаемых событий, взять в качестве основы свою более широкую и непротиворечивую парадигму, отмаппить представления заказчика вместе с его парадигмой на свою парадигму, создать модель желаемых событий в своей парадигме. При этом происходит дополнение модели заказчика до полноты и устранение внутренних противоречий. Затем аналитик должен отмаппить эту модель обратно в парадигму заказчика и сверить полученные данные. Если заказчик согласен с исправленной моделью желаемых событий, то можно либо научить его своей парадигме, что сэкономит силы на переводах с одной парадигмы в другую и обратно, либо придется каждый раз маппиться туда и обратно. Это породит трудности и риски перевода, но знание этих рисков поможет нам справиться с ними. В нашем случае я пользуюсь парадигмой, которая предполагает, что события бывают физические и функциональные, и все они – это экстенты 4-Д пространства-времени. Для моделирования желаемых событий я использую нотацию BPMN.
Утвердив модель объекта, можно переходить к согласованию модели класса объектов. Например, мы согласовали определение того, что такое любое событие 12-00. Это единственный звуковой сигнал, поданный в течении 5 секунд в промежутке времени с 11-45 по 12-15 любого дня. Теперь надо понять, а что есть класс таких событий. Классом таких событий будет множество всех таких сигналов. Однако, теперь у нас появляются новые требования. Например, можно указать среднеквадратичное отклонение от номинала. Пусть это будет среднеквадратичное отклонение в 7 минут относительно 12-00. Надеюсь, вам понятно, что этот параметр относится к классу желаемых событий, а не к желаемым событиям класса. (Те же параметры можно обсуждать с заказчиком постфактум относительно фактически происшедших событий). К сожалению, в нотации BPMN нет элемента для обозначения класса желаемых событий. Поэтому все, что касается класса желаемых событий, нам приходится моделировать самостоятельно вне нотации BPMN. То же касается фактических событий и класса фактических событий.
Рассмотрим представление модели любого желаемого события 12-00 на экране монитора. Это будет выглядеть так:
Заметим, что мониторов много и у каждого из вас будет свое изображение. У кого-то больше, у кого-то меньше, у кого-то в одних цветах, у кого-то в других. Это и есть множество различных представлений модели желаемых событий 12-00. Именно поэтому представлений одной модели много – у каждого из вас свое.
Когда я создавал на своем экране первое представление модели желаемых событий, программа одновременно сделала еще одну работу. Она создала и сохранила представление модели этого и других представлений в виде файла c расширением XPDL. Этот файл был создан на основе нашего представления о модели как об информационном объекте. При этом для создания файла была использована та же нотация BPMN. Дело в том, что в нотации есть две части. Одна описывает то, какими данными описывается модель (набор графических примитивов (условное обозначение события), создаваемые объекты и их параметры (объекты класса Event)), а в другой описан вид хранения этих данных (как производится запись в файле XPDL).
Представление нотации BPMN можно найти у меня на книжной полке. У вас она может быть представлена пикселями на мониторе.
Итак, для создания представления модели событий 12-00 я воспользовался нотацией BPMN, которая была у меня в голове. Я взял из нотации условное обозначение желаемых событий и на основе этого условного обозначения создал представление модели желаемых событий 12-00 у себя на экране. Одновременно у меня была создана модель представлений этой модели в виде файла с расширением XPDL.
Мы видим, что количество сущностей, которые участвуют в моделировании простого события, превосходит все ожидания. Но так оно и есть. Вспомните, сколько вам пришлось поработать только для того, чтобы написать первое слово!
Профдеформации бизнес-аналитиков
Задача разработчиков нотаций сделать так, чтобы для аналитика разрыв между замысливанием объекта и его реализацией был минимальным. Это желание оправдано, и разработчики потрудились на славу. Однако, вместе с этим мы получили издержки: произошли деформации в сознании у аналитиков:
- Аналитики перестали осознавать все шаги процесса выявления требований к проектируемой системе и перестали замечать множество сущностей, которые участвуют в этом процессе.
- Аналитики порой не разделяют объекты информационных систем и объекты реального мира. Они начинают думать, что договора хранятся в информационных системах, а не в стеллажах бухгалтерий. Или наоборот, считают, что событие – это информация.
- Аналитики перестали замечать разницу между классом желаемых событий и классом фактических событий.
- Аналитики перестали различать объекты реального мира и классы этих объектов.
На последней деформации сегодня остановлюсь подробнее. Я нередко слышу тезис о том, что есть термины: событие и экземпляр этого события.
Например, на диаграмме:
аналитики видят событие. А событие 12-00 1-го января 2015 года они называют экземпляром этого события!
Я не знаю, как объяснить таким аналитикам, что они при этом, мягко говоря, проявляют свою неграмотность. Я понимаю, откуда взялась эта деформация, но почему-то она настолько сильна, что, даже показав ее явно, нельзя быть уверенным, что аналитик поймет свое заблуждение. Поэтому я попробую на этом остановиться подробно.
Итак, пусть у нас есть определение термина электрон, и пусть есть определение термина экземпляр электрона. Как вы думаете, эти два термина на что указывают? Правильно: на любой объект класса «электроны». Помимо этих терминов есть термины «класс электронов» и «тип электронов». Если мы ведем речь о типах частиц, то экземпляр электрона — это экземпляр частицы типа электрон (но не экземпляр этого электрона). Возможно, это экземпляр данного типа электронов. Точно также экземпляр события — есть экземпляр объекта типа событие, но не экземпляр этого события. Возможно, это экземпляр данного типа событий. Экземпляр лося – есть экземпляр животного типа лось, но не экземпляр этого лося. Возможно это экземпляр данного типа лосей. Прошу вас, запомните это! Если уж очень хочется вместо термина событие использовать термин экземпляр события, то запомните, что элемент диаграммы BPMN моделирует в таком случае любой экземпляр события. Итак, элемент диаграммы моделирует любое событие из класса событий, или любой экземпляр события из класса экземпляров событий. Никак по-другому.
Еще один термин-паразит, проникший в наши ряды, — это термин «экземпляр класса». Не забываем, что термин «экземпляр класса» указывает на класс, а не на объект этого класса. На объект указывает созвучный ему термин «элемент класса».
Продолжение следует
В следующих статьях мы рассмотрим моделирование функциональных событий в нотации BPMN.
