2013-05-22

Universal singleton/namespace pattern for js (node.js or browser)


// File: first.js
// first declaration of singletonName (e.g. for abstract interfaces)
(function(singletonName) {
 singletonName.publicProperty = 'public property value of first declaration';
 var privateProperty = 'privat property value of first declaration';
 singletonName.publicMethod = function() {
  console.log('publicMethod of first declaration to be owerwritten');
 };
 singletonName.toBeOverridden = function() {
  console.log('publicMethod of first declaration to be overridden ');
 };
 privateMethod = function() {
  console.log('privateMethod of first declaration');
 };
} (global.singletonName = global.singletonName || {}));

// File: second.js
// second declaration of singletonName can extend, override and call inherited finctionality
(function(singletonName) {
 singletonName.publicProperty = 'public property value of second declaration will overwrite publicProperty of first declaration';
 var privateProperty = 'privat property value of second declaration will not overwrite privateProperty of first declaration';
 singletonName.publicMethod = function() {
  console.log('publicMethod of second declaration will overwrite publicMethod of first declaration');
 };
 privateMethod = function() {
  console.log('privateMethod of second declaration will not overwrite privateMethod of first declaration');
 };
 singletonName.toBeOverridden = singletonName.toBeOverridden.override(function() {
  console.log('Overridden method');
  this.inherited(); // call to the inherited variant of this method
 });
 singletonName.wrapper = function() {
  console.log('Wrapper for override previous singleton structure');
  singletonName.publicMethod = singletonName.publicMethod.override(function() {
   console.log('Overridden method');
  });
 };
 // Place singletonName initialization code here
 if (1==1) {
  console.log('singletonName initialization code');
 }
} (global.singletonName = global.singletonName || {}));


// File: global.js
if (typeof(window) != 'undefined') window.global = window;

Function.prototype.override = function(fn) {
 var superFunction = this;
 return function() {
  this.inherited = superFunction;
  return fn.apply(this, arguments);
 }
}

// File: test.js
require('./global.js');
require('./first.js');
require('./second.js');
singletonName.wrapper();

2011-12-29

Территориальные государства отомрут сами

Не по профессиональной тематике

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

2011-04-13

Захабрился

Но я сразу себе сказал - не буду вступать в дискуссии, обсуждать, защищать, объяснять, хотя руки чешутся...

2011-01-19

Введение мета-уровеня

Очевидно, что любая информационная система, имеющая слой хранения данных, привязана к структурам хранения и, в случае их изменения, требует реинженеринга слоя приложений и слоя представления. Изменения бизнес-логики приложения требует внесения изменений только в интерфейсную часть, если конечно, изменения не коснулись структур данных. Эта закономерность становится очень заметной, если предметная область динамически изменяется, а так же в задачах со слабо-структурированными данными и там, где требуется интеграция на межкорпоративном уровне. Эти три направления практически блокированы во всех современных парадигмах и архитекторах информационных систем. Тем не менее, глобальная сеть, динамика которой растет все большими и большими темпами, в последнее время активно двигается в сторону интеграции, не отказываясь при этом от слабо-структурированного контента. Проблему эту пока ни кто не формулирует в явном виде, ее обходят, разными способами: ограничивая функционал до фиксированного набора команд (например CRUD или набор команд многих сетевых протоколов как FTP или HTTP), ограничивая интерфейс до фиксированного универсального и не решающего прикладные задачи (например Google Documents), и ограничивая функционал, как сейчас поступают создатели всех веб-приложений. Это частичные решения, они покрывают одну локальную задачу, заточены под нее и действительно обеспечивают интеграцию, благодаря ограничению однородности на всех слоях информационной системы. Однородность данных, однородность логики и однородность интерфейсов может какое-то время удовлетворять задачи личных коммуникаций пользователя, типовые сервисы массового использования и ряд локальных задач, сложность которых не велика, а массовость использования позволяет привлечь большие бюджеты в разработку и сопровождение. Но для прикладных предметных областей, например, в сфере обработки данных, систем САПР, АСУП, АСУ ТП, и других прикладных приложений, баз данных, как то: АБС (автоматизированных банковских систем) или CRM (систем управления взаимодействием с клиентами), биллинговых, логистических, телеметрических, гео-информационных и многих других прикладных систем, подход ограничения, сводящий к однородности любой из трех слоев, не допустим. Для прикладных систем, как раз характерна сложная и разнообразная логика, специфические и специализированные интерфейсы, многообразие данных и большие объемы обрабатываемой информации.

Таким образом, возникает необходимость построения четвертого мета-слоя, описывающего три слоя информационных систем на более абстрактном формальном языке. Такой мета-слой, в свою очередь, так же будет включать какие-то структуры данных (мета-данных), логики (мета-логики) и интерфейсов (шаблонов и компонентов). Поэтому, его нельзя разместить над тремя слоями ИС и рассматривать как надстройку. Скорее, имеет смысл выделить его во второй уровень информационной системы - мета-уровень, который полностью повторяет структуру классической трехслойной модели, однако, находится на одну степень абстракции выше. Например, если в ИС предметная область именовалась "перевозка грузов автотранспортом", то подняв ИС на один уровень абстракции выше, мы можем уже говорить о "перемещении объектов", это может включать в себя и "перевозку грузов" и "перемещение грузов внутри склада", а так же объект может быть не только грузом, но и самим транспортным средством или контейнером или сотрудником транспортной компании и т.д. Подняв абстракцию на один уровень выше, система заметно повысила функциональность, потребовались новые экраны, которые могут справляться с произвольными описаниями объектов, разнотипными связями, сложной номенклатурой и т.д. Хранение данных, при этом, заметно упростилось, произошла свертка таблиц, обычно это декомпозиция, абстрагирование, или даже переход к параметрическим БД или к ORM (системам объектно-реляционного отображения). Такой подход не нов, и применяется достаточно давно, однако, мета-уровень вводится не осознано и поэтому он реализуется частично, закрывая какую-то одну задачу или аспект системы. Например, на уровне данных, структура переходит к более высокому уровню абстракции, а вот бизнес логика как была привязана к конкретике прикладного приложения, так и осталась без своего мета-двойника. То же верно и со слоем прикладных интерфейсов пользователя, включающим формы ввода, вывода и поиска, экранные и печатные отчеты. Наиболее распространен случай введения мета-уровня в слой данных, реже в слое приложений, и еще реже в пользовательских интерфейсах. Однако, даже введение всех трех компонентов мета-уровня не приведет к появлению качественно новой системы. Кроме компонентов есть еще и интерфейсы между ними, реализованные как API вызовы, формальные языки, протоколы передачи данных, форматы сериализации, средства адресации объектов и т.д. Без введения мета-уровня во всех компонентах и в их склейке, свобода от "привязки к конкретике" не будет достигаться. В данный момент мне не известны системы, имеющие полную мета-модель в своей основе. Однако, и это не все. Повышая абстрактность, не стоит забывать, что необходимы еще и средства "индивидуализации", реализующие обратный процесс, ведь не смотря на абстрактность кода, на экран должен выводиться вполне кнкретный, специфический (сделанный под задачу) интерфейс. Например, имея в мета-модели предметной области класс "объект перемещения", мы должны его трактовать то как "груз для перевозки", то как "транспортное средство". Эти два варианта конкретизации абстрактного класса имеют совершенно разную структуру данных, включая атрибуты, связи и классификаторы. Пока существует два способа решения задачи - переход к параметрической БД или к ORM, и то и другое, хранит только один уровень абстракции в СУБД. А это значит, что мы лишаемся преимуществ реляционного подхода, не можем строить прямых запросов к базе данных, не можем использовать индексов, смешиваем в одной таблице сущности разных классов, а в одном поле, значения разных параметров. Не говоря уже о сложности с различными типами данных в параметрическом подходе и всех "заплатках", реализованных в ORM для этих нужд, когда для каждого типа параметров применяются разные таблицы. Встает вопрос: "а стоит ли нам полностью отказываться от конкретики?". В случае, если все три слоя ИС будут переведены на один уровень абстракции вверх, такой вопрос встанет с еще большей силой, т.к. не только данные нельзя уже обрабатывать с использованием классических подходов, но и логика уже становится полностью скриптовой (интерпретируемой), а интерфейсы - полностью динамическими, которые строятся во время исполнения. При таких условиях, очевидна потеря в производительности и быстродействии на несколько порядков. Сложность же разработки увеличивается в разы.

Если же мы не откажемся от конкретики и введем мета-уровень параллельно с классическим уровнем и его тремя слоями, то у нас встанет два вопроса: (a) как их объединить, и (б) как разграничить применение каждого. Рассмотрим их по очереди.

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

Разграничение же абстрактного и конкретного уровней можно рассмотреть на примерах. Для слоя логики, абстрактные операции сводятся к фиксированному набору операций. По примеру CRUD (Create, Read, Update, Delete) мы можем построить следующий набор унифицированных операций не только для табличных структур (как это предусматривает CRUD), но и для сетевых и иерархических (что требует от нас мета-уровень слоя данных). Далее объекты предметной области в гибридных базах данных с наличием нескольких абстрактных слоев будем называть “профилями”. Вот пример унифицированного интерфейса над профилями:
Create – создать профиль
Delete – разрушить профиль (включая обработку ограничений целостности)
Link – установить связь между профилями
Unlink – разрушить связь между профилями
Select – выбрать множество данных
Load – выбрать отдельный профиль из БД в память
Save – сохранить профиль из памяти в БД
Merge – склеить копию профиля в памяти с копией в БД
Expand – дополнить профиль в БД недостающими данными
Set parent – установить родительский профиль
Set order – установить порядок в группе
Exchange – поменять идентификаторы местами
Абстрактные операции мета-уровня не привязаны к предметной области и, таким образом, не решают прикладных задач. Это не логика предметной области, а скорее системное API (набор элементарных функций), определяющий минимальный функциональный слой, одинаковый для всех приложений, использующих одну мета-модель. Конкретика и специфика, появляется в интерпретируемом уровне, где хранятся скрипты - сценарии предметной области. Таким образом, обеспечивается высокая производительность операций абстрактного уровня и достаточная производительность операций скриптовой логики, т.к. все скрипты, по сути являются лишь последовательностью вызовов API и потеря в производительности вполне приемлема.

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

Процесс разработки программного обеспечения должен быть модифицирован в соответствии со спецификой введения мета-уровня. Если классический подход к разработке начинается с одного из трех слоев: (а) с разработки структуры баз данных, (б) с описания бизнес-логики или процессов, (в) с описания пользовательского интерфейса. И начиная с одного из слоев, постановщик заданий конкретизирует и дописывает дополнительные атрибуты, чтобы перейти к другим двум слоям. При этом, как раз это доописание и конкретизация, характеризуемая привязкой к специфике задачи, добавляет в информационную систему те особенности, которые мешают решению нашей исходной задачи. Эта дополнительная информация попадает прямо в программный код, в дизайн и структуры данных, закрепляя, таким образом, приложение на определенном уровне абстракции. Если хоть одна деталь привязывает ИС к нижнему, максимально конкретизированному уровню абстракции, то переход к более высокой абстракции рано или поздно приводит к конфликту и необходимости реинженеринга ИС. Таким образом, разработку приложения, построенного на мета-модели нужно все же начинать с описания конкретики предметной области, но затем осознанно переходить к абстрактной модели и полностью отрывать ее от конкретики, после чего описывать конкретику своей предметной области заново, но уже в терминах мета-модели. Построенное таким образом приложение, содержит одновременно два уровня абстракции, более высокий из них зашит в приложение, а более низкий – формируется из компонентов, предоставляемых абстрактной моделью, дописывая и конкретизируя модель. Таким образом, мы можем сказать, что сложность разработки повышается примерно в 3 раза. Однако, стоимость владения, поддержки, внесения изменений, реинженеринга, интеграции, встраивания и других модификаций над всеми тремя слоями – упрощается и удешевляется на несколько порядков. Многие возможности, как то, межкорпоративная интеграция, в принципе становятся возможными только при наличии обобщающей мета-модели у двух и более ИС. Разработка программного обеспечения и прикладных программ, опять перестает быть индустрией, какой она стала благодаря увеличению однотипного и монотонного труда программиста в условиях “неабстрактных систем”. При применении подхода с мета-уровнем, процесс разработки сводится к трем отрезкам: (а) классический анализ предметной области, (б) абстрагирование и построение мета-модели, (в) индивидуализация и вторичное построение модели предметной области, но уже в терминах мета-модели.

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

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

2010-07-08

Метамодель в задачах интеграции информационных систем

Т.Г. Шемсединов
УДК 004.9

Введение

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

Постановка задачи

Задачу интеграции информационных систем можно разбить на три составляющих: интеграция внутри предприятия, межкорпоративная интеграция и интеграция в реальном времени. Если первый пункт достаточно проработан и понятен, хотя и не прост, то уже второй приводит к целому ряду проблем: гетерогенность платформ и операционных сред, различия в архитектурах ИС предприятий, различия в подходах к моделированию данных, противоречия в принципах сетевого взаимодействия, несовместимость средств визуализации и, в конце концов, отсутствие понимания между разработчиками и общепринятого подхода к интеграции, постоянные войны стандартов между ведущими ИТ-компаниями. Все это не способствует решению поставленных задач [3,4].
Второй аспект проблемы заключается в том, что разработка информационных систем обычно начинается с одного из слоев: представления, логики или данных (то есть, постановка задачи базируется на описании пользовательского интерфейса, бизнес-логики и процессов или же структуры базы данных). А ни один из слоев не описывает предметную область с достаточной полнотой, обеспечивающей динамическое связывание нескольких ИС. Дело в том, что и логика, визуальное представление и, тем более, структуры данных, в межкорпоративном взаимодействии очень динамичны и могут меняться не только в процессе проектирования и разработки информационных систем, а и во все время их ежедневной эксплуатации. Интеграция ИС на одном из уровней, и при неполном описании, приводит к тому, что изменение этого уровня в одной из систем, рушит все объединяющие связи. Поэтому, для интеграции ИС необходимо использовать описание на более высоком уровне, например, с использованием метаданных. Таким образом, мы приходим к необходимости интеграции на уровне метамоделей.

Применение метамодели

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

Параметры метамодели

Какие же дополнительные параметры необходимы для описания метамодели? Обычно, при моделировании предметной области теряются очень важные параметры модели – атрибуты связей между сущностями предметной области. Дело в том, что в реляционной и объектной моделях, связи не могут иметь атрибутов. Если это необходимо, их вводят, как атрибуты сущностей, состоящих в связях, а что они в действительности принадлежат не сущностям, а связям, “знает” логика приложения, т.е. эта часть модели описывается в коде, а не в структурах данных. При интеграции же, удаленная система уже не “знает” особенностей, а семантика, описанная не полностью, просто теряется, препятствуя интеграции систем. Какие же могут быть атрибуты связей: класс связи, направление, сила связи, условия действия, время установления, стойкость и т.д. Как в реляционных СУБД, так и в языках программирования, понятие ссылки сводится к идентификации двух связываемых сущностей и не позволяет добавлять дополнительные атрибуты.
Рисунок 2 – Пример объектов, описываемых метамоделью
Теряется, так же, и целостность объектов. Реляционная и объектная декомпозиция размещает атрибуты одной сущности во многих таблицах или многих классах, однако, это приводит к тому, что обратная операция в большинстве случаев уже не возможна без человека. Часть атрибутов описаны как поля таблицы, другие же – вынесены в разные таблицы, которые ссылаются на описываемую сущность. Но связи в реляционной модели используются не только для внутреннего моделирования объектов и их сложных свойств, но и для описания внешних отношений между разными объектами. Таким образом, по связи невозможно однозначно определить, является ли дочерняя таблица частью родительской сущности или отдельной сущностью. На практике приходится даже раскрашивать ER-диаграммы и структуры баз данных, выделяя цветами группы таблиц описывающих одни сущности. Но масштабность задач требует вводить не только такую одноранговую группировку, предметная область может быть разделена на зоны, что задается как префиксы к именам таблиц или группы таблиц помещаются в разные базы данных.
Таким образом, метамодель должна обеспечивать две принципиально разных возможности: связь между объектами и включение одного объекта в другой, как составной части. Кроме того, включение объектов так же должно быть разделено на включение “сильное” (вложенный объект может существовать только внутри родительского) и включение “слабое” (вложенный объект временно находится внутри родительского контейнера).
Современные СУБД не предоставляют возможности записывать источник получения данных в полях таблиц, хотя данные могут быть взяты из импорта, введены вручную, получены из внешней системы и т.д. Приходится выходить из положения, добавляя поле, описывающее источник данных другого поля. Реляционная модель не предоставляет возможности формально указать, что одно поле является атрибутом другого поля. Задача "понимания" этой логики ложится на приложение. Чтобы упростить операции можно применять суффиксы и префиксы в именовании полей, например поле Frequency содержит значение частоты, FrequencySource – указывает на источник данных и т.д. Аналогичным образом, может храниться и время фиксации измеренной величины (например: FrequencyTime). Однако, часто может быть необходимо хранить одно или несколько предыдущих значений. Для одного значения можно добавить поле (PreviousFrequency), для хранения истории требуется введение отдельной таблицы, и вот логика уже определяется приложением, т.е. на уровне СУБД невозможно явно указать, что таблица хранит историю параметра.
Теряются, так же, точность, весомость и степень доверия к атрибутам сущностей. Сохраняя значения атрибутов, необходимо определять в метаданных, что они поступали, например, с разных датчиков из разных систем, имеющих различную погрешность. Таким образом, к полю, хранящему значение, имеет смысл прикреплять поле-спутник, для указания точности (например, максимальное возможное значения отклонения или среднеквадратическое отклонение). Сопутствующие величины так же часто теряются, например, для производственных систем, могут быть метаданные: количество проведенных изменений для получения среднего значения, хранимого в поле; доверительный интервал значения; вероятностные характеристики; которые могут изменяться в зависимости от пути поступления данных в базу; время события получения данных и т.д. Реляционные СУБД не поддерживают также операций над нечеткими величинами, их приходится хранить в нескольких полях, а обрабатывать программно. Таким образом, модель предметной области размывается между структурой базы данных, сервером приложений и клиентом, что приводит к несовместимости с другой системой.
Теряется и семантика групповых связей, когда несколько связей описывают один аспект предметной области, а инструментов для объединения связей в группы нет. Сложности есть и в формальном описании сложных свойств, когда свойство распадается на несколько полей, а описать их группировку или определить ее невозможно. В таких случаях нужно использовать метаданные, которые будут интерпретированы в сервере приложений или в клиенте.

Выводы

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

Литература

1. Дон Тапскотт. Электронно-цифровое общество. Рефл-бук, 1999, 408 с.
2. Под редакцией Н. Ермошкина. Демистификация ИТ. Что на самом деле информационные технологии дают бизнесу. 2006, Альпина Бизнес Букс, 304 с.
3. Don Tapscott. Grown Up Digital: How the Net Generation is Changing Your World. 2008.
4. Беккер Й., Вилков Л., Таратухин В., Кугелер М., Розерман М. Менеджмент процессов. М.: Эксмо, 2007. 360 с.

2010-02-17

CLEAR

Clear Language for Entity Adequate Representation

Short guide Version 7.0 Date: 2008-01-31

1. Overview

This language is designed for platform independent entity representation for memory structures, storage and network interactions as well. It is next step in data representation languages evolution after markup languages, so it is based on both, XML experience and binary data encoding. But it is devoid of indeterminacy on the one hand and is human understandable on the other hand. Clear language structures are simple and obvious so do not expect something supernatural here. It is simple and clear...

2. Requirements

  • Compact and efficient
  • Expressive and human-readable
  • High-performance parsing
  • Single-meaning syntax and modeling rules
  • Native hierarchical, table, network and relational structures support
  • Object-oriented and data types support
  • Maps directly to programming-language structures
  • Maps directly to network protocol packets
  • Maps directly to database engine structures
  • Self decrypted and extensible syntax
  • UTF-8 support
  • Security and data safety
  • Transport independent
  • BLOB support in BASE64

3. Fields

Fields are for holding named values as a entity properties. CLEAR gives possibility to defile field types using regular expressions. All characters except 0x00..0x1F, 0x25 ("%") and 0x5D ("]") are allowed in values without escaping. Escaped characters should be encoded as %NN where NN is hexadecimal character code (for example %10 or %25). Symbol 0x22 (double quotation) should be escaped only if it is the first letter in value.

Fields are of the following two formats. First is simple:

Syntax: FieldName[value]

Second format allows to use 0x5D ("]") without escaping and used for regular expressions and other values which oftenly uses square brackets: Name["value-with-]-symbol"]. But combination of 0x22 (double quotation) and 0x5D ("]") should be escaped as in example: Name["value-with-%22]-symbols"]

4. Links

Format of links is similar to fields first format except of using 0x3E (">") instead of
0x5D ("]").

Syntax: LinkName<URL>
Example: MySite<http://meta-systems.com.ua/>

5. Sets

Format of sets is similar to fields first format except of using 0x3E ("}") instead of
0x5D ("]").

Syntax: SetName{item-1,...,item-N}
Example: Colors{green,navy,yellow}

6. Entities and hierarchy

CLEAR allows organizing fields, sets and links into entities or objects. Entities are separated with line breaks (0x0D 0x0A). Objects can be organized hierarchically as trees in markup languages. Numbers in the beginning of any row are hierarchy level, for example:

1: Node1:Class1 Field1[value1] Field2[Value2] Link1<link1>
2:   SubNode1 Field3[value3] Set1{} Set2{item4,item5} Field4[value4]
2:   SubNode2 Field5[value5] Field6[value6]
3:     SubSubNode1 Set3{item6,item7} Field7[value7] Link2<link2>
2:   SubNode3 Field9[value9]
3:     SubSubNode2:Class2,Class3 Field10[value10] Link3<link3>


Thanks to level numbering we can skip branches and quickly parse to the necessary entity. It is also releases us of "end" keywords needed in other languages to close tree levels. In CLEAR, for example, level 3 object ends when next level 3 or level 2 object starts (generally when sibling or higher level object starts or EOF reached).

7. Entities Classes and Properties naming

Entity name and class definitions are precedes fields, links and sets declarations. CLEAR allows multiple for inheritance and allows entity without ancestor class at all. Classes can be defined in *.model files as type declarations. Classes separates by ":" from entity name and separates by "," from each other. For example:

1: Node1:Class1 Field1[value1] Field2[value2]
2:   SubNode1:Class2,Class3 Field3[value3]
2:   SubNode2 F[val1] F[val2] [val3] [val4] <url1>


We need to give user possibility to encode any symbol of 0x00-0xFF in entity names and class names, so 0x00-0x1F should be escaped as - %1F, also we need to escape following: colon (":") as %3A, dash ("-") as %2D, equality ("=") as %3D, plus ("+") as %2B, star ("*") as %2A, comma (",") as %2C and space as %20. So we escape only 39 chars of 256 set.

Previous example shows us fields and links without name. CLEAR allows having multiple properties (fields, links and sets) with one name or properties without name. Parser organizes those properties into arrays so we can access values by property name or array index.

8. Folders

Folders are entities used for grouping other entities. Folders have colon (":") but have no class specified. For example:

1: Folder:
2:   SubNode1 Field1[value1] Field2[value2]
2:   SubNode2 Field3[value3] Field4[value4]

9. Members

Members are complex properties of parent entities. Members have "#" as a first letter in their names. For example:

1: Node1:Class1
2:   #SubNode1 Field3[value3] Field4[value4]
2:   #SubNode2 Field5[value5] Field6[value6]

10. CLEAR model files (*.model)

Data definition files contain types and classes definitions. Model files are of common CLEAR format. See examples and explanations further at this guide.

11. CLEAR files (*.clear)

CLEAR have default extension for data files. Root entity contains links to data definition (*.model) files. For example:

1: Node1:CLEAR <http://xross.net.ua/clear.model> <models/example.model>
2:   SubNode01 Field2[value2]


12. Comments

Lines which not started with "N: " (where N is decimal number) are commented. For example:

// comments here
1: Node1:Class1 Field1[value1]
-- comments here

13. Types

In the following example you can see type definitions as regular expression and as enumerated dictionary. Type definitions marked with "Type" class and all should be at the second level of model file (directly under root node).

1: ExampleModel
2:   float:Type  ["^-?\d*\.?\d*$"]
2:   string:Type [".*"]
2:   Align:Type  {Top,Right,Bottom,Left}
2:   Class1 Aligns{Top,Left:Align} Align[Align]
2:   Class2 Field1[0:float] Field2[float]
3:     #Member Set1{0,12.5,15.1:float} Set2{string}

14. Classes

In previous example there are Class1 and Class2 declared.