Какие есть способы проверить архитектуру?

Question

Как проверить архитектуру? Есть ли что-то связанное с тестированием, которое можно сделать, пока архитектура еще находится в форме?

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

Обновление: Я использую слово «архитектура» так же, как оно используется в Code Complete .

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

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

Answer 1

Обычно «тестирование архитектуры» означает тестирование аппликативной и технической архитектуры (в отличие от деловой и функциональной, которая не столько «проверена», сколько «проверена»).
И это не «модульное тестирование» или «непрерывная интеграция» или TDD, а скорее подход «черного ящика» для тестирования всей системы (состоящей из множества модулей) от начала до конца.

Вы действительно можете приступить к разработке не одной, а нескольких политик тестирования: когда они касаются «архитектуры», они часто являются «общесистемными» тестами, которые подразумевают выделенную инфраструктуру (сеть, сервер, близкий к цели развертывания). 1006 *

Итак, при разработке ваших первых «архитектурных» тестов вы можете принять во внимание:

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

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

Answer 2

Правило дизайна № 1: Не думайте, что все легко, думая, что система будет легкой, обычно означает, что требования или объем того, что должно быть закодировано, еще не продумано.

Правило дизайна №2: не проектируйте что-либо, а затем передайте это разработчикам и скажите им, что это легко, когда вы еще не написали код или не работали с технологией.

Правило дизайна № 3: Новые технологии - это не серебряная пуля, которая устраняет все ваши проблемы. Все новые технологии имеют проблемы с интеграцией и часто содержат множество ошибок, которые еще не устранены поставщиком.

Учитывая эти правила, действуйте следующим образом:

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

Подтвердите любые недоказанные предположения - то есть то, с чем вы или команда не работали раньше. Чтение белой книги или пресс-релиза поставщика не считается. Убедитесь, что он работает, прежде чем строить свою систему на нем, если это что-то, что не было сделано ранее или используется по-новому.

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

Answer 3

Ваша архитектура - это проектный документ, верно?

Проверки - это то, что вы хотите.

Проверки могут обнаруживать ошибки так же, как и тестирование. Инспекции поймают «жучки» раньше.

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

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

Answer 4

Идея проведения модульных тестов для архитектуры становится очень популярной с тех пор, как стали популярными функции фитнеса. Есть несколько очень полезных фреймворков, таких как ArchUnit , которые можно использовать для написания фитнес-функций.

Answer 5

ATAM - это то, на что вы должны обратить внимание. Это метод для оценки архитектуры. Ключевым шагом является разработка «сценариев», в основном вещей, которые система может потребовать сделать в будущем, меняющихся или расширенных требований. Например, если система работает на другой ОС. Затем вы оцените, как архитектура будет соответствовать этим сценариям.

Answer 6

МЕТОДИКА ИСПЫТАНИЙ НА ПРОГРАММНОМ ОБЕСПЕЧЕНИИ НА АРХИТЕКТУРЕ

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

http://cs.gmu.edu/~offutt/rsrch/JinDiss.pdf

Answer 7

Если вы хотите выполнить итерацию, вы должны разработать только то, что вам нужно для итерации. Архитектура в основном рассматривается как один уровень выше design . Это означает, что я использую многоуровневую архитектуру MVC для принятия решения о том, как проектировать структуру своего класса.

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

Возьмите программу, которую вы хотите собрать, и воспользуйтесь тремя наиболее важными функциями. Подумайте, как их реализовать и как спроектировать структуру классов для этого. Подумайте о вещах, которые могут измениться, и сделайте их изменяемыми в вашем дизайне. Затем начните свою первую итерацию. Перед началом первой итерации подумайте о выборе архитектуры: используете ли вы MVC, архитектуру на основе клиент-сервер, у вас есть уровень базы данных или что-то подобное? Это те варианты, которые будут влиять на ваши последующие варианты дизайна.

Для дальнейшего чтения я предлагаю http://en.wikipedia.org/wiki/Iterative_and_incremental_development и Планирование Программирование XP от Кента Бека.