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

На главную | Контакты | Карта сайта

| Система Грант-Экспресс

| Новости РФФИ
| Объявления
| Подписка на новости

| Общие сведения о РФФИ
| Кто есть кто в РФФИ
| Состав совета Фонда
| Адрес и телефон для справок

| Устав РФФИ
| Указы Президента
| Постановления и распоряжения Правительства

| Нормативные документы

| Решения совета Фонда

| Конкурсы РФФИ
| Региональные конкурсы
| Международные конкурсы
| Программы РФФИ
| Финансовое обеспечение проектов

| Вестник РФФИ
| Газета Поиск
| Публикации в СМИ
| Книги, изданные при поддержке РФФИ
| Информационный бюллетень РФФИ
| Издания РФФИ

| Использование результатов
| Контроль использования финансовых средств

| Международная деятельность
| Научные фонды
| Ведомства и академии
| Библиотеки и информационные центры
| Полезные ссылки

| Издательство Wiley
| Издательство «The American Mathematical Society»
| Издательство Elsevier
| Американское физическое общество (APS)
| Издательство IOP Publishing Limited
| Издательство The Royal Society of Chemistry
| Издательство Springer

| Введение
| 2009 год
| 2010 год
| 2011 год

| WIN-1251
| KOI8-R
| English

1.2. ОБЗОР ТЕХНОЛОГИЧЕСКИХ ДОСТИЖЕНИЙ, ОРИЕНТИРОВАННЫХ НА РАЗРАБОТКУ ИНФОРМАЦИОННЫХ СИСТЕМ И БАЗ ДАННЫХ

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

1.2.1. Развитие интероперабельного промежуточного слоя (middleware)

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

Архитектура промежуточного слоя базируется на стандартах интероперабельных систем, разрабатываемых Object Management Group (OMG) - крупнейшим в мире консорциумом разработки программого обеспечения, включающим свыше 800 членов - компаний-производителей программного продукта, телекоммуникационных и компьютерных компаний, компаний-разработчиков прикладных систем и конечных пользователей. Целью OMG является создание согласованной информационной архитектуры, опирающейся на теорию и практику объектных технологий, а также на общедоступные спецификации интерфейсов информационных ресурсов для обеспечения интероперабельности. Эта архитектура должна обеспечивать повторное использование компонентов, их интероперабельность и мобильность.

Напомним, что технически интероперабельность компонентов (представляемых объектами) решена введением объектной модели-ядра, унифицированного языка спецификации интерфейсов объектов (IDL), отделением реализации компонентов от спецификации их интерфейсов, введением общего механизма поддержки интероперабельности объектов (брокера объектных заявок, играющего роль "общей программной шины", поддерживающей взаимодействие объектов), введением стандартов отображения IDL в конкретные языки программирования (C, C++, Ada, Smalltalk, Java).

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

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

1.2.1.1. Стандартные Объектные Службы

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

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

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

Служба Жизненного Цикла поддерживает создание, удаление, копирование и перемещение объектов. Для создания объектов используются специальные объекты - "фабрики объектов" (object factories). Для определения положения таких объектов используется понятие локатора фабрики (factory finder). Для локаторов определена операция поиска, которая возвращает совокупность соответствующих фабрик. Клиенты задают локатор фабрик как параметр в операциях создания, копирования и перемещения объектов.

Служба Транзакций предоставляет гарантию того, что поддерживаются некоторые, или все присущие транзакциям ACID-свойства (атомарность, непротиворечивость, изолированность, долговременность). Транзакционная служба поддерживает два вида транзакций: плоские (flat) и гнездовые (nested). Клиент может посылать заявки к множеству объектов, размещенных в различных узлах сети в области действия транзакции. Поддержка таких распределенных транзакций требует от ORB возможности передачи "контекста транзакции" с каждой заявкой.

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

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

Нетрудно видеть, что стандартами OMG регламентированы услуги, совершенно необходимые при реализации информационных систем.

1.2.1.2. Объектные средства

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

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

1.2.1.3. Эволюция продуктов CORBA

Эволюция кратко рассматривается на примере брокеров Orbix компании IONA Technologies, специализирующейся в области CORBA технологий.

В настоящее время брокеры Orbix доступны для 20 платформ (в том числе для различных вариантов UNIX, Windows NT, OS/2, QNX, VxWorks, MVS). Допустимые языки программирования - C++, Ada95, Smalltalk, Java. IONA поддерживает реализации CORBA-совместимых служб, таких как Orbix Object Transaction Monitor (OTM), OrbixOTS ( CORBA Object Transaction Service), OrbixEvents и OrbixTalk - (CORBA Event Service), OrbixNames (свободно распростроняемая версия реализации службы имен -- CORBA COSNameService), OrbixTrader (OMG Trading Object Service), OrbixSecurity (CORBA Security Service).

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

В плане интеграции CORBA c другими распределенными объектными архитектурами существенно прежде всего обеспечение взаимодействия с COM (Component Object Model) компании Microsoft. Примером подобного кросс-продукта является OrbixCOMet, предлагаемый IONA Technologies. Этот продукт позволяет создавать прикладные программы для серверов, используя одновременно протоколы DCOM и IIOP [http://www.iona.com/news/pressroom/corbacom.html].

Применения CORBA и Java для построения распределенных прикладных систем посредством OrbixWeb разнообразны. Поучителен следующий пример инфраструктуры издательской системы дома McClatchy. Основная ее задача - обеспечить совместное использование информации для ускорения процесса публикации новостей и улучшения качества редактирования. CORBA выполняет при этом следующие главные функции. Во-первых, клиенты могут подключаться в любой точке, используя WWW и OrbixWeb. Отсюда информация попадает в базу данных. Журналисты из всех 23 изданий компании одновременно пользуются этой информацией и включают в свои публикации в зависимости от аудитории. Во-вторых, редакторские системы используются локально в газетных издательствах, что позволяет создавать, исключать и редактировать информацию, размещаемую удаленно. [http://www.iona.com/news/pressroom/nando.html].

1.2.1.4. WWW браузеры, интегрированные с CORBA

Важной тенденцией, отражающей процесс интеграции WWW и CORBA, является появление компаний, поддерживаюших CORBA и работающих на рынке WWW. Известным представителем этой тенденции является компания Visigenic Software, осуществляющая политику встраивания брокеров в продукты других компаний. Так, по соглашению с Netscape Communications Corporation в Netscape Enterprise Server включен Visigenic Broker для C++ и для Java, а в Java пакет WWW браузера Netscape Communicator 4.x встраивается Java брокер Black Widow. В частности, в версии Netscape Communicator 4.0 определено связывание HTML страниц с CORBA объектами при помощи языка скриптов JavaScript.

По соглашению с фирмой Oracle, Visigenic Broker используется в Network Computing Architecture. По соглашению с фирмами Novell и Silicon Graphics, брокеры Visigenic включаются в будущие версии операционных систем компаний.

OmniBroker - это совместимая с CORBA 2. реализация ORB компании Object-Oriented Concepts, Inc., для платформ DEC Ultrix, Solaris 2.5, WNT 4.0. OmniBroker распространяется свободно для некоммерческих применений. К его характерным чертам относятся: поддержка отображения IDL в C++ и Java, использование протокола IIOP в качестве собственного, поддержка службы наименования и трейдера (помогающего клиентам динамически отыскивать подходящие серверы).

1.2.1.5. Управление потоками работ

Стандартизация средств управления потоками работ (Workflow Management Facility - WfMF) - одна из ближайших задач OMG. Управление потоками работ поддерживает операционные аспекты процессов в информационных системах, включая задание последовательности действий, назначение действий определенным агентам, передача данных (документов) между исполнителями действий, управление действиями и потоками данных на основе правил и процедур. Как CORBA, так и управление потоками работ нацелены на поддержку распределенных, неоднородных систем. Поэтому тщательная интеграция этих технологий является важной. Стандартизация WfMF отличается от работ Workflow Management Coalition (WfMC) [Workflow Management Coalition (1994): The Workflow Reference Model. Document Number WFMC-TC1003, 29-Nov-94, Version 1.1]: управление потоками работ - лишь одна из составляющих архитектуры управления объектами OMG. Стандарт WfMF, обсуждаемый в настоящее время, включает:

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

- Средства исполнения потоков работ, определяющие набор интерфейсов манипулирования потоковыми объектами и их семантику.

- Средства мониторизации потоков работ, позволяющие производить опрос состояния экземпляров потоков работ, находящихся в режиме исполнения.

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

После разработки стандарта, примененение средств управления потоками работ в распределенных информационных системах, создаваемых по грантам РФФИ, безусловно окажется целесообразным.

1.2.2. Прогресс систем управления базами данных

1.2.2.1. Объектно-реляционные СУБД и стандарт SQL3

Почти одновременное объявление "универсальных серверов баз данных" ведущими производителями средств баз данных (Oracle, Informix, IBM) обозначило начало широкого внедрения объектно-реляционых баз данных в информационные системы. Требования прикладных систем стали столь разнообразными, что их уже невозможно удовлетворить в рамках реляционной модели или за счет каких-либо предопределенных расширений языка SQL. Диапазон необходимых видов данных распространяется от традиционных структурированных данных к слабоструктурированным и текстовым данным, мультимедийным данным, пространственным данным, изображениям, аудио- и видео-данным. Требуются не столько новые встроенные типы данных, сколько средства, позволяющие пользователям расширять язык самим, определяя новые типы данных и собственные функции. В объектно-реляционных СУБД это стало возможным.

Появление этой модели данных не было неожиданностью. Она предопределена разработкой стандарта SQL3 в течение почти десяти лет (принятие стандарта SQL3 планируется в 1999 г.). SQL3 вводит абстрактные типы данных (АТД), позволяющие определять данные произвольной структуры и поведения. Функции, связанные с типами, определяются как функции SQL, либо как функции произвольных языков программирования. Различаются объектные и необъектные АТД. АТД могут быть употреблены в столбцах реляционных таблиц в качестве параметров функций, в качестве типов атрибутов других АТД. Экземпляры объектов или ссылки на экземпляры могут храниться в таблицах. SQL3 поддерживает понятия подтипа и множественного наследования. Множественные, мультимножественные и списковые значения произвольных типов возможны. Для уменьшения различий между строками таблиц SQL3 и объектами, строки таблиц могут приобретать уникальные идентификаторы. Понятие "подтаблицы" вводится аналогично понятию подтипа. Операции связываются со строковыми типами аналогично АТД. В отличие от АТД, строковые типы не являются строго инкапсулированными: к зкземплярам строковых типов (кортежам) применимы любые операции SQL.

Объектно-реляционные СУБД демонстрируют готовность ведущих фирм к немедленной реализации стандарта SQL3 после его появления. Так, Oracle8, следуя SQL3, уже ввел АТД, реляционные таблицы, столбцы которых могут быть типизированы АТД, объектные таблицы, коллекции и вложенные таблицы.

Существенным элементом архитектуры новых СУБД являются пакеты АТД, поддерживающие класс важных типов данных. В Oracle8 примерами подобных пакетов ("картриджей") являются следующие. Картридж контекстов обеспечивает развитый лингвистический сервис и доступ посредством SQL к полнотекстовым данным и неструктурированной информации. Картридж пространственных данных обеспечивает средства создания географических информационных систем. Видео-картридж обеспечивает надежную доставку полноэкранной видеоинформации и аудиоданных с качеством компакт-дисков посредством различных сетевых инфраструктур (таких как ATM, кабельные и спутниковые сети). Картридж изображений обеспечивает объектный интерфейс доступа к статическим двумерным изображениям в удобных форматах при использовании эффективных схем сжатия.

1.2.2.2. Многоуровневое построение приложений, связь с WWW

Одновременно с введением развитых моделей данных и средств их поддержки, новые СУБД особое внимание уделяют развитию распределенных многоуровневых приложений клиент/сервер и приложений для WWW. Так, в состав Oracle8 включен Oracle Application Server (OAS). Возможности OAS особенно важны для проектирования открытых информационных систем.

СУБД рассматривается Oracle важным компонентом NCA - архитектуры сетевых вычислений, предложенной корпорацией. NCA является развивающейся на основе общепринятых стандартов интегрированной средой для построения распределенных объектных приложений для WWW, традиционных систем клиент/сервер и корпоративных интрасетей. Решения OAS ориентированы как на статические, так и на динамичексие применения в среде HTML.

В OAS в качестве компонента включен HTTP сервер для поддержки статических HTTP страниц. Дополнительно OAS может работать с несколькими внешними HTTP серверами, такими как Netscape, Microsoft и Apache. Организации, использующие эти серверы, могут продолжать применение CGI, NSAPI, или ISAPI. Статические применения создаются как HTML-страницы при помощи типового HTML редактора. Дополнительно для сложных применений все более используется Java.

Разработчики информационных систем осознают ограниченность серверов HTTP. Они не масштабируемы, плохо приспособлены для связи с базами данных и для создания приложений, в которых требуется реализовать достаточно сложные прикладные функции. Прикладными системами, реализуемыми в рамках HTTP серверов, трудно управлять. Новые продукты различных фирм (таких как Netscape, Microsoft, IBM, Oracle) направлены на устранение этих недостатков.

Введение динамического контекста в страницы HTTP, обеспечение интерактивного поведения, обеспечение доступа к существующим (унаследованным - legacy) компонентам или генерация для таких компонентов (например, база данных) интерфейсных WWW-процессоров являются проблематичными. В Oracle исторически наиболее распространенным способом Web-изации приложений является применение PL/SQL для програмирования Web приложений.

Новыми являются средства OAS для обеспечения доступа к существующим компонентам посредством Java и CORBA. JDBC (Java Database Connectivity) используется для доступа к базам данных.

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

Oracle обеспечивает возможность программирования в Java, используя CORBA, включая клиентскую и серверную логику. Протокол IIOP используется в качестве основного средства связи между ними. JDBC и транзакционая служба используются со стороны сервера. Тем самым обеспечивается возможность разработки серверов, тесно интегрированных с базами данных. OAS является CORBA 2.Х совместимым благодаря Oracle ORB, который интегрируется с клиентскими брокерами, такими как Visigenics.

OAS реализует запросы, следующие от многих HTTP серверов. Такие запросы могут быть организованы посредством IIOP в рамках многих параллельных соединений. OAS реализует также развитые средства безопасности.

1.2.2.3. Объектные СУБД

Менее масштабным является развитие чисто объектных СУБД, где наиболее активны компании Object Design, Objectivity, O2. Частично отражает эту деятельность версия стандарта объектно-ориентированных СУБД ODMG 2.0, опубликованная в 1997 г. Основные компоненты архитектуры ODMG 2.0 - это объектная модель (профиль объектной модели-ядра OMG), Язык Определения Объектов (ODL), Язык Объектных Запросов (OQL), средства связывания баз данных с языками программирования (в первую очередь, с C++, Smalltalk и Java). Главным отличием от предыдущей версии стандарта является расслоение спецификаций типов на спецификации интерфейсов, классов и литералов. Спецификации интерфейсов не могут иметь экземпляров и определяют абстрактное поведение типов объектов. Спецификации классов определяют абстрактное состояние и абстрактное поведение типа объектов и могут иметь экземпляры. Наконец, спецификации литералов определяют только абстрактное состояние литеральных типов. ODMG поддерживает множественное наследование только для объектного поведения. Допускается наследование поведения интерфейсов от интерфейсов и классов от интерфейсов. Классы и интерфейсы не могут множественно наследовать поведение классов. Дополнительно к множественному, разрешено однократное наследование состояния и поведения для классов. Аргументом в пользу подобного изменения стандарта является неэффективность и противоречивость множественного наследования состояний.

1.2.3. Развитие средств Java для создания информационных систем

1.2.3.1. Промежуточный слой среды Java

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

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

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

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

Слияние RMI и IIOP является ключевым в поддержке CORBA из среды Java (JavaSoft и OMG имеют совместную программу для этого). Используя стандарт отображения Java в IDL, клиенты и серверы Java могут взаимодействовать с CORBA-совместимыми серверами вне зависимости от языка программирования такого сервера. CORBA в соединении с Java позволит достичь еще большей гибкости в создании распределенных систем. Этот процесс начался как только Netscape приняла решение включить брокеры Visigenics в состав своих браузеров.

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

Важным стандартом является также JDBC, позволяющий Java-клиентам взаимодействовать с базами данных согласованно с ODBC (Object Database Connectivity). JDBC позволяет устанавливать соединения с базой данных, получать доступ к метаданным, выдавать запросы на SQL, получать результирующие наборы данных, и др.

1.2.3.2. Компонентные модели Java

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

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

JavaBean представляет собой специализированный Java класс, которым можно манипулировать (в том числе визуально) при помощи специального конструктора. Ряд компонентов можно настроить и соединить при построении апплетов, прикладных систем, или при разработке более сложных JavaBeans.

Дальнейшим развитием компонентной модели Java является стандарт Enterprise JavaBeans (EJB) для создания серверных компонентов. В многопользовательских приложениях большая часть логики приложения перемещается из клиента в серверы. EJB позволяет создавать многоуровневые, распределенные, объектные прикладные системы. Возможность введения нескольких уровней обеспечивает ряд преимуществ в производительности, масштабируемости, надежности, гибкости, повторном использовании компонентов. EJB представляет собой набор технологий, основанных на JavaBeans, позволяющих изолировать разработчиков от низкоуровневых протоколов, подобных RMI или IIOP. Серверные компоненты выполняются в рамках компонентной исполнительной среды, предоставляющей им ряд сервисов, включающих управление транзакциями, состояниями, нитями, а также совместным использованием ресурсов. Существенно, что EJB устанавливает общий интерфейс прикладных программ к таким сервисам, независимо от их фактической реализации. Интерфейсы таковы, что можно использовать существующие сервисы, принадлежащие различным компаниям.

В целом развитие средств Java приводит к образованию все более продуктивной среды конструирования систем.

1.2.4. Средства проектирования информационных систем

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

Средство ОАП определяет интерфейсы и семантику, необходимые для поддержки и создания совокупности моделей ОАП и манипулирования такими моделями, каждая из которых определяет структуру, смысл и поведение прикладных систем в составе объектной архитектуры OMG. Названные модели могут принадлежать к различным классам - статических моделей (в частности, структурных моделей типов, классов), динамических моделей (поведенческих моделей, моделей объектного взаимодействия, моделей потоков данных в объектой среде), моделей применения компонентов системы агентами окружающей среды (в частности, так называемые use-case модели И.Якобсона), архитектурных моделей (известных как композиционные модели систем), и др.

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

Пока удалось создать унифицированную графическую нотацию, интегрировавшую опыт трех компаний - Rational, OMT и Objectory. Эта нотация получила название Унифицированного Языка Моделирования (Unified Modeling Language - UML), который чрезвычайно быстро завоевал широкое прзнание и сейчас является де-факто международным стандартом графической нотации ОАП. Нотация определяет посредством диаграмм различные сущности - статические и динамические. Простая, графическая метамодель языка UML сопровождает нотацию и позволяет (к сожалению, нестрого) уточнить смысл отдельных понятий.

Фирмы-разработчики средств ОАП очень быстро перестроились и приняли нотацию UML в качестве основной в своих инструментальных средствах. Известными примерами таких средств является Rational Rose и Paradigm Plus (фирма Platinum). OMG в своей архитектуре позиционировала результат этой работы как часть вертикального домена разработки прикладных систем, совместимого с Архитектурой Объектных Средств.

Пока OMG принята только нотация UML в качестве стандарта. Процесс проектирования еще нуждается в стандартизации. Кроме того, графическая нотация сама по себе не позволяет адекватно описать проектируемую систему и требования к ней. Поэтому дополнительно к UML рядом фирм развивается формальная нотация - Object Constraint Language (OCL), ориентированная на то, чтобы восполнить этот пробел. OCL является декларативным языком, позволяющим специфицировать инварианты состояний системы, а также ее функции посредством пред- и пост-условий.

Copyright © 1997-2007 РФФИ | Дизайн и программирование: Intra-Center