1.4Архитектура системы

1.4.1Общее понятие системной архитектуры

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

Архитектура включает в себя данные:

• об организации программной системы, её подсистемах и базы данных;

• о структурных элементах, входящих в систему, и их интерфейсах;

• о поведении, которое определяется кооперациями, в которых участвуют структурные элементы;

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

• о стиле архитектуры.

Хорошо спроектированная архитектура имеет следующие качества:

• многоуровневая структура подсистем (модулей);

• слабое связывание модулей между собой;

• простота понимания организации системы;

• надёжность и масштабируемость;

• хорошая возможность повторного использования компонентов;

• учёт наиболее важных и критичных функций системы;

• хорошо продуманный интерфейс с системой и хорошо продуманные интерфейсы с её подсистемами.

Следовательно, для создания качественной архитектуры новой информационной системы необходимо:

• представить организационную структуру (автоматизируемого предприятия и приложения);

• определить функциональные требования и специфицировать классы, которые реализуют отдельные функции системы;

• организовать классы в подсистемы (модули);

• сгруппировать модули в архитектурные слои.

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

1.4.2Архитектурные уровни

Наиболее распространённый в настоящее время стиль архитектуры программных систем – это трёхуровневая (или трёхзвенная) архитектура (three–tiered architecture), которая включает следующие уровни:

1. Уровень представления – User Service.

2. Уровень логики приложения (бизнес-правила) – Business Service.

3. Уровень управления данными – Data Service.

С точки зрения информационных систем эти уровни можно интерпретировать следующим образом:

1. User Service – включает графический интерфейс пользователя (диалоговые окна, отчёты).

2. Business Service – удовлетворяет требования к системе. Включает программные классы предметной области, а также классы управления и служебные классы. Классы управления и служебные классы не являются классами предметной области. Первые несут ответственность за координацию взаимодействия классов предметной области в соответствии с требованиями, вторые – выполняют вспомогательные функции. Например, управляют передачей сообщений в системе, обеспечивают обмен информацией с базой данных, поддерживают генерацию всевозможных отчётов, обеспечивают безопасность системы, включая защиту информации.

3. D ata Service – поддерживает хранение и манипулирование данными. Как правило, это реляционная или объектная база данных под управлением соответствующей системы управления базами данных (СУБД).

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

1. “Толстый клиент”. Клиент – уровень представления, уровень логики приложения. Сервер – база данных.

2. “Тонкий клиент”. Клиент – уровень представления. Сервер приложения – уровень логики приложения, база данных.

Для объектно-ориентированных информационных систем, как правило, используется многоуровневая архитектура (multi-tiered architecture). Проводится декомпозиция существующих уровней, которая подразумевает распределение обязанностей, выполняемых классической трёхуровневой архитектурой. Например, сервис генерации отчётов можно разделить на два уровня: высокий и низкий. Первый обеспечивает генерацию шаблона определённого отчёта, второй – генерацию самого отчёта и файловый ввод-вывод. После выполнения декомпозиции трёхуровневая архитектура превращается в многоуровневую без явно выраженных границ.

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

1. Повторное использование. Если логика приложения представлена в виде изолированных модулей, то эти модули можно использовать в других системах (приложениях).

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

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