2. Модели среды открытых информационных систем

2.1 Структура открытой информационной системы

 

Обобщенная структура любой ИС представляется состоящей из двух взаимодействующих частей (на рис. 2.1 обведены пунктирной линией) [1]:

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

– среды или системной части, обеспечивающей исполнение прикладных программ.

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

Эта модель учитывает тот факт, что всякая ИС может вступать во взаимосвязь со следующими сущностями «внешнего мира»:

– с пользователем (User – U), причем пользователем может быть как человек, так и прикладная программа;

– с внешней средой (External Environment – EE).

Взаимосвязь ОИС с «внешним миром» реализуется соответствующими интерфейсами:

– интерфейсом взаимодействия ОИС с пользователем (User Interface – UI);

– интерфейсом с внешней средой (External Environment Interface –EEI).

Можно выделить тесно связанные две группы вопросов стандартизации:

• стандарты интерфейсов взаимодействия прикладных программ со средой ИС (Application Program Interface – API);
• стандарты интерфейсов взаимодействия самой ИС с внешней для нее средой (Ex ternal Environment Interface – EEI).

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

Важным при рассмотрении интерфейса ОИС с внешней средой является то, что он определяет сопряжение ОИС и внешней среды при выполнении следующих групп функций:

• взаимосвязь с пользователем (User – U);
• представление и хранение данных (Information – I);
• коммуникации, в том числе телекоммуникации (Communication – C).

Рисунок 2.1 – Обобщенная структура информационной системы

 

• Эти две группы интерфейсов определяют спецификации внешнего

Спецификации внешних интерфейсов среды ИС и, как будет видно далее, спецификации интерфейсов взаимодействия между компонентами самой среды, – это точные описания всех необходимых функций, служб и форматов определенного интерфейса. Совокупность таких описаний составляет модель открытых систем (Reference model).

 

2.2 Архитектура открытых систем

 

Как отмечалось выше, понятие архитектуры обычно вводится как внешний взгляд на описываемый объект, безотносительно к его реализации.

В связи с этим нужно уточнить представление об архитектуре систем и средств, как внешнем их описании (reference model) с точки зрения того, кто ими пользуется. Архитектура открытой системы, таким образом, оказывается иерархическим описанием ее внешнего облика и каждого компонента с точки зрения:

• пользователя (пользовательский интерфейс),
• проектировщика системы (среда проектирования),
• прикладного программиста (системы и инструментальные средства/среды про граммирования),
• системного программиста (архитектура ЭВМ),
• разработчика аппаратуры (интерфейсы оборудования).

 

Предлагаемый взгляд на архитектуру открытых систем вытекает из указанной выше необходимости комплексной реализации общих свойств открытости и является расширением принятого понятия об архитектуре (например, об архитектуре ЭВМ).

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

Уровень среды для конечного пользователя (user environment) характеризуется входными и выходными описаниями (генераторы форм и отчетов), языками проектирования информационной модели предметной области (языки 4GL), функциями утилит и библиотечных программ и прикладным уровнем среды коммуникаций, когда требуются услуги дистанционного обмена информацией. На этом же уровне определена среда (инструментарий) прикладного программирования (application environment): языки и системы программирования, командные языки (оболочки операционных систем), языки за просов СУБД, уровни сессий и представительный среды коммуникаций.

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

На уровне оборудования легко видеть привычные для разработчиков ЭВМ составляющие архитектуры аппаратных средств:

• система команд процессора (процессоров),
• организация памяти,
• организация ввода-вывода и т.д., а также физическую реализацию в виде:
• системных шин,
• шин массовой памяти,
• интерфейсов периферийных устройств,
• уровня передачи данных,
• физического уровня среды хранения.

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

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

Стандарты интерфейсов этих компонент (де-факто или принятые официально) определяют лицо массовых продуктов на рынке. Область распространения этих стандартов являются предметом согласования интересов разных групп участников процесса информатизации – пользователей, проектировщиков систем, поставщиков программных продуктов и поставщиков оборудования.

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

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

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

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

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

 

 

Таблица 2.1 – Детализация уровней модели среды открытых информационных систем

Иерархия представ- ления архитектуры системы обработки данных	Компоненты системы обработки данных
	Интерфейсы	Средства обработки данных	Представление и хранение данных	Коммуника- ции
Среда для конечного пользователя и инструментарий	Генераторы форм и отчетов	Утилиты и библиотеки	Языки программирова- ния 4GL	Прикладной уровень OSI
Иерархия представ- ления архитектуры системы обработки данных прикладного программиста	Интерфейсы	Средства обработки данных	Представление и хранение данных	Коммуника- ции
	Языки программные и командные (оболочки)	Прикладные программы	Языки запросов СУБД	Уровни сес- сий и пред- ставитель- ный OSI
Операционная  система	Средства оконного интерфейса	Верхний уро- вень ОС (организация процесса обработки)	Средства доступа к среде хранения	Транспорт- ный уровень OSI
	Драйверы	Ядро операци- онной системы	Файловая система	Сетевой уровень OSI
Оборудование	Системные ин- терфейсы (в т.ч. организация ввода-вывода)	Процессоры (система команд)	Организация памя- ти	Уровень передачи данных OSI
	Периферийные устройства	Системная шина	Шины (интерфейс) массовой памяти	Физический уровень OSI.

 

В последние годы активно развивались два направления идеологии, концепции и системы стандартов открытых систем:

• направление открытых вычислительных систем (open computing systems OCS), обеспечивающее возможность относительно простого и эффективного по трудоёмкости переноса апробированных программных средств и информации баз данных на различные типы аппаратных платформ за счет стандартизации процессов и интерфейсов взаимодействия прикладных программ с операционными системами компьютеров;
• направление взаимосвязи открытых систем (open system interconnection – OSI), унифицирующее структуру, процессы и интерфейсы для обеспечения совместимости методов и средств обмена данными между разнотипными удаленными компьютерами, а также поддерживающее возможность предварительного выбора типов и ресурсов компьютеров в соответствии с потребностями ИС для решения конкретных прикладных задач.

 

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

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

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

 

2.3 Моделирование среды открытых систем

 

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

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

 

Референсная модель (OSI/ISO)

 

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

Когда речь заходит о моделях открытых систем, обычно упоминают известную референсную модель OSI/RM (Open System Interconnection Reference Model) или в русском варианте, «модель взаимосвязи открытых систем» ВОС. Эта модель берет свое начало из сетевой архитектуры SNA (System Network Architecture), предложенной IBM в 1974 году. Эта многоуровневая архитектура обеспечивала взаимодействие типа «терминал- терминал», «компьютер-компьютер» по глобальным связям. Нижние уровни архитектуры были реализованы специализированными аппаратными средствами, наиболее важным из которых являлся процессор телеобработки. Функции верхних уровней SNA выполнялись программными модулями. Один из них составлял основу программного обеспечения процессора телеобработки, другие входили в состав стандартной операционной системы.

Модель OSI/RM разработана международной организацией по стандартизации ISO. Ее описание приведено в документах, имеющих индекс ISO 7498, а также в рекомендации X.200 организации ITU-T (ранее, до 1994 г., называвшейся CCITT). Оба документа являются эквивалентными с технической точки зрения и имеют статус формального междуна- родного стандарта.

OSI/RM предназначена для определения общей основы процесса стандартизации в области взаимосвязи систем, обеспечивающей целостность и взаимную согласованность стандартов. Разработанные на этой основе стандарты позволяют реализовывать унифицированные средства обмена данными между системами, удовлетворяющие требованиям, определенным в модели OSI/RM. Системы, взаимодействующие посредством такого рода стандартных процедур обмена данными, называются «открытыми системами», а реализуемая ими взаимосвязь – «взаимосвязью открытых систем».

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

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

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

Рисунок 2.2 – Модель взаимосвязи открытых систем

 

Модель MUSIC была предложена Центральным Агентством по вычислительной технике и телекоммуникации (CCTA) Великобритании (рис. 2.3).

Рисунок 2.3 – Модель MUSIC

 

 

MUSIC – это акроним от английских названий основных элементов модели:

M – Management;

U – User interface;

S – Service interface for programs;

I – Information and data formats;

C – Communications interfaces.

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

 

Модель MIC

 

Модель открытой системы, разработанная AFUU (Французская Ассоциация пользователей UNIX и открытых систем) и AFNOR (Французская Ассоциация стандартизации), названа MIC (Model for Interactions between Components) – модель взаимодействия между компонентами, авторы также называют ее конвергентой моделью [2] [23].

Эта модель представляет собой попытку объединить различные подходы к классификации компонент среды (табл. 2.2).

Модель строится в виде матрицы 7´4, столбцы которой соответствуют видам взаимодействия (обслуживания) в системе: взаимодействие с пользователем, системные средства, доступ к данным, коммуникационные средства. Легко видеть, что столбцы этой матрицы в точности соответствуют разбиению, предложенному в модели MUSIC (см. раздел 2.3.1.), за исключением отсутствующего элемента M (Management).

Строки матрицы соответствуют уровням обслуживания в рамках каждого типа взаимодействия от физического уровня до уровня связи с прикладной программой (или пользователем). Этот тип классификации соответствует принципу разбиения на уровни, принятому в коммуникационной модели OSI. Поэтому для варианта, использующего спецификации OSI для коммуникационных взаимодействий, столбец коммуникаций в точности соответствует модели OSI. Однако такое разбиение в настоящее время можно считать достаточно условным, поскольку на основе существующих стандартов далеко не все элементы допускают четкое разбиение на семь уровней (рис. 2.4). Так, даже коммуникационный элемент, реализованный на основе спецификаций TCP/IP, будет иметь другое разбиение.

 

Наименование	Область пользователя	Область систем и процессов	Информацион- ная область	Коммуникаци- онная область
Определения	Спецификация интерфейса пользователя	Спецификация процессов	Данные концеп- туального характера	Спецификации коммуникаций
Инструментарий высокого уровня	Объектное кодирование (символы)	Язык команд и программирова- ния	Язык запросов	Сеансовый и представитель- ский уровни модели OSI/RM
Системы высокого уровня	Многоокон- ность	Система высокого уровня	Доступ к данным	Транспортный уровень модели OSI/RM
Система низкого уровня	Драйверы	Ядро системы	Файловые системы	Сетевой уровень модели OSI/RM
Исполнитель- ные устройства высокого уровня	Интерфейсы	Центральный процессор	Память	Канальный уровень модели OSI/RM
Исполнитель- ные устройства низкого уровня	Периферия	Шины	Шины и внеш- ние накопители большой емкости	Физический уровень модели OSI/RM

Рисунок 2.4 – Модель MIC

 

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

 

Эталонная модель OSE/RM

 

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

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

Комитетом IEEE POSIX 1003.0 была предложена эталонная модель среды открытых информационных систем OSE/RM (Open Systems Environment/Reference Model).

В целом функциональное обслуживание представлено следующими видами услуг среды ОИС:

• услуги, реализуемые операционной системой;
• услуги интерфейса «человек-машина»;
• услуги административного управления данными;
• услуги обмена данными;
• услуги программной инженерии;
• услуги компьютерной графики;
• сетевые услуги.

Кроме перечисленных выше основных видов услуг, существуют дополнительные, встроенные во все основные услуги: защиты информации, административного управления, а также набор инструментальных средств. Ниже приведено краткое описание каждого вида услуг.

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

 

• Сетевые услуги создают для распределенных прикладных программ возможности и механизмы доступа к данным и взаимодействия между ними в неоднородной сетевой среде.
• Услуги защиты информации предназначены для обеспечения защищенного распространения информации и защиты вычислительной инфраструктуры от несанкциониро ванного доступа.
• Услуги административного управления – неотъемлемая часть любой операции, выполняемой в функциональной среде открытых систем. Они обеспечивают механизмы контроля и управления для операций, осуществляемых отдельными прикладными программами в базах данных, системах, сетях, а также средства взаимодействия пользователя с этими компонентами.

В простейшей форме эталонная модель OSE/RM иллюстрирует достаточно прямолинейные взаимоотношения пользователь-поставщик: прикладное программное обеспечение является пользователем предоставляемых услуг, а объекты прикладной платформы/внешней среды – поставщиком услуг. API и EEI определяют обеспечиваемые услуги.

Следует отметить, что помимо выше описанных, существуют и другие модели. Среди них можно отметить ряд специальных, т. е. проблемно ориентированных моделей. В частности, предлагаемая ISO модель ODP (Open Distributed Processing) – Открытая Распределенная Обработка – ориентирована, как следует из названия, на распределенную обработку в различных вычислительных сетях. Известны также модели CIM, EDI, Data Management DISC и др., описание которых можно найти в различных публикациях по проблемам открытых операционных систем.

 

Обобщенная модель среды открытых систем

 

Как уже отмечалось выше, OSE/RM – не единственная модель, используемая в качестве методологической основы стандартизации компонентов и интерфейсов среды открытых систем. На основе анализа и обобщения известных общих моделей (в том числе, MUSIC, MIC и OSI) модель среды ИС можно представить в виде матрицы типов компонентов этой среды, включающей три уровня, и четыре функциональные группы каждый (рис. 2.6).

Уровни описания в предлагаемой модели вместе с их подуровнями:

• компоненты служб и сервисов, предлагаемых средой для функционирования приложений, такие, например, как оконные оболочки, утилиты, системы программирования и системы управления базами данных;
• компоненты операционных систем;
• аппаратура: функциональные блоки и модули средств вычислительной техники и передачи данных (которые, например, видит системный интегратор при составлении спецификаций на оборудование ИС).

 

Функциональные группы компонентов в предлагаемой модели составляют:

• компоненты, обслуживающие интерфейс с пользователем (User – «U»);
• компоненты, обеспечивающие системные функции среды по организации про- цессов обработки данных (System – «S»);
• компоненты, обеспечивающие представление и хранение данных (Information – «I»);
• компоненты среды телекоммуникаций (Communication – «C»).

Модель предполагает, что взаимодействие между средой ОИС и внешней средой осуществляется с помощью трех типов интерфейсов (U, I и C).

Составные части ОИС разделены интерфейсом взаимодействия прикладных программ со средой ОИС, называемым интерфейсом прикладного программирования API. В отличие от интерфейса ОИС с внешней средой, этот (внутренний) интерфейс определяет сопряжение двух взаимодействующих объектов (функциональной части и среды ОИС) при выполнении функций не только групп U, I и С, но и функций среды по организации процессов обработки данных (System – S).

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

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

• средства работы конечного пользователя с текстами и отчетными формами (текстовые редакторы, генераторы форм и отчетов, пакеты деловой графики и т.д.);
• языки и системы программирования, включаемые в целевые ИС для трансляции на месте новых версий фрагментов приложений;
• средства внесения новых или изменения существующих данных в информационной базе ИС;
• средства прикладного уровня эталонной модели взаимосвязи открытых систем (OSI/RM) для тех случаев, когда требуется дистанционный обмен информацией, (например, электронная почта или передача файлов).

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

• оболочки операционной системы, формирующие пользовательский интерфейс и командные языки;
• утилиты системных сервисов, библиотечные программы общего пользования; системы управления базами данных с характерными для них языками, в частности, со стандартным языком SQL;
• средства уровня представлений и уровня сессий эталонной модели OSI/RM.

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

С другой стороны, эти компоненты или системы работают в среде операционной системы, составляющей второй уровень предлагаемой модели. На этом уровне присутствуют:

• средства оконного интерфейса, имеющиеся в составе операционной системы;
• средства организации процессов обработки данных;
• средства доступа к среде хранения данных;
• средства транспортного уровня эталонной модели ВОС.

Второй подуровень уровня операционной системы включает традиционные сис темные программы:

• драйверы ввода/вывода;
• ядро операционной системы;
• файловую систему;
• средства сетевого уровня эталонной модели ВОС.

Выбор стандартов этого уровня определяется типами аппаратно-программных платформ:  UNIX, Windows NT и т.д.

Нижний уровень предлагаемой модели среды ИС образуют спецификации аппаратуры. Здесь легко увидеть привычные для разработчиков ЭВМ и системных программистов характеристики архитектуры технических средств:

• организация ввода/вывода;
• система команд и управление прерываниями;
• организация памяти;
• канальный уровень (звено данных) эталонной модели ВОС.

Наконец, замыкают эту модель аппаратные интерфейсы:

• интерфейсы периферийных устройств;
• системная шина;
• интерфейс (шины) массовой памяти;
• физический уровень эталонной модели ВОС.

 

Рисунок 2.5 – Концептуальная модель OSE/RM

	U	S	I	C
Компоненты услуг среды	Текстовые про- цессоры, генера- торы форм отче- тов, и т.д.	Языки програм- мирования	Средства проектирования и ведения баз данных	Прикладной уровень ВОС
	Оболочки ОС, командные языки	Утилиты, библиотеки программ	СУБД	Уровень представлений и сессий ВОС
Компоненты операционной системы	Оконный интерфейс	Организация процессов	Доступ к среде хранения	Транспортный уровень ВОС
	Драйверы ввода-вывода	Ядро ОС	Файловая система	Сетевой уровень ВОС
Аппаратура	Организация ввода-вывода	Система команд, организация пре рываний, и т.д.	Организация памяти	Канальный уровень ВОС
	Интерфейс периферийных устройств	Системная шина	Шина массовой памяти	Физический уровень ВОС

Рисунок 2.6 – Модель среды информационной системы, поддерживающей технологии обработки данных в одномашинной конфигурации

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

Для сложных и ответственных ИС важно предусмотреть наличие в модели следующих средств:

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

Эти три группы функций могут относиться к разным функциональным группам компонентов, указанным выше, и поэтому они представляются третьим измерением предлагаемой модели.

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

 

Цели создания эталонной модели OSE/RM

 

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

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

 

 

 

Переносимость прикладного программного обеспечения и повторное его использование

 

Исчерпывающий и согласующийся набор спецификаций OSE/RM на уровне исходного кода необходим для переносимости программного обеспечения между реализациями прикладной платформы. Это дает возможность организациям защитить свои вложения в существующее программное обеспечение, исключив затраты на его повторную разработку.

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

 

Переносимость данных

 

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

 

Взаимодействие приложений

 

Стандарты и OSE/RM должны определить спецификации по коммуникационным услугам и форматам, которые позволят двум логическим объектам программного обеспечения обмениваться данными и совместно их использовать. Эти спецификации должны быть предусмотрены для тех ситуаций, в которых взаимодействующие логические объекты функционируют на одной и той же или различных прикладных платформах.

 

Взаимодействие с точки зрения административного управления и защиты информации

 

Спецификации OSE/RM по прикладным платформам должны обеспечить возможность взаимодействия для целей административного управления и защиты информации между различными реализациями платформ.

 

 

Мобильность пользователей

 

Стандарты и OSE/RM должны позволить физическим лицам взаимодействовать с широким набором реализаций прикладных платформ без переобучения. Вариации в методах взаимодействия, которые не основаны на функциональных различиях или специальных требованиях, ухудшают производительность и должны исключаться общими спецификациями интерфейса пользователя.

 

Масштабируемость прикладной платформы

 

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

 

Масштабируемость распределенных систем

 

Стандарты OSE/RM должны определяться таким образом, чтобы скрыть механизм реализации услуг. Сложность реализации должна быть скрыта от пользователя услуг за интерфейсом услуг и, следовательно, должна быть прозрачна для пользователя. С точки зрения прикладного программного обеспечения это снижает объемы и стоимость прикладных программ и служит основой для миграций технологии.