2.2.3. Этап проектирования архитектуры

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

Проект выполняется в терминах программных и аппаратных платформ, на которых предстоит реализовать систему.

Описание системы в терминах составляющих ее модулей называется архитектурным проектированием (architectural design). Проект архитектуры включает выбор стратегических решений по клиентской и серверной частям системы.

Описание внутренних механизмов каждого модуля (прецедентов) называется детализированным проектированием (detailed design).

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

Архитектурное проектирование связано с выбором стратегии решения и разбивкой системы на модули. Стратегия решения (solution strategy) требует разрешения вопросов, касающихся клиентской (пользовательский интерфейс) и серверной (база данных) частей системы, а также всевозможного ПО промежуточного уровня (middleware), необходимого для связывания клиента и сервера. Выбор основных строительных блоков (модулей) относительно независим от стратегии решения, однако детализированный проект модулей должен соответствовать выбранному решению по архитектуре клиент/сервер.

Зачастую модели архитектуры клиент/сервер расширяются до так называемой трехзвенной архитектуры (three-tier architecture), в которой логика приложения составляет отдельный слой:

• клиент;

• логика приложения;

• сервер.

Среднее звено представляет собой слой логики и в этом качестве может поддерживаться или не поддерживаться отдельным аппаратным обеспечением.

Логика приложения — процесс, который может выполняться на клиентской машине или на сервере, т.е. он скомпилирован в виде клиентского или серверного процесса и реализован как библиотека DLL (Dynamic Link Library — динамически подключаемая библиотека), интерфейс API (Application Programming Interface — интерфейс прикладного программирования), RPC-вызовов (Remote Procedure Calls — удаленный вызов процедуры) и т.д.

2.2.4. Этап детализированного проектирования

Архитектурный проект описывает программный продукт с точки зрения составляющих его модулей. Детализированный проект описывает каждый модуль. При разработке типичной ИС модули реализуются либо в виде клиентской компоненты, либо серверной компоненты. За первые отвечают проектировщики прикладной части, вторую должны разрабатывать проектировщики баз данных.

Проект пользовательского интерфейса (клиентского приложения) должен соответствовать принципам проектирования GUI-интерфейса, установленным разработчиком конкретного GUI-интерфейса (Windows, Motif, Macintosh). Подобные принципы обычно доступны в WWW как часть электронной документации GUI интерфейса.

Основной принцип объектно-ориентированного проектирования GUI-интерфейса:

- управление приложением является прерогативой пользователя, а не программы.

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

Проект базы данных определяет объекты сервера базы данных — скорее всего, реляционной (или, возможно, объектно-реляционной). Часть этих объектов представляет собой контейнеры данных (таблицы, взгляды и т.д.). Другие объекты являются процедурами (хранимые процедуры, триггеры и т.д.)