Компромиссная модель данных в сервис-ориентированной информационной системе

Размещено на http://www.allbest.ru/

Компромиссная модель данных в сервис-ориентированной информационной системе

М.В. Евланов, В.А. Никитюк

Харьковский национальный университет радиоэлектроники, Харьков

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

Ключевые слова: сервис, информационная технология, сервис-ориентированная архитектура, интеграция информационных систем, комбинаторная топология, симплекс

Розглядається задача розробки моделі, що заснована на математичному апараті комбінаторної топології, який дозволяє виявити у просторі даних окремі слабко залежні друг від друга структури даних, досліджувати процеси взаємодії окремих структур даних. Запропонована модель може бути реалізована в рамках розроблюваної інформаційної технології інтеграції даних в сервіс-орієнтованих інформаційних системах.

Ключові слова: сервіс, інформаційна технологія, сервіс-орієнтована архітектура, інтеграція інформаційних систем, комбінаторна топологія, симплекс.

We consider the task of developing a model which is based on the mathematical formalism of combinatorial topology. Сombinatorial topology allows you to identify data structures that are weakly dependent on each other in a single data space, to investigate the interactions of individual data structures. The proposed model can be implemented within developed information technology for data integration processes in service-oriented information systems.

Keywords: service, information technology, service-oriented architecture, integration of information systems, combinatorial topology, the simplex.

компромиссный данные ориентированный архитектура

Введение

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

а) проблемы, вызванные взаимовлиянием ERP-ИС и бизнес-процессов (БП) управляемого объекта, к которым относятся:

- сложность согласования предлагаемых изменений БП управляемого объекта с оптимальным использованием ERP-ИС, эксплуатируемой на этом объекте;

- возможность потери конкурентоспособности управляемого объекта вследствие перепроектирования его БП под «промышленный стандарт», поддерживаемый ERP-ИС;

- наличие в ERP-ИС избыточных функциональных задач (ФЗ) и функциональных модулей (ФМ) (по сравнению с фактическими потребностями управляемого объекта с учетом ограничений на различные виды используемых ресурсов);

б) проблемы, связанные с затратами, к которым относятся:

- высокая стоимость покупки, внедрения и сопровождения ERP-ИС;

- высокие материальные и временные затраты на переход к другой версии ERP-ИС или же на переход к ERP-ИС другого производителя (что снижает гибкость и стратегический контроль на корпоративном уровне);

в) проблемы, связанные с персоналом управляемого объекта, к которым относятся:

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

- возможность снижения эффективности работы управляемого объекта в целом из-за неверных действий сравнительно небольшой группы пользователей ERP-ИС (проблема «слабого звена») или из-за неверных данных, вводимых отдельными пользователями;

г) проблемы создания и модернизации ERP-ИС, к которым относятся:

- низкая степень гибкости ERP-ИС и трудности адаптации такого класса систем к потокам данных и БП конкретных объектов;

- ограничение возможности индивидуальной доработки ERP-ИС;

- проблемы совместимости с «устаревшими» ИС предприятий-партнеров;

д) проблемы, связанные с эксплуатацией ERP-ИС, к которым относятся:

- сложность эксплуатации ERP-ИС;

- возможные проблемы с формированием необходимой отчетности, со сферами ответственности и моральным состоянием сотрудников управляемого объекта из-за «стирания границ ответственности», вызванного внедрением и эксплуатацией ERP-ИС на управляемом объекте;

- конфликт концепций ERP и ERP ІІ, связанных с защитой информации, с мерами по нераспространению секретной информации между подразделениями управляемого объекта.

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

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

Анализ особенностей информационных систем с сервис-ориентированной архитектурой

Главное преимущество сервис-ориентированной архитектуры (ЅОА) современной ИС заключается в возможности интеграции отдельных сервисов по результатам анализа потоков документов, основанных на бизнес-процессах. Такая интеграция позволяет ускорить формирование новых вариантов функциональной структуры системы с ЅОА (ЅОА-ИС), увеличить производительность ЅОА-ИС и сделать ее приложения более гибкими в реакции на изменение бизнес-процессов [2].

Главные цели разработки и внедрения ЅОА-ИС заключаются в следующем [3]:

- достижение хорошей прозрачности и гибкости процесса;

- устранение разъединенности подразделений объекта автоматизации;

- управление более качественными данными;

- повторное использование ИТ-сервисов;

- приведение сочетания бизнеса и ИТ в соответствие целям деятельности предприятия.

Среди рассмотренных выше основных целей ЅОА-ИС наиболее критичной в [3] считается достижение хорошей прозрачности и гибкости процесса. Для достижения этой цели эффективным является использование решения уровня ИТ-сервисов. Под ИТ-сервисами следует понимать модули, которые представляют собой используемую функциональность отдельных элементов БП. Существуют также системные сервисы, такие как: контроль системы, ведение журналов, организация взаимодействия и т.д. [2]. Уровень ИТ-сервисов это быстрорастущий сегмент рынка ЅОА-ИС, в котором и поставщики, и предлагаемые ими продукты отличаются разнообразием [3].

Практический опыт, накопленный в процессе разработки и успешного внедрения ряда прикладных решений в области ЅОА-ИС, позволил представить структурную схему взаимодействия основных элементов ИС в виде, показанном на рис. 1 [3].

Выделение нерешенных проблем построения информационных систем с сервис-ориентированной архитектурой. На ранних этапах создания ИС с SOA предполагались следующие перспективы их развития: поддержка гибкого конфигурирования БП; сокращение управленческих расходов; возможность динамически развертывать ИТ-сервисы; обеспечение плавной интеграции приложений, подразделений предприятия и партнеров этого предприятия по бизнесу. Однако эти завышенные требования не были реализованы в полной мере. Опыт разработки и внедрения показывает, что критичной ошибкой большинства предприятий является разрыв между их целями и текущими вложениями в нужные компоненты и технологии для достижения этих целей [3]. Так, много усилий прикладывается к разработке и внедрению отдельных ИТ-сервисов. Однако усилия на разработку и внедрение корневых составляющих SOA - реестра и хранилища SOA - во многих случаях затрачиваются недостаточно правильно, чтобы ИС с SOA могла функционировать успешно [1,3].

Другой, не менее важной проблемой информатизации предприятий, является уже отмеченное выше разнообразие поставщиков и решений на рынке ЅОА-ИС. Такое разнообразие приводит к тому, что ЅОА-ИС целого ряда предприятий формируются из разнородных ИТ-сервисов. Вследствие этого возникает интерес к решению проблемы повышения эффективности использования ИТ в основной деятельности предприятия и к оптимизации затрат расходуемых при этом ресурсов различного рода [4]. Эта задачу не следует считать элементарной или же типовой. Имеется большое количество примеров того, как работы по информатизации предприятия не дают желаемого эффекта или же приводят к излишним трудозатратам. Неудачи в этой области породили эффект, который в [5] назван «ИТ-слепотой» (IT blindness) - неспособностью существующих ИС и ИТ «увидеть» и оценить реальные процессы в той среде, в которую они включены.

Рис. 1. Структурная схема взаимодействия основных составляющих сервис-ориентированной архитектуры информационной системы (ЅОА-ИС)

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

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

В большинстве случаев, говоря о таких законах, закономерностях, моделях и методах, прежде всего, проводят аналогию с процессом создания зданий и сооружений различного назначения. Данная аналогия не является новой, однако в последнее время она получила дополнительное распространение после работ специалистов компании Microsoft «Metropolis» и «Metropolis and SOA Governance», проводящих аналогии между эволюцией информационных технологий и процессами эволюции городов и промышленности [6,7].

Однако такое представление носит исключительно концептуальный характер и пока не подкреплено математическими моделями и методами интеграции разнородных представлений отдельных сервисов. В целом же можно утверждать, что проблема интеграции разнородных ИТ-сервисов на различных уровнях еще далека от своего разрешения [8,9].

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

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

1) наличие единой семантической модели систем информационных показателей, в рамках которой происходит согласование различных систем информационных показателей пользователей SOA-ИС;

2) наличие ограниченного количества семантических моделей систем информационных показателей и специального инструмента согласования этих моделей.

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

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

Задачей, которая имеет более важное значение с точки зрения эксплуатации разнородных ИС и их отдельных элементов, является реализация SOA-ИС, которые объединяют в себе информационные представления равноправных групп пользователей. Такие SOA-ИС являются информационно и организационно открытыми. При этом предполагается, что в таких SOA-ИС существует группа описаний, которые определяют не только синтаксис, но и семантику конкретных реализаций моделей ИС и ее компонентов [10]. Элементы этой группы получили название «метамодель». В более общем смысле метамодель в работе [11] предлагается рассматривать как принцип устройства открытой системы и одновременно как механизм, обеспечивающий конструирование, существование и взаимодействие множеств моделей этой системы. В той же работе высказано предположение, что реализация метамодели открытой системы включает в себя не только определенные типы структур данных и взаимодействие этих структур, но и определенные типы и способы организации этих взаимодействий, то есть имеет характер сложно организованной, но целостной системы взаимодействий и способов организации этих взаимодействий.

Практические работы по реализации идеи метамоделирования ИС в настоящее время связаны, главным образом, с деятельностью Object Management Group. Предлагаемая ими архитектура MDA (Model Driven Architecture) является одной из первых попыток реализации идеи метамоделирования при разработке программных систем. Сейчас MDA опирается на следующие стандарты OMG [12-14]:

- UML - универсальный язык моделирования;

- Common Warehouse Metamodel (CWM) - стандарт для обмена данными между банками данных, системами поддержки принятия решений и технологиями порталов;

- Meta-Object Facility (MOF) - общий абстрактный язык для описания метамоделей, основа для CWM и UML-метамоделей;

- XML Metadata Interchange (XMI) - XML-формат для хранения и обмена метаданными.

Пример соотношения между этими стандартами и технологиями Java показан на рис. 2 [13].

Рис. 2. Соотношение между MDA и технологиями реализации программных систем

Однако решения MDA не являются метамоделью в полном смысле этого слова. Среди ее недостатков, которые проявляются уже в настоящее время, следует выделить:

- ориентация на существование единой семантической модели проектируемой системы;

- невозможность автоматизации определения и согласования противоречий между отдельными моделями проектируемой системы.

Отмеченные противоречия возникают, главным образом, из-за различий в представлении данных пользователями SOA-ИС.

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

При разработке математической модели SOA-ИС будем основываться на следующих предпосылках:

- группы пользователей обладают равными правами на определение представлений данных (каждый пользователь имеет одинаковые возможности по определению структуры и содержания представления данных, с которыми он будет впоследствии работать);

- каждый пользователь определяет только визуально наблюдаемые представления данных (то есть представления данных в виде программных интерфейсов, бумажных или электронных документов, формируемых в результате работы SOA-ИС);

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

Тогда задача построения математической метамодели проектируемой SOA-ИС на уровне хранимых данных будет сводиться к следующим задачам:

- задаче моделирования отображения представлений данных, определяемых пользователями SOA-ИС, в единое комплексное описание ИС (по аналогии с MDA);

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

Разработка топологической компромиссной модели данных сервис-ориентированной информационной системы

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

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

Задача 2. Задача синтеза оптимальной физической реализации компромиссной модели данных ИС в виде базы данных, оптимизированной под конкретную СУБД.

Задача 3. Задача синтеза оптимальной физической реализации компромиссной модели обработки данных в виде программной системы, оптимизированной в ходе проектирования и компиляции.

Для решения Задачи 1 необходим подход, который, формируя компромиссные Data Flow Diagrams, Entity-Relations Diagrams или диаграммы классов, позволял бы создать единое описание информации (данных) и отмеченные выше процессы обработки данных. Основная концепция такого подхода заключается в идее сохранности структуры проектируемой SOA-ИС на различных этапах проектирования. Под структурой SOA-ИС понимается взаимосвязь процессов обработки информации, внешних по отношению к системе сущностей и хранилищ данных, в сильной степени обусловленная последовательностью выполнения процессов хозяйственной деятельности объекта автоматизации. Под сохранностью понимается тождественность представлений структуры системы на этапах проектирования функциональной структуры системы, разработки видов обеспечений и внедрения созданной SOA-ИС на объекте. В соответствии с этим подходом совокупность средств создания ИС можно рассматривать как единую CASE-систему, построенную по аналогии с пакетом ARIS, которая разрабатывается с учетом особенностей основного технологического процесса проектирования ИС. Однако, в отличие от пакета ARIS, данная CASE-система должна предусматривать не только процессы прямого и обратного проектирования функциональной структуры и видов обеспечений SOA-ИС, но и обеспечивать проверку условий сохранности структуры проектируемой SOA-ИС на различных этапах проектирования [15].

В результате анализа математических аппаратов, позволяющих формализовать правила решения Задачи 1, становится возможным выделить два основных математических аппарата:

- аппарат комбинаторной топологии, используемый для формализованного описания моделей конкретных пользователей;

- аппарат теории категорий, описывающий особенности взаимодействия моделей конкретных пользователей и/или разработчиков SOA-ИС.

Особенности использования аппарата теории категорий для формализованного описания взаимодействия компромиссных моделей в ходе решения Задачи 1 представляют собой тему отдельного исследования и в данной работе не рассматриваются.

Выбор математического аппарата комбинаторной топологии обусловлен тем, что, в отличие от традиционного для Entity-Relation Diagram двумерного представления данных, большинство современных SOA-ИС ориентированы на многомерное представление данных. Следует также отметить, что существующие методы сбора и анализа требований пользователей SOA-ИС к данным не позволяют осуществлять их аналитическую обработку и выявление конфликтов. Поэтому возникает необходимость создания смысловых моделей требований и ограничений, изоморфных по отношению к вариантам реализации компромиссных моделей данных и моделей процессов обработки данных. Предполагая, что каждый атрибут данных SOA-ИС имеет свое смысловое значение, отличное от значений всех остальных атрибутов данных, возможно представить семантическое описание каждого требования к данным как точку или замкнутую область пространства данных, определенную на общем евклидовом смысловом пространстве данных проектируемой SOA-ИС. Поэтому можно утверждать, что любое статическое состояние проектируемой SOA-ИС может быть описано сочетанием требований к данным, которые определяются пользователями и/или разработчиками проектируемой ИС. Такое сочетание представляется как симплекс [16] вида

(1)

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

(2)

. (3)

Предлагаемый подход к моделированию описаний требований к данным позволяет представить математическую модель смыслового пространства данных ИС, как некоторый комплекс конечную совокупность симплексов . Особенностью такого комплекса являются условия пересечения симплексов - они должны либо не пересекаться, либо пересекаться гранями. Грань определяется симплексом, аналогичным симплексу (2), чьи линейно независимые точки смыслового пространства присутствуют в обоих симплексах. Эти условия в процессе анализа требований позволяют аналитически обнаружить в комплексе возникающие конфликты между требованиями и перекрытия различными требованиями друг друга. Кроме того, эти условия позволяют обнаружить ошибки, возникающие в ходе детализации требования к данным (описание некоторой области смыслового пространства соответствующим симплексом) или же в ходе обобщения требований к данным (формирование комплекса из соответствующей совокупности симплексов ). Один из методов моделирования данных, позволяющий реализовать подобные возможности, рассмотрен одним из авторов статьи в работе [17].

В общем случае любое визуально наблюдаемое представление данных можно отнести к одной из трех следующих групп:

- одномерное представление данных (симплекс состоит из одного элементарного атрибута) вида

(4)

- двумерное представление данных (симплекс состоит из последовательности элементарных атрибутов) вида

(5)

- трехмерное представление данных (симплекс состоит из последовательности, в которой кроме элементарных атрибутов присутствуют и агрегаты атрибутов) вида

(6)

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

Для выражения (4) условия (2) и (3) примут следующий вид

. (7)

Здесь - количество всех уникальных элементарных атрибутов данных, которые могут участвовать в формировании одномерного симплекса.

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

В том случае, если такое отношение порядка не задано на двумерном представлении данных, то для всех отличных от нуля барицентрических координат в дополнение к условиям (2) и (3) должно выполняться условие вида

, (8)

где - отличные от нуля барицентрические координаты симплекса , и .

В том случае, если такое отношение порядка задано на двумерном представлении данных, то для всех отличных от нуля барицентрических координат в дополнение к условиям (2) и (3) должны выполняться условия вида

(9)

где - барицентрическая координата последнего элементарного атрибута данных, определяющего ключ, .

Для выражения (6) возможно также задание отношения порядка не только на последовательности элементарных атрибутов, но и на последовательности атрибутов, образующих агрегат. Поэтому кроме условий (2), (3), (8) и (9) для выражения (6) должны также выполняться условия вида

, (10)

для случая отсутствия отношения порядка на агрегате и вида

(11)

для случая определения отношения порядка на агрегате.

Исходя из выражений (4) - (11), решение задачи разработки компромиссной модели данных ИС следует проводить в два этапа.

На первом этапе формируются множества требований к данным каждого конкретного пользователя ИС. Для описания структуры такого множества требований к данным введем понятие «локальный комплекс». Этот комплекс формируется следующим образом

(12)

где - обозначение локального комплекса конкретного k-го пользователя ИС; - симплекс i-ой мерности, определяющий структуру tr-го требования к данным k-го пользователя SOA-ИС; i - количество измерений конкретного симплекса , ; tr - идентификатор требования к данным, , f - количество требований к данным, которые выдвинуты k-м пользователем SOA-ИС.

При формировании локального комплекса должно выполняться условие

(13)

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

Смысл условия (13) заключается в отбрасывании не связанных между собой структур данных. Поэтому ранг множества атрибутов может являться показателем связности требований к данным для конкретного k-го пользователя ИС. Значение этого показателя в общем случае определяется, исходя из особенностей организационных структур объектов автоматизации.

На втором этапе формируется общесистемное множество требований к данным, которое определяет структуру информационного пространства проектируемой SOA-ИС. Структура такого общесистемного множества определяется комплексом, который формируется следующим образом

(14)

где - обозначение общесистемного комплекса; p - количество пользователей SOA-ИС, которые выдвинули требования к данным.

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

 (15)

В идеальном случае значение выражения (15) должно стремиться к нулю.

Выводы и перспективы дальнейших исследований

Использование математического аппарата комбинаторной топологии для формализованного описания требований пользователей к данным и для создания компромиссной модели пространства данных SOA-ИС позволяет:

- формировать модель многомерного пространства данных SOA-ИС;

- выявлять в пространстве данных отдельные слабо зависимые друг от друга образования данных, представляемые в виде симплексов;

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

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

Основываясь на предложенных в данной статье подходах к описанию компромиссной модели данных, можно сделать следующие выводы.

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

Во-вторых, предлагаемые топологические модели не зависят от конкретного вида возможных моделей требований к данным и моделей самих данных. Такая независимость наиболее предпочтительна для формирования метамоделей SOA-ИС.

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

Список литературы

1. Черняк, Л. На пути к предприятию, управляемому в реальном времени Текст Л. Черняк // Открытые системы. - 2002. - № 12. - С. 43-47.

2. Горобец, Н. ISO 20000: зрелое управление ИТ-услугами [Текст] / Н. Горобец // Директор информационной службы. - 2006. - № 9.

3. Фаулер, М., UML в кратком изложении. Применение стандартного языка объектного моделирования [Текст] / М. Фаулер, К. Скотт. - М.: Мир, 1999. - 191 с.

4. Mellor, S. Model-Driven Development [Text] / Stephen Mellor, Anthony Clark, Takao Futagami // IEEE Software, September/October 2003, IEEE Computer Society. - 2003.

5. Левыкин, В.М. Концепция построения CASE-системы разработки информационных управляющих систем [Текст] / В.М. Левыкин, М.В. Евланов, М. Мухайрат // АСУ и приборы автоматики. - 2001. - Вып. 114. - С. 55-59.

6. Понтрягин, Л.С. Основы комбинаторной топологии [Текст]. - М.: Наука, 1986. - 118 с.

7. Левыкин, В.М. Применение синергетических моделей для описания процессов разработки информационных систем [Текст] / В.М. Левыкин, М.В. Евланов, Л.М. Кондратьева // Восточно-европейский журнал передовых технологий. - 2005. - №. 2/2(14). - С. 83-88.

Размещено на Allbest.ur