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

Рассмотрим основные типы архитектур, приведенных Гарланом и Шоу [2].

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

2. Архитектура независимых компонентов состоит из компонентов, функционирующих параллельно во времени.

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

2.2 Архитектура параллельно взаимодействующих процессов характеризуется тем, что в ней одновременно запускается несколько процессов (в различных потоках).

2.3 Приложение, построенное по архитектуре событийно-управляемых систем, представляет собой набор компонентов, каждый из которых находится в состоянии ожидания, пока не произойдет воздействующее на него событие.

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

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

Сравнение архитектур для данной системы приведено в таблице 11.

Таблица 11. - Сравнение архитектур

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

Преимущества архитектуры:

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

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

3. Позволяет объединить различные клиенты. Использовать ресурсы одного сервера часто могут клиенты с разными аппаратными платформами, операционными системами и т. п.

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

Ключевая задача проектирования архитектуры системы состоит в соблюдении двух принципов:

1. Принцип «слабой вешней связанности» (Low Coupling) - количество связей между отдельными подсистемами должно быть минимальным;

2. Принцип «сильного внутреннего сцепления» (High Cohesion) - связность отдельных частей внутри каждой подсистемы должна быть максимальной.

Архитектура большинства корпоративных приложений включает в свой состав три слоя:

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

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

3. Слой источника данных (data source) - отвечает за обращение к БД, обмен сообщениями, управление транзакциями с внешними приложениями.

Глава 5. Эскизный проект

5.1 Диаграмма деятельности для системы в целом