Пример компоновки функционального профиля
Разработка и применение профилей являются неотъемлемой частью процессов проектирования, разработки, внедрения и сопровождения ИС. Профили характеризуют каждую конкретную ИС на всех стадиях ее жизненного цикла, задавая гармоничный набор базовых стандартов, которым должна соответствовать ИС и ее компоненты. Профиль такой системы не является статичным, он развивается и конкретизируется в процессе установления и специфицирования требований, отражения их в ТЗ, проектирования ИС и оформляется в составе документации проекта системы. При формировании и применении профилей конкретных ИС можно использовать международные, национальные стандарты и ведомственные нормативные документы, а также стандарты "де-факто" при условии доступности соответствующих им спецификаций ("общедоступные спецификации"). Для корректного применения описание профиля обязательно должно содержать [15]:
• определение целей использования данного профиля;
• точное перечисление функций объекта или процесса стандартизации, определяемого данным профилем;
• формализованные сценарии применения базовых стандартов и спецификаций, включенных в данный профиль;
• сводку требований к ИС или ее компонентам, определяющих их соответствие профилю, и требований к методам тестирования соответствия;
• нормативные ссылки на конкретный набор стандартов и других нормативных документов, составляющих профиль, с точным указанием применяемых редакций и ограничений, способных повлиять на достижение корректного взаимодействия объектов стандартизации при использовании данного профиля;
• информационные ссылки на все исходные документы.
На стадиях реализации жизненного цикла ИС выбираются, компонуются и применяются следующие основные функциональные профили: среды распределенной ИС, прикладного программного обеспечения, защиты информации в ИС, инструментальных средств, встроенных в ИС (рис. 7.7).
Прикладное программное обеспечение конкретной ИС практически всегда является проблемно-ориентированным и определяет основные функции системы. Функциональные профили ИС должны включать в себя гармонизированные базовые стандарты.
При использовании указанных функциональных профилей ИС следует еще иметь в виду согласование (гармонизацию) этих профилей между собой.
Рис. 7.7. Структура реализации открытых систем с использованием стандартных профилей[1]
Необходимость такого согласования возникает, в частности, при использовании стандартизованных API-интерфейсов, в том числе интерфейсов приложений со средой их функционирования, интерфейсов приложений со средствами защиты информации. При согласовании функциональных профилей ППО возможны также уточнения профиля среды ИС и профиля встраиваемых инструментальных средств создания, сопровождения и развития ППО.
Наиболее выпукло проблемы формирования функциональных профилей можно показать на примере открытой распределенной информационной системы с архитектурой "клиент-сервер". Рассмотрим общие подходы к построению профилей таких систем [15].
Профиль среды распределенной ИС должен определять ее архитектуру в соответствии с выбранной моделью распределенной обработки данных, например, Distributed Computing Environment (DCE) или Common Object Request Broker Architecture (CORBA).
В первом случае модель определяется стандартами консорциума OSF, в частности, используется механизм удаленного вызова процедур (Remote Procedure Call – RPC) с учетом стандартов "де-факто", которые специфицируют применяемые мониторы транзакций (например, монитор транзакций Tuxedo) [14].
Во втором случае модель определяется стандартами консорциума OMG, в частности спецификацией брокера объектных запросов (Object Request Broker – ORB). Стандарты интерфейсов API приложений со средой ИС должны быть определены по функциональным областям профилей ИС. Декомпозиция структуры среды функционирования ИС на составные части, выполняемая на стадии эскизного проектирования, позволяет детализировать профиль среды ИС по функциональным областям эталонной модели OSE/RM:
• графического пользовательского интерфейса (MOTIF консорциума OSF или стандарт X Window IEEE);
• реляционных или объектно-ориентированных СУБД (например, стандарт языка SQL-92 и спецификации доступа к разным базам данных);
• операционных систем с учетом сетевых функций, выполняемых на уровне операционной системы (например, набора стандартов POSIX – ISO и IEEE);
• телекоммуникационной среды в части услуг и сервисов прикладного уровня: электронной почты (по рекомендациям ITU-T Х.400, Х.500), доступа к удаленным базам данных RDA (по стандарту ISO 9594-1.2), передачи файлов, доступа к файлам и управления файлами (по стандарту ISO 10607 – 1, 2, 3, 4, 5, 6).
Профиль среды распределенной ИС должен включать в себя:
• стандарты протоколов транспортного уровня (по ISO/IEC OSI или стандарт "де-факто" протокола TCP/IP);
• стандарты локальных сетей (например, стандарт Ethernet IEEE 802.3 или стандарт Fast Ethernet IEEE 802.3 u);
• стандарты средств сопряжения проектируемой ИС с сетями передачи данных общего назначения (например, по рекомендациям ITU-T: Х.25, Х.З, Х.29 и др.).
Профиль и выбор аппаратных платформ ИС связан с определением их параметров: вычислительной мощности серверов и рабочих станций в соответствии с проектными решениями по разделению функций между клиентами и серверами; степени масштабируемости аппаратных платформ; надежности. Функциональный профиль
ИС содержит стандарты, определяющие параметры технических средств и способы их измерения (например, стандартные тесты измерения производительности).
Профиль защиты информации в ИС должен обеспечивать реализацию политики информационной безопасности, разрабатываемой в соответствии с требуемой категорией безопасности и критериями безопасности, заданными в техническом задании на систему [7]. Построение профиля защиты информации в распределенных системах "клиент-сервер" методически связано с точным определением компонентов системы, ответственных за те или иные функции, сервисы и услуги, и средств защиты информации, встроенных в эти компоненты. В области защиты информации должны выполняться следующие функции;
• защита, реализуемая операционной системой;
• защита от несанкционированного доступа на уровне программного обеспечения промежуточного слоя;
• управление данными, реализуемое СУБД;
• защита программных средств, в том числе средства защиты от вирусов;
• защита информации при обмене данными в распределенных системах, включая криптографические функции;
• администрирование средств безопасности.
Основополагающим документом в области защиты информации в распределенных системах являются рекомендации Х.800, принятые МККТТ (сейчас ITU-T) в 1991 г. Подмножество указанных рекомендаций должно составлять профиль защиты информации в ИС с учетом распределения функций защиты информации по уровням концептуальной модели ИС и взаимосвязи функций и применяемых механизмов защиты информации. При использовании профиля защиты информации в ходе проектирования, разработки и сопровождения ИС целесообразно учитывать методические рекомендации, изложенные в интерпретации "Оранжевой книги" национального центра компьютерной безопасности США для сетевых конфигураций. Профиль защиты информации должен включать в себя указания на методы и средства обнаружения в применяемых аппаратных и программных средствах недекларированных возможностей ("закладок" и вирусов). Профиль должен также содержать указания на методы и средства резервного копирования информации и восстановления информации при отказах и сбоях аппаратуры системы.
Профиль инструментальных средств, встроенных в ИС, отображает решения по выбору методологии и технологии создания, сопровождения и развития конкретной ИС, описание которых должно быть выполнено на стадии эскизного проектирования системы. Состав встроенных инструментальных средств определяется на основании решений и нормативных документов об организации сопровождения и развития ИС. При этом должны быть учтены правила и порядок, регламентирующие внесение изменений в действующие системы. В области профиля инструментальных средств, встроенных в ИС, должны выполняться функции централизованного управления и администрирования, связанные:
• с контролем производительности и корректности функционирования системы в целом;
• преобразованием конфигурации ППО, тиражированием версий;
• управлением доступом пользователей к ресурсам системы и конфигурацией ресурсов;
• перенастройкой приложений в связи с изменениями прикладных функций ИС;
• настройкой пользовательских интерфейсов (генерацией экранных форм и отчетов);
• ведением баз данных системы;
• восстановлением работоспособности системы после сбоев и аварий.
Дополнительные ресурсы, необходимые для функционирования встроенных инструментальных средств (минимальный и рекомендуемый объем оперативной памяти, размеры требуемого пространства на дисковых накопителях и т.д.), учитываются в разделе проекта, относящемся к среде ИС. Выбор инструментальных средств, встроенных в ИС, производится в соответствии с требованиями профиля среды ИС. Ссылки на соответствующие стандарты, входящие в профиль среды, должны быть указаны и в профиле инструментальных средств, встроенных в ИС. В этом профиле также предусмотрены ссылки на требования к средствам тестирования, которые необходимы для процессов сопровождения и развития системы. К встроенным в ИС средствам тестирования относятся средства функционального контроля приложений, проверки интерфейсов, системного тестирования и диагностирования серверов (клиентов) при максимальной нагрузке.
Поясним сказанное ранее на конкретном примере [18]. Нужно построить профили основных функциональных компонент корпоративной ИТ компании, которая хотела бы обеспечить переносимость разрабатываемых ею SQL-приложений (как серверной, так и клиентских частей), написанных с использованием языков C+ + и SQL. Сетевая инфраструктура данной организации основана на использовании локальной сети FDDI (рис. 7.8).
Рис. 7.8. Пример корпоративной информационной технологии
Для обеспечения целей открытости корпоративная технология должна строиться из программных и аппаратных систем, поведение которых на своих интерфейсах соответствует стандартам. В частности, в данном случае задача состоит в том, чтобы построить два OSE-профиля, один из которых специфицирует требования к интерфейсам клиентских систем, другой – к интерфейсам сервера баз данных.
Обозначим для определенности профиль клиентской стороны системы (Client Side of System) как <PC>. Он будет включать в себя спецификации как минимум двух классов интерфейсов, а именно интерфейса API, определяющего взаимодействие клиентской системы с прикладной программой (Application Program), а также коммуникационного интерфейса, определяющего состав протоколов сетевого взаимодействия между клиентскими и серверными системами.
Коммуникационный интерфейс можно формировать, начиная с мощного протокола прикладного уровня RDA (ISO 9579), используемого, в частности, для реализации распределенных SQL-приложений с архитектурой "клиент-сервер" над стеком протоколов модели RM OSI. Для большей гибкости решения разобьем стек протоколов модели RM OSI на две группы протоколов: протоколы верхних трех уровней, которые обозначим OSI Stack (7-5), и протоколы транспортной системы, обеспечивающие транспортные услуги OSI в режиме с соединением.
Если обратиться к справочнику международных стандартизованных профилей, то можно обнаружить, что уже существует профиль, описывающий набор протоколов для реализации передачи данных по транспортному протоколу OSI через локальную сеть FDDI. Данный профиль имеет наименование <ТС54>. Он включает в себя ссылки на стандарт транспортного протокола OSI, стандарт протокола сетевого уровня (Х.25) вместе с дополнениями, адаптирующими этот протокол для использования в локальных сетях, а также ссылки на стандарты протоколов нижних уровней, определяющих функционирование сети FDDI. Профиль <ТС54> является типичным примером OSI-профиля, так как устанавливает только функции сетевого взаимодействия, определенные стандартными протоколами, разработанными в соответствии с моделью RM OSI.
Таким образом, описание коммуникационного интерфейса в профиле <РС> будет содержать ссылки на следующие спецификации: стандарт протокола DRA, стандарты протоколов верхних уровней модели RM OSI (OSI Stack (7-5)), профиль <ТС54>.
В состав спецификаций API необходимо включить стандарты языков <С+ + >и <SQL> (Std "C++" и Std "SQL" соответственно), а также интерфейс RDA, реализующий сервис протокола RDA для клиентских систем. Следовательно, описание интерфейса API в профиле <РС> содержит ссылки на следующие спецификации: Std "C++", Std "SQL", интерфейс RDA-клиента.
В профиль <РС> могут входить спецификации и других классов интерфейсов, например графического пользовательского интерфейса. Тогда в профиль <РС> пришлось бы включать такие ссылки, если бы одним из исходных требований к разрабатываемой системе было требование обеспечения легкости перевода пользователей с одной компьютерной платформы на другую.
Профиль серверной части (Server Side of System) обозначим как <PS>. Он будет содержать идентичный с профилем <РС> коммуникационный интерфейс (иначе клиентские и серверные системы не смогли бы взаимодействовать). Интерфейс API профиля <PS> будет почти идентичным соответствующему интерфейсу профиля <РС>, за исключением некоторых различий в программных интерфейсах для сервиса RDA в клиентской и сервисных системах.
Если в исходной постановке задачи имеется требование обеспечения переносимости хранимых данных, то в профиль <PS> следовало бы ввести ссылки на стандарты, определяющие форматы представления данных в долговременной памяти. Такие стандарты относятся к классу интерфейсов, называемых информационными.
В соответствии с введенными определениями, построенные в примере профили <РС> и <PS> относятся к OSE-профилям. С целью наглядного представления случаев применения и функциональности профилей используются специальные схемы (сценарии), на которых, как правило, определяются основные функциональные компоненты описываемой данным профилем технологии, их взаимосвязи, интерфейсы, распределение основных функций в системе и пр. Для профилей <РС> и <PS> таким сценарием может служить схема, показанная на рис. 7.9.
Рис. 7.9. Пример схемы (сценария) для наглядного представления случаев применения и функциональности профилей
Если же коммуникационная структура компании была бы построена на базе Intranet, то в этом случае следует перепроектировать профиль, заменив <Т54>, например, на профиль <Ti>, основанный на использовании следующих стандартов:
• RFC 1006 (IETF STD 35). ISO Transport Service on top the TCP;
• RFC 793 (IETF STD 7). Transmission Control Protocol (TCP);
• RFC 791 (IETF STD 5). Internet Protocol (IP);
• RFC 1390 (IETF STD 36). Transmission of IP and ARP over FDDI Networks;
• ISO 9314 FDDI LAN.
Основная идея построения новой транспортной системы <Ti> состоит в использовании протокола TS (RFC 1006), эмулирующего интерфейс протокола TP OSI над стеком протоколов TCP/IP, а также протокола (RFC 1390), обеспечивающего передачу IP-пакетов через сеть FDDI. Протокольная структура транспортной системы <Ti> представлена на рис. 7.10.
Рис. 7.10. Стек протоколов конечной системы, реализующей транспортный сервис ТР OSI над стеком протоколов TCP/IP и FDD I
Следует заметить, что профиль <Ti> относится к классу коммуникационных профилей. Однако по определению он не является OSI-профилем, так как содержит ссылки на стандарты, не входящие в состав стандартов модели OSI. Тем не менее с этой оговоркой этот профиль можно успешно применять при компоновке основного профиля.
Рассмотренный пример еще раз демонстрирует исключительную по важности роль профилей в реализации принципов открытых систем. Построение профиля на самых ранних стадиях создания программной или информационной системы и следование ему на всех дальнейших стадиях жизненного цикла системы позволяет пользователю (заказчику) составлять спецификацию на приобретаемые и разрабатываемые аппаратные и программные средства, как системные, так и прикладные, обеспечивать независимость от конкретного поставщика при создании и модернизации системы. Разработчики приложений, в свою очередь, следуя профилю, создают условия для повторного применения разработанных приложений при смене платформ, а поставщики средств вычислительной техники – для обновления продуктовой линейки и расширения рынка сбыта.
На основе профиля должны проводиться тестирование и сертификация приложений на соответствие требованиям открытости. Основу большинства применяемых в настоящее время профилей составляют стандарты серии POSIX. Общий их перечень состоит из более 45 наименований, перечень российских стандартов в области реализации открытых систем в настоящее время содержит около сотни наименований [4, 26].