Автоматизация хаоса-2

В своей статье "Автоматизация хаоса", опубликованной в Computerra #17/1999, я уже упоминал об исповедуемом мною подходе к корпоративной автоматизации (разработка "от данных"), позволяющего быстро создавать системы, приносящие реальную пользу. Значительный читательский отклик показал актуальность поднятого вопроса. Но практическое использование этого подхода требует методологического инструментария, позволяющего "правильно" структурировать наблюдаемую действительность и перекладывать ее на язык эффективно реализуемых моделей. Кроме того, важно понимать границы применимости подхода - когда и почему его использование может быть эффективным. Задача этой публикации - описать тот набор понятий и подходов, который в течение ряда лет я успешно использовал при проектировании и реализации самых различных систем. Описываемая система понятий легко отображается в реляционную модель и обеспечивает регулярное проектирование пользовательского интерфейса.

Андрей Акопянц, Computerra #25/2000

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Query By Form (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 году и до сих пор успешно эксплуатируется в ИБГ "Никойл". Имеются и другие примеры реализации.

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

Об авторе:

Андрей Акопянц - директор Института коммерческой инженерии (www.ice.ru). Страница в Internet: www.ice.ru/libertarium/peoples/akop.html.