проверяемость дизайна

Question

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

Это некоторые смутные мысли, но хотелось бы знать, существует ли методичный, автоматизированный подход к тестированию проекта в первую очередь. Другими словами, можем ли мы также иметь «Test Driven Design»?

Answer 1

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

Нельзя протестировать проект на основе функциональных требований , поскольку удовлетворение функциональных требований зависит от реализации, а не от дизайна.

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

Answer 2

Интересная тема!

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

Во-вторых, мне лично очень не нравятся инструменты моделирования UML.Если такой формальный метод проверки будет реализован, то, скорее всего, это будет что-то вроде Rational Rose - я давно поклялся, что больше никогда не подойду к этому.

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

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

Это говорит вам о том, завершен ли ваш дизайн - хотя и не является ли он «правильным».

Я не знаю, как сказать, является ли проект «правильным», не создавая его и не тестируя и не полагаясь на человеческий опыт.и знания.