Эволюция системной архитектуры

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

Перечислим основные причины перехода от централизованных к распределенным системам.

1. Стоимость аппаратных средств. Закупка и сопровождение распределенных систем клиент/сервер обойдется гораздо дешевле, чем покупка мэйнфрейма эквивалент­ной мощности.

2. Усовершенствование пользовательских интерфейсов. Многие из наследуемых систем, ос­нованных на мэйнфремах, имеют текстовые интерфейсы, основанные на формах. Сегодня пользователям привычнее графические интерфейсы и более простое взаимодействие с системами. Такого рода интерфейсы требуют большего количе­ства локальных вычислений и более эффективно работают в системах типа клиент/сервер.

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

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

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

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

Рис.8. Идеальная и реальная структуры систем

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

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

Рис.9. Преобразование наследуемой системы в распределенную

Несмотря на интеграцию интерфейса пользователя и предоставляемых наследуемой системой сервисов, все-таки при планировании децентрализации лучше рассматривать их в качестве отдельных логических уровней (рис. 10).

1.Уровень представления отвечает за организацию вывода на экран информации для конечных пользователей системы.

2.Уровень проверки данных связан с управлением вводом-выводом данных, осущест­вляемым конечными пользователями.

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

4.Уровень сервисов приложения отвечает за выполнение основных вычислений приложением.

5.Уровень базы данных отвечает за хранение и управление данными приложения.

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

Рис.10. Многоуровневая модель системы

Рис.11. Варианты распределения систем

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