О тестах и не только

Кратко - так:

UseCase - проецируется в класс реализации, вложенные UseCase - во вложенные классы.. 

Далее ТЗ детализируются УТВЕРЖДЕНИЯМИ (предикатами) внутри UseCase - Типа - "должна быть настройка ТАКАЯ-ТО" это проецируется также во вложенный класс.. или в функтор.. 

ну и тесты - примерно так же 

ну и АСПЕКТЫ - присущие ВСЕЙ системе и ОРТОГОНАЛЬНЫЕ UseCase.. т.е. это такие UseCase которые могут включаться в ОСНОВНЫЕ прецеденты системы.. 

пример АСПЕКТОВ - логирование, печать, аудит.. 

АСПЕКТЫ описываются отдельно и от прецедентов ставим к аспектам стрелки РЕАЛИЗАЦИИ. На выходе - получаем конкретны классы, позволяющие модифицировать аспекты для конкретного их применения.. 

Например АСПЕКТ "печать" реализуется "печатью документа" или "печатью картинки" в соответствующих прецедентах "работа с документом" и "работа с картинкой".. 

аспекты в части реализации - по сути - ПРИМЕСИ есть основная реализация аспекта, которая примешивается к реализации прецедента и детализуется некоторыми особенностями прецедента.. например для аспекта "печать" - ОСОБЕННОСТЬ - это то ЧТО печатаем - ДОКУМЕНТ или КАРТИНКУ.. 

всё остальное скрыто в ОПИСАНИИ и РЕАЛИЗАЦИИ аспекта.. например что есть предварительный просмотр.. есть собственно печать.. что в печати бывают колонтитулы... 

логирование - так это вообще АСПЕКТ, который описывается отдельно и который включается практически во ВСЕ прецеденты.. ДЕТАЛИЗАЦИЯ логирования это то ЧТО ИМЕННО логируем.. а детали логирования... сбора логов.. и т.п - скрыто собственно в АСПЕКТЕ 

АСПЕКТ это также - сохранение в форматы, DnD, копирование в Clipboard, разные граничные условия, типа обработки исключений и отсылки логов

 АСПЕКТ - это показ различных уведомлений и предупреждений пользователю.. они конечно присущи каждому конкретному ПРЕЦЕДЕНТУ, но имеют общую АРХИТЕКТУРУ, описание и ТЗ 

СКИНЫ - это классический ПРИМЕР аспекта 

скин конечно инкорпорирован в каждую конкретную реализацию ПРЕЦЕДЕНТА, но при этом скин - это целостная сущность т.е. в итоге имеем набор шаблонов АСПЕКТОВ и ПРЕЦЕДЕНТОВ, и каждый последующий прецедент конструируем на основе этих шаблонов, если спроектировалось, то всё отлично, если не спроектировалось - расширяем библиотеку шаблонов 

про ТЕСТЫ - наверное отдельная серия... Тесты на языке типа - 

"Открываем Конституцию" 
"Смещаемся в конец"
"Выделяем 5 параграфов"
"Печатаем." 

Это - реальность 

это FORTH 

на самом деле главное, что тесты МОЖНО и НУЖНО писать в терминах разрабатываемой системы 

И если ТЗ расписано в терминах ПРЕЦЕДЕНТОВ и АСПЕКТАХ, то автоматически получаем КАРКАСЫ тестов автоматических 

а из АВТОМАТИЧЕСКИХ тестов получаем - автоматическое тестирование и управление баг-трекингом 

есть ПРЕЦЕДЕНТ.. под него есть тест.. пока тест проходит - всё хорошо.. тест перестал проходить - идём в баг-треккер.. 

ищем такую ошибку про тест.. если не нашли, то заводим.. отправляем в разработку.. 

если нашли - переводим из состояния ЗАКРЫТО в состояние В РАЗРАБОТКЕ.. 

постим в ошибку новые подробности типа логов и скриншотов.. и так - по кругу. 

то же касается и ОШИБОК, а не только ПРЕЦЕДЕНТОВ.. 

была ошибка в баг-треккере - пишем под неё тест.. вносим в базу тестов.. пускаем каждый день.. дальше - по кругу.. либо тест прошёл.. либо - СМ ВЫШЕ 

КАЖДУЮ ошибку которую ПРАВИТ разработчик - покрываем тестом... или находим УЖЕ существующий.. 
---------------------------------
P.S. Если вы думаете, что я написал, что-то сложное, то читайте ДЕЙСТВИТЕЛЬНО сложное:
http://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_%D0%BE_%D0%B4%D1%83%D1%88%D0%B5

а то, что я написал - я постараюсь в конечном итоге проиллюстрировать диаграммами на UML и конечно примерами кода. А пока это конечно не статья, а "поток сознания".