Замусоривание Великого и Могучего обломками бритвы Оккама (апология иноязычных неологизмов)
Trashing of The Great and Might by The Scrap of The Okkam`s Razor (An Apology of The Foreign-language Neologisms)

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

Учётные системы как специальная категория программного обеспечения

За последние два десятка лет мне доводилось разрабатывать на заказ программные системы в самых разных предметных областях. И регулярно я ловил себя на чувстве, что отлаживаю один и тот же код. Дело в том, что несмотря на различие предметных областей (банковские, логистические, торговые, производственные) всех их объединяет то, что по сути они ведут учёт одного и того же — объектов учёта.
А природа этих объектов учёта не так уж важна с точки зрения программного кода.
И в конечном счёте всё это системы управления бизнесом, или, точнее системы управления бизнес-процессами.
Вот об автоматизации управления бизнес-процессами я и хотел бы поговорить в этой статье.
Я предлагаю использовать термин «учётные системы» как обобщение таких категорий ПО, как КИС (корпоративные информационные системы), АСУ, ERP, бухгалтерские, складские, логистические, банковские системы, в которых характерной чертой являются функции управления объектами учёта. Для учётных систем характерно то, что управление объектами учёта осуществляется пользователями, в соответствии с их бизнес-ролями и, соответственно, правами доступа. Конечно, возможны частные решения, когда некоторые манипуляции с объектами учёта производятся серверными (хранимыми) процедурами, но в конечном счёте события, влекущие активизацию этих процедур инициируются именно пользователями. В отличие, например, от АСУТП (MES), в которых события, инициирующие бизнес-процедуры, наступают помимо пользователей, например, по изменениям показаний датчиков. Впрочем, для АСУТП подобные подходы тоже вполне применимы, но это тема уже другой статьи.

Объекты учёта
Объекты учёта (бизнес-объекты) могут иметь очень разную природу с точки зрения проблемной среды. Для CRM-модуля это в первую очередь клиенты, в том числе потенциальные и их заказы. Для HR-модуля — сотрудники, позиции штатного расписания. Для складской системы — товарные партии и прочие единицы хранения. Объектами учёта могут являться как материальные объекты, так и процессы, и события. Предполагается, что каждый класс объектов учёта соответствует отдельной таблице в схеме базы данных.
Объекты учёта могут быть типизированы по разнообразным, заранее предопределённым типам. Так сотрудник может быть либо мужского, либо женского пола, клиент может быть либо физическим, либо юридическим лицом, а юридическое лицо в свою очередь может относиться к вполне определённой форме собственности и т.д.
В схеме БД типизация соответствует ссылке на справочник соответствующих типов.
Объект учёта может обладать определёнными статусами, как задаваемыемыми явно, так и наличием данных и их значений в определённых атрибутах (полях записи).Например «новый», «подтверждён», «утверждён», «завершён», «закрыт». Статусы используются для определения прав доступа к объекту, и, как следствие, к его месту в бизнес-процессе исполнения его жизненного цикла. То есть являются основой управления потоком работ (WorkFlow).
Отдельного внимания заслуживает статус типа «утверждён». Дело в том, что некоторые объекты учёта, например бюджетное назначение, требуют довольно сложной дисциплины согласования, выражающееся в форме наложения виз. Состав требуемых виз может в свою очередь зависить от других статусов или иных атрибутов. Например, то же бюджетное назначение может требовать разного состава виз в зависимости от суммы и принадлежности к статьи к бюджетному классификатору.
Учётная система может вести фискальную информацию по объектам учёта - историю их изменений. От минимальной (кто и когда создал и в последний раз изменял объект учёта) до полной детальной истории по изменению каждого атрибута, позволяющей не только выявить злоумышление, но и откатить состояние объекта учёта на нужный момент.

Диаграммы расширенной ER-нотации
В отличие от классической ER-нотации Ченя, я предлагаю формировать диаграмму из объектов («квадратиков») разных форм. Так на диаграмме будут различаться объекты учёта и справочники типов. Последние в свою очередь могут различаться по своему внутреннему устройству на линейные и иерархические. Отдельными формами могут быть представлены статусы и визы. Отдельным атрибутом объектов учёта может быть способ ведения фискальной информации. Точно так же от классических связей «один ко многим» и многие ко многим» можно перейти к гораздо более тонкому описанию связей, указывающих в первую очередь на их прикладной смысл, а не на способ размещения внешних ключей в таблицах. Например связь формы «виза» с формой «объект учёта» может указывать на условия обязательности наличия такой визы для конкретного объекта учёта. Возможно, для различных проектов могут потребоваться различные расширения. Но благодаря наличию универсального диаграммера, подбор наиболее адекватной проекту нотации не проблема.

диаграмма системы управления бизнесом

Так выглядит универсальный диаграммер и диаграммы в нём

Бизнес-процессы
Я предлагаю рассматривать бизнес-процессы как управление жизненным циклом объектов учёта. Соответственно описание бизнес-процесса — это сценарий жизненного цикла объекта учёта. Кто и что может/должен сделать с объектом учёта в зависимости от его статуса. Возможно, диаграммы описания бизнес-процессов как сценариев окажутся более громоздкими и менее наглядными, чем IDEF3 и EEPC, например, но в отличие от них они будут действительно однозначно описывать бизнес-процессы, что позволит на основе таких диаграмм автоматически генерировать прототип серверной логики и пользовательского интерфейса.

Управление правами доступа
Я предполагаю, что права доступа должны распределяться не только на уровне процедур, таблиц и их полей, но и на отдельные записи таблиц, то есть раздельно на каждый объект учёта определённого класса. Доступ к процедурам, таблицам и полям и так управляется любым SQL-сервером СУБД достаточно гибко механизмом грантования. А вот критерии прав доступа на каждую запись (объект учёта) могут быть весьма нетривиальными. Эти критерии можно разделить на относящиеся к авторству (оунерству, «владению») конкретным пользователем конкретной записи, и на относящиеся к значениям произвольных атрибутов записи.
В первом случае имеется в виду различие прав доступа в зависимости от отношения пользователя к «владельцу» записи — у его начальника, подчинённых, коллег по подразделению или иной группе. То есть начальник «владельца» записи может иметь больше прав на манипуляции с записью, чем, например, подчинённый, или вообще сотрудник другого подразделения.
Во втором случае имеется в виду, что права доступа на запись (объект учёта) имеющим значения атрибута «сумма» больше $1000 для пользователя с конкретной ролью (например, «менеджер по продажам») могут быть урезаны, по сравнению с записью, где значение атрибута «сумма» меньше $1000. Описание прав доступа так же предполагается посредством диаграмм специальной нотации, позволяющим автоматическую генерацию серверных (хранимых) процедур, вычисляющих соответствующие права доступа.

Автоматическая генерация
Я предполагаю, что прикладной проект учётной системы должен быть полностью описан набором диаграмм соответствующих нотаций. Из расширенной ER-нотации порождается схема базы данных — таблицы, соответсвующие объектам учёта и справочникам типов, таблицы статусов и виз, таблицы ведения фискальной информации, а также триггеры, сохраняющие целостность данных, в частности фиксирующие изменения объектов учёта в фискальных данных. Из диаграмм управления правами доступа порождаются хранимые процедуры, вычисляющие права доступа конкретного пользователя на каждое поле каждой записи запрашиваемого набора данных, и возвращающих запрошенный набор (за исключением записей, на которые у пользователя не оказалось никаких прав), сопровождаемый маской прав доступа (rwed-mask) на каждое поле каждой записи. Из диаграмм сценариев бизнес-процессов порождаются серверные процедуры, вычисляющие статус, в частности по составу имеющихся для каждого объекта учёта виз.
И (NB!) прототип диаграмм пользовательского интерфейса.
А вот сложные и нетиповые алгоритмы поддержки бизнес-логики приложения генерировать автоматически смысла нет — проще реализовать их вручную и привязать к триггеру или к кнопке на пользовательском интерфейсе.

автоматически сгенерированная система управления бизнес процессами

В этом тестовом приложении все формы и их элементы сгенерированы автоматически — ни одной строчки кода, написанного вручную.

Структура пользовательского интерфейса учётных систем
Современные RAD-системы (Delphi, PowerBuilder и другие) позволяют разработчику создавать пользовательский интерфейс (GUI) буквально как душе угодно. Но реально в каждом проекте устанавливается стандарт на пользовательский интерфейс хотя бы для сохранения стилистического единства. И это касается не только эстетики отображения элементов интерфейса, но их функционального поведения. Согласитесь, что странно выглядит продукт, в котором горячие клавиши, состав управляющих кнопок, чекбоксов и радиокнопок или реакция на клики мыши заряжены совершенно по-разному.
Я предположил, что состав пользовательского интерфейса может быть структурирован, и предлагаю такую структуризацию.
Заранее прошу прощения за, может быть, неблагозвучную терминологию.
1) Мэйнлет — список выбора объекта учёта определённого класса,
с набором управляющих кнопок read,new,delete,save
2) Детлет — форма, содержащая значения атрибутов выбранного
в списке выбора мэйнлета объекта учёта. Такие атрибуты, как
типы объекта учёта, задаются соответсвующими списками выбора -
лукапами (lookup). Кроме того, на детлете может быть задан
подчинённый мэйнлет — список выбора для объектов учёта,
подчинённых данному объекту учёта. Например заявки данного клиента.
3) Агрлет — форма, содержащая агрегатные (суммарные, средние,
максимальные или минимальные) значения определённых атрибутов
объекта учёта на выборке, заданной в списке выбора мэйнлета
4) Фильтлет — форма фильтрации выборки мэйнлета. Фильтлет состоит
из полей с отношением (<,>,=,~ и т.д.), лукапов фильтрации по типам
и подчинённых фильтлетов, в свою очередь фильтрующих состав лукапов.
Все элементы фильтлета могут быть наделены чекбоксами, указывающими
участвует ли данный элемент в фильтрации. Вместо чекбоксов могут
быть радиогруппы, указывающие какой из элементов участвуе в фильтрации,
предполагая, что участвовать может только один элемент из радиогруппы.
5) MMRлет (точно неблагозвучно :( , может «узлет» будет лучше? :) )
Элемент, управляющий много-множественной связью — привязкой.
Справа налево из одного списка в другой перекидываются строки при
привязывании подчинённых объектов учёта к главному, Слева направо -
при отвязывании. Или наоборот. Как больше понравится заказчику :)
6) Функлет — форма вызова процедуры. Её поля рассматриваются как параметры
вызываемой процедуры.
В общем случае все списки выбора могут быть реализованы различными элементами используемой среды разработки. Я пользуюсь Tcl/Tk, так что списки выбора могут быть представлены комбобоксами, листбоксами, тривью и иными, доступными в тулките или его расширениях. Один (с раскраской, переупорядочиванием и быстрым поиском по колонкам) я даже сам реализовал.
Любой из вышеприведённых элементов может быть размещён одним из
нижеперечисленных способов:
1) Отдельный фрейм. На той же форме, но в отдельной рамке
2) Закладка. Ну понятно… Впрочем, есть возможность размещать элементы
на общих закладках, а есть на специализированных. То есть для фильтлетов,
например, свой собственный набор закладок, для детлетов — свой, и т.д.
3) Локально перекрывающий фрейм. Это фрейм отрисовывается поверх того окна,
на котором размещена кнопка его вызова.
4) Глобально перекрывающий фрейм. Он отрисовывается поверх всего приложения.
5) Отдельное окно. С рамкой, крестиком, квадратиком… Ну то есть полноценное
окно с точки зрения операционной системы.
Понятно, что всё это многообразие в рамках одного проекта бессмысленно.
Но надо же как-то потрафить эстетическим предпочтениям заказчика.
Возникает вопрос — покрывает ли такая структуризация все мыслимые
решения для GUI учётных систем? Очевидно, нет. Всегда найдется заказчик, который захочет, чтоб, например, распределение статей бюджета велось непосредственно на «диаграмме пирога» (pieslice). Ну так недолго и вкрутить.
Возникает другой вопрос — сводима ли функциональность любого учётного приложения к такой структуре GUI? Наверное, да. А если что-то сводиться вдруг не захочет, лапами упрётся — ну так недолго и вкрутить, как я уже упоминал выше.

Возвращаясь к автоматической генерации
Как я уже упоминал выше, прототип диаграммы пользовательского интерфейса, содержащий структуру вложенности элементов и их привязку к объектам учёта, и в общем случае вообще к таблицам и их полям, может быть автоматически сгенерирован из диаграммы бизнес-процессов. Вопрос в том, следует ли для данного прикладного проекта стремиться как можно тоньше подстроиться под требования заказчика в алгоритме автогенерации, или проще потом ручками прототип довести до рабочего состояния. Возможно, если заказчик предъявляет действительно адекватные требования, которые очевидно окажутся востребованы для других заказчиков — тогда есть смысл подкрутить алгоритм. А если требования заказчика слишком экзотичны — тогда проще докручивать прототип.
И ещё. Автоматически разместить элементы на формах так, чтоб удовлетворить эстетические и эргономические требования мягко говоря сложно. Поэтому я реализовал в своём инструментарии опцию редактирования, позволяющую подвигать-порасширять (посужать?) элементы на форме. А главное, результаты такого редактирования сохраняются относительно последующих перегенераций. Ну если конечно в очередной версии какую-то форму вовсе не снесут…

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

BPEL

Business process executing language — язык исполнения бизнес-процессов, бипел. Неудачная попытка пристегнуть бизнес-процессы к веб-сервисам. Так и не заработал. А ведь в середине прошлого десятилетия был очередной «серебряной пулей», столько о нём вещали всюду… Ну да вещать — не мешки ворочать :)

ERP

Enterprise resource planning. Дословно — планирование ресурсов предприятия. По смыслу — АСУ, автоматизированная система управления. В расширенном смысле — КИС — корпоративная информационная система.

 

RAD

Rapid application design — средства автоматизации разработки программных приложений. Самый широко используемый в России пример — Delphi.

 

DDL-SQL

Data definition language of structured query language — язык, позволяющий описывать схемы баз данных со всеми составляющими её элементами — таблицами, индексами, триггерами и т.д.

 

САПР

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

Серебряная пуля

1) Мифическое средство борьбы с мифическими вампирами. В англоязычной культуре — панацея, средство спасения ото всего.

2) Название книги Брукса (легендарного автора книги «Мифический человеко-месяц»). В книге «Серебряная пуля» Брукс предостерегал от преувеличения значимости надвинувшегося тогда на человечество объектно-ориентированного программирования. Как всегда, оказался прав. Проблем ООП привнесло едва ли не больше, чем решило.

Репликационный сервер

Программное средство для синхронизации данных на разных, как правило удалённых, серверах СУБД. Не гарантирует целостность данных. Просто констатирует наличие репликационных конфликтов и предлагает разрешить их вручную.

Синяя Борода

Сказочный персонаж — брачный маньяк-аферист. Женившись, запрещал новой жене посещать тайную комнату своего замка. Ослушавшихся запрета убивал, а трупы складывал в эту же комнату. Не правда ли, очень похоже на Axaptу и Oebs :)