Содержание к диссертации
Введение
Глава 1. Методологические аспекты проблемы анализа и синтеза открытых информационных систем 14
1.1. Роль и место рассматриваемой проблемы в условиях процессов глобализации и стратегии научно-технологического развития РФ 14
1.2. Сравнительный анализ известных научных результатов в области проектирования информационных систем 19
1.3. Обоснование нового подхода к анализу и синтезу информационных систем 53
1.4. Выводы по главе 1 72
Глава2. Открытые информационные системы и их анализ 75
2.1. Основные понятия и определения теории множеств и абстрактной алгебры 75
2.2. Информационные системы как источники и приемники информации 82
2.3. Интерфейсы и компоненты открытых информационных систем 86
2.4. Совместимость и фильтрация компонентов. Многокомпонентная интероперабельная структура 94
2.5. Выводы по главе 2 102
Глава 3. Техническая самоорганизация открытых информационных систем. Концепция. Принципы. Методология 104
3.1. Исследование открытой информационной системы с позиций самоорганизации 104
3.2. Концепция и принципы технической самоорганизации информационных систем 113
3.3. Особенности реализации принципов технической самоорганизации открытых информационных систем 121
3.4. Выводы по главе 3 135
Глава 4. Структурно-параметрический синтез открытых информационных систем 138
4.1. Особенности разработки алгоритмического комплекса синтеза открытых информационных систем 138
4.2. Онтологический каркас открытой информационной системы 142
4.3. Обобщенный метод синтеза многокомпонентных интероперабельных структур 151
4.4. Выводы по главе 4 178
Глава 5. Практическая реализация результатов работы 179
5.1. Обобщенная методика блочно-иерархической организации открытых информационных систем 179
5.2. Семантическое моделирование и структурный синтез средств защиты бортовой электроники как открытой информационной системы 185
5.3. Методика компонентной сборки Web-приложений 194
5.4. Методика обеспечения интероперабельности диалоговых информационных систем 201
5.5. Технология построения открытых исследовательских пространств 210
5.6. Выводы по главе 5 239
Выводы 240
Список сокращений 242
Список литературы 243
Приложение 1. Классы компонентной сборки программных систем 272
Приложение 2. Индивиды и роли онтологии компонентной сборки программных систем 276
Приложение 3. Алгоритмы компонентной сборки программных систем 278
Приложение 4. Спецификации стандартизированного профиля открытого виртуального исследовательского пространства 291
Приложение 5. Копии свидетельств об официальной регистрации программ для ЭВМ 306
Приложение 6. Копии документов о внедрении результатов диссертационной работы. 310
- Сравнительный анализ известных научных результатов в области проектирования информационных систем
- Основные понятия и определения теории множеств и абстрактной алгебры
- Онтологический каркас открытой информационной системы
- Технология построения открытых исследовательских пространств
Сравнительный анализ известных научных результатов в области проектирования информационных систем
Известны эффективные методики, концепции, технологии, подходы к управлению развитием ИС в контексте определенных направлений деятельности и сфер приложения, нашедшие своё эффективное применение в различных задачах. Некоторые из них приобрели статус международных, государственных, корпоративных стандартов. Ниже перечислены некоторые, наиболее важные, технологии и стандарты, применяемые при разработке ИС:
1. MRP (Material Requirements Planning) – планирование поставок материалов, исходя из данных о комплектации производимой продукции и плана продаж.
2. MRPII (Manufacture Resource Planning) – планирование материальных, мощностных и финансовых ресурсов, необходимых для производства. Стандартизовано ISO.
3. CRP (Capacity Requirements Planning) – планирование производственных мощностей, исходя из данных о технологии производимой продукции и прогноза спроса.
4. ERP (Enterprise Resource Planning) – финансово-ориентированное планирование ресурсов предприятия, необходимых для получения, изготовления, отгрузки и учёта заказов потребителей на основе интеграции всех отделов и подразделений компании.
5. SCM (Supple Chain Management) – управление цепочками поставок. Реализация бизнес-процессов на базе внешних предприятий и торговых площадок Основано на референтной модели SCOR, стандартизованной Supply Chain Council.
6. CRM (Customer Relationship Management) – управление взаимоотношениями с заказчиками. Комплекс методов и средств, нацеленный на привлечение, удовлетворение требований и сохранение платежеспособных клиентов.
7. ERPII (Enterprise Resource and Relationship Processing) – управление ресурсами и взаимоотношениями предприятия. Объединяет в себе 3 вышеперечисленные технологии.
8. Workflow – технология, управляющая потоком работ при помощи программного обеспечения, способного интерпретировать описание процесса, взаимодействовать с его участниками и при необходимости вызывать соответствующие программные приложения.
9. OLAP (Online Analytical Processing) – оперативный анализ данных. Технология поддержки принятия управленческих решений на основе концепции многомерных кубов информации.
10. Project Management – управление проектами. Поддерживается рядом международных стандартов.
11. CALS (Continuous Acquisition and Lifecycle Support) – непрерывная информационная поддержка поставок и жизненного цикла. Описывает совокупность принципов и технологий информационной поддержки жизненного цикла продукции на всех его стадиях. Объединяет в себе практически все вышеперечисленные подходы и технологии.
Для анализа сильных и слабых сторон существующих подходов, методов и инструментов проектирования и реализации информационных систем необходимо выделить систему требований к ним. Известны определения понятия термина "Требование". В работе [102] приводится такая формулировка: «Требование – это условие или возможность, которой должна соответствовать система». В IEEE Standard Glossary of Software Engineering Terminology (1990) [255] данное понятие трактуется шире. Требование – это:
1. Условия или возможности, необходимые пользователю для решения проблем или достижения целей.
2. Условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам.
3. Документированное представление условий или возможностей для пунктов 1 и 2.
Классификации требований представлены в работах [82, 94, 103, 256]. Все требования могут быть разделены на требования к информационной системе как к конечному результату и на требования к организации работ по созданию информационной системы. В первой группе выделяют уровни бизнес-процессов, пользователей и функционирования. Вторая группа определяет системные требования. К. Вигерс формулирует данный термин, как «высокоуровневые требования к продукту, которые содержат многие подсистемы» [94]. При этом под системой понимается программная, программно-аппаратная, либо человеко-машинная система, являющаяся сложной, структурированной системой. Системные требования являются подмножеством функциональных требований к продукту. INCOSE (International Council on Systems Engineering) даёт более детальное определение системы: «комбинация взаимодействующих элементов, созданная для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы». Этот же подход прослеживается в стандарте ГОСТ Р ИСО/МЭК 12207/99 [256]: работы, связанные с системой в целом и с программным обеспечением выделяются в отдельные группы в целях удобства оперирования.
К. Вигерс [66] выделяет следующие основные группы нефункциональных требований:
требования к внешним интерфейсам (External Interfaces),
требования к атрибутам качества (Quality Attributes),
требования к ограничениям (Constraints).
Далее рассмотрим модели жизненных циклов информационных систем.
Модель жизненного цикла (ЖЦ) – это структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует. Стандарт ISO/IEC 12207 [233] не предлагает конкретную модель ЖЦ и методы разработки ПО, а регламентирует общие положения для любых моделей ЖЦ, методологий и технологий разработки. Описание структуры процессов ЖЦ носит общий характер, при этом не делается конкретных, детальных рекомендаций по осуществлению элементарных процессов и действий [123] .
Традиционно выделяются следующие основные этапы ЖЦ информационных систем:
1. Анализ требований.
2. Проектирование спецификаций.
3. Программирование/внедрение.
4. Тестирование и отладка.
5. Эксплуатация и сопровождение.
С 1986 г. институтом программного инжиниринга (SEI) развивается модель зрелости организации как разработчика программного обеспечения (CMM), которая включает описание процессов разработки ПО, уровней эволюции. На практике были выявлены слабые стороны модели, которые были обусловлены многообразием подходов, а также структурными, функциональными и организационными особенностями различных компаний. В связи с этим, с 2002 года развивается (интеграционная) модель (CMMI), являющаяся развитием CMM и содержащая практические рекомендации по повышению эффективности процесса создания ПО в конкретных ситуациях за счет координированного внедрения и использования множества моделей совершенствования процессов разработки программного обеспечения.
SEI объединяет организации, разрабатывающие и специфицирующие различные аспекты качества ИС: программный инжиниринг (ACM, IEEE), менеджмент проектов (PMI) и качество (ASQ).
Далее приводится анализ моделей управления жизненным циклом информационных систем, которые в разное время были успешно применены на практике. Каскадная модель предполагает переход на следующий этап после полного окончания работ по предыдущему этапу и характеризуется четким разделением данных и процессов их обработки.
Модель обладает следующими положительными сторонами: известность, упорядоченность, доступность, простота и удобство, стабильность требований, обеспечение строгого контроля. Имеется ряд недостатков: линейность, нет итераций между фазами, не показывает реальной скорости ведения проекта, клиенту нет возможности ознакомиться с предварительной версией целевой системы, трудно оценить качество, пользователю нет возможности постепенно привыкнуть к системе, нет гарантии запуска ИС в эксплуатацию, результаты этапа не могут быть изменены до конца проекта, все требования должны быть известны в начале проекта, нет возможности динамических изменений требований, требует жесткого управления и контроля, избыточное количество документации, сложность декомпозиции.
Основные понятия и определения теории множеств и абстрактной алгебры
Отображение множеств обозначается символом / : А -+ В или А А В. Отображение / называется сюръективным, если для каждого Ь Є В найдется а Є А такое, что Ь = af. Отображение / инъективно, если из а\ a2 следует &i/ 7 a2,f. Если отображение одновременно и суръективно и инъективно, то оно называется биективным или взаимно однозначным. Два отображения f\ и /2 совпадают, если у них одни и те же А и В и для каждого а Є А имеем af\ = а/2. Символом Fun(A} В) или ВЛ обозначено множество всех отображений из А в В.
Декартово произведение двух множеств Ах В состоит из всевозможных пар (а, 6), где а Є А и Ь Є В. Декартово произведение Ах х х Ап состоит из последовательностей - кортежей (аь ..., ап), где аг Є Л, г = 1,..., п. Допустим теперь, что / - произвольное множество, и пусть каждому а Є I сопоставлено множество Аа. Декартово произведение А = ЦАа есть множество функций а, определенных на /, выбирающих для каждого а Є I элемент а(а) = аа, принадлежащий Аа.
Пусть - некоторое множество, и пусть для множества / задано разбиение / = [J 4 і Є . Кроме того, каждому а Є I сопоставлено множество Аа, и А = Y\Aa есть декартово произведение множеств Аа по всем а Є 1{. Тогда множество А и декартово произведение всех Аг по всем і Є находятся в естественном взаимно однозначном соответствии.
Известно следующее универсальное свойство декартовых произведений. Пусть дано произведение А = ]\Аа,а Є I. Символом тга : А - Аа обозначена сюръекция проецирования, сопоставляющая каждому а Є А его значение а(а). Множество А будем рассматривать одновременно с набором всех проекций 7га, а Є /. Допустим теперь, что задано некоторое множество В с набором отображений va : В -+ Аа. Тогда имеется единственное отображение v : В -+ А, продолжающее все vQ в следующем смысле. Для каждого а Є I имеет место коммутативная диаграмма т.е. 1Утга = іуаи для каждого Ь Є В функция hv выбирает bv Є Аа Для построения множества А с набором инъекций иа : Аа - А так, чтобы выполнялось следующее, двойственное предыдущему, универсальное свойство. Если В - некоторое множество и заданы отображения иа : Аа — В то имеется единственное продолжение всех этих vQ до v : А — В. Продолжение здесь понимается в том смысле , что всегда имеет место коммутативная диаграмма A » В
Мультиотображением изАвВ называется отображение, сопоставляющее каждому а Є А некоторое непустое подмножество в В. Частичным мультиотображением изАвВ называется произвольное отображение из А в В. При этом некоторым а Є А отвечает пустое подмножество в В. Отношения между элементами из А и В взаимно однозначно связаны с частичными мультиотобра-жениями. Если р - отношение, то соответствующее отображение сопоставляет каждому а Є А множество всех Ь Є В для которых выполняется арЬ.
Будем рассматривать отношения между элементами одного и того же множества А как бинарные отношения на множестве Д обладающие свойствами:
1. Рефлексивность: ара для каждого аєА
2. Симметричность: арЬ = Ьра для любых а и Ь из А. Антисимметричность: арЬ Д Ьра = а = b
3. Транзитивность: арЬ/\Ърс = аре.
Рефлексивное, симметричное и транзитивное отношение называется эквивалентностью на множестве А. Рефлексивное, антисимметричное и транзитивное отношение есть отношение порядка.
Пусть А множество ир- эквивалентность на А. Символом А/р обозначим множество, элементами которого являются всевозможные различные смежные классы вида [а\р, а Є А. Это множество называется фактор множеством множества А по эквивалентности р.
Известна основная теорема об отображениях. Пусть дано отображение / : А — В. Его ядром Kerf называется отношение р на А, определяемое правилом а\ра2 = a\f = а2/. Р = Kerf есть эквивалентность на А, причем имеется единственное отображение ф : А/р - Б , делающее коммутативной диаграмму A В
Здесь r - естественное отображение и p задается правилом [а] р = af. Корректность этого правила следует из определения р. Таким образом, имеется каноническое разложение f = пр, где т - сюръекция и ip - инъекция.
Операции и отношения определяем на заданном непустом множестве . При любом натуральном п выделяют n-арные операции и n-местные отношения. п-арная операция - это произвольное отображение вида ш : А х х А — А.
Если а\,...,ап - элемент декартова произведения, то результат применения операции обозначается а\,..., апсо. п-местное отношение на множестве - это отображение вида р : А х х А -+ 2. Для каждого А система всех операций на А обозначается через Ор А, и Rel А обозначает систему всех отношений. Соответственно ОрпА и RelnA обозначают наборы n-арных операций и n-местных отношений.
Зададим множество символов основных операций. Каждому wE отвечает определенная арность. определяет сигнатуру алгебры А и представление / : - Op А - отображение, реализующее каждый символ операции и Є в виде определенной операции той же арности, что ишвА
Алгебра может быть формализована несколькими способами, например, так (A,,f). При заданном имеем класс -алгебр. В этом большом классе выделяются различные подклассы, задаваемые различными специальными аксиомами.
-Модель это набор (Д,/), где А основное множество - носитель модели, - множество символов основных отношений и / - реализация / : — Rel А всех символов отношений из в А, согласованная с «местностью», приписанной каждому ф Є .
Алгебраическая система возникает тогда, когда исходят одновременно из набора операций П и набора отношений Ф. В этом случае имеем (А, П, Ф, /ь /2), где /і и /г - соответствующие реализации: f\ : Г2 — Ор Д /2 : Ф — Ле/ Л. Две алгебры Л и Б с одним и тем же П называются однотипными. Аналогично определяется однотипность моделей и общих алгебраических систем.
Пусть А и Б - две однотипные -алгебры и /І : А -+ В отображение множеств. Говорят, что отображение /І согласовано с п -арной операцией ио Є ft, если выполняется ( 2i... anuY = di ... а со. Аналогично определяются согласованность с нульарной операцией.
Пусть А и В Ф-модели и дано отображение ц:А В. Если ф п-местное отношение в Ф, то согласованность ци ф означает, что имеет место импликация ф(аи ... ,ап) = 0«,... , ). Отображение ц : А В есть гомоморфизм Ф-моделей, если имеет место согласованность /І со всеми ф Є Ф. Если всегда выполняется строгая согласованность, то /І : Л — В - строгий гомоморфизм моделей. Гомоморфизм алгебр, рассматриваемых как модели, всегда является строгим.
Пусть А -алгебра и р эквивалентность на множестве А. Если ш n-арная операция в ft, то говорят, что р и со согласованы, если для любых двух кортежей, для которых выполняется CLipa -, г = 1,...,п, выполняется также (ai... апш)р{а[... а псо). Эквивалентность р называется конгруэнцией ft-алгебры А, если р согласована с каждой операцией из ft. Если р - конгруэнция, то все операции набора ft естественно реализуются и на фактор-множестве А/р. ft-алгебра А/р, которая называется фактор алгеброй алгебры А по конгруэнции р. При этом естественное отображение г : А - А/р есть естественный гомоморфизм - эпиморфизм алгебр.
Онтологический каркас открытой информационной системы
В главе 2 было показано, что открытая информационная система представляет собой композицию интероперабельных структур, получаемых в результате фильтрации сети совместимых функциональных блоков A-деревьями требований и ограничений. В свою очередь сеть совместимых компонентов строится на основе отображений элементарных свойств блоков, привязанных к точкам доступа на множество обобщенных интерфейсов. Согласно известному принципу построения открытых информационных систем, любые свойства входящих в ее состав блоков должны быть стандартизированы, то есть должен существовать общедоступный документ, регламентирующий:
одиночные параметры или систему параметров, на основе которой формируется система элементарных свойств, ассоциированных с точками доступа блоков;
система доменных ограничений специфицированных параметров;
режимы функционирования, определяемые доменными ограничениями;
способ интерпретации возможных значений одиночных параметров или системы параметров.
Расширим введенный в [62] список целей, достижимых посредством профилей ИС, определяющих комбинации базовых стандартов ИТ:
1. Выявление конкретных классов, подмножеств, факультативных возможностей и параметров базовых стандартов для обеспечения взаимодействия программных и/или аппаратных компонентов в пределах одной системы или взаимодействия нескольких систем между собой, а также для связи отдельных компонент программно-аппаратных систем, называемых далее сервисами, с автоматизируемыми и неавтоматизируемыми процессами предметной области.
2. Обеспечение совместимости компонент, используемых в реальной прикладной системе, в соответствии с требованиями базовых стандартов.
3. Выявление комбинаций базовых стандартов в проектах ИС, существенных для пользователей систем, для поставщиков программных и технических средств, а также для широкого класса организаций – потребителей ИС.
4. Унификация при разработке тестов соответствия ИС или их компонентов требованиям профиля.
В общем случае под профилем информационной системы будем понимать тройку множеств [3,6]:
На верхнем уровне расположен концепт Document, от которого наследуются все спецификации, стандарты. Все документы сгруппированы по двум уровням: уровень классификаторов, эталонных документов и уровень прикладных документов.
На первом уровне выделены концепты Classifier, Reference Model Classifier, Interoperability Model Classifier. Они образуют основу таксономии остальных нормативных документов. Заранее стоит отметить, что предлагаемая модель расширяема, т.е. может быть добавлено произвольное число классификаторов каждой группы и, в том числе, допускается добавление новых групп без серьезных изменений структуры онтологии.
На втором уровне вводится группа концептов и атомарных ролей, формализующих множество прикладных документов. Концепт AppDocument определяет все множество документов. Наследуемый Interface Document выделяет только такие документы, которые регламентируют поведения каждого интерфейса. Для каждого документа предусмотрена модульная структура, задаваемая концептом Interface Document Part, каждый модуль может содержать некоторое количество логических групп (наборов) параметров ParameterSet, включающих отдельные параметры Parameter. Как только части документа классифицируют хотя бы по одному признаку, они становится Classified Document Part.
Параметры, регламентируемые в нормативной документации, имеют определенную область значений, задаваемую доменом, который описывается концептом Domain Mode. При описании домена, задается базовый системный тип System Data Type определяющий значения параметров, а также ограничения Restriction , описываемые множествами Set и/или перечислениями Enumeration. Для одного параметра может быть определено несколько экземпляров Domain Mode, задающих различные области их определения. Это необходимо для гибкости формирования стандартизированных профилей ИС.
Граничный концепт Interface Profile используется для формирования выборки параметров нормативных документов и режима их использования. С этим концептом непосредственно связаны многочисленные концепты Interface (Интерфейс) и их разновидности, которые моделируют вход/выход и способы взаимодействия с системой. В зависимости от типа системы интерфейсы определяются форматами и структурой передаваемых данных, а также поддерживающими их средствами доступа. [7]
На уровне прикладной предметной области можно говорить о существовании интерфейсов типа "процесс-процесс"и "процесс-сервис". Интерфейс отдельного процесса позволяет принимать информационные потоки 4х видов: входной, выходной, поток контроля, поток механизм. В общем случае, один и тот же информационный поток может быть отнесен сразу к нескольким видам, причем это справедливо как для одного, так и для нескольких процессов:
"выход-вход
"выход-контроль
"выход-механизм".
, что определяется спецификой выбранного подхода к описанию бизнес-процессов IDEF0.
На рис. 4.5 показан слой процессов прикладных областей (бизнес-процессов) онтологического каркаса.
Концепт SubjectArea определяет предметную область, включающую бизнес-процессы Process, часть которых может быть автоматизирована AutProcess. Все процессы, согласно спецификации IDEF0 имеют несколько точек входа для информационных потоков: вход, выход, контроль и механизм. Для автоматизированных процессов значение имеют только потоки типа вход и выход, поскольку они выполняются в контексте более общих бизнес-процессов, для которых известны все потоки. Эти точки описываются концептами InputInterface, OutputInterface, Control, Mechanism.
Для связи интерфейсов бизнес-процессов с их профилем вводится атомарная роль hasInterfaceProfile. Особенности внутреннего устройства бизнес-процессов выходят за рамки каркаса и могут быть описаны дополнительными средствами, либо текущая онтология может быть дополнена простыми и сложными концептами и ролями, формализующими одну из существующих нотаций, предназначенных для этих целей [3].
Следующий уровень онтологии охватывает множество информационных систем с их интерфейсами, причем любая ИС рассматривается с позиций сервисно-ориентированного подхода. Это означает, что для формализации ИС, она должна быть представлена совокупностью отдельных сервисов, каждый из которых обладает своими интерфейсами, позволяющими принять/передать информационные потоки, обладающие структурой и форматом, регламентирую-мыми соответствующими профилями.
На рис. 4.6 показан слой сервисов поддержки автоматизируемых процессов.
В онтологии может быть зарегистрирована информационная система Information System, которая состоит из сервисов AppService, имеющих три основные группы интерфейсов:
системный (System Interface),
пользовательский (User Interface),
с платформой (Platform Interface). Как и в случае интерфейсов бизнес-процессов, эти интерфейсы имеют свой профиль, с которым связаны посредством атомарной роли hasProfileInterface
Технология построения открытых исследовательских пространств
Открытое виртуальное исследовательское пространство (ОВИП) представляет собой программно-аппаратный комплекс, ориентированный на автоматизацию исследовательских процессов в научных, образовательных и промышленных сферах деятельности государства, функционирующий в разнородной распределенной вычислительной среде и удовлетворяющий свойствам открытых систем. Удовлетворение свойствам открытости означает, что ОВИП должен обладать механизмами масштабирования, интеро-перабильности, кроссплатформенности.
При реализации физической модели ОВИП сделаны допущения:
1. Представляет собой систему интеграции процессов:
объединения и управления разнородными ПАК, ориентированными на процессы исследования;
формирования профилей виртуальных лабораторий;
тестирования виртуальных лабораторий на переносимость;
моделирования загрузки виртуальных лабораторий, как единого информационного ресурса;
коммуникации;
электронного документооборота.
2. Представляет собой масштабируемую систему.
3. Обладает механизмами масштабирования по пользователям и виртуальным лабораториям.
4. Существует 3 базовые группы пользователей: наука, образование, бизнес, остальные группы являются подгруппами базовых групп.
5. Обладает механизмами масштабирования по типам ВЛ и по количеству однотипных ВЛ.
6. Независимо от аппаратной платформы.
7. Независимо от программной платформы.
Задачи, решаемые с помощью ОВИП:
1. Классификация и настройка исследовательских систем для включения в единое информационное пространство.
2. Интеграция исследовательских систем в единое информационное пространство.
3. Управление исследовательскими системами как единым информационным ресурсом.
4. Автоматизация проектирования профилей виртуальных лабораторий.
5. Автоматизация процессов обмена исследовательской информацией.
АРХИТЕКТУРНЫЕ РЕШЕНИЯ ПО ОВИП
На физическом уровне ОВИП представляет собой 7 групп ПАК, взаимодействующих в среде Интернет рис. 5.23 терминалы управления; исследовательские системы; порталы нормативной документации; порталы ИТ – спецификаций и стандартов открытых систем; системы электронного документооборота; система обмена исследовательской информацией; система управления ОВИП. [24]
Система управления ОВИП 5.24 состоит из следующих блоков:
1. Блок управления.
2. Блок моделирования и классификации компонент.
3. Блок настройки компонент.
4. Блок построения профиля компонент.
5. Блок конфигурирования компонент.
6. Блок моделирования процесса загрузки компонент.
7. Блок управления загрузкой компонент.
Блок 1 обеспечивает формирование управляющих страниц, передачу их на терминалы, представление данных пользователю и выполнение запросов, а также отвечает за управление работой всего комплекса. Блок 2 предназначен для определения принадлежности включаемой компоненты к определенной группе, собирает и систематизирует данные, которые могут быть получены в процессе работы компоненты. Блок 3 реализует функцию включения компоненты в систему и настройки компоненты. Для этого необходимо описать интерфейсы работы компонента, сгенерировать сервисные файлы для описания функциональности компоненты и зарегистрировать компоненту. Задачей блока 4 является анализ и подбор существующих стандартов и профилей открытых систем с целью построения профиля включаемой компоненты. Посредством этого блока система управления ОВИП взаимодействует с порталами нормативной документации, спецификаций и стандартов открытых систем. Блок 5 предназначен для формирования и последующей настройки сегментов комплекса из отдельных распределенных вычислительных узлов. Так же Блок 5 формирует расписание загрузки на основе поступающих заявок и результатов работы блока 6.
Блок 6 выполняет оптимальное планирование сегментов комплекса на основе имитационного моделирования. Использует данные о заявках из блока 5 и набор алгоритмов планирования, для обеспечения гибкости настройки модели. Блок 7 осуществляет распределение нагрузки на сегменты комплекса и непосредственно управляет поведением компонент. Оповещает пользователей о текущем состоянии работы компонент. Ядром системы управления ОВИП служит генератор виртуальных лабораторий, который представляет собой совокупность блоков 1, 6, 7.
Целью генератора виртуальных лабораторий является формирование структуры лабораторного ресурса, расписания его загрузки и управление экспериментами.
Блок управления ОВИП, представленный на рис. 5.25 предназначен для формирования пользовательского интерфейса взаимодействия с ОВИП. Сначала формируются группы страниц, для отображения в Web – браузере. Модуль 1.1 генерирует управляющие сигналы, которые передаются модулю 1.6. Управляющий сигнал содержит идентификатор запрашиваемой страницы в формате URL. Модуль 1.6 анализирует сигнал, преобразует его в формат запроса к базе данных и передает в метафайл 1.7, в которой содержатся метаданные, включающие:
идентификаторы серверных страниц, предназначенных для формирования наборов данных;
идентификаторы шаблонов страниц, предназначенные для форматирования данных.