Российские Электронные Библиотеки

Проблемы и методика формирования профилей открытых информационных систем

1. Введение

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

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

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

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

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

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

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

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

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

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

Потребность в средствах интеграции приложений уровня предприятия (Enterprise Application Integration – EAI) создала условия для бурно развивающегося рынка EAI-услуг. По оценке IDC объем этого сектора рынка уже в 2000 г. составлял 5 млрд. долл., а прогноз на 2005 г. составляет 21 млрд. долл.

Под средствами EAI понимается комбинация процессов, программных средств, стандартов и аппаратуры, благодаря которой обеспечивается “бесшовная” интеграция приложений в пределах одной ИС или двух и более ИС уровня предприятия, позволяющая им функционировать как единой системе. Хотя средства EAI, как правило, рассматриваются применительно к построению ИС для какого-либо одного предприятия, в настоящее время эти средства требуются и для интеграции ИС, принадлежащих нескольким предприятиям. Например, они нужны при создании систем класса B2B (Business-to-Business), когда необходимо обеспечить единые бизнес-транзакции в виде цепочек приложений, выполняемых в нескольких системах.

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

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

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

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

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

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

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

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

Согласно результатам опроса, проведенного корпорацией Cutter в 1999 г., среди компаний, разрабатывающих программное обеспечение ИС, более 60% уже применяют компонентный подход. Из них о применении модели COM / DCOM заявили 33% крупных компаний, EJB - 40%, CORBA - 18%, причем отмечено, что применение спецификаций компонентов в архитектуре CORBA растет.

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

3. Категории и виды профилей ИС

В зависимости от сферы распространения профилей ИС рассматриваются следующие их категории:

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

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

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

В зависимости от сферы распространения профилей ИС рассматриваются следующие их категории:

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

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

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

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

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

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

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

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

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

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

В качестве иллюстрации на рис. 2 и 3 приведены модель среды распределенных вычислений (Distributed Computing Environment) по основным функциям и функциям защиты информации [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. Среда распределенных вычислений DCE реализована большинством ведущих поставщиков программного обеспечения для распределенных систем. Она обеспечивает все услуги безопасности, необходимые для функционирования распределенных приложений, использующих механизм удаленного вызова процедур: услуги аутентификации, услуги управления доступом (авторизации), конфиденциальность данных, целостность данных, невозможность отказа от совершенных действий. Предлагаемая концептуальная модель представлена на рис. 3.

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

1. Профиль среды ИС, включающий в себя:

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

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

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

5.  Формирование и применение профиля ИС как органическая часть процессов жизненного цикла.

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

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

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

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

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

1.3. На основе разработанной системотехнической структуры и выбранной парадигмы организации распределенной системы производится конкретизация концептуальной модели OSE/RM. Конкретизация модели 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.

6.  Заключение

Разработанная в ИСП РАН методика формирования и применения профилей ИС адресована заказчикам сложных ИС, проектировщикам ИС, системным интеграторам.

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

Нормативные требования к ИС могут быть предъявлены заказчиком и включены в раздел ТЗ “Требования к стандартизации”.

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

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

Литература

  1. ГОСТ Р ИСО / МЭК ТО 10000-1-99. Информационная технология. Основы и технология функциональных стандартов. Часть 1. Основные положения и основы документирования.
  2. ГОСТ Р ИСО / МЭК ТО 10000-2-99. Информационная технология. Основы и таксономия функциональных стандартов. Часть 2. Принципы и таксономия профилей ВОС.
  3. ГОСТ Р ИСО / МЭК ТО 10000-3-99. Информационная технология. Основы и таксономия функциональных стандартов. Часть 3. Принципы и таксономия профилей среды открытых систем.
  4. ГОСТ Р ИСО / МЭК 12207-99. Информационная технология. Процессы жизненного цикла программного обеспечения.
  5. Е.Н.Филинов. Архитектура и структура среды распределенной обработки данных, методы и средства формального описания cреды // Распределенная обработка информации. Труды Шестого международного семинара. Новосибирск. Сибирское отделение РАН. 1998. с. 101-105.
  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 г.

  • Е.Н.Филинов, А.В.Бойченко
  • Институт системного программирования РАН
  • Статья в журнале "Директор информационной службы", № 2, 2001 г.

Поиск:
Последнее обновление страницы было произведено: 2004-05-20

Все предложения и пожелания по содержанию и структуре портала направляйте по адресу: rdlp@iis.ru