hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Чтоm		такое программная архитектура?
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

Для чего она применяется?

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
347Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

Архитектура – начальный проект системы. Но ее действие простира% ется шире. Мы пользуемся системной архитектурой с целью:

Проверки правильности

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

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

Распространения информации

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

Спецификация архитектуры – важное средство для информирования о со& стоянии вашей системы. Следите за тем, чтобы она соответствовала со& стоянию программного обеспечения.

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

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

Выявления различий

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

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								348m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
Глава 14. Программная архитектураClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

навливает стратегию обработки ошибок. Она выявляет проблема% тичные области и области особого риска для проекта, способствуя выработке мер по минимизации этого риска. Главная задача архи% тектора%строителя – добиться, чтобы проектируемое им здание не рухнуло после завершения строительства, если будут соблюдены все оговоренные условия (даже в каких%то неожиданных ситуаци% ях). Так и мы должны обеспечить запас прочности для нашей про% граммной структуры. Здание не должно рассыпаться, если возник% нет слабый ветерок или некоторая дополнительная нагрузка.

Такая общая точка зрения на систему необходима нам, чтобы вы% брать разумные компромиссы, гарантируя при этом соответствие проекта предъявляемым к нему требованиям. Такие важные зада% чи лучше решать в самом начале, а не пытаться с запозданием вно% сить изменения, когда близится конец разработки.

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

Компоненты и соединения

Архитектура занята в основном компонентами и соединениями. Она определяет количество и тип тех и других.

Компоненты

Архитектура хранит информацию обо всех компонентах, что бы ни значили они в ее контексте. Компонентами могут быть объект, про% цесс, библиотека, база данных или продукт стороннего разработчика. Каждая из системных компонент определяется как понятный и логич% ный блок. Каждая решает лишь одну задачу и делает это хорошо. Ни% какие компоненты не содержат некой штуковины, если для этой шту% ковины есть конкретный модуль.

Не занимаясь проблемами реализации компонент, архитектура описы% вает все предоставляемые продуктом функции, а возможно, и важней% шие внешние интерфейсы. Она определяет область видимости компо% нент: что они могут видеть, а что нет, и кто их может видеть, а кто нет. Как будет показано далее, разные архитектурные стили устанавлива% ют разные правила видимости.

Соединения

Архитектура устанавливает все соединения между компонентами и опи% сывает их свойства. Соединение может представлять собой обычный вызов функции или поток данных в канале. Оно может быть обработчи% ком событий или передачей сообщений через какой%либо механизм ОС или сети. Соединения бывают синхронными (блокирующими вызвав% шего до завершения обработки запроса) или асинхронными (сразу воз%

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Чтоm		такое программная архитектура?
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
349Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

вращающими управление вызвавшему и использующими какой%то ме% ханизм последующей передачи ему ответа). Это имеет значение, по% скольку влияет на порядок передачи управления внутри системы.

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

Архитекторы и маркетологи

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

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

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

Технические архитекторы должны тесно сотрудничать с маркето% логами, чтобы представлять себе место нового продукта в общей стратегии компании и мнение клиентов о том, какое решение они сочли бы действительно выдающимся. Архитектура программно% го продукта должна учитывать проблемы маркетинга – юзабили% ти, надежность, обновляемость и расширяемость. Каждый из этих факторов оказывает реальное влияние на проектирование программного продукта. Одна лишь поддержка различных спо% собов оплаты может сильно повлиять на прибыльность проекта –