hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								474m
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
Глава 19. СпецификацииClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

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

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

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

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

Функциональная спецификация

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

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

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

Это обстоятельство применяется на практике: на некоторых космиче% ских аппаратах NASA вместо одного компьютера работает пять; четыре компьютера реализуют спецификацию для некоторого расчета, выпол% няя независимо разработанные программы. Пятый компьютер усред% няет результаты четырех расчетов (или приходит к заключению, что один из четырех дает результаты, совершенно не согласующиеся с ос% тальными).

				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
475Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

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

Если ваша задача программирования недостаточно четко поставлена, не начинайте кодирование, не написав спецификации и не согласовав ее.

Спецификация системной архитектуры

Спецификация архитектуры описывает общий вид и структуру про% граммного решения. В нее входят такие вещи, как:

•Физическое расположение компьютеров. (Будет ли это система кли% ент/сервер или однопользовательское настольное приложение?)

•Компонентный состав программного обеспечения. (Как оно разде% ляется? Какие части нужно написать, а какие можно купить?)

•Параллелизм. (Сколько потоков выполняется одновременно?)

•Хранение данных (включая структуру базы данных).

•Другие аспекты системной архитектуры (избыточность, каналы связи и пр.)

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

Спецификация интерфейса пользователя

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

Иногда то, что представляется пользователю, сильно отличается от ре% ализации, скрытой за сверкающим фасадом. Приведем два примера:

•Система, активно использующая сетевые соединения, может быть развернута на одной машине и скрываться за единым интерфейсом

пользователя.

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								476m
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
Глава 19. СпецификацииClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

•Имеющаяся функциональность может быть упрощена с целью облег% чить использование или создать урезанную, более дешевую версию.

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

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

Проектная спецификация

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

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

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

				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
477Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

Но, прежде чем вы с облегчением вздохнете, послушайте следующий совет. Замените ее документом с той же информацией, но в котором легче поддерживать точность. Средства грамотного программирова# ния (см. раздел «Практические методологии самодокументирования» на стр. 103) служат замечательным механизмом составления докумен% тации, которая генерируется из самого кода – нужно лишь добавить в него комментарии в особом формате. Такая документация может за% менить обременительные проектные спецификации.

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

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

Спецификации тестирования

Спецификация тестирования описывает стратегию тестирования оп% ределенного программного объекта. Она объясняет, как проверить со% ответствие реализации функциональным спецификациям, чтобы опре% делить готовность программы к выпуску. Естественно, объем этой за% дачи зависит от того, что проверяется – отдельная компонента, под% система, настольное приложение или встроенный продукт.

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

Как мы видели в главе 8, многие тесты уровня кода могут сами выпол% няться в коде и запускаться автоматически в процессе разработки. Эти тесты стоят в стороне от тестов верхнего уровня, которые можно про% водить только путем запуска программы в окончательном контексте, моделируя ввод данных оператором.

Если можно создать программные поблочные тесты для вашего про% дукта, это предпочтительнее, чем писать пространные тестовые специ% фикации. Тестовые спецификации на уровне кода в процессе развития системы быстро устаревают точно так же, как и проектные специфи% кации. Пользуйтесь кодом программного теста как документацией ва% шей стратегии тестирования – писать «литературный» тестовый код так же просто, как обычный «литературный» код. Автоматизирован% ные циклы тестирования заставят вас обновлять тесты по мере измене% ния кода, иначе они просто не пройдут успешно!