Автоматизация хаоса-2
АрхивРабота со временем, версии
Изменения состояния информационной модели состоят в возникновении, изменении атрибутов и исчезновении сущностей. Зачастую нас интересуют вопросы "что было вчера?", "что изменилось?". Для ответов на них нужны консистентные способы представления истории в модели.
Заметим, что изменения данных могут иметь два содержательно разных источника - реальные изменения во внешнем мире, который мы моделируем, и "ошибки ввода". История интересует нас, как правило, только в отношении изменений во внешнем мире. Хотя историю редактирования тоже может быть интересно хранить. Иногда эти два типа изменений не различаются.
Для разных категорий сущностей представление истории решается по-разному.
В объект можно включить дополнительный атрибут - дату/время возникновения версии (временной штамп) и при каждом изменении создавать новую версию объекта. Если есть атрибуты, более других подверженные изменениям, то их можно выносить во множественные группы, добавив к ним временной штамп.
В случае справочников можно поступить точно так же - снабжать записи, расшифровывающие коды, временным штампом.
Отношения в мире не меняются принципиально (запись отношения не аутентична) - любое изменение означает прекращение старого отношения и возникновение нового. Это означает, что все отношения должны быть снабжены атрибутами - временем возникновения и временем прекращения.
Множественные атрибуты в этом смысле никаких трудностей не вызывают: в группу добавляется время, и у них появляется еще одна причина для размножения.
Для разных категорий с интерфейсной точки зрения мы можем либо все время работать в одном временном срезе, либо работать "в истории".
С объектами работают обычно первым способом - в текущем временном срезе. При этом наличие версий не затрудняет нам жизнь. Если нужно узнать, что было раньше, мы можем либо запросить другой временной слой, либо историю указанной сущности. Система при этом может подсказывать, что, собственно, изменялось.
С отношениями обращаться к истории приходится чаще.
"Оживление" модели. Операции, Процессы, Планы
Описываемые выше категории сущностей характеризуют статическую картину, изменения в которой происходят с помощью простейших операций редактирования: добавление/удаление экземпляров сущностей, изменение значений атрибутов. С помощью таких операций при грамотно построенной модели можно без значительных трудозатрат отразить любое изменение состояния системы.
Но если мы хотим использовать систему не только для отражения ситуации, но и для поддержки деятельности, нам необходимы еще некоторые понятия для отражения операций, обычно являющихся следствием неких событий внешнего мира.
Операции. Любая операция имеет как дату (время) ее выполнения системой, так и дату (время) события во внешнем мире, послужившего основанием для этой операции. Кроме того, операция содержит информацию об операторе, ее выполнившем, и набор атрибутов. Как правило, операциям (как и объектам) присваивается уникальный идентификатор, так как на операцию приходится часто ссылаться. Вообще, по своим основным свойствам операции похожи на объекты. Они так же группируются по иерархически упорядоченным категориям, где подкатегория наследует атрибуты вышестоящей категории.
Вообще говоря, не должно быть другого способа изменить состояние системы, кроме как некоторой операцией. При этом простейшие операции - это просто редактирование, запись о котором должна сохраняться там же, где и о других операциях, со всеми необходимыми реквизитами - кто, когда, зачем и др.
Как правило, категория операции кроме набора реквизитов определяет также алгоритм ее исполнения, то есть любая операция как-то влияет на состояние данных системы (дополнительно к самому факту появления записи об операции). Причем обычно требуется, чтобы действие, выполняемое операцией, было обратимо, то есть должен быть также формализован алгоритм "откатки" операции, и в системе должны сохраняться все необходимые для этого данные.
При этом о необходимости выполнения некоторых операций нам может стать известно еще до того, как мы будем выполнять их на самом деле. То есть операции могут быть исполненными и ожидаемыми. Фиксация в системе ожидаемых операций позволяет встраивать контроль исполнения. Факт появления ожидаемой операции также может изменять состояние данных в системе, так же как и факт исполнения ожидавшейся операции.
В некоторых классах систем (например, бухгалтерских) то, что мы назвали операцией, называется Документом, а системы, построенные по этому принципу, - документно-ориентированными. Алгоритм выполнения операции в таких системах обычно описывается как набор проводок.
Процессы - совокупности связанных операций. Обычно у процесса имеется некоторый объект-носитель, появление которого порождает процесс, продвижение процесса порождает операции и изменяет состояние этого (хотя и не только) объекта, и после окончания процесса объект-носитель "застывает".
Примером может служить, например, исполнение договора. Носителем в данном случае будет Договор (объект, фиксирующий условия договора), а операциями - платежи, приемка-сдача этапов, дополнительные соглашения и др.
Часто, когда появляется объект-носитель, мы можем породить план исполнения процесса, то есть ту последовательность ожидаемых операций, которая должна быть выполнена для завершения процесса.
Операции в плане обычно упорядочены и связаны причинно-следственными связями: без исполнения одних операций другие невозможны. При этом одни операции исполняются во внешнем мире и только отражаются в системе, а другие выполняются собственно в системе.
Некоторые операции могут исполняться автоматически, когда для них возникли условия: выполнены те операции, от которых они зависят, и наступило время. Для этого в систему может быть включен планировщик, отслеживающий автоматически выполнимые операции и напоминающий персоналу о необходимости выполнения просроченных "ручных" операций.
Заключение
Описываемая концепция не является умозрительной - она многократно испробована на практике. Одно из ее приложений - комплексная система автоматизации деятельности брокерской компании Backbone, которая была разработана для "Ринако+" еще в 1996 году и до сих пор успешно эксплуатируется в ИБГ "Никойл". Имеются и другие примеры реализации.
И хотя, как и всякая методология, описываемые концепции требуют того, чтобы их пропустили через личный опыт, я надеюсь, что среди читателей найдется достаточное количество тех, чей опыт позволит им адекватно и с пользой для себя воспринять этот материал.
