Главная | Обратная связь | Поможем написать вашу работу!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 27.11. Варианты распределенных систем

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

⇐ Предыдущая 186 187 188 189 190191192 193 194 195 Следующая ⇒