Модули могут иметь вид процедур и использоваться в качестве стандартных блоков для создания более крупных систем. При объектно-ориентированном программировании модули принимают форму объектов, каждый из которых имеет свою собственную внутреннюю организацию, не зависящую от строения других объектов.
Традиционным представлением модульной структуры, получаемой с помощью процедур, является структурная схема. На такой схеме каждый модуль изображается в виде прямоугольника, а зависимости между модулями в виде стрелок, соединяющих прямоугольники. Для изображения структуры объектно-ориентированных систем используются диаграммы классов. Рисунок.
Основная цель при проектировании модульной системы – сделать модули максимально независимыми друг от друга. Тогда при модификации изменения необходимо вносить только в конкретные модули. Однако для того чтобы модули составляли связную и логическую систему между ними должны существовать межмодульные связи. Следовательно, создать модули, максимально независимые друг от друга, значит минимизировать связи модулей системы.
Ранее говорилось, что сегодня большая часть программного обеспечения проверяется с помощью тестирования. К сожалению, тестирование не всегда дает точный результат. Проводя тестирование, мы не можем с достоверностью сказать, что система программного обеспечения работает правильно, если только мы не проведем достаточное количество испытаний, которые будут включать все возможные сценарии. Но существует более тысячи разных путей, по которым может пойти простой цикл, содержащий оператор if-then-else, когда цикл выполняется только десять раз. Поэтому проверить все возможные пути сложной программы просто невозможно.
С другой стороны, разработчики программного обеспечения создали методы тестирования, которые с достаточно большой вероятностью позволяют обнаружить ошибки в программе. Одна из методик основывается на наблюдении, что ошибки в программном обеспечении имеют свойство скапливаться в одном месте. То есть опыт показывает, что некоторые модули большой системы содержат больше ошибок, чем другие модули. Поэтому, определив эти модули и проверив их более тщательно, чем остальные, можно выявить больше ошибок, чем, если проверять все модули достаточно тщательно, но одинаковым образом. Это пример применения принципа Парето, названного в честь итальянского социолога и экономиста Вильфредо Парето (1848-1923. В общем, принцип Парето говорит о том, что часто можно достичь больших результатов, если прикладывать усилия в ограниченном пространстве.
Другой метод тестирования называется тестированием базового пути. В этом случае создается набор контрольных данных, которые бы подтверждали, что каждая команда программы выполняется по меньшей мер один раз. Для определения контрольных данных была разработана методиками, в которой используется теория графов (Теория графов – это геометрический подход к изучению объектов. Граф задается множеством вершин (узлов) и множеством ребер (связей), соединяющих некоторые пары вершин. Пример графа: схема линий метрополитена). Хотя при таком способе тестирования и невозможно гарантировать, что были проверены все пути программной системы, однако можно утверждать, что в процессе проверки каждый оператор выполнился, по крайней мере, один раз.
В методах тестирования, основанных на принципе Парето и проверке базового пути, подразумевается, что нам известно внутреннее строение тестируемой системы. Поэтому эти способы тестирования можно отнести к категории тестирования методом «прозрачного ящика». В отличие от этого, при тестировании методом «черного ящика» внутреннее строение системы остается неизвестным. Основное внимание при таком тестировании уделяется не тому, как именно система выполняет задачу, а тому, выполняется ли задача правильно, точно и вовремя.
К тестированию методом «черного ящика» часто относят анализ граничного значения. В этом случае определяются граничные точки технических требований системы, и она проверяется в этих точках. Например, если система должна принимать входящие значения, заданные в определенном интервале, тогда она проверяется с наименьшим и наибольшим значениями. Или если система должна координировать действия, тогда она проверяется с использованием самых сложных действий.
Другой способ тестирования методом «черного ящика» — применение избыточности. Согласно этому подходу разные проектные группы или даже разные компании создают независимо друг от друга две программные системы, выполняющие одинаковые действия. Затем эти две системы проверяются с использованием одних данных и результаты проверки сравниваются. Ошибки определяются по расхождениям результатов тестирования. Этот метод часто используется при проверке космических систем.
Другая методика тестирования (бета-тестирование) все более широко применяется разработчиками программного обеспечения, предназначенного для продажи. В этом случае часть предполагаемых покупателей снабжается предварительной версией программы, которая называется бета-версией. Прежде чем утвердить окончательную версию продукта и выпустить ее на рынок, разработчики пытаются выяснить, как программное обеспечение будет работать в реальных условиях. Бета-тестирование позволяет также узнать мнение покупателя (как положительное, так и отрицательное), что помогает усовершенствовать рыночную стратегию. Кроме того, распространение бета-версии программного обеспечения помогает другим разработчикам создавать продукты, совместимые с этим программным обеспечением. Например, распространение бета-версии новой операционной системы способствует разработке совместимых с ней обслуживающих программ, и окончательная версия операционной системы появляется на прилавках магазинов вместе с сопутствующими продуктами. Наконец, существование бета-версии программного обеспечения стимулирует всеобщий интерес к продукту на рынке и увеличивает количество продаж.
