В своей статье "Автоматизация хаоса", я уже упоминал об исповедуемом мною подходе к корпоративной автоматизации (разработка "от данных"), позволяющего быстро создавать системы, приносящие реальную пользу. Значительный читательский отклик показал актуальность поднятого вопроса.

Но практическое использование этого подхода требует методологического инструментария, позволяющего "правильно" структурировать наблюдаемую действительность, и перекладывать ее на язык эффективно реализуемых моделей. Кроме того, важно понимать границы применимости подхода - т.е. когда и почему его использование может быть эффективным.

Задача этой публикации - описать тот набор понятий и подходов, который в течение ряда лет я успешно использовал при проектировании и реализации самых различных систем. Описываемая система понятий легко отображается в реляционную модель и обеспечивает регулярное проектирование пользовательского интерфейса.

Цели корпоративной автоматизации

Имеет смысл немного порассуждать о целях автоматизации вообще. Многие излагаемые здесь соображения могут показаться тривиальными, но жизнь показывает, что в реальной жизни они очень часто игнорируются, что приводит к весьма печальным результатам как для проектов автоматизации, так и для компаний, их осуществляющих.

Прежде всего - корпоративная автоматизация является не целью, а средством. Любая офисная деятельность может быть осуществлена с помощью Word-a, Excel-а и соответствующим образом построенного персонала. Поэтому разработка сложных корпоративных систем оправдана только тогда, когда она приносит реальный экономический эффект - т.е. решает некоторые бизнес-задачи.

Далее - полная автоматизация деятельности сколько-нибудь большого по размерам предприятия является светлой, но, увы, недосягаемой мечтой. Поэтому автоматизация - это всегда длительный процесс, в ходе которого постепенно охватывается все большее число бизнес-процессов компании. И крайне важным является последовательность, в которой это происходит, поскольку именно от правильности определения последовательности зависит сроки окупаемость разработки, да и ее судьба в целом. Очевидно, что последовательность этапов разработки и внедрения должна быть такова, чтобы наиболее приоритетные бизнес-задачи решались в первую очередь.

Имеется два разных класса бизнес-задач, решаемых при внедрении автоматизированных систем.

Один класс задач - это обеспечение эффективного принятия и исполнения решений, т.е. обеспечение ключевых лиц, принимающих решения, полной, оперативной и удобной для использования информацией, необходимой им для принятия решений и контроля за их исполнением. При этом ключевые лица - это не обязательно высший менеджмент. Это могут быть и рядовые сотрудники, в том случае, если от правильности и четкости выполнения ими своих обязанностей существенно зависят показатели деятельности компании.

Для этого класса задач первоочередной задачей является создание и поддержка единого информационного пространства организации, интегрирующего по возможности, всю корпоративную информацию, и позволяющего презентовать ее удобном для использования виде. К этому же классу примыкает такая бизнес-задача, как уменьшение зависимости компании от конкретных персоналий, что требует максимально возможного отчуждения существенной информации.

Имеется также другой класс задача - снижение операционных издержек за счет автоматизации рутинных операций, повышения производительности труда и внедрения автоматизированных систем контроля исполнения. Этот класс задач решается путем создание комплекса автоматизированных рабочих мест (АРМов), обеспечивающих максимально возможный сервис их пользователям.

Естественно, все взаимозависимо - часто невозможно обеспечить накопление информации, не обеспечив удобными АРМ-ами тех работников, которые должны вводить эту информацию, приложения для доступа и изучения информации также можно рассматривать как некоторые АРМы, и конечно, работа АРМов невозможна без информационной базы.

Но тем не менее эти классы задач нужно разделять, так как от того, какие задачи признаются приоритетными, зависит как раз та последовательность разработки и внедрения, о важности которой мы уже говорили.

Итак - описываемые в этой статье подходы хорошо работают в том случае, если в качестве приоритетной признается задача информационного обеспечения.

Эта ситуация достаточно часта, по крайней мере, это было именно так в подавляющем большинстве случаев, с которыми мне приходилось встречаться. Дело в том, что экономия на операционных издержках при достаточно дешевом персонале обычно не окупается - часто дешевле нанять лишнюю девочку за 200$ в месяц, чем платить 10000$ за дополнительный АРМ.

Конечно, бывают критические участки, которые невозможно "расшить" наймом дополнительного персонала, и от производительности труда на которых существенно зависит доход и конкурентоспособность компании, но это скорее исключение, чем правило. Еще одно исключение - это использование готовых или разработка тиражируемых систем, где стоимость разработки раскладывается на множество пользователей, за счет чего удельная стоимость решения (в расчете на рабочее место) оказывается достаточно низкой.

Разработка "от данных" - основные принципы

Идея разработки "от данных" основана на том, что базовые информационные структуры, описывающие корпоративную информацию (предметную область), являются гораздо более фундаментальными и устойчивыми к изменениям ситуации, чем бизнес-процессы, организационная структура и распределение обязанностей между исполнителями.

Более того - значительная часть работы, выполняемая персоналом, на самом деле сводится к поиску, вводу и редактированию некоторой информации. И если нам удается создать удачную информационную модель предметной области, и обеспечить "естественные" операции ввода, поиска и редактирования информации, то это уже обеспечивает хороший базис для внедрения и использования системы.

Т.е. концепция проектирования системы "от данных" предполагает создание и внедрение начальной версии системы в виде "проблемно-ориентированного редактора", предоставляющего возможность полного управления информацией предметной области. Для создания сложных отчетов при этом, как правило, можно использовать какие-то подключаемые стандартные средства, а простые выборки нужно уметь получать в самом редакторе.

Конечно, сервис по вводу и редактированию информации, обеспечиваемый такой системой, будет ниже, чем в случае специализированных АРМов, так как одна содержательная транзакция часто оказывается разделена на несколько базовых действий, но в большинстве случаев уровень сервиса оказывается приемлемым. Далее развитие системы может идти по пути разработки отдельных АРМ для критических участков, позволяющих реализовывать бизнес-транзакции как одно целое.

Ключевой фактор в таком подходе - это выбор удачной метамодели, в рамках которой мы будем моделировать предметную область. Дело в том, что уже упомянутые "естественные" операции ввода, поиска, просмотра и редактирования информации должны быть естественными для метамодели, и в то же время естественным образом отображаться на операции предметной области.

Т.е. описываемый подход является действительно эффективным в том случае, если нам не придется программировать специальные, "заточенные" под предметную область операции визуализации, ввода и редактирования данных, а мы с достаточной степенью приближения получим эти операции в силу того, что правильно выберем метамодель и правильно отобразим нашу предметную область в эту метамодель.

Метамодели данных

Итак - метамоделью я называю некоторую целостную концепцию организации данных, определяющую структуру, интерфейс просмотра, поиска, ввода и редактирования информации. Следствием целостности является ее постижимость для конечного пользователя, который понимает, как "как оно устроено", что и как можно, а что нельзя делать с данными.

Для того, чтобы пояснить эти тезисы я приведу примеры нескольких широко известных и успешных метамоделей.

Плоские файлы

Набор упорядоченных однородных записей, каждая из которых содержит некоторый набор полей (атрибутов). Естественными способами просмотра является таблица и набор карточек (форм). Естественными способами ввода является по-записный ввод и редактирование - либо в табличном (при небольшом числе полей), либо в карточном представлении. Естественным способом задания поискового запроса является QBF (query by form) - т.е. наложение конъюнктивного условия на поля записи и отбор записей, удовлетворяющих этим условиям. При этом обычно можно управлять порядком записей, задавая _ключи сортировки_ - т.е. атрибуты, задающие лексикографический порядок.

Часто используется также операции консолидации записей - вычисления сумм, средних и др., и в том числе и многоуровневый (с промежуточными итогами) с помощью группировки записей, определяемой значениями некоторых атрибутов.

Плоские файлы и системы работы с ними (электронные картотеки) появились очень давно (dbase II) и до сих пор пользуются заслуженной популярностью до сих пор (Lotus notes).

Я так подробно остановился на плоских файлах именно потому, что это наиболее простая из успешных метамоделей, в полной мере демонстрирующая описываемый подход.

В самом деле - если ваша информация укладывается в структуру плоского файла, то описав состав полей, вы автоматически получаете почти готовую прикладную систему (например, записную книжку), уже обеспеченную всеми необходимыми функциями.

Электронные таблицы

Другую модель предлагают электронные таблицы. Информация организована в виде прямоугольной таблицы, в ячейках которой хранятся значения, вообще говоря, разных типов, или формулы. Наиболее успешно электронные таблицы используются для отображения статических моделей, где имеется структура взаимозависимых числовых параметров, причем данные чаще изменяются, чем появляются и исчезают. Кроме того, электронные таблицы полностью покрывает возможности плоских файлов, зачастую используются в качестве таковых, и не уступают им по популярности.

И снова мы видим фундаментальное свойство хорошей метамодели - если мы сумели естественно отобразить свои данные на электронную таблицу, мы автоматически получили готовое приложение, позволяющее вводить, просматривать и анализировать информацию в естественном для нее виде.

Реляционные БД

В свое время реляционная модель претендовала на то, чтобы стать успешной метамоделью для всех типов информации. И именно с ее появлением были связаны популярные в начале 70-тых победные реляции о "программировании без программистов" и др. Считалось, что концепция связывания таблиц достаточно проста и естественна для того, чтобы ей мог оперировать конечный пользователь, и соответственно, программист БД теперь не нужен...

В качестве естественного средства запросов к реляционным БД был разработан графический интерфейс "Query by example" (QBE), в качестве естественного интерфейса для просмотра/редактирования данных выступал многооконный интерфейс, в каждом окне обеспечивающий работу с одной таблицей (плоским файлом). Следы этого подхода мы видим во всех "настольных" системах, начиная с Paradox и заканчивая MS Access.

Тем не менее, жизнь показала, что только очень простые предметные области ложатся на реляционную модель "естественным" способом, т.е. таким, при котором не требуется программирование и простой пользователь может, например, пользоваться оболочкой Access-а как готовым приложением.

Поэтому реляционные модели данных в значительной степени утратили функцию метамодели, и в силу своей универсальности и множества эффективных реализаций (реляционные СУБД) успешно используются как базис для реализации различных систем, в том числе и оперирующих некоторыми метамоделями.

Другие примеры метамоделей

Еще одна успешная метамодель, крайне удобная для учетных (бухгалтерских, складских и др.) задач - это многомерные базы данных (известные как DM или OLAP). Данные в этой метамодели представлены в виде многомерного куба, где на измерениях определены некоторые иерархии, а в клетках этого куба находятся числовые значения. Операции извлечения данных из такого куба описываются в терминах поворотов, срезов, и иерархического "схлопывания" измерений с агрегированием значений (суммирование, взятие среднего и др.).

Подробно мы эту модель рассматривать не будем - несмотря на ее молодость, по ней существует достаточно обширная литература и множество поддерживающих ее программных продуктов.

Еще один пример метамодели данных - это XML. С появлением связанных технологий, таких как XSL (язык описания визуализации), XQL (язык описания запросов) и XML-баз данных (например, Tamino от Software AG) XML стал претендовать на роль успешной и очень удобной для многих приложений метамодели данных. Впрочем, новое - хорошо забытое старое. Как способ организации данных, XML очень похож на давным-давно используемые иерархические базы данных, которые нынче принято называть "постреляционными"...

Что предлагается...

Теперь я, наконец, подошел к тому, чтобы описывать метамодель, которую я использовал во множестве проблемно-ориентированных редакторов на протяжении последних десяти лет.

Специального названия для нее я до сих пор не придумал (может, кто подскажет). В отличии от перечисленных выше метамоделей она не является простой, так как оперирует примерно десятком разнородных понятий.

Она также не подержана (к сожалению) инструментально - т.е. нет стандартного программного продукта, позволяющего на базе описания модели предметной области в предлагаемых терминах автоматически получить работающую систему. Но, поскольку она достаточно близка к реляционной модели, а ее интерфейсы легко отображаются стандартными средствами GUI, то реализовать модель на ее базе не слишком трудоемко, что неоднократно делалось мной и моими коллегами в разных программных средах.

Но она описываемая концепция обладает свойствами метамодели - т.е если вы изложите анализируемую действительность в предлагаемых терминах, вы немедленно получаете... Нет, к сожалению, не работающую систему, но, по крайней мере, ее функциональную спецификацию, описывающую как организацию данных, так и пользовательские интерфейсы. А также высокую степень уверенности в том, что такая система может быть быстро реализована, будет полезна своим заказчикам с самых ранних этапов внедрения, и может быть легко доработана до любого требуемого состояния.

Интерфейсные объекты и метафоры

Ключевое свойство метамодели - единство структур данных и интерфейсов. В этом разделе мы опишем те понятия и концепции, которые используются для организации пользовательского интерфейса системы, создаваемой по принципу "проблемно-ориентированного редактора данных".

ОКНО - окно в смысле WINDOWS. Каждое окно в каждый момент времени содержит либо ТАБЛИЦУ, либо ФОРМУ. Окна могут быть Модальными (т.е. не допускать выполнения операций в других окнах приложения, пока это окно не закрыто) и Немодальными, Немодальные окна могут быть ЗАВИСИМЫМИ - т.е. их содержимое может зависеть от действий, выполняемых в других окнах, и обновляться автоматически.

ТАБЛИЦА содержит информацию об упорядоченной совокупности однородных записей, обычно по строке на запись. Атрибутам записи соответствуют колонки таблицы. Таблица обычно используется для просмотра, реже - для редактирования. Некоторая запись таблицы обычно является текущей, и доступна навигация по записям (изменение текущей позиции) - перемещения вверх/вниз, на первую/последнюю. Часто реализуется специализированный поиск либо по набору первых букв, либо полному значению поискового поля.

Иногда таблицы снабжают специальными панелями управления, позволяющими фильтровать записи и управлять их порядком. Сортировку иногда выносят на шапку таблицы (клик на шапке поля вызывает сортировку по нему).

ФОРМА содержит информацию об единичной записи некоторой категории, представленную в виде карточки (поля, подсказки, элементы оформления и др.). Формы часто бывают многостраничные - с закладками. Когда "под" формой лежит упорядоченная совокупность записей, форму также используются для навигации - включают в нее кнопки/клавиши перемещения на следующую/предыдущую и первую/последнюю запись.

Обычно имеется способ перейти из таблицы в форму, содержащую развернутую информацию о текущей записи таблицы. Это может происходить в том же окне, где таблица, а может сопровождаться открытием отдельного окна. Если такое окно открывается как немодальное, то его делают зависимым от окна таблицы, т.е. навигируя по таблице, мы меняем содержимое окна формы.

ПОДФОРМА позволяет включить в форму в качестве ее элемента таблицу. Подформы обычно используют для работы с МНОЖЕСТВЕННЫМИ АТРИБУТАМИ и ОТНОШЕНИЯМИ.

QBF. Крайне полезно иметь унифицированную возможность для любой совокупности записей уметь отобрать из нее подмножество, удовлетворяющее заданным пользователем критериям, и упорядоченное указанным способом.

Эти критерии удобней всего задавать в стиле Query By Form - когда для ввода критериев используется обычная форма для данного типа записи, и в ее поля вводятся ограничения на значения соответствующих атрибутов. В стиле QBF проще всего задавать конъюнктивные условия (хотя можно и дизъюнктивные - путем задания нескольких "слоев").

Исключительно полезными при этом является возможность

- параметризовать запросы (например, от текущей даты с некоторым смещением)

- включать в состав запроса явно написанные на SQL выражения

- создавать библиотеки именованных запросов, предоставив механизм для сохранения/восстановления/редактирования запросов.

- персонализировать доступ к сохраненным запросам, так как в реальной жизни их накапливается много.

Почти все объекты и отношения нуждаются в возможности включения в записи о них дополнительной, плохо структурированной и заранее неизвестной информации, которая, тем ни менее, должна позволять искать эти объекты.

Это проще всего делать, включая в состав полей текстовое поле примечания, допускающее поиск по подстроке в стиле QBF.

СПЕЦИАЛИЗИРОВАННЫЕ ПОИСКИ, ФИЛЬТРАЦИИ И СОРТИРОВКИ

Наряду с общим механизмом QBF часто удобно иметь для часто используемых отборов и сортировок специализированные инструменты на панели (два-три-четыре типичных варианта сортировки и критерия фильтрации).

Категории сущностей

Описываемые категории являются основным интеллектуальным инструментом при анализе предметной области. Правильное выделение объектов, отношений, справочников и др. является залогом успешной реализации системы. И хотя отображение действительности на модель, как всегда, может быть выполнено многими разными способами, но описываемые категории вычленяются, как правило, достаточно однозначно.

ОБЪЕКТ - самоопределенная сущность, сохраняющая свою аутотентичность от "рождения" до "смерти". Характерными примерами объектов, встречающихся почти в любой ИС, являются люди, организации и документы.

Объект всегда имеет простой уникальный идентификатор, либо естественный (являющийся атрибутом самого объекта - например, ИНН для организаций или SSN для американца), либо искусственный, полуученый путем автоматической нумерации объектов в системе и/или в виде некой хэш-функции на базе его естественных атрибутов, образующих уникальное сочетание.

Объект почти всегда имеет ИМЯ. Объект имеет ряд АТРИБУТОВ (реквизитов) (например, город, улица и др.), которые обычно группируются в некоторые группы логически связанных атрибутов (например, почтовый адрес). В качестве атрибута могут выступать простые значения (числа, строки, тексты и др.) и ССЫЛКИ, т.е. идентификаторы других объектов. Кроме того, в качестве атрибутов могут выступать СПРАВОЧНИЕ КОДЫ.

В состав атрибутов объекта всегда нужно включать произвольное текстовое ПРИМЕЧАНИЕ

Объекты делятся на разные категории, определяемые набором атрибутов и их значениями. Категории могут быть выстроены иерархически (объектное наследование), например,

Лица

юридические лица

физические лица

резиденты

нерезиденты

объекты "нижестоящих" категорий содержат все атрибуты "вышестоящих", но могут содержать и дополнительные.

Для каждой категории может быть определено одно или несколько ПРЕДСТАВЛЕНИИЙ (VIEWs). ПРЕДСТАВЛЕНИЕ описывается набором атрибутов, в которые, кроме атрибутов самого объекта, могут входить атрибуты связанных объектов, справочников и др., а так же критерием отбора объектов, включенных в ПРЕДСТАВЛЕНИЕ

Для представления может быть определен

Вид табличного (списочного) представления

Форму (представление в виде карточки)

Форма обычно бывает многостраничной, при этом группы связанных атрибутов не разбиваются по страницам.

При просмотре списка надо уметь для любого элемента списка попасть в его ФОРМУ. В ситуации, когда в списке представлены объекты разных подкатегорий, удобно, когда вид формы для конкретного объекта специфичен для его узкой категории. Т.е. работая, например, со списком Лиц, и открывая карточку конкретного лица удобно видеть разные формы для лица физического и юридического.

Форма может открываться в том же окне (вместо списка), а может - в отдельном. Окно формы может быть как модальным, таки и немодельным (зависимым). Из просмотра формы надо уметь вернуться в список в тот же контекст. Как правило, список нужен для просмотра, а редактирование и ввод новых объектов удобней делать в Форме.

СПРАВОЧНИК - относительно небольшая (как правило) и достаточно статичная табличка, ставящая в соответствие некоторым простым обозначениям (СПРАВОЧНЫМ КОДАМ) развернутую информацию, соответствующую этим кодам. В простейшем случае это просто строки с развернутыми названиями (например, название товарной группы), в более сложном - могут быть нагружены еще какой-то информацией (например, код категории льготности, полное наименование и соответствующая ставка налогообложения).

СВЯЗЬ имеет место в случае, когда объект содержит ссылку на другой объект. Например, наличие связи между Организацией и Подразделением, определяется ссылкой из Подразделения на Организацию.

Связи содержательно именуются, причем на разных концах связи имена могут быть разные (например Вышестоящая организация, и Структурные подразделения). Для связи 1:n могут быть определены дополнительные условия а связь, ограничивающие список связанных объектов, например связь Производственные подразделения., фильтрующая из всех Структурных подразделений те, у которых есть признак производственные

Связям не соответствуют никакие дополнительные объекты данных, и определение связей используется как основа для построения интерфейсных решений. Наличие связи позволяет перемещаться (навигировать) между связанными объектами в одну и другую строну., и выполнять связанное редактирование данных.

Например, связь между Организацией и Подразделением предполагает:

- Возможность из Подразделения перейти в Организацию с целью просмотра или редактирования данных об организации.

- При вводе нового Подразделения указать Организацию, просто выбрав ее из списка.

- Возможность из Организации перейти в список ее Подразделений с целью просмотра, и редактирования как списка (добавление/удаление подразделений), так и информации об отдельных подразделениях в нем.

- возможность при построении ПРЕДСТАВЛЕНИЯ (VIEW) подразделения ссылаться на атрибуты организации.

ОТНОШЕНИЯ связывают между собой два и более объектов. Отношение не имеет собственной "cамости" и однозначно описывается теми объектами, которые в это отношение вступают, и типом отношения. Кроме этого, отношение может содержать дополнительные атрибуты. Примером отношения является Занимаемая должность, связывающая Организацию и Сотрудника, и характеризуемая типом отношения - занимаемой позицией. Это отношение может быть нагружено дополнительной информацией, такой как оклад, уровень занятости, и т.д.

Отношения также образуют систему категорий, отличающихся набором атрибутов. Интерфейсно отношения могут быть представлены либо в виде отдельных списков (по категориям), содержащих ссылки (связи) на объекты, вступившие в данное отношение, либо представляться в виде табличных подформ в формах тех объектов, которые вступают в это отношение. Например, может быть

(1) отдельная доступная для просмотра/редактирования таблица Занимаемые должности, и/или

(2) страничка (подформа) Сотрудники в форме Организация, и/или

(3) страничка (подформа) Занимаемые должности в форме Люди.

В случае (1) ввод и редактирование записей производится в стиле связей (из Организаций и Сотрудников к Занимаемой должности, и из Занимаемой должности - к Организациям и Сотрудникам. В случае 2 и 3 - путем редактирования соответствующих подформ. Записи подформы, содержащих ссылки на объекты, лучше редактировать переходом в форму, хотя при малом кол-ве атрибутов можно это делать и в таблице.

МНОЖЕСТВЕННЫЕ АТРИБУТЫ И ГРУППЫ

Множественные атрибуты (группы атрибутов) похожи на отношения 1:n, но в отличии от них не содержат ссылки на второй и прочие объекты. Пример множественного атрибута:

список телефонов

Если считать, что в телефоне выделяется код и тип телефона (рабочий, домашний, мобильный и др.), то телефоны являются множественным групповым атрибутом.

Интерфейсно множественные атрибуты естественнее всего представлять подформой с редактированием прямо в таблице, если число атрибутов в группе мало.

Для отношений и множественных атрибутов достаточно сложно, но возможно, реализовать механизм задания QBF-запросов, так как возможно задание нескольких условий - либо конъюнктивных, либо дизъюнктивных. Интерфейсно включение условия на отношение или множественный атрибут должно происходит так же, как ввод новой записи.

Работа со временем, версии

Изменения состояния информационной модели состоят в возникновении, изменении атрибутов и исчезновении сущностей. Зачастую нас интересуют вопросы: "что было вчера?", "Что изменилось?". Для ответов на эти вопросы нужны консистентные способы представления истории в модели.

Заметим, что изменения данных могут иметь два содержательно разных источника - реальные изменения во внешнем мире, который мы моделируем, и "ошибки ввода". История интересует нас как правило, только в отношении изменений во внешнем мире. Хотя историю редактирований тоже может быть интересно хранить. Иногда эти два типа изменений не различаются.

Для разных категорий сущностей представление истории решается по разному.

В ОБЪЕКТ можно включить дополнительный атрибут - дату/время возникновения версии (временной штамп), и при каждом изменении создавать новую версию объекта. Если есть атрибуты, более других подверженные изменениям, то для такие атрибуты можно выносить в множественные группы, добавив к ним временной штамп.

Для справочников можно поступить точно также - снабжать записи, расшифровывающие коды, временным штампом.

ОТНОШЕНИЯ в мире не меняются принципиально (запись отношения не аутентична) - любое изменение означает прекращение старого отношения, и возникновение нового. Это означает, что все отношения должны быть снабжены атрибутами - временем возникновения и временем прекращения.

МНОЖЕСТВЕННЫЕ АТРИБУТЫ в этом смысле никаких трудностей не вызывают - в группу добавляется время, и у них появляется еще одна причина для размножения.

Для разных категорий с интерфейсной точки зрения мы можем либо все время работать в одном временном срезе, либо работать "в истории".

С объектами работают обычно первым способом - в текущем временном срезе. При этом наличие версий не затрудняет нам жизнь. Если нам нужно узнать, что было раньше, мы можем либо запросить другой временной слой, либо историю указанной сущности. Система при этом может подсказывать - что собственно, изменялось.

С отношениями обращаться к истории приходится чаще.

"Оживление" модели. Операции, Процессы, Планы

Описываемые выше категории сущностей характеризуют статическую картину, изменения в которой происходят с помощью простейших операций редактирования - добавления/удаление экземпляров сущностей, изменение значений атрибутов. С помощью таких операций при грамотно построенной модели можно не слишком трудоемко отразить любое изменение состояния системы.

Но если мы хотим использовать систем не только для отражения ситуации, но и для поддержки деятельности, нам необходимы еще некоторые понятия для отражения операций, обычно являются следствием некоторых событий внешнего мира.

ОПЕРАЦИИ. Любая операция имеет как дату (время) ее выполнения системой, так и дату (время) события в внешнем мире, послужившего основанием для этой операции. Еще операция содержит информацию об операторе, ее выполнившем, и набор атрибутов. Как правило, операциям (как и объектам) присваивается уникальный идентификатор, так как на операцию приходится часто ссылаться. Вообще, по своим основным свойствам, операции похожи на объекты. Они так же группируются по иерархически упорядоченным категориям, где подкатегория наследует атрибуты вышестоящей категории.

Вообще говоря, не должно быть другого способа изменить состояние системы, кроме как некоторой операцией. При этом простейшие операции - это просто редактирования, запись о которых должна сохраняться там же, где и о других операциях, со всеми необходимыми реквизитами - кто, когда, зачем и др.

Как правило, категория операции, кроме набора реквизитов определяет также алгоритм ее исполнения - т.е. любая операция как-то влияет на состояние данных системы (дополнительно к самому факту появления записи об операции). Причем обычно требуется, чтобы действие, выполняемое операцией, было обратимо - т.е. должен быть также формализован алгоритм "откатки" операции, и в системе должны сохраняться все необходимые для этого данные.

При этом о необходимости выполнения некоторых операций нам может стать известно еще до того, как мы будем выполнять их на самом деле. То есть операции могут быть исполненными, и ожидаемыми. Фиксация в системе ожидаемых операций позволяет встраивать контроль исполнения. Факт появления "ожидаемой'' операции также может изменять состояние данных в системе, так же как и факт исполнения ожидавшейся операции.

В некоторых классах систем (например, бухгалтерских) то, что мы назвали операцией, называется Документом, а системы, построенные по этому принципу - документно-ориентированными. Алгоритм выполнения операции в таких системах обычно описывается как набор проводок.

ПРОЦЕССЫ - совокупности связанных операций. Обычно у процесса имеется некоторый объект-носитель, появление которого порождает процесс, продвижение процесса порождает операции и изменяет состояние этого (хотя и не только) объекта, и после окончания процесса объект-носитель "застывает".

Примером может быть, например, исполнение договора. Носителем в данном случае будет Договор (объект, фиксирующий условия договора), а операциями - платежи, приемка-сдача этапов, дополнительные соглашения и др.

Часто, когда появляется объект-носитель, мы можем породить ПЛАН исполнения процесса, т.е. ту последовательность ожидаемых операций, которая должна быть выполнена для завершения процесса.

Операции в ПЛАНЕ обычно упорядочены и связаны причинно-следственными связями - без исполнения одних операций другие невозможны. При этом одни операции исполняются в внешнем мире, и только ОТРАЖАЮТСЯ в системе, а другие выполняются собственно в системе.

При этом некоторые операции могут быть выполнены автоматически, когда для них возникли условия - выполнены те операции, от которых они зависят, и наступило время. Для этого в систему может быть включен ПЛАНИРОВЩИК, отслеживающий автоматически выполнимые операции, и напоминающий персоналу о необходимости выполнения просроченных "ручных" операций.

Заключение

Описываема концепция не является чисто теоретической - она многократно испробована на практике. Одно из ее приложений - комплексная система автоматизации деятельности брокерской компании Backbone, которая была разработана для Ринако+ еще в 1996 году, и до сих пор успешно эксплуатируется в ИБГ "Никойл". Имеются и другие примеры реализации.

И хотя, как и всякая методология, описываемые концепции требуют того, чтобы их пропустили через личный опыт, я надеюсь, что среди читателей найдется достаточное количество тех, чей опыт позволит им адекватно и с пользой для себя воспринять этот материал.