Содержание к диссертации
Введение
ГЛАВА 1. Анализ архитектуры информационных систем ... 17
1.1. Объектный подход к анализу и проектированию информационных систем 17
1.2. Управление модификацией на этапе разработки 28
1.3. Архитектуры с метаданными времени выполнения 31
1.3.1. Представление метаданных 31
1.3.2. Хранилища данных 37
1.3.3. Слабоструктурированные данные 40
Выводы 45
ГЛАВА 2. Архитектура и методика проектирования часто модифицируемых транзакционных систем 46
2.1. Анализ особенностей бизнес-процессов с преобладанием транзакционных операций 46
2.1.1. -Процессы в сфере учета и уплаты коммунальных услуг 47
2.1.2. Основные виды документов и их движение 49
2.1.3. Основные виды процессов 51
2.1.4 .Управление массовыми процессами „. 53
2.1.5. Управление информационными ресурсами 57
2.2. Информационно - логическая модель транзакционного бизнес -процесса 58
2.3. Естественная логическая архитектура информационной системы 62
2.5. Объектно-реляционная модель документа 74
Выводы ; 76
ГЛАВА 3. Инструментально-исполняющая система на основе документно - терминологической модели данных 77
3.1. Структура метаданных 78
3.1.1. Метабаза документов 78
3.1.2. Метабаза бизнес-логики 82
3.2. Администрирование 93
3.3. Открытая архитектура как средство обеспечения модифицируемости 95
Выводы 99
ГЛАВА 4. Анализ опыта разработки транзакционных информационных систем на основе документно-терминологической модели 100
4.1. Информационная система УГИББД МВД Республики Татарстан 100
4.2. Система управления коммунальными платежами МАРС 103
4.2.1. Причины применения документ-ориентированного подхода 103
4.2.2. Структура системы 106
4.3. Документный подход в геологии 108
4.3.1. Причины применения документного подхода 108
4.3.2. Применения положений стандарта POSC при разработке и анализе информационных систем на основе документного подхода 113
4.3.3. Информационная система на основе документно -терминологической модели в геологии на примере модуля ТРИАС-база 127
4.3.4. Документные модели нереляционных объектов на примере трехмерных геологических моделей 130
Выводы 135
Заключение 136
Список использованных источников 140
- -Процессы в сфере учета и уплаты коммунальных услуг
- Открытая архитектура как средство обеспечения модифицируемости
- Система управления коммунальными платежами МАРС
- Документные модели нереляционных объектов на примере трехмерных геологических моделей
Введение к работе
Среди информационных систем, автоматизирующих бизнес-процессы, значительное место занимают системы, называемые русскоязычной литературе учетно-отчетными или информационно-справочными [1,12,49], в функции которых входит информационная поддержка алгоритмически несложных интерактивных бизнес-процессов. В англоязычных источниках [32,59] такие системы получили названия систем OLTP - On-Line Transact Processing. Мы будем далее называть такие системы транзакционными.
Транзакционные системы имеют самостоятельное значение в предметных областях с несложной алгоритмикой, а также как подсистемы, обеспечивающие ввод информации в комплексных системах общеуправленческого характера, автоматизирующие группы связанных бизнес-процессов, такие как системы ERP, CRM, PDM [82]. Значительную роль транзакционные подсистемы играют в специализированных отраслевых информационных системах с массовыми транзакциями [84] - банковских, биллинговых системах в связи и жилищно-коммунальном секторе, системах продажи билетов на транспорте, и т.д.
Транзакционные системы составляют основу для автоматизации бизнес-процессов во взаимоотношениях граждан и органов государственной власти и управления [8,70], таких как регистрация актов гражданского состояния, регистрации имущественных прав и сделок и имуществом, налоговых взаимоотношений, в специализированных системах управления [7] и других массовых бизнес-процессов.
Согласно данной концепции жизненного цикла [1,14] программная система за время своего существования последовательно проходит несколько качественно различных стадий. Обычно выделяют 4 стадии:
разработка
изготовление
эксплуатация
разработанной корпорацией Rational Rose. В данной методологии вводятся понятия фазы и итерации витка ЖЗ.
Фаза, согласно RUP - это промежуток времени между двумя важными опорными точками процесса, в которых должны быть достигнуты четко определенные цели, подготовлены те или иные артефакты проектирования и принято решение, следует ли переходить к следующей фазе. RUP состоит из четырех фаз:
Начало - определение бизнес-целей проекта
Исследование - разработка плана и архитектуры проекта
Построение - постепенное создание системы
Внедрение - поставка системы конечным пользователям
Внутри каждой фазы происходит несколько итераций. Итерация представляет собой полный цикл разработки, от выработки требований до реализации и тестирования. Итерация - это завершенный этап, в результате которого выпускается версия (для внутреннего или внешнего использования) разрабатываемого продукта, реализующего часть требуемых функций.
Понятия, позиционирующиеся в ранних моделях ЖЦ как этапы, в RUP носят названия рабочих процессов (РИС 3)
Основные mwmрзёвд '. \'. :10Ш&^щШШ^^^Ш^ШШ^^^Щ«^^^^^ШШ
'_''"-"' - >><>y-<<<<-yj^4*$&^^ <-у/Уу:-ууу-ууу^уууууу
ТреСздш &шш я щвешряизияз
бьяяавеяяе
ВОДДЄрЖИ
:'Г ':': "''"'"'"У.
- /^^<^^^л^^^л...i.^^??^yтг^--^т^yv^l^v,
Шу^тщщ^шщ ЫМкрщ ЩтШЩіїєт шт?р::в №ед Щит
Рис. З - Модель ЖЦ в RUP
Данная модель уже в середине 80-х годов оказалась несоответствующей реальности, так как в процессе эксплуатации системы
1Щ происходили изменения требований к системе, изменялась программно-
техническая среда, масштабы применения и другие изменения, требующие внесения корректировки в действующую систему, а не проектирования и внедрения принципиально новой ИС.
Для адекватного отражения данного факта была разработана спиральная модель [19] ЖЦ (Рис 2). На каждом витке спирали создается
{Ч версия ИС, уточняются цели и характеристики проекта, сравниваются с
полученными результатами, планируются работы на следующем витке. Таким образом, процесс проектирования превращается в непрерывную итерационную процедуру. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работ на текущем, при этом недостающие фрагменты выполняются на
\ \/ \$v&l / /
N ^*я»->^ &т3
\
*s
хеспроша» \ \у -?~~ \Вер^2 / /
Рис. 2 - Спиральная модель ЖЦ
Хотя спиральная модель ЖЦ акцентирует внимание на его непрерывном характере, следует признать недостатком модели жесткую последовательность работ в пределах одного витка. Дальнейшее развитие модель ЖЦ получила в методологии Rational Unify Process (RUP) [14],
разработанной корпорацией Rational Rose. В данной методологии вводятся понятия фазы и итерации витка ЖЗ.
Фаза, согласно RUP - это промежуток времени между двумя важными опорными точками процесса, в которых должны быть достигнуты четко определенные цели, подготовлены те или иные артефакты проектирования и принято решение, следует ли переходить к следующей фазе. RUP состоит из четырех фаз:
Начало - определение бизнес-целей проекта
Исследование - разработка плана и архитектуры проекта
Построение - постепенное создание системы
Внедрение - поставка системы конечным пользователям
Внутри каждой фазы происходит несколько итераций. Итерация представляет собой полный цикл разработки, от выработки требований до реализации и тестирования. Итерация - это завершенный этап, в результате которого выпускается версия (для внутреннего или внешнего использования) разрабатываемого продукта, реализующего часть требуемых функций.
Понятия, позиционирующиеся в ранних моделях ЖЦ как этапы, в RUP носят названия рабочих процессов (РИС 3)
Основные mwmрзёвд '. \'. :10Ш&^щШШ^^^Ш^ШШ^^^Щ«^^^^^ШШ
'_''"-"' - >><>y-<<<<-yj^4*$&^^ <-у/Уу:-ууу-ууу^уууууу
ТреСздш &шш я щвешряизияз
бьяяавеяяе
ВОДДЄрЖИ
:'Г ':': "''"'"'"У.
- /^^<^^^л^^^л...i.^^??^yтг^--^т^yv^l^v,
Шу^тщщ^шщ ЫМкрщ ЩтШЩіїєт шт?р::в №ед Щит
Рис. З - Модель ЖЦ в RUP
Легко видеть, что в RUP все процессы могут идти на всех стадиях ЖЦ, хотя и с различной степенью интенсивности. В процессе каждой итерации выполняются все рабочие процессы, хотя в разных фазах упор делается на разных работах. В начальной фазе главной задачей является выработка требований, в фазе исследования - анализ и проектирование, в фазе построения - реализация, в фазе внедрения - развертывание.
Легко видеть, что с течением времени спецификации видов работ на
этапах жизненного цикла информационной системы становится все более
размытой. В отличие от водопадной модели с четкой временной
дифференциацией работ в модели RUP все виды работ выполняются на всех
стадиях. Отчасти это можно объяснить все возрастающей сложностью
информационных систем и активным применением в практике их создания
модульного и иерархического принципов построения сложных систем
[23,35,73], а также возрастающей стандартизацией программно-
информационных решений [29,72,87].
Иерархично-модульный принцип построения информационных систем приводит к тому, что ее подсистемы находятся на различных стадиях жизненного цикла, вся же система, после своего первоначально создания находится в фазе эксплуатации. Такая ситуация позволяет говорить о том, что на этапе эксплуатации системы в целом идут также процессы сопровождения [56,60]:
корректировка ошибок, т.е. исправление выявленных в процессе эксплуатации отклонений реального поведения системы от заявленного в технической документации
администрирование, т.е. корректировка поведения системы средствами самой системы в рамках заявленных в технической документации возможностей
модификация, т.е. расширение поведения системы за рамки первоначальной постановки.
Распределение затрат между этими тремя процессами зависит как от особенностей предметной области и архитектуры самой информационной системы, однако ряд авторов отмечают существенное преобладание затрат на модернизацию [56,60], все возрастающую с увеличением частоты модификаций.
Будем называть программные системы, период возникновения новых требований к которым соизмерим со временем модернизации и внедрения, непрерывно модифицируемыми.
В настоящее время все большее число информационных систем попадает под данное определение. Основными факторами, вызывающими их возрастание являются [43,80,106]:
тотальный переход на поддержку умственного труда информационными технологиями и необходимостью, в связи с этим автоматизации слабо формализованных задач,
общее увеличение динамики экономических, технологических и научных процессов в мире вообще и в России в особенности, усилением мировых интеграционных процессов,
- нарастание количества эксплуатируемых информационных систем и
необходимостью их интеграции, в том числе без участия человека (системы
класса В2В, Р2Р)
При модификации, с точки зрения пользователя происходит переход части информационной системы со стадии эксплуатации на стадию разработки, т.е. на затратную стадию. Чем масштабнее изменения в бизнес-процессах и чем они чаще, тем большие затраты несет пользователь и тем менее эффективным становится эксплуатация информационных технологий.
Поскольку масштаб и частота изменений бизнес-процессов определяются факторами, лежащими вне информационной системы, для снижения затрат на фазу модификации мы можем воздействовать только на саму информационную систему, делая ее более адекватной задаче частой модификации. Сложная информационная система состоит из множества
подсистем, модулей, баз и наборов данных и других обособленных программных и информационных компонент. Эти компоненты в различных комбинациях применяются пользователем для автоматизации определенных бизнес-функций. В соответствии с определением модификация заключается в расширении системы за рамки первоначальной постановки задачи, т.е. за рамки выполняемого системой набора бизнес-функций. Для автоматизации новых бизнес-функций требуется изменить и/или добавить в систему некоторое количество программных и информационных компонент.
Архитектура информационной системы, т.е. принципы, по которым образуются программные и информационные модули системы, оказывает существенное влияние на стоимость модификации. Чем большее количество модулей необходимо добавить или изменить при добавлении или изменении бизнес-процесса, тем больше затраты на модификацию. На некотором уровне эффективности происходит отказ пользователя от использования данной
информационной системы или использования информационных технологий вообще для решения некоторого круга своих задач.
В настоящее время решение проблемы сокращения стоимости разработки и модификации наиболее часто производится двумя путями: наращивания мощности средств разработки и стандартизацией компонент. Оба этих пути детально рассмотрены в монографии [84].
Наращивание мощности средств разработки привело к созданию сложный комплексов CASE-средств [19,37], совмещающих средства бизнес-анализа, быстрой разработки приложений, тестирования и документирования, управления запросами пользователей и других компонент. Такая сложность и комплексность программного обеспечения, требующих высокой квалификации разработчиков может оказаться неадекватной задачам малых оперативных корректировок. Фактически, сложность модификации переносится из слоя прикладного программного обеспечения в слой программного обеспечения поддержки разработки.
Стандартизация компонент, как правило, ограничивается системными и общесистемными программными средствами - операционной системой, СУБД, сетевыми протоколами и т.п. [52,57]. На этом пути сделаны значительные успехи. Стандартизация прикладного программного обеспечения испытывает значительно большие трудности и наиболее успешна в областях, мало подверженных изменениям, таким образом, делая, таким образом, этот подход неприемлемым для сокращения трудоемкости при частых модификациях.
Наиболее перспективным представляется путь использования архитектуры программной системы, соответствующей условиям ее эксплуатации. Можно привести успешные примеры, когда применение соответствующей архитектуры позволяло решить задачу, неразрешимую в ранее использующейся архитектуре. Одним из примеров является разработка концепции хранилища данных [102], позволившая решить задачу интеграции исторических данных из различных источников с заранее неизвестной структурой данных. Другим примером является бурное развитие, в настоящее время, средств работы со слабоструктурированными данными [41,42,43], позволяющими работать с записями, состав которых может варьироваться от экземпляра к экземпляру.
Несмотря на успехи новых архитектурных подходов, реляционные СУБД в настоящее время и в ближайшей перспективе являются единственной промышленной основой для разработки и сопровождения основного компонента OLTP-систем - базы данных.[31,80]. В значительной мере это определяется простотой и мощностью лингвистической компоненты современных реляционных СУБД - языком запросов SQL, а также эффективной реализацией функций манипулирования данными, обеспечиваемой мощной математической основой реляционных СУБД.
Все вышесказанное позволило сформулировать проблему исследования: разработка на основе реляционной модели данных архитектурных принципов и методики построения транзакционных
информационных систем, явно предназначенных для работы в условиях частых изменений структур данных и функциональных требований к системе.
Объектом исследования является архитектура OLTP-систем на основе реляционных баз данных.
Предметом исследования является архитектура OLTP-систем на основе реляционных баз данных как фактор сложности модификации.
Целями исследования является создание и исследование методики построения транзакционных информационных систем, минимизирующей сложность их модификации.
Основными задачами являются:
анализ влияния архитектуры OLTP-систем на сложность их модификации;
разработка архитектурно-методических принципов построения транзакционных информационных систем в условиях частых модификаций;
разработка, в рамках предложенных принципов, инструменталыю-исполняющей программной среды унифицирующей разработку и модификацию транзакционных систем на основе метаданных; оценка эффективности разработанных методики и инструментария при создании прикладных программных систем для задач с высокой частотой модификации. Методологической основой проведенных исследований является объектный подход к анализу задач обработки информации и синтезу информационных систем [16].
Методами исследования являются: теория реляционных баз данных[21,32], методы логического моделирования информационных структур [23,35,37], концепция жизненного цикла программно-информационной системы [13,14], методология разработки программного обеспечения Rational Unify Process [14,17].
В рамках объектного подхода к анализу и проектированию
информационных систем были проанализированы задачи, решаемые OLTP-
системой. Выявлено, что в наиболее общем виде OLTP-система решает
задачу автоматизации формирования типизированных информационных
наборов, далее используемых человеком, другими информационными
системами или исполняющими механизмами. В процессах с участием
человека такие информационные наборы принято называть документами[49].
Для достижения поставленной цели и решения сформулированных
задач выдвинута следующая гипотеза исследования: архитектура часто
модифицируемых транзакционных систем должна строиться исходя из
рассмотрения взаимодействия пользователя с транзакциониои системой как
интерактивного человеко-машинного процесса изготовления
типизированных информационных наборов (документов).
Научная новизна и теоретическая значимость результатов исследования заключаются в:
разработке методики анализа модифицируемости архитектуры
транзакционных информационных систем;
разработке методики построения транзакционных
информационных систем, минимизирующей сложность их
модификации;
- выделении документа как основного архитектурного элемента при
проектировании базы данных для OLTP- систем;
разработке объектно-реляционной модели документа для
унифицированного построения OLTP-систем;
I- разработке метода учета табличных зависимостей БД путем
расширения понятия домена на группу атрибутов;
разработке метода обеспечения целостности БД путем построения
семантических сетей терминов, в которых проектируются
логическая и физическая модели БД;
обосновании применимости методов анализа данных, ранее применяемых в аналитических целях, для выявления зависимостей в БД при ее проектировании и модификации.
Практическая ценность диссертационной работы заключается в разработке на основе выдвинутых теоретических положений инструментальной системы для построения транзакционных информационных систем.
Теоретические и практические аспекты диссертационной работы составляют в совокупности оригинальную методику реализации OLTP-систем, доступную для использования специалистами в области информационных технологий.
Достоверность результатов обеспечивается применением математического аппарата теории множеств и реляционной алгебры, а также экспериментальной проверкой работоспособности и эффективности 10 прикладных транзакционных информационных систем, разработанных на основе предложенной в диссертации методики.
Апробация результатов. Основные результаты диссертации докладывались на следующих конференциях: Вторая международная конференция "Развитие и применение открытых систем" (Петрозаводск, 1995); Международная конференция "Эволюция инфосферы" (Москва, 1995); Третья международная конференция "Развитие и применение открытых систем" (Москва, 1996); Второй научно-практический конгресс "Информатизация регионов" (Санкт-Петербург, 1996); Международная научно-методическая конференция "Новые информационные технологии в университетском образовании" (Кемерово, 2002); Первая международная конференция "Инфокоммуникационные технологии глобального информационного общества" (Казань, 2003).
Публикации. По теме диссертации опубликовано 10 научных работ, в том числе 2 коллективные монографии, 3 статьи, 5 тезисов.
-Процессы в сфере учета и уплаты коммунальных услуг
В наиболее общем виде модель предметной области выглядит следующим образом: Владелец собственности непосредственно или через ряд посредников передает ее в долговременное пользование потребителям, получая за это некоторые периодические платежи.
Для обслуживания собственности привлекаются поставщики услуг, заключающие договора на обслуживание с владельцем собственности или потребителями. Услуги могут предоставляться через цепочки посредников, являющимися самостоятельными организациями или подразделениями поставщика.
Нормы и правила, по которым взаимодействуют владельцы, потребители и поставщики услуг, устанавливаются государственными органами, они же могут получать некоторые единовременные или периодические платежи, выплачивать различного рода дотации и трансферты владельцам собственности, потребителям и поставщикам услуг, а так же устанавливают форму отчетности со всех участников процесса.
Для управления денежными потоками между участниками процесса задействуются финансовые организации, производящие финансовые операции.
Участники процесса могут совмещать в себе часть функций. Так, владелец собственности может оказывать часть услуг, устанавливать часть норм и правил, принимать оплату за свои услуги и услуги сторонних организаций. Потребитель может являться владельцем собственности. Возможны и другие совмещения.
В целом в системе наблюдаются 4 вида ресурсов, перемещающиеся между участниками процесса: 1. Права на владение, распоряжение и использование объектов собственности 2. Услуги и работы, направленные на поддержание объектов собственности в надлежащем состоянии 3. Информация, необходимая для проведения расчетов между регистрирующими органами, потребителями, владельцами, и поставщиками. 4. Денежные средства всех назначений. Наиболее сложная область, покрываемая данной моделью - область эксплуатации жилого фонда города, района или территории. В крупных системах подобного рода присутствуют все перечисленные виды ресурсов, участников и процессов. Однако сфера возможного применения не исчерпывается жилищно-коммунальным хозяйством. Под данную модель попадают также: учет и регистрация сделок с земельными ресурсами и учет и регистрация транспортных средств учет лицензирования прав учет и регистрация технически опасных объектов обязательные страховые платежи Также под данную модель, с некоторыми корректировками, попадают операции в сфере социального обеспечения - выплата пенсий, пособий, распределение специальных услуг между отдельными категориями граждан. В сфере чисто коммерческих операций под данную модель попадают долговременные отношения между хозяйствующими субъектами типа расчетов за сданное сельскохозяйственное сырье, телемаркетинг, периодическое обслуживание технических средств и т.д. Таким образом, объектная модель данной области очень сложна и ее построение требует хорошего знания множества специфических дисциплин. Рассмотрим этот процесс с другой стороны - какими документами обмениваются субъекты описанных процессов
В делопроизводстве сложилась классификация документов по их роли в процессах документооборота. Данная классификация варьируется в зависимости от предметной области [2,33,77,86], однако можно выделить абстрактные классы документов, существующие во всех предметных областях:
Первичная документация. Первичные транзакционные документы отражают различные единичные факты - оплаты, поставки ресурса, совершения сделок, изменения отельных параметров объектов и субъектов и т.п. Первичные документы одномоментны, авторизованны и неизменны после их создания и утверждения. Первичные документы подразделяются на регистрируемые субъектом (входящие) и генерируемые субъектом (исходящие). Для одного субъекта документ может быть входящим, для другой - исходящим. 2. Исторические документы. Исторические документы служат для накопления информации об объектах и субъектах системы. Для субъектов ведется карточка лицевого счета - для объектов - паспорт объекта. Исторические документы могут корректироваться как непосредственно вручную пользователем, так и автоматически, на основе первичных документов з. Групповые документы.
Реестры. Реестры являются средством группировки первичных документов для их накопления и передачи в системе. Реестр содержит сами первичные документы в виде ссылок на них и некоторые обобщающие сведения -количество документов различных типов, общие суммы по документам или количество товарно-материальных ценностей, контрольные суммы и т.п. Первичные документы при реестровой схеме группировки также должны присутствовать в системе. і Журналы ( ведомости ). Журналы и ведомости служат для непосредственного дублирования ряда сведений из первичных документов для целей учета и отчетности. При этом журналы, как правило, копируют часть сведений из первичных документов, ведомости же создаются автономно и на их основе, затем могут формироваться наборы первичных документов.
Словари и справочники. Словари и справочники являются частью НСИ, применяемых для унификации системы обозначений, и обеспечения терминологической целостности в первичных, исторических и групповых документов. Словари и справочники, как правило имеют разновременные версии а также активную (используемую при формировании новых документов) и пассивную (используемая для распознавания более ранних документов).
Методики. Методики служат для фиксации в системе более сложных алгоритмических зависимостей в системе, не сводящиеся к терминологической целостности. Методики могут содержаться в системе в виде сплошных текстовых документов чисто для справки, но основная часть методик реализуется в виде алгоритмов бизнес-правил, реализованных в системе. В учетных данных алгоритмов обязательна ссылка на соответствующий документ
Открытая архитектура как средство обеспечения модифицируемости
Концепция открытых систем [29,30,52] возникла параллельно с возникновением вычислительной техники из необходимости совместного использования программных и технических средств различных производителей. Достаточно полный обзор данной проблемы дан в [84]. Наибольший акцент на ранних стадиях [57] развития идеологии открытых систем делался на обеспечении мобильности, т.е. переносимости программного обеспечения с одной архитектуры технических средств на другую. Результатом этой работы стало появление стандартов на языки высокого уровня и их взаимодействия с операционной системой. В дальнейшем, с развитием информационных технологий в область действия концепции открытых систем попадали все новые и новые области. В 60-70-е годы интенсивно разрабатывались вопросы сетевого взаимодействия (модель OSI), в 70-80-е -структуры данных (CODASIL, SQL). Можно упомянуть еще несколько областей стандартизации - графика (GKS, PHIGS), человеко-машинный интерфейс (X/Open, OpenLook), представление печатных текстов (PostScript) и т.д.
Несмотря на обилие примеров удачного решения конкретных проблем, определения открытой системы весьма разнообразны. Наиболее удачными, на наш взгляд, являются: Определение Ассоциации французских пользователей UNIX и открытых систем AFFU: «Открытая система - это система, состоящая из элементов, которые взаимодействуют друг с другом через стандартные интерфейсы»
Определение ШЕЕ: «Открытая система - это исчерпывающая и последовательная совокупность международных стандартов в области информационных технологий и функциональных профилей стандартов, которая специфицирует интерфейсы, службы и поддерживающие форматы для достижения взаимодействия и переносимости приложений, данных и персонала».
Определение комитета IEEE POSIX 1003: «Открытая система, реализующая открытые спецификации на интерфейсы, службы и форматы данных, достаточные для того, чтобы обеспечить: - возможность переноса (мобильность) прикладных систем, разработанных должным образом, с минимальными изменениями на широкий диапазон архитектур - совместную работу (интероперабельность) с другими прикладными системами на локальных и удаленных платформах - взаимодействие с пользователями в стиле, облегчающим последним переход от системы к системе.
Не менее разнообразными являются и модели открытых систем, определяющие, какие собственно интерфейсы, службы и форматы существуют в системе. Необходимо отметить, что уровень, рассматриваемый моделями, постепенно повышается. Если ранние модели, такие как POSIX и OSI стандартизировали системные функции, то модели MIC , OSE/RM и MUSIC, захватывают вопросы построения прикладных систем. Частные модели, такие как SQL, PHIGS, XML, формализуют отдельные прикладные аспекты, не рассматривая опросы операционной среды или сетевых протоколов.
Common Warehouse Metamodel (CWM) - это стандарт, разработанный консорциумом OMG для обмена метаданными между различными программными продуктами и репозиториями, участвующими в создании корпоративных информационно-аналитических систем. Он основан на открытых объектно-ориентированных технологиях и стандартах, используя UML в качестве языка моделирования, XMI и XML - для обмена метаданными и язык программирования JAVA - для реализации моделей и спецификаций.
В соответствии с вышеизложенным для реализации инструментально-исполняющей системы был выбран профиль Java-XML-SQL, обеспечивающий интероперабельность программных решений, в том числе и на уровне исполняющих модулей.
В качестве языка реализации был выбран язык Java, единственный на сегодня полностью интероперабельный широко распространенный язык программирования.
Система написана на языке Java версии 1.4. Для работы системы необходимо наличие установленного пакета Java 2 Runtime Environment версии не ниже 1.4.0 (рекомендуется 1.4.1).
Преимущества платформы Java, активно использующиеся в системе: -кросс-платформенность, позволяющая запускать систему на любых ОС, поддерживающих Java: Windows, UNIX, Linux, MacOS -унифицированный доступ JDBC к реляционным СУБД, что позволяет соответствующим модулям обращаться к внешним базам данных, поддерживающим работу с JDBC (Oracle, Sybase, Informix, MySQL, PostgreSQL), ODBC (DBF, Microsoft Access, Microsoft Excel, текстовые файлы CVS, TXT) -возможность работать в гетерогенной среде - совместно работающие клиентские приложения на множестве ОС -отсутствие необходимости в установке клиентской части ПО работы с СУБД, например клиентских драйверов для Oracle
Особым вопросом являлся выбор стандарта для представления метаданных. Как мы показали в 1-й главе, существующие ранее подходы к хранению метаданных базировались на сложных языках типа EXPRESS, применяемых для хранилищ данных. Для транзакционных систем необходимо более легкое решение. В результате тщательного изучения был выбрано языковое семейство XML, достоинства которого сейчас неоспоримы [20,46,48,93]: -совместное хранение в одном файле как данных, так и метаданных, описывающих его структуру, -кросс-платформенность - наличие библиотек для обработки XML на разных операционных системах, -унифицированность хранения - файлы не подвержены типичным проблемам, связанным с обработкой текстовой информации, таким как: неверная кодировка файлов, гарантированное хранение всех интернациональных символов, включая весь набор русских символов, -возможность автоматического преобразования файлов без написания программ, используя язык XSLT.
Для переноса служебной базы между удаленными машинами, работающими на разных базах данных, также используется формат XML.
Для хранения данных в рассматриваемом решении выбраны реляционные базы данных. В качестве основного продукта управления базами данных был выбран сервер Oracle. Используя в продукте лишь стандартные решения для Oracle, мы получаем масштабируемый продукт. В небольшой информационной системе становится возможным использовать облегченные и менее дорогие разработки, такие как Oracle Lite. Имея полную совместимость с Oracle Server снизу вверх, этот продукт способен удовлетворить нужды информационной системы, хранящей данные относительно небольших объемов. Oracle Lite используется также как локальная база данных или как кэш глобальной базы данных, из которой в данном случае берутся лишь необходимые первичные данные и вся обработка данных ведется лишь на клиенте. Это дает три преимущества: возможность работы без необходимости покупки полнофункциональной СУБД, работа с данными при временном отсутствии соединения с хранилищем данных и при локальной обработке данных происходит значительная экономия сетевого трафика
Система управления коммунальными платежами МАРС
Система МАРС (Муниципальная автоматизированная расчетная система) предназначена для учета и управления взаимными обязательствами натурального и денежного характера, возникающими между поставщиками и массовыми потребителями - физическими и юридическими лицами в рамках долговременных юридических взаимоотношений. Значительное количество взаимоотношений между хозяйствующими субъектами в современном мире происходит в рамках долговременных договорных обязательств. Особенно часто такие взаимоотношения устанавливаются в сфере эксплуатации объектов недвижимости, крупных или технически сложных объектов собственности, таких как транспортные средства или системы связи. В последнее время интенсивно развиваются системы предоставления товаров и услуг через Интернет, что также связано де-факто с установлением потенциально долговременных персонифицированных отношений ( хотя бы односторонних, в виде гарантий владельцев интернет-магазинов об обеспечении конфиденциальности предоставленных покупателем адресных и других сведений личного характера).
Учет взаимных обязательств в долговременных договорах представляет из себя сложную задачу даже в простых договорах купли-продажи. Изменение реквизитов сторон, естественное изменение номенклатуры поставляемых товаров, условий их поставки, включение всякого рода дополнительных соглашений, появление форс-мажорных обстоятельств и другие факторы, несущественные или крайне редкие в кратковременных договорах, таких как покупка в магазине или поездка на поезде, становятся практически неизбежными в долговременных соглашениях. Простые информационные структуры резко усложняются при необходимости учета зависимости многих, если не всех параметров от времени.
Ситуация еще более усложняется, если такие долговременные отношения устанавливаются в массовом порядке. Массовые долговременные соглашения наиболее характерны для отношений населения с организациями, предоставляющие некоторый спектр услуг или регистрирующие определенные правовые или социальные аспекты. Массовость долгосрочных взаимоотношений предполагает, что помимо основных бизнес-процессов, существует огромное количество всевозможного рода особых ситуаций, которые информационная система, осуществляющая автоматизацию учета должна адекватно отрабатывать. Массовость накладывает на организацию информационных систем еще несколько особенностей технического характера: ? в системе накапливается огромное количество информации, которую необходимо вводить, хранить, обрабатывать и предоставлять различным группам пользователей. ? массовая информационная система, как правило, распределена по значительному количеству рабочих мест, связанных между собой разнообразными по техническим данным и, в основным, плохими по качеству каналами связи
Массовые взаимоотношения населения с организациями попадают, как правило под пристальное внимание центральных, местных и ведомственных органов власти и управления. Органы власти и управления, как правило, регулируют такого рода взаимоотношения, даже если они носят чисто коммерческий характер. Органы власти достаточно часто устанавливают некоторые правила учета и обоснования взаимных обязательств между населением и организациями, при этом достаточно часто в процесс включается бюджет в виде дотаций и отчислений. Проблема вносимая местными и ведомственными распоряжениями, с точки зрения организации информационной системы, заключается в том, что наборы бизнес-правил меняются достаточно часто, носят недостаточно согласованный характер и неунифицированы территориально. Последнее обстоятельство практически исключает появление готовых к внедрению «коробочных» информационных систем.
Достаточно часто системы подобного рода обладают еще несколькими неприятными для автоматизации особенностями.
Во-первых, несмотря на персонифицированный характер взаимоотношений, услуги, оказываемые организациями населению носят характер «общественного блага», т.е. могут быть предоставлены только группе лиц сразу. Например уборка территории или капитальный ремонт магистральных инженерных сетей затрагивает сразу большую группу потребителей, проживающих на данной территории или подключенных к данным сетям. Распределение затрат, понесенных обслуживающей организацией, на потребителей, получивших от них выгоду, носит достаточно произвольный характер и производится, как правило, на основе некоторой базы - количества проживающих, занимаемой жилой или общей площади, установленной мощности газовых или электрических приборов и т.п. Практически всегда в этот процесс вмешиваются органы управления, устанавливающие особые правила для некоторых категорий потребителей. Таким образом, помимо учета потребителей, потребляемых ресурсов и произведенной оплаты, информационная система должна уметь вести массу учетных параметров, меняющихся во времени и пространстве.
Во-вторых, из политических, экономических или организационных факторов, реальные бизнес-процессы в подобных системах принимают весьма причудливый вид. Услуги, денежные средства, правоотношения и информация о них предоставляются, перераспределяются и учитываются массой способов, распределяясь между большим количеством организаций и учреждений. Организации - участники данного процесса, преследуют свои ведомственные и корпоративные цели, в результате чего действительно необходимы операции нагружаются дополнительным смыслом, вплетаются в посторонние процессы. Информация, проходя через организации-посредники теряется и искажается, денежные средства задерживаются или перераспределяются, качество услуг, как правило, падает.
Существующие технические, методологические и организационные трудности, характерные для крупных информационных систем вообще, в дополнении к перечисленным выше особенностям данных систем, обуславливают отсутствие на рынке готовых тиражируемых решений, аналогичных известным системам бухгалтерского учета или управления товародвижением компаний 1С, БЕСТ, Инфин. Реально работающие системы в данной области - как правило разработки собственных служб АСУ одной из организаций, предоставляющих услуги, разработки местных специализированных программных фирм или отдельных программистов. Подобные продукты подвержены непрерывной модификации на уровне исходного кода программ и структур данных и неотчуждаемы от разработчиков
Документные модели нереляционных объектов на примере трехмерных геологических моделей
В системах геологического и гидродинамического моделирования широко используется представления пространственных образований -геологических тел и их совокупностей, - в виде сеток - трехмерных наборов элементарных объемов (ячеек). Данное представление необходимо для численного моделирования как геометрии тел, так и распределения в их объеме различных физических и геологических параметров.
Выделяют два основных вида сеток - регулярные и нерегулярные сетки. Регулярная сетка является массивом размерности, соответствующей размерности моделируемого пространства. Значения координат вершин любой из ячеек сетки являются функций от индексов массива. Геометрию такой сетки можно не хранить, если функция достаточно проста, что характерно для широко распространенного случая равномерных сеток. В последнее время в практике моделирования все большее распространения приобретают нерегулярные сетки, характерной особенностью которой является невозможность вычисления координат вершин ячеек по их индексу. Для нерегулярных сеток возникает необходимость эффективного, с точки зрения занимаемого объема и времени выполнения характерных операций, логической модели хранения геометрической информации.
В общем случае логическая модель геометрии ячейки сетки включает в себя сильно связанный связями многие-ко-многим сущности узел , дуга и сторона . ER-диаграмма модели представлена на Рис 33. Большая сложность общей логической модели и значительный объем хранимых данных требуют изыскания путей упрощения общей логической модели с учетом семантики геологических моделей и характером решаемых задач.
Для геологических моделей характерно применения сеток, состоящих из шестигранных ячеек, ребра которых являются прямолинейными отрезками. Ячейки, в основном плотно прилегают друг к другу. Для таких сеток нет необходимости хранить все сущности ячейки: грани, ребра и вершины, так как они однозначно восстанавливаются из упорядоченного набора вершин шестигранника. На данной модели основан метод хранения угловой точки. Модель угловой точки является наиболее экономичной по объему хранимой информации и составляет 24 атрибута на ячейку.
Наиболее часто встречающейся задачей при интерактивной работе с сеточными данными является визуализация некоторого подмножества ячеек. Алгоритм решения этой задачи отбор ячеек по критерию, восстановление геометрии граней, отсечение невидимых граней (1)
В современных программно-технических моделирующих комплексах первая задача решается сервером базы данных, вторая - клиентом и третья -графическим контроллером рабочего места.
При хранении информации о геометрии сетки в реляционных клиент-серверных СУБД с использованием модели угловой точки возникают ряд технических трудностей. В клиент-серверных технологиях узким местом является сеть передачи данных между сервером и клиентом. Экспериментальные оценки показывают, что скорость обмена данными, для подобных задач, между клиентом и сервером в сети Ethernet lOMbod не превышает 2 тысячи записей в секунду. Для характерных размеров сеток в 1 млн. ячеек время передачи данных на клиента составит около 10 минут, что для интерактивных задач совершенно недопустимо.
Основываясь на технологиях визуализации, применяемых в современных графических контроллерах, и особенностях визуализируемой информации, можно ввести дополнительный этап обработки информации -удаление заведомо невидимых граней, каковыми являются смежные грани визуализируемых ячеек. Алгоритм визуализации в данном случае будет следующая отбор ячеек по критерию, восстановление геометрии граней, удаление заведомо невидимых граней, отсечение невидимых граней (2)
Предварительное удаление заведомо невидимых граней эффективно даже при использовании специализированных графических контроллеров со встроенной поддержкой рендеринга, так как контроллер освобождается от большого объема расчетов с заведомо бесполезной информацией.
Вынесение этапа удаления заведомо невидимых граней на сервер и передача для визуализации на клиента только несмежных граней позволит для плотных геометрий значительно сократить объем передаваемой информации. В данном методе объем передаваемой информации будет пропорционален площади поверхности визуализируемого тела, тогда как в случае (1) он пропорционален объему тела. Для характерных размеров сетки в 1 млн, ячеек сокращение объема передаваемых строк составит около 100 раз, с вполне приемлемым временем 5 сек на сопоставимых технических средствах.
Для реальных геологических тел отношение немного меньше за счет сложной формы, но также достаточно велико (Рис. 34) Техническая реализация предложенной методики на модели угловой точки наталкивается на другую сложность. Восстановление граней и определение заведомо невидимых является достаточно сложной вычислительной процедурой, что в реляционных базах данных исключает эффективное использование индексов для поиска информации, что приводит к увеличению времени на обработку данных, вычислений на сервер БД.
Можно предложить другую модель хранения геометрии ячеек, свободную от указанных недостатков и основанную на выделении граней как основного логического объекта. Грани в такой модели являются упорядоченным массивом координат вершин граней, хранящихся в виде последовательного списка. Ячейки представляются неупорядоченным множеством ссылок на грани, при этом смежные грани ячеек определяются на этапе записи данных в базу так, что смежная грань записывается в базу один раз. Данная модель имеет средний объем хранимой информации о геометрии около 36 атрибутов на ячейку.
Алгоритм (3), в отличие от алгоритма (2) не использует априорную информацию о форме ячеек и может использоваться в случае ячеек другой формы. Предлагаемая модель хранения геометрии позволяет решить задачу исключения заведомо невидимых граней ячеек с использованием исключительно реляционных запросов вида: select face_id, count(face_id) from face ... where ... having count(face_id) = 1 Выполнение подобных sql-запросов производится встроенными высокоэффективными процедурами с использованием индексов. Проведенные экспериментальные оценки на сервере с процессором P-IV 1.5 GHz, работающем под управлением Oracle 9.x показывают время выполнения запроса (3) из массива граней реального геологического тела (1 млн. ячеек) в диапазоне от 3 до 5-ти секунд
