Технологическия платформа учетных систем
"Мельница Данных"
 
  1. Введение. Традиционные подходы к созданию и сопровождению учетных систем
  2. Решения, предлагаемые технологией "Мельница данных"
  3. Работа с системой
    • Запуск оболочки "Обозреватель данных"
    • Элементы интерфейса пользователя
    • Работа с формами и таблицами данных
    • Работа с инспектором объектов
    • Работа с формаой задания параметров
    • Формирование отчетов Microsoft Excel
    • Формирование отчетов в виде HTML-документов

 

  Введение. Традиционные подходы к созданию и сопровождению учетных систем
 

Компьютер предназначен для обработки информации. Он получает исходную информацию, анализирует ее и выдает результат обработки. Достаточно рано компьютеры научились выдавать результат расчета в приемлемом для человека виде, а вот где взять исходную информацию в виде, приемлемом для последующей обработки? Таким образом, встала задача по вводу информации в компьютер (для последующей быстрой обработки и  вывода результата в приемлемом виде), а также сохранению ее там, чтобы не вносить каждый раз заново. Появилась потребность в методах формализованного хранения и обеспечения доступа к сохраненной информации, т.е. появилась необходимость в учетных системах и базах данных. Чем они отличаются друг от друга?
База данных хранит, анализирует и предоставляет доступ к формализованным данным  НЕЗАВИСИМО от их семантики, от их смысла.
Учетная система транслирует ввод пользователя в ФОРМАЛИЗОВАННЫЕ команды управления базой данных и инициирует тем самым процессы сохранения, изменения и обработки данных. Также задачей учетной системы является выдача результатов расчетов в удобном для человека виде. Т.е. учетная система  «паразитирует» на базе данных.
Семантические алгоритмы («для каждого кредитора, который является VIP…») предпочтительно сосредоточить в учетной системе. Почему это так? Потому что однажды было принято решение стандартизировать системы управления базами данных. Для этого была избрана реляционная модель. Что такое реляционная модель ? Объекты реального мира представляются в БД в виде « реляционных кортежей ». Кортеж – это набор данных некоторых заранее оговоренных типов. В обычной жизни «кортеж» называют также записью.  Кортежи имеют свое время жизни и могут быть сохранены. Аналитик (это тот человек, который строит и сопровождает модель) определяет состав и типы элементов кортежа, представляющего объект реального мира (эти элементы принято называть полями). Определяет ограничения, налагаемые на значения этих полей. Определяет связи между элементами кортежей. Реляционная модель рекомендует использовать ссылки, устанавливающие отношения между элементами кортежей.
Например, строим модель, описывающую человека – уроженца некоего региона:

i2
Модель вводит две сущности: «Человек» и «Регион». Каждая строка каждой из таблиц представляет собой кортеж (или запись). Полями кортежа, представляющего человека, являются:

  1. Фамилия (тип: строковый);
  2. Имя  (тип: строковый);
  3. Отчество  (тип: строковый);
  4. Дата рождения  (тип: дата);
  5. Регион  (тип: строковый).

Каждое поле имеет определенный тип. Сущность «Регион» имеет одно поле «Регион» строкового типа.
Организована ссылка, устанавливающая, что каждое значение в поле «Регион» кортежа, представляющего сущность «Человек», соответствует одному из значений в поле «Регион» сущности «Регион». Это налагает ограничение на значение поля «Регион» сущности «Человек» и ограничение уникальности поля «Регион» сущности «Регион». Уникальность необходима для того, чтобы определять посредством ссылки однозначное соответствие региона. Идентичность региона, если она не определяется семантически (допустим, существует два разных региона с одинаковым наименованием) вводится искусственно посредством суррогатного ключа. Этот ключ является однозначным идентификатором региона и используется для организации ссылок следующим образом:

i3
Мы присвоили регионам произвольные, но уникальные, числовые идентификаторы, что позволило нам организовать ссылку стандартным образом, не зависящим от семантики представленных сущностей. Такая операция называется нормализацией. При последовательном применении нормализации к реляционной модели модель можно привести к так называемым нормальным формам I, II и III.
Таким образом, видно, что для организации ссылки необходимо иметь идентичность на принимающей стороне. Где идентичность – там уникальность, где уникальность, там необходим быстрый индексный доступ каждому идентифицированному кортежу.  Затем аналитик определяет алгоритмы обработки кортежей, и за этом заканчивает работу. Результатом его трудов является «реляционная модель».  Для того чтобы подготовить такую модель, необходимо владение теорией реляции и знание довольно большого количества стандартных приемов проектирования.  Эта модель поступает программисту на реализацию.
Как осуществляется реализация? Программист создает формальные описания всех сущностей модели, ограничений, связей, алгоритмов обработки данных на некоем формальном языке. В качестве стандарта языка, описывающего реляционную модель, был принят стандарт SQL (Structured Query Language, или «Структурированный язык запросов»). Этот язык состоит из двух подмножеств:

  1. DDL (data definition language) – для описания структур хранения и алгоритмов обработки данных;
  2. DML (data manipulation language) – для манипуляции данными.

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

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

а также в модули, реализующие пользовательский интерфейс в части:

  1. ввода данных пользователем;
  2. отображения по-новому организованных данных;
  3.  формирования отчетов по новым критериям на основе по-новому организованных данных.

Модули, реализующие интерфейс пользователя, как правило, реализуются на компилируемом языке программирования, и изменения в них требуют перекомпиляции и редистрибуции.
Таким образом, задача по сопровождению учетных систем, реализованных на базе стандартной реляционной модели, традиционными средствами сопряжено со значительными затратами ресурсов.
Для того чтобы снизить издержки на сопровождение модели была введена теория объектных моделей. В рамках этой теории объекты реального мира представляются в виде объектов модели. Объекты модели соотносятся с классами. Объект, соотнесенный с неким классом, является экземпляром этого класса. Класс полностью определяет структуру объекта, поведение объекта и способы взаимодействия с объектом. В объекте выделяется часть, называемая его состоянием, выделяется часть, называемая его поведением и часть, называемая его представлением. Объект в процессе проявления своего поведения может изменять свое состояние и состояния других объектов. Классы, с которыми соотносятся объекты, объединяются в рамках иерархии. Иерархическое отношение между классами объектов соответствует отношению между объектами реального мира, выражаемому словом «является». Дочерние в этой иерархии классы называются наследниками своих родителей.
Например, классы «Человек» и «Учащийся школы» состоят в иерархическом отношении, т.к. учащийся школы ЯВЛЯЕТСЯ человеком (обратное неверно). Иначе, класс «Учащийся школы» является наследником класса «Человек», а класс «Человек» является родителем для класса «Учащийся школы».
i4
На данной схеме представлен класс «Человек», два экземпляра этого класса (Иванов Иван Иванович и Петров Петр Петрович), класс «Учащийся школы», являющийся наследником класса «Человек» и экземпляр этого класса (Сидоров Сидор Сидорович). Экземпляр класса «Учащийся школы» также ЯВЛЯЕТСЯ экземпляром класса «Человек».
Фамилия, имя, отчество и пр. определяют состояние объектов. Элементы состояния объекты называются полями. Поведением этих объектов является, например, возможность смены фамилии и невозможность смены даты рождения. Элементы поведения объектов называются методами. Методы могут быть прилагаемы к экземпляру класса (методы экземпляра) или нет (методы класса). Методы могут возвращать значения определенного типа. В этом случае они называются функциями. Целесообразно было бы предоставить доступ к информации, например, о возрасте человека. Возраст можно получить при помощи метода (функции), который вычислит разницу между годом рождения человека и текущим годом. Такой метод будет методом экземпляра, т.к. будет выполняться для определенного объекта (человека). Информация, получаемая при помощи выполнения методов, наряду с информацией о состоянии объекта является элементом представления объектов и называется свойством.
Объекты могут включать в себя другие объекты. Говорят, что такие объекты находятся в отношении инкапсуляции со своим владельцем. Инкапсулированные объекты не имеют самостоятельного существования без инкапсулирующего объекта, т.е. их время жизни не может превышать время жизни инкапсулирующего объекта. Каждый объект обязан иметь идентичность. В тех случаях, когда состояние объекта не позволяет однозначно его идентифицировать, вводятся искусственные идентификаторы. Посредством этих идентификаторов один объект может использовать ссылку на другой объект. Эти объекты находятся в отношении использования. Говорят «объект1 использует объект2». После уничтожения объекта-приемника ссылки значение ссылки не может быть определено.
Например, у человека может быть ряд контактных телефонных номеров, для описания которых используется класс «Контактные телефоны» с полями «Вид телефона» и «Телефонный номер». Телефонные номера имеют смысл только для известного человека (объекта класса «Человек») и без него существовать не могут. Можно сказать, что объект класса «Человек» инкапсулирует объекты класса «Контактные телефоны». При уничтожении объекта класса «Человек» будут уничтожены все объекты класса «Контактные телефоны», которые он инкапсулировал.
Создание объекта определенного класса называется инстанцированием.

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

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

  Решения, предлагаемые технологией "Мельница данных"
 

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

  1. Объектная модель хранится в системе по тем же принципам, что и модель бизнес-данных, т.е. объекты классов, описывающих метаданные системы (классы, поля, методы, свойства, пользовательские формы) хранятся в базе данных и отображаются при помощи стандартного пользовательского интерфейса. Моделирование системного слоя метаданных системы произведено разработчиками платформы. Модель системного слоя документирована и доступна для просмотра и использования разработчикам прикладных систем.
  2. Разработка прикладных учетных систем ведется в той же среде, что и работа конечных пользователей. Текущая модель прикладной системы доступна для просмотра и использования всеми разработчиками.
  3. На основе заложенной объектной модели прикладной системы автоматически генерируется SQL-код (как DML, так и DDL составляющие), что полностью освобождает разработчика прикладной системы от SQL-программирования.
  4. Пользовательские интерфейсы (формы, представления) также описываются при помощи объектной модели и хранятся в базе данных. Это позволяет автоматически генерировать формы просмотра данных и формы задания параметров методов, что освобождает разработчика прикладной системы от написания кода клиентского приложения. Для тонкого управления поведением форм задания параметров может использоваться язык VB-script.
  5. При внесении изменений в объектную модель:
    • новое состояние модели отображается в пользовательском интерфейсе в доступной для всех разработчиков форме;
    • текущая объектная модель в виде диаграммы классов может быть выгружена в HTML-отчет, что является базовой возможностью платформы;
    • внесение изменений в структуру базы данных и пользовательские интерфейсы производится автоматически средствами платформы.

Основными элементами стандартизованного пользовательского интерфейса являются развитые элементы управления, работающие с данными:

  • Таблицы данных - отображают списки объектов в табличной форме, удобной для восприятия пользователя. Таблицы данных позволяют производить сортировку, группировку объектов, фильтрацию данных по ряду условий, подведение агрегатов (количества объектов, наибольшего, наименьшего значения, суммы, среднего и т.д.), отображение и скрытие групп, подведение итогов по группе. Таблицы данных имеют функционал, позволяющий отображать иерархические структуры, а также производить произвольный отбор отображаемых объектов пользователем. Используемые таблицы данных позволяют работать с большими объемами данных без потери производительности.
  • Инспектор объектов - отображает все свойства выбранных (одного или нескольких) объектов в двух колонках: имя свойства - значение свойства. Инспектор объектов позволяет просматривать все свойства объектов, а также изменять значения свойств как одного объекта, так и для всех выделенных объектов одним действием.
  • Форма задания параметров - отображается при вызове пользователем одного из методов. На форме расположены элементы управления Поле ввода, соответствующие описанным для метода параметрам. Внешний вид и поведение элементов управления зависят от типа описанных параметров. Поведением элементов управления на форме можно управлять при помощи скрипта формы, разрабатываемого на языке VB-script.
  • Поле ввода - используется для задания значений свойств и параметров как в Таблице данных, так и в Инспекторе объектов и на формах задания параметров. Имеет функционал, позволяющий редактировать значения различных типов. Использование стандартизованного пользовательского интерфейса позволяет снизить издержки как на его сопровождение, так и на обучение пользователей работе на новых участках.

Реализованы развитые возможности интеграции с третьесторонними системами. Они обеспечиваются следующими механизмами:

  1. Возможность переноса в Microsoft Excel любого видимого представления "as-is" с сохранением всех группировок, сортировок, агрегатов и т. п.
  2. Возможность вывода отчетов в виде документов Microsoft Office с передачей в среду функционирования Office соединения с БД, что позволяет строить отчеты любой степени сложности.
  3. Возможность использования в системе любого внешнего Ole-объекта как метода любого класса без ограничений.
  4. Возможность использования скриптлетов (фрагментов кода на скриптовом языке VBScript и/или JScript) как методов системы, фактически - возможность реализации на этих языках сколь угодно сложного поведения.
  5. Возможность формирования отчетов непосредственно в виде html-документов для последующей публикации их в сети Internet.
   
  Системный слой объектной модели "Мельница данных"
 

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

  1. Все классы наследуются от единого корня, класса TObject. Класс TObject вводит ряд элементов состояния, поведения и представления, которые наследуются всеми учитываемыми объектами в обязательном порядке.
  2. Множественное наследование не поддерживается (т.е. у каждого класса может быть один и только один родитель).
  3. Множественная инкапсуляция не поддерживается (т.е. у каждого объекта может быть один либо ни одного инкапсулирующего объекта).
  4. Простые типы данных вводятся посредством доменов. Домены определяют обязательность своих значений, а также другие характеристики, зависящие от класса домена. Домены бывают:
    • строковые (определяют максимальную длину строки);
    • целочисленные (определяют максимальное и минимальное значение целого числа);
    • вещественные (определяют максимальное и минимальное значение числа, количество значащих цифр);
    • логические;
    • значения типа "дата";
    • значения типа "время";
    • значения типа "дата со временем";
    • перечисления (определяют список возможных значений);
    • ссылка (определяют класс-приемник ссылки);
    • большие двоичные объекты (текст, изображение, файл, и т.д.).
 

...