Ю. А. Григорьев, Г. И. Ревунков - Банки данных

Рис. 8.6. Организация связи Java-программ с базами данных

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

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

1.Сервер СУБД на компьютере-сервере.

2.Серверный программный комплекс (сервер приложений), функцио­ нирующий на компьютере-сервере. В общем случае этот сервер может не совпадать с сервером, на котором работает сервер СУБД. Серверный ком­ плекс принимает и обрабатывает запросы клиентской программы. В такой схеме серверная программа берет на себя сложную обработку данных, а клиентская — управляет пользовательским интерфейсом. Серверы прило­ жений работают на Unix-компьютерах и связаны сетевым протоколом TCP/IP с клиентскими компьютерами, работающими под MS Windows.

170

8.4. Примеры систем распределенной обработки данных

ЦЕНТР

ФИЛИАЛЫ

Кластер

Рис. 8.7. Структура информационной системы крупного московского коммерческого банка

Такая схема позволяет совместить высокую надежность и эффективность обработки данных, так как отвечающая за работу с данными серверная часть расположена на Unix-платформе с простым и привычным клиентским местом под управлением Windows.

171

8.Тенденции развития систем распределенной обработки данных

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

Впоследнюю версию автоматизированной банковской системы (АБС) вошли отдельные модули, созданные по Java-технологии, для реализации, например, системы клиент—банк. Разработчики проекта считают, что Java является перспективным направлением в банковских технологиях.

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

1. Наилучший результат получается при работе меньшего числа спе­ циалистов. Если обеспечить соответствующими условиями работы неболь­ шой коллектив высококвалифицированных специалистов и организовать взаимодействие между ними, то работать они будут существенно эффектив­ нее, чем большое число средних программистов. При большом количестве работников сложность управления коллективом умножается на сложность самого проекта и превышает мыслимые размеры. Могут позволить себе задействовать сотню и больше программистов в одном проекте лишь фир­ мы масштаба и опыта IBM, AT&T или Novell. При меньших возможностях фирмы попытка создать проект силами такого большого коллектива приве­ дет к неуправляемости и неустойчивости проекта и к малой производитель­ ности труда разработчиков.

Разработчики системы решили ограничиться небольшой (до 10 чело­ век) группой профессионалов. Конечно, для обеспечения гладкого функ­ ционирования такой группы нужна поддержка работников иных специали­ заций, например, системных администраторов. Такая группа является само­ организующейся и методом проб и ошибок, как показывает опыт, выдает нужный результат. Попытка увеличить группу хотя бы до 12—14 человек приведет к неизбежному разрастанию коллектива до 25—30 человек (за счет управленцев) из-за необходимости организовывать сложное взаимо­ действие между ними. При этом общая производительность труда группы разработчиков не повысится.

172

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

2.Важным является наличие хорошего постановщика задачи и архи­ тектора проекта. Эти люди должны владеть приемами выделения основных задач проекта и сведения их к стандартным классам алгоритмов. Это позво­ ляет организовать разработку больших проектов как поточное промышлен­ ное производство без потери качества работы.

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

4.Существующие инструментальные средства создания приложений обычно экономически выгодны для группы разработчиков. Вложенные средства с лихвой окупаются экономией затрат труда. Многие существен­ ные для программиста утилиты встроены в операционную систему Unix и часто полностью покрывают все потребности разработчиков.

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

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

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

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

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

173

8. Тенденции развития систем распределенной обработки данных

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

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

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

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

Сложные модели данных. Нормализация таблиц БД позволяет упро­ стить задачу обеспечения целостности БД. Однако часто сложные (ненор­ мализованные) структуры данных являются и более естественными, и более эффективными. Это видно из объектно-реляционных моделей БД и соответ­ ствующих продуктов, например, UniSQL и Montage. Таким же образом представление связей «многие-ко-многим» часто бывает рискованным, но часто дает и преимущества. Двадцать лет практики научили нас, что иногда нормализованные таблицы или связи «многие-ко-многим» это правильно, а иногда нет. Базы данных будущего должны предоставлять такой выбор.

Базы данных, а не языки. Одним из следствий модели составной БД является то, что лежащая ниже БД становится независимым и отдельным компонентом от любой высокоуровневой языковой среды. Сегодня боль­ шинство современных БД тесно ограничены либо SQL, либо некоторым объектно-ориентированным языком типа C++/Smalltalk. Такое связывание имеет большие преимущества для многих приложений, но иногда разработ­ чик хочет использовать только менеджер БД, не желая выбирать опреде-

174

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

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

Навигация и запросы. Сегодня объектно-ориентированные БД под­ держивают один стиль навигации, сетевые СУБД (т.е. поддерживающие сетевую модель данных) и метод доступа ISAM — другой. Реляционные БД обеспечивают запросы и операции на множествах. В составной БД разра­ ботчик не выбирает, т.е. низкоуровневые компоненты БД обеспечивают такие же навигационные возможности, как и [SAM. Высокоуровневые про­ цессоры запросов ориентируются либо на операции со множествами, либо на навигацию указателей, либо на то и другое. Поскольку это очень важно, усилия специалистов в следующем десятилетии будут направлены на под­ держку поэлементного навигационного стиля и вычислений, основанных на запросах. Часто подход, основанный на запросах, — наилучший путь пер­ воначального указания множества записей, в то время как навигационные операции — единственный путь дальнейшей работы с полученными в ре­ зультате данными в манере достаточно развитой, чтобы удовлетворить по­ требностям сложных приложений.

Память. Предположим, что мощный сервер с 500 Мбайт ОП поддер­ живает работу ста настольных компьютеров, каждый из которых имеет 50 Мбайт ОП. В этой ситуации совместная память персональных компьюте­ ров составляет 5000 Мбайт, что значительно превышает объем памяти сер­ вера. Сейчас этим пользуются брокеры объектных запросов (менеджеры баз данных). В перспективе все приложения переместят большую часть своих частных структур данных под управление менеджеров БД.

Контрольные вопросы

1.Назовите достоинства и недостатки файлового сервера БД.

2.Для решения каких проблем была разработана модель сервера приложений?

3.Перечислите особенности, присущие открытой системе.

4.Каковы перспективы развития систем распределенной обработки данных?

175

9. ПРОБЛЕМЫ ПРОЕКТИРОВАНИЯ СИСТЕМ РАСПРЕДЕЛЕННОЙ ОБРАБОТКИ ДАННЫХ

К началу ЗО-х гг. XX в. слоэюилась схема проектирования (рис. 9.1), ко­ торую сейчас называют каскадной. Каскадная схема предполагает переход к следующему этапу после полного окончания работ по предыдуи^ему этапу.

9Л. Этапы проектирования распределенных систем

Процесс проектирования систем распределенной обработки данных (СРОД) включает следующие этапы:

1)выявление информационных потребностей конечных пользователей;

2)концептуальное проектирование;

3)разработка архитектуры СРОД;

4)логическое проектирование;

5)отладка и тестирование прикладных программ;

6)сопровождение.

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

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

На втором этапе данные структурируются в КС БД, а функции объединяются в задачи будущей системы. При разработке КС БД проек­ тировщик руководствуется следующими абстракциями: агрегацией, обобщением, ассоциацией. Концептуальная схема БД изображается ERD-диаграммами (диаграммы Чена или Баркера). На этом этапе также разрабатываются спецификации будущей системы, т.е. определяются входные и выходные данные и алгоритмы связей между ними. Концеп­ туальный проект не зависит от реализации и отражает содержательную сторону будущей системы.

На этапе разработки архитектуры СРОД решаются следующие задачи:

176

p. /. Этапы проектирования распределенных систем

Рис. 9.1. Этапы проектирования распределенной системы

•осуществляется выбор структуры комплекса технических средств

(КТО;

•определяется состав общесистемных пакетов (ОС, СУБД и др.);

•выполняется распределение задач по машинам СРОД.

На этапе логического проектирования выполняется отображение КС БД и спецификаций прикладных задач в СУБД-ориентированную среду. При этом КС БД преобразуется в логическую схему БД, а спецификации задач — в ПП на конкретном языке. Проектирование систем распределен­ ной обработки данных по рассмотренной схеме довольно часто приводило к неутешительным результатам: сразу после внедрения они признавались морально устаревшими.

177

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

9.2.Кризис проектирования

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

ипостроены диаграммы распределения ошибок по этапам цикла проектиро­ вания систем и затрат на их устранение. Это показало, что больше всего ошибок (56%) допускается при выявлении информационных потребностей пользователей и на этапе концептуального проектирования, т.е. еще до реа­ лизации проекта. На их устранение требуется 82% затрат от общего объема издержек на устранение ошибок проектирования. Эта тенденция носила довольно устойчивый характер.

На основании этих результатов Дж. Мартин сформулировал принцип неопределенности в информатике: процесс автоматизации задач, которые пользователь хочет решать с помощью системы обработки данных, изменя­ ет его представление об этих задачах. Другими словами, процесс внедрения информационной системы корректирует требования к этой системе. Этот принцип указывает на обратное влияние информационных технологий (In­ formation Technology — IT) на реконструкцию бизнес-процессов (Business Process Reengineering — BPR), т.е. средствами вычислительной техники пользователь решает свои задачи иначе, чем без их использования. В 1995 г. В.П. Меллинг сформулировал выводы о взаимосвязи IT и BPR, которые, по существу, являются обобщением принципа неопределенности Мартина:

1) существует двунаправленное воздействие бизнес- и ИТ-платформы предприятия;

2)если бизнесили ИТ-платформа меняется, то маловероятно, что со­ ответствующая наследуемая ИТ-архитектура предприятия сохранится;

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

В середине 90-х г. XX в. была разработана новая схема (модель) про­ ектирования СРОД, учитывающая выводы Меллинга, — спиральная.

9.3. Макетирование системы

На разработку новой модели проектирования СРОД повлияли сле­ дующие три феномена.

Феномен персональных вычислений, основанный на пocтoяннqй дос­ тупности сотрудников к персональным компьютерам. Феномен состоит в том, что во многих видах информационных, проектных и управленческих работ исчезла необходимость в работниках-исполнителях (машинистках, чертежниках, делопроизводителях и др.), являющихся посредниками между постановкой задачи и ее решением.

178

9.3. Макетирование системы

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

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

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

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

2. Нельзя затягивать процесс выявления информационных потребно­ стей по следующим причинам:

• часто пользователь видит только свою ПО и многие подразделения пытаются обособиться (мой сервер, моя сеть, мне больше ничего не надо),

• многие сотрудники инертны, не инициативны и пытаются использо­ вать только простые средства (текстовый редактор).

3. После выявления информационных потребностей доработка проек­ та должна вестись централизованно профессиональными разработчиками в контакте с конечными пользователями.

Влияние второго феномена при проектировании СРОД проявляется в параллельной разработке нескольких подсистем. Причем разработка каждой подсистемы носит спиралевидный характер (рис. 9.2). Следует отметить, что здесь разделение работ на этапы 1—6 (см. рис. 9.1) является условным. Схема организации работ должна планироваться как адаптивная, а не как

179