Требования к программному обеспечению
Если ТП описывают требуемую систему на языке пользователя, то ТПО описывают ее на языке инженера. Поэтому в этом документе сначала могут оказаться расчеты размера системы. Что особенно характерно для современных объектных методологий, потребность в ТПО уменьшилась, поскольку архитектура будет состоять из прикладных классов, у которых ясные взаимосвязи с языком ТП. В этой ситуации, ТПО и АП могут быть объединены.
Говорят, скульптор думает о своей законченной работе, как о заключенной внутри глыбы камня или куска дерева, и которую нужно оттуда извлечь, отсекая лишнее. Это помогает. Точно так же, мы можем представить себя глядящими глазами пользователя на наше творение в один из дней в будущем. Если мы смотрим на него используя свойства (черты) системы, мы можем спросить себя: "Как это должно быть реализовано?" Тогда очень легко получить описание потребностей пользователя на языке инженера-программиста.
Архитектурный проект
Если уже приходится делать работу, заключенную в АП, то может показаться, что самая тяжелая работа по проектированию к этому моменту завершена. Есть также большой соблазн вообще уклониться от написания Архитектурного Проекта. В то время как мы умышленно опускаем детали проекта в АП, иногда чтобы удовлетворить требованиям независимости от платформы (portability), иногда просто чтобы развеять туман вокруг большой картины, мы по-прежнему должны быть уверены в том, что наш проект действительно реализуем. Инженер должен знать по крайней мере один приемлемый способ реализации каждого свойства до того, как искать его, и должен подумать о концептуальной целостности кода, требуемого для реализации этих свойств.
Утверждение, что архитектурный проект не должен касаться детального проекта, мы считаем ошибочным. Если мы не можем рассматривать реализацию, мы не можем быть хорошими инженерами, поскольку любой идиот может спроектировать нереализуемое. Только учитывая реализацию мы обнаруживаем ограничения наших проектов и находим разницу между хорошим и плохим. Мы способны увидеть альтернативы, сравнивать их и выбирать лучшее. Если мы не можем учитывать реалии реализации, то один дизайн так же хорош, как и другой, и эта критическая стадия познания становится упражнением в письме, кто быстрее может "написать документ", нимало не задумываясь над написанным!
АП -- это дидактический документ. Он учит читателя тому, как посмотреть на проблему и решение так же, как смотрел автор.
Детальный проект
ДП -- это записка в бутылке. Он говорит читателю о том, как автор планировал реализацию, поэтому код можно понять. Детальность изложения должна прояснить те места, которые остались за кадром в АП, и привести читателя в точку, где уже должен быть сам код. Иногда, это объяснение может быть выражено псевдокодом, но не обязательно. Следует допускать возможность исправления ДП. Во время реализации будут возникать такие детали проекта, как организация кода в модули. Если такие детали не передать с помощью ДП нашим коллегам, то как еще это сделать? Это простое упущение вызывает в дальнейшем слишком много ненужных проблем, поскольку инженеры посчитают составляющие системы хорошо документированными, только в случае, если они знали, с чего начать! Окончательный вариант ДП должен говорить последователям, что они должны знать, чтобы понять систему и изменить ее.
План тестирования
План Тестирования -- наиболее чувствительный к контексту тип документа, но очень полезно руководствоваться следующими наблюдениями в рамках требований ситуации. Стратегическая цель тестирования -- напрячь систему. Не будет никакой пользы, если делать тестирование хаотично, поэтому необходимо найти одну или несколько моделей системы, которые могут дать нам индикатор для типичных и стрессовых ситуаций. Таким образом, полезная структура -- описать модель, выяснить стрессовые условия и затем перечислить их.
Снова и снова в этой работе мы видим эхо глубокой структуры, которую мы выявили, написав простейшую программу. У нас есть проблемная область, семантика системы и карта взаимосвязей между ними, созданная программистом при рассмотрении желания. Этот паттерн -- центральное действие программирования компьютеров. В нем самом может и не содержаться понимания, но способность это делать -- единственное доказательство, что проблема на самом деле понята в терминах заданной семантики. Если семантика строгая и проверяемая, как семантика цифрового компьютера, можно заявить о "глубоком" или "истинном" понимании, но это только предположение, поскольку кто-нибудь всегда может заглянуть за горизонт и сказать: "Посмотри на это так!"
Этот паттерн настолько важен, что мы хотим сфокусировать на нем внимание. Хотя мы стараемся избегать замысловатого жаргона без стоящего за ним реального смысла, мы хотим ввести термин, "Ход конем" ("Вилка"), чтобы обозначить этот паттерн. Мы позаимствовали этот термин из шахмат. Там конь стоит на доске и может совершать последовательность L-образных перемещений. Другие фигуры могут перемещаться только по горизонтали, вертикали или диагонали, а L-образные ходы коня позволяют напасть сразу на две фигуры, каждая из которых ограничена своим собственным миром, и таким образом добиться чего-нибудь полезного в любом случае.
Такого вида паттерн появляется снова и снова, но мы всегда можем свести его к написанию простейшей программы. Компьютерная система может находиться во многих состояниях и развиваться в соответствии со своей собственной внутренней логикой. Окружающий мир, за которым следит компьютер, также может находиться во многих состояниях и изменяться (эволюционировать). Используя интуицию, дизайнер может абстрагировать и внести в компьютер критические аспекты проблемы, применяя одну и ту же структуру в обоих случаях, поэтому компьютер и реальность будут согласованы. Тестовые ситуации, формируемые моделью проблемы и системы, будут охватывать допустимые (и, вероятно, недопустимые) состояния пространства входных воздействий, в соответствии с интуицией автора, таким образом, что в любом случае можно будет проверить изменение состояния системы. Проектировщик, при необходимости выполнения манипуляций с данными, будет использовать свойства самих данных, определяемые структурой данных, и отражать эти свойства на свойства языка, как в каноническом: