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

Евгений Николаевич Филинов — зав. отделом, Александр Викторович Бойченко — старший научный сотрудник Института системного программирования РАН. Им можно написать по адресу boytchen@ispras.ru

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

Введение

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

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

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

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

В [1] «профили» определяются как подмножество и/или комбинации базовых стандартов информационных технологий, необходимые для реализации требуемых наборов функций. Для определения места и роли каждого базового стандарта в профиле требуется концептуальная модель. Такая модель, называемая Open System Environment/Reference Model (OSE/RM), предложена в [3]. Таким образом, придание конкретной ИС перечисленных свойств открытых систем реализуется с помощью разработки ее профиля. В соответствии с этим открытые системы определяются IEEE как системы, в которых реализован «исчерпывающий и согласованный набор базовых международных стандартов информационных технологий и профилей функциональных стандартов, которые специфицируют интерфейсы, службы и поддерживающие форматы [данных], чтобы обеспечить интероперабельность и мобильность приложений, данных и персонала».

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

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

Группы стандартов средств интеграции приложений в ИС уровня предприятия

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

Под средствами интеграции приложений уровня предприятия (Enterprise Application Integration — EAI) понимается комбинация процессов, программных средств, стандартов и аппаратуры, благодаря которой обеспечивается «бесшовная» интеграция приложений в пределах одной или нескольких ИС уровня предприятия, позволяющая им функционировать как единой системе. Хотя средства EAI, как правило, рассматриваются применительно к построению ИС для одного предприятия, в настоящее время они требуются и для интеграции ИС, принадлежащих нескольким предприятиям. Например, они нужны при создании систем класса business-to-business, когда необходимо обеспечить единые бизнес-транзакции, реализуемые цепочками приложений, которые выполняются в нескольких системах.

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

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

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

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

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

4. Интеграция платформ. Современные ИС уровня предприятия строятся на основе распределенной клиент-серверной архитектуры, в решениях последних лет — трехзвенной или многозвенной. С учетом гетерогенности аппаратно-программных платформ это определяет необходимость в средствах интеграции неоднородных платформ, предоставляемых их поставщиками, например, в средствах интеграции систем, базирующихся на Windows NT/Windows 2000 и Unix.

5. Интеграция компонентов в составе приложения. Модульная структура приложений — один из основных способов обеспечения открытости ИС. В последние пять-семь лет серьезное развитие получила компонентная разработка приложений, главной особенностью которой является создание унифицированных интерфейсов программных модулей. Компонентом считается программный модуль и его унифицированный интерфейс, посредством которого другие компоненты могут подключаться к нему и поддерживать взаимодействие с ним.

Потребность в разработке приложений, включающих в себя серверные и клиентские компоненты, привела к созданию интегрированных сред разработки и исполнения распределенных компонентов (Distributed Component Platform — DCP), поддерживающих сложившиеся де-факто стандарты компонентов. Среди этих стандартов известны: Component Object Model/Distributed Component Object Model (COM/DCOM) компании Microsoft, ее основной конкурент, Enterprise Java Beans (EJB) с протоколом Java RMI компании Sun Microsystems, спецификации компонентов в архитектуре CORBA, поддерживаемые консорциумом OMG, а также стандарты компонентной разработки Web-приложений, предложенные консорциумом World Wide Web Consortium.

Принципы построения и структура профиля ИС

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

Необходимость стандартизации интерфейсов и протоколов для области телекоммуникаций была осознана еще 20 лет назад. Здесь сложились подходы и методология, без которых было бы немыслимо построение сетей передачи данных, локальных и глобальных вычислительных сетей. Разработана семиуровневая эталонная модель взаимосвязи открытых систем — OSI/RM [2] и соответствующие ей функциональные стандарты. Однако то, как должны быть построены открытые системы, между которыми устанавливается взаимосвязь, модель OSI/RM не устанавливает.

Для этой цели служит эталонная модель среды открытых систем. Модель OSE/RM (см. рис. 1), принятая в качестве основы для предлагаемой методики, закреплена документами ISO/IEC [8].

Рис. 1. Эталонная модель ОИС (OSE/RM - Open System Environment)

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

Кроме того, определяются стандартизованные интерфейсы взаимодействия данной ИС с внешней средой — другими ИС и Internet и/или корпоративными сетями.

Спецификации функций компонентов ИС относят к четырем функциональным группам:

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

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

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

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

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

В качестве иллюстрации на рис. 2 и 3 приведены основные функции и функции защиты информации в модели среды распределенных вычислений (Distributed Computing Environment — DCE) [9].

На рис. 2 приведены следующие службы DCE:

  • RPC runtime - удаленный вызов процедур реализации протокола RPC поверх транспортных протоколов TCP/IP или UDP/IP;
  • DCE Threads - слой поддержки создания, администрирования и синхронизации "нитей" управления в выполняемом процессе;
  • DTS - распределенная служба времени;
  • DFS - распределенная файловая система;
  • CDS - служба каталога ячейки DCE;
  • GDS - служба глобального каталога DCE;
  • ATM I - интерфейс между приложениями и монитором транзакций (стандарт X/Open XA - часть модели распределенной обработки транзакций X/Open DTP).

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

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

Структура полного профиля ИС включает в себя следующие группы подпрофилей (профилей более низкого уровня).

1. Профиль среды ИС, в который входят:

  • профиль основных функций среды ИС, содержащий спецификации API-интерфейсов, функций ПО промежуточного слоя, СУБД, пользовательских интерфейсов, операционных систем и требований к аппаратным средствам, а также стеков протоколов телекоммуникационной среды;
  • профиль средств системного и сетевого администрирования;
  • профиль средств защиты информации;
  • профиль инструментальных средств, встроенных в ИС.

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

  • профили процессов жизненного цикла прикладного ПО ИС (стандарт ISO 12207 [4]);
  • профили обеспечения качества прикладных программных средств ИС;
  • профили инфраструктуры проекта данной ИС.

Формирование и применение профиля ИС

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

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

1. Разработка профиля среды приложений ИС.

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

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

1.3. На основе разработанной системотехнической структуры производится конкретизация концептуальной модели OSE/RM. Конкретизация модели заключается в иерархической декомпозиции по тем же смысловым принципам, которые заложены в модели OSE/RM верхнего уровня (рис. 1).

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

1.5. Наполнение конкретизированной модели OSE/RM базовыми стандартами информационных технологий путем выбора их из номенклатуры международных и национальных стандартов де-юре и де-факто с учетом требований (спецификаций), полученных на этапе 1.4.

1.6. Гармонизация базовых стандартов (в смысле требований ГОСТ Р ИСО/МЭК 10000), выбранных на предыдущей стадии и включаемых в профиль ИС, с формированием ограничительных спецификаций их обязательных и факультативных возможностей для обеспечения совместимости компонентов и обеспечения их непротиворечивости.

1.7. Уточнение при необходимости конкретизированной модели OSE/RM и параметров компонентов.

1.8. Разработка спецификаций интерфейсов и протоколов взаимодействия компонентов, которые не обеспечены базовыми стандартами, по возможности с использованием формальных языков спецификаций, таких как RSL, IDL, SDL, ADL [5].

1.9. Формирование требований соответствия профилю ИС и ссылок на соответствующие методы тестирования и тесты.

2. Разработка вспомогательного профиля ИС.

2.1. Разработка профиля жизненного цикла прикладного ПО ИС (стандарт ГОСТ Р ИСО/МЭК 12207-99 [4]). Для реализации этого этапа должна быть выполнена и документирована адаптация данного стандарта применительно к данной ИС.

2.2. Разработка профиля обеспечения качества прикладных программных средств ИС.

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

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

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

Для облегчения обеспечения взаимодействия приложений и прикладных подсистем ИС уровня предприятий (например, ERP) может оказаться целесообразным применить для структуризации приложений принципы, заложенные в модель OSE/RM. Пример такой структуризации приведен на рис. 4.

Заключение

Разработанная в ИСП РАН методика формирования и применения профилей ИС адресована заказчикам сложных ИС, проектировщикам, системным интеграторам. Нормативные требования к ИС могут быть предъявлены заказчиком и включены в раздел ТЗ «Требования к стандартизации».

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

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

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

Литература
  1. ГОСТ Р ИСО/МЭК ТО 10000-1-99. Информационная технология. Основы и технология функциональных стандартов. Часть 1. Основные положения и основы документирования
  2. ГОСТ Р ИСО/МЭК ТО 10000-2-99. Информационная технология. Основы и таксономия функциональных стандартов. Часть 2. Принципы и таксономия профилей ВОС
  3. ГОСТ Р ИСО/МЭК ТО 10000-3-99. Информационная технология. Основы и таксономия функциональных стандартов. Часть 3. Принципы и таксономия профилей среды открытых систем
  4. ГОСТ Р ИСО/МЭК 12207-99. Информационная технология. Процессы жизненного цикла программного обеспечения
  5. Филинов Е.Н. Архитектура и структура среды распределенной обработки данных, методы и средства формального описания cреды // Распределенная обработка информации. Труды VI международного семинара, Новосибирск. Сибирское отделение РАН. 1998
  6. Филинов Е.Н. Выбор и разработка концептуальной модели среды открытых систем // Открытые системы, № 6. 1995
  7. Липаев В.В., Филинов Е.Н. Мобильность программ и данных в открытых информационных системах, РФФИ. М., 1997
  8. ISO/IEC TR 14252:1996. Information Technology. Guide to the POSIX Open System Environment (OSE)
  9. OSF DCE. Release 1.2.2, 1998

Поделитесь материалом с коллегами и друзьями