Лаврищева Е.М., Грищенко В.Н. Сборочное программирование. Основы индустрии программных продуктов

Подождите немного. Документ загружается.

121

Тестирование модулей и структур агрегатов

Тестирование заключается в динамической проверке поведения программы на

конечном множестве тестовых данных, выбранных из входного пространства, на

соответствие ожидаемому поведению.

Динамическое тестирование всегда предполагает выполнение программы, а

конечное – создание большого количества тестов, которые могут быть выполнены

в ограниченные сроки наблюдения за поведением программы.

Методы тестирования, в основном, отличаются подходами к выбору множества

тестовых данных из входного пространства. Основная цель тестирования –

обнаружение дефектов в ПС и установление ее функциональной пригодности,

удобства применения, производительности и др.

Тестирование на протяжении процесса разработки агрегата из модулей

выполняется на нескольких уровнях. Для каждого уровня тестирования

определяется категория объектов тестирования (весь агрегат ПС, программные

компоненты, отдельные модули) и набор проверяемых тестируемых характеристик.

На каждом уровне тестирование повторяется многократно, образуя циклы:

тестирование–исправление–повторное тестирование.

В современной практике тестирования все виды действий, начиная с

планирования до оценки результатов тестирования, должны интегрироваться в

четко определенный, документируемый и контролируемый процесс тестирования.

Это облегчает взаимодействие между разработчиками, группой тестирования и

руководством проекта, а также позволяет сделать процесс видимым, повторяемым

и измеряемым.

Связь тестирования с другими видами проверки. Тестирование имеет много

общего с процессами верификации и валидации (V&V). Общность процесса

тестирования с процессами V&V заключается в единстве состава и структуры

планов, рекомендуемых стандартом IEEE Std. 829, а также объектов и

применяемых методов. Отличие этих процессов состоит в условиях их применения.

Тестирование – основной процесс в ЖЦ, выполняемый всегда, для всех объектов

ПО системы независимо от ее критичности. Процессы V&V, в современной

трактовке стандартов IEEE Std. 1012 и ISO/IEC 12207 – поддерживающие

процессы, которые могут применяться к выбранным объектам тестирования для

проверки планов тестирования и подтверждения того, что выполненное

тестирование адекватно уровню критичности ПС. По отношению к процессу

тестирования V&V выполняет контрольную функцию и подтверждает соответствие

объектов установленным требованиям.

Тестирование ПС тесно связано с отладкой и собственно программированием,

но охватывает гораздо более широкий круг проблем и участников –

программистов, тестировщиков, аналитиков и инженеров по качеству.

Виды и уровни тестирования. Традиционно выделяется три уровня

тестирования ПО: автономное или модульное (unit testing), интеграционное

(integrating testing) и системное (system testing). В стандарте ISO/IEC 12207

прослеживаются четыре уровня тестирования:

– модульное (в процессе «Построение ПО»),

– интеграционное (в процессе «Сборки ПО»),

122

– тестирование ПС (как процесс):

– системное (в процессе «Испытания ПС»).

Модульное тестирование предполагает проверку функционирования модулей в

изоляции друг от друга. Оно обычно выполняется разработчиками с доступом к

коду и чередуется с отладкой. Объектами тестирования являются отдельные

процедуры, программные модули и компоненты, состоящие из тесно связанных

модулей.

Цели модульного тестирования – обнаружение дефектов в реализации функций

объектов и подтверждение соответствия объекта спецификациям проекта

(техническому проекту).

Наиболее полно вопросы систематического модульного тестирования освещены

в стандарте IEEE 1008-87 “Standard for Software Unit Testing”.

Интеграционное тестирование предназначено для проверки правильности

взаимодействия между программными объектами, протестированными автономно.

Современные систематические стратегии интеграции определяются

архитектурой ПС и моделью разработки (обычно итерационной с приращениями).

Интеграционное тестирование выполняется при каждой сборке новой версии

ПС с целью выявления дефектов в интерфейсах между интегрируемыми

компонентами и подтверждения их соответствия проекту архитектуры ПС.

Тестирование ПС заключается в проверке функционирования интегрированной

версии системы в моделируемой среде. Цели тестирования на этом уровне –

выявление дефектов в реализации внешних функций ПС и подтверждение его

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

Системное тестирование ориентировано на оценку качества сопряжения

модулей ПС с другими не программными компонентами современных систем.

На этом уровне тестирования производится проверка соответствия ПС целям

качества, установленным в требованиях к системе , таким как надежность,

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

системами, средой, аппаратным обеспечением. Большая часть функциональных

отказов и дефектов должна быть идентифицирована и устранена на предыдущих

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

неудовлетворительными техническими характеристиками функционирования всей

системы.

Задачи системного тестирования часто объединяют в единый процесс, При этом

тестирование технических характеристик ПС должно выполняться отдельно.

Вывод. Рассмотрен общий подход к управлению модульными структурами.

Базовым формальным аппаратом для описания операций над модульными

структурами является теория матричных преобразований для их представления в

виде графа. Матричное представление используется для задания матрицы вызовов,

задающей обращение одного модуля к другому. Проведено доказательство

отношения достижимости на графе модульной структуры. Рассмотрены операции

построения модульных структур и методы тестирования сложных программных

агрегатов.

123

Г л а в а 5

КЛАССИФИКАЦИЯ И ТИПИЗАЦИЯ

ПРОГРАММНЫХ РЕСУРСОВ

Большое значение для проблематики современного сборочного программи-

рования имеют компоненты повторного использования (КПИ) или reuses. Они

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

компоненты, объекты данных, информационные ресурсы Интернета и т.п.

Главная задача сборки разных программных ресурсов в конкретные

программные системы (ПС) – обеспечение взаимоотношений или взаимодействий

новых и готовых программных ресурсов широкого применения, которые создаются

для разных платформ и в разные периоды развития компьютерных и

информационных технологий.

Эффективное применение готовых программных ресурсов основывается на

проведении их типизации и классификации. Особенно это касается нового вида

ресурсов, так называемых менеджеров информационных ресурсов (ИР),

используемых при построении прикладных систем и веб-приложений в среде

Интернета.

Компоненты разработки, КПИ, программы и информационные ресурсы – объекты

типизации и классификации в программной инженерии.

5.1. ОБЩИЕ МЕТОДЫ ТИПИЗАЦИИ И КЛАССИФИКАЦИИ

ПРОГРАММНЫХ КОМПОНЕНТОВ

Сущность любой классификации состоит в разбивке множества элементов на

классы эквивалентности согласно классификационным характеристикам и

признакам. Классы эквивалентности не должны пересекаться, и все элементы

конкретного класса должны иметь соответствующие признаки.

Для одного и того же множества может существовать несколько систем

классификации, каждая из которых зависит от выбранных базовых признаков и

способов группировки их в классификационные характеристики (например,

программная инженерия как наука качественного производства). Основой такой

системы является информация, которая сопровождает компоненты, и правила их

упорядочивания соответственно определенным признакам – функциональность,

системная среда и т.п.

Системы классификации компонентов не существует, поэтому ее построение

основано на общих знаниях о компонентах и подходах к их применению. Эти

знания распределяются среди таких групп общих свойств, как структурные

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

124

Классификация компонентов – это унификация представления информации о

компонентах для дальнейшего поиска и отбора их из среды хранения, например

репозитария. Она выполняется с учетом таких признаков: принадлежность к ПрО;

тип компонента (модуль, класс, сервис и др.); интерфейс; готовность КПИ; тип

структуры КПИ (каркас, паттерн, контейнер) и т.п.

Физическое размещение КПИ в репозитарии выполняется с помощью каталога,

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

которые выбирают в репозитарии, требуют настройки на условия среды

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

5.1.1. ПОДХОД К ТИПИЗАЦИИ КОМПОНЕНТОВ

Классификация компонентов обусловлена типизацией, и, хотя классического

определения понятия типизации компонентов пока не существует, оно связано с

отдельными экземплярами компонентов, для которых могут применяться

операции по определению их интерфейсов.

Согласно теории типов любой тип рассматривается, как множество элементов,

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

значение истины.

Если точно d



D (D – домен) и P = {P

, P

,, …, P

} – совокупность предикатных

функций, то тип T определяется выражением

T = {d: D | P}. (5.1)

Исходя из этого выражения, сформулируем следующее определение.

Тип – это определенная характеристика свойства, в том числе структуры и

поведения, которые относятся к определенной совокупности объектов. Если

понятие типа рассматривают в контексте типа данных, то объекты – значения из

определенного множества, а свойства – совокупность операций над ними.

Формально каждый тип данных задается абстрактной системой, которая

состоит из множества значений (домена данных для этого типа) и совокупности

операций над этим множеством (сигнатуры типа) [207]. Иными словами,

выражение (5.1) принимает вид

T = (X,



), (5.2)

где X – множество элементов типа данных;



– совокупность операций над

элементами множества.

Как было сказано ранее (см. глава 2), типы данных делят на базовые или

примитивные (например, integer, real) и сложные или производные (например,

array, struct), которые состоят из упорядоченной совокупности данных с меньшим

уровнем структурированности. Для обеспечения целостности обработки

типизированных переменных в состав операций сложных типов должны входить

операции непосредственно как над самой переменной, так и над отдельными

составляющими. Это приводит к построению иерархической системы типов

данных в рамках единой теории типов.

Каждый язык программирования (ЯП) имеет собственную совокупность типов

данных и механизмы конструирования новых типов. Главное назначение

типизации – представление абстракций таким образом, чтобы ЯП, который

применяется для реализации программного проекта, поддерживал согласованность

125

принятых проектных решений, определяющихся соответствующей системой типов

данных.

Обобщение понятия типа данных – класс в терминологии ООП [35, 36, 158].

Класс определяет множество объектов с общей структурой, состоящей из

экземпляров класса, и поведения, которое определяется методами формирования

совокупности операций над этими экземплярами (создание, уничтожение,

сериализация и др.), а также над переменными класса и экземплярами класса.

Переменные могут иметь типы, простые или сложные, которые соответствуют

другим классам и обеспечивают построение иерархической системы классов.

Совокупность внешних переменных и методов класса определяют интерфейс, с

помощью которого экземпляры других классов взаимодействуют с экземплярами

данного класса.

Если сравнить наведенные определения типа и класса, то их сущности

принципиально не различаются на абстрактном уровне. Поэтому эти понятия в

современных ЯП часто рассматривают, как синонимы.

Любое взаимодействие с экземплярами компонентов в ООП происходит через

интерфейсы, которые состоят из методов и атрибутов. Атрибут – логическое

представление схемы взаимодействия экземпляра компонента с внешними

переменными с помощью специальных методов, которые не относятся к операциям

обработки данных, а обеспечивают доступ к этим переменным. Для каждой

внешней переменной существует пара методов – выборка значения переменной

(get-метод) и присвоение ей нового значения (set-метод).

С обобщающей точки зрения, интерфейс экземпляра компонента состоит из

совокупности методов. Каждый компонент может иметь несколько таких

интерфейсов, которые определяют его функциональные свойства. Кроме того,

компонент может иметь специальный интерфейс, методы которого работают с его

экземплярами (например, компонентная модель EJB языка JAVA имеет интерфейс,

который называется “домашним” интерфейсом (Home-interface) [91].

В состав этих методов, в частности, входят методы поиска экземпляров

компонента, их создание, уничтожение, и т.п. Для каждого компонента могут

существовать несколько методов поиска, создания и т.д. в зависимости от

алгоритма выполнения этой операции и соответствующей сигнатуры. Например,

поиск экземпляра компонента может происходить по его уникальному

идентификатору или значению определенной переменной.

Таким образом, каждый компонент характеризуется

– специальным интерфейсом, методы которого работают с экземплярами

компонента, но не определяют непосредственно функциональные свойства

экземпляров;

– одним или несколькими функциональными интерфейсами, которые

реализуются в экземплярах компонентов и определяют их функциональные

свойства.

Сравнивая этот факт с определением типа или класса и учитывая точку

зрения классической теории делаем вывод, что понятие типизации компонентов не

является определенным и принципиально отличается от аналогичного понятия для

типов данных или классов. Сущность этого понятия лучше исследовать на примере

операции приведения типов.

Для переменной определенного типа данных операцию приведения к другому

126

типу выполняют при условии, что существуют формальные алгоритмы

преобразования множества значений типа и сохраняется семантика

соответствующих операций.

Если существуют два типа: T

= (X



и T

= (X



), то T

тип приводится к

при следующем условии:

→ T

, если F(X

)

– функция преобразования множеств Ω

, Ω

Для экземпляра определенного класса операция приведения к экземпляру

другого класса выполняется успешно, если его совокупность методов и полей

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

абстрактном уровне равные понятия тип и класс используются как синонимы, и

операция приведения для классов имеет семантику, похожую для приведения

типов.

На абстрактном уровне операция приведения экземпляра класса в соответствии

с заданным интерфейсом может рассматриваться как частный вид абстрактного

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

классов. Если выполняется операция приведения экземпляра класса в соответствии с

определенным интерфейсом, то обязательное условие – реализация этим

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

операции приведения для типов и классов – семантически эквивалентны.

Рассмотрим операцию приведения для компонентов. Приведем следующие

выводы относительно программного компонента [64, 65]:

– компонент может иметь несколько интерфейсов;

– реализации одного и того же компонента могут иметь разную структуру и

поведение в разных средах;

– статический аспект проверки типов для компонентов принципиально

невозможен.

Для экземпляров компонентов операция приведения возможна лишь в

соответствии с определенным интерфейсом компонента. С учетом того, что

компонент может иметь несколько интерфейсов, тип экземпляра компонента –

динамическая характеристика, которая определяется во время выполнения

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

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

статически определен описанием своего класса, поэтому всегда имеет конкретный

тип. Согласно определению понятия интерфейса операция приведения всегда

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

проверяется во время компиляции класса. Для ООП всегда выполняются

следующие утверждения:

– любой экземпляр обязательно является экземпляром определенного класса и

обладает всеми методами, заданными в этом классе;

– экземпляр класса может быть приведен в соответствие с одним из

суперклассов или с интерфейсом, который реализуется в этом классе.

Аналогичных утверждений для экземпляров компонентов не существует.

Понятие, которое было бы аналогично понятию класса для экземпляров

компонентов, определить не удается (т.е. все экземпляры класса имеют типичную

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

этому условию). Хотя сами интерфейсы компонента могут иметь родовидовые

отношения с интерфейсами других компонентов, тем не менее, связи “класс–

127

суперкласс” и “наследование для интерфейсов компонентов” принципиально

различаются как сущностью, так и методами реализации.

Аналогично имеется существенное различие на уровне классов компонентов. С

точки зрения типизации, класс – это полностью определенное статические

понятие. Наоборот, выражение “тип компонента” – это неопределенное понятие в

статическом аспекте. Во время функционирования компонентной программы для

компонента может существовать несколько экземпляров разной структуры и

поведения. Поэтому операция приведения компонента с одним из его интерфейсов

в динамическом аспекте также не определена и выполняется только для его

отдельных экземпляров.

5.1.2. КЛАССИФИКАЦИОННЫЕ ПРИЗНАКИ КОМПОНЕНТОВ

Согласно основам теории сущность любой классификации состоит в разбиении

множества из нескольких классов эквивалентности соответственно совокупности

свойств, которые называются классификационными признаками. Классы

эквивалентности не пересекаются, все элементы конкретного класса имеют

соответствующие свойства.

Пусть C – множество элементов и t

, t

,.., t

– совокупность таких признаков,

что для каждого c



C существует только один признак, присущий данному

элементу.

Введем совокупность T

= {t

, t

, … t

}. Тогда на множестве C существует

эквивалентность относительно T

. Элементам каждого из классов эквивалентности

присущ признак t

, объединение C

составляют множество C, т.е. C = C



…



...

Назовем T

классификационной характеристикой, а каждое t

–

классификационным признаком характеристики T

. Пусть T = {T

, T

, …, T

} и

каждое T

– классификационная характеристика. Тогда T определяет

классификационную систему для множества C.

Введем следующие определения.

Множество C – классификационное множество, если для него существует

классификационная система T. Метод классификации для множества C – это способ

построения классификационной системы T при условии выполнения требований к

отношению эквивалентности на этом множестве.

Классификационная характеристика T

является полной для множества C, если

для каждого элемента c



C обязательно существует классификационный признак

из T

Классификационная характеристика T

является частичной для множества C,

если существует C



C и для каждого элемента c



не существует

классификационного признака из T

. Такой случай существует, если

классификационные характеристики зависимы друг от друга. Например,

характеристика T

является полной для множества C, и определяет классы

эквивалентности C

 C

 , …, C

, а характеристика T

– лишь для одного или

нескольких C

Классификационные характеристики T

и T

иерархически упорядочены, если:

– полная характеристика для определенного подмножества C



C (или самой

C); T

– частичная характеристика для C

; T

– полная классификационная

128

характеристика для одного из классов эквивалентности C



Приведем несколько следствий.

1. Для одного и того же множества может существовать несколько систем

классификации.

2. Система классификации – это понятие относительное, т.е. зависит от

первичных, базовых признаков и способов группирования их в классификационные

характеристики.

3. Каждый метод классификации определяется:

– способом группирования первичных признаков в классификационные

характеристики;

– типом классификационных характеристик (полных или частичных);

– иерархическими связями между характеристиками.

Основные задачи классификации. Любая классификация рассматривается при

решении следующих задач.

Во-первых, распределить элементы множества среди подмножеств согласно

определенным знаниям о самом множестве и об отдельных элементах, а также их

взаимосвязях, семантических признаках, и т.п. Решение этой задачи дает

возможность по принадлежности конкретного элемента множества к

определенному классу эквивалентности определить априори совокупность свойств

данного элемента. Если определенный элемент c



, то c имеет признак t

из

классификационной характеристики T

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

согласно условиям, которые связаны с классификационными признаками.

Результат поиска – класс эквивалентности, который отвечает заданным свойствам.

Поиск происходит соответственно заданным классификационным характеристикам

,…, T

и конкретным признакам этих классификационных характеристик.

В целом при классификации компонентов решаются аналогичные задачи.

Особенность состоит в выборе системы классификационных признаков,

характеристик и способов применения знаний о классификации компонентов.

Метод классификации компонентов – это метод классификации, который

обеспечивает определенную систему представления информации и знаний о

программных компонентах в целях быстрого поиска и отбора необходимых

объектов. Основой такой системы является информация, которая сопровождает

компоненты, и правила упорядочения соответственно определенным признакам:

функциональности, системной среде, ресурсам и др. Результат применения метода

классификации ПК – классы эквивалентности, которые определяют совокупности

компонентов с аналогичными свойствами соответственно классификационным

признакам.

Единой системы классификации компонентов на данный момент не существует.

Ее построение основывается на общих знаниях о компонентах и их применении.

Эти знания образуют следующие группы общих свойств компонентов :

– структурные признаки;

– функциональные возможности;

– характеристики поведения.

Детализация этих групп и объединение свойств из разных групп в единую

совокупность компонентов обеспечивает создание целевой системы классификации.

129

5.1.3. КЛАССИФИКАЦИЯ КОМПОНЕНТНЫХ МОДЕЛЕЙ

СОВРЕМЕННЫХ СИСТЕМ

Базис этой классификации – компонентная модель, на ее основе создаются

компоненты и классификационная система с соответствующими классифика-

ционными характеристиками.

Рассмотрим наиболее распространенные в настоящее время практически

применяемые виды компонентных моделей современных систем [40, 166, 176,

209]:

– модель COM в среде ОС Windows, основана на понятии сервера;

– модель DCOM, распределенная COM в сетевой среде Windows;

– компонентная модель .NET в среде .NET, которая является надстройкой к

другим ОС, в частности Windows, Linux;

– много платформенная модель CORBA функционирует в различных средах

ОС;

– компонентная модель EJB платформы JAVA, функционирует на любой ОС,

для которой реализована виртуальная JAVA-машина.

С формальной точки зрения классификационная характеристика для множества

компонентов (Comp) имеет такой вид:

= {COM, DCOM, .NET, CORBA, EJB}. (5.3)

Классы эквивалентности – это совокупности компонентов, которые созданы в

рамках конкретной компонентной модели. Метод классификации – тривиальный

(группировка всех признаков в единую характеристику).

Если есть компонент, который согласно приведенной классификации построен

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

именно:

– ОС, на которых компонент может функционировать;

– особенности построения компонента;

– методы развертывания компонентов;

– особенности взаимодействия с другими компонентами и др.

Данная классификация наиболее распространена и имеет высокий уровень

обобщения. Каждый из соответствующих классов эквивалентности может быть

разделен на более детализированные совокупности. Например, на основе более

глубокого анализа модели COM и ее свойств [209] существует следующая более

детальная классификация.

Классификация COM-компонентов сервера автоматизации. Учитывая

общую классификацию компонентов, для сервера выделяем классы:

– полные серверы (самостоятельные, завершенные приложения с

возможностями встраивания компонента в другие приложения, т.е. они могут

использоваться, как готовые при построении компонентных систем более высокого

уровня структурирования);

– обычные серверы автоматизации (а также завершенные приложения, не

имеющие возможности встраивания в другие приложения);

– мини-серверы (дополнительные компоненты, которые не имеют признаков

самостоятельного функционирования в компонентной среде, могут применяться

лишь в операционном контексте клиентского компонента);

130

– компоненты Active X (разновидность мини-серверов, которые подаются как

самостоятельные библиотеки, с возможностью передаться в сеть, например, для

функционирования в среде Интернет–браузера);

– серверы процессов (как фоновые задачи в ОС, постоянно функционируют и в

общем случае могут не иметь связей с конечным пользователем).

Такая классификация – это ее расширение с учетом предыдущего примера, т.е.

для классификационной характеристики T

уже определены классы

эквивалентности и для одного из классов, который имеет признак COM, вводится

новая классификационная характеристика T

. Она является частичной

характеристикой для всего множества компонентов Comp и полной для множества

COM-компонентов. Классификационные характеристики T

и T

иерархически

упорядочены.

Рассмотрим классификационные признаки для T

. Анализ приведенной выше

последовательности классов классификации показывает, что существует несколько

характеристик, на основе которых построены соответствующие классы, а именно,

– уровень завершенности приложения;

– возможности встраивания в компоненты более высокого уровня

структурированности;

– типы и виды среды функционирования;

– наличие связей с интерфейсом конечного пользователя.

Например, можно сформировать классификационную систему на основе всех

четырех классификационных характеристиках. Однако для такой системы

множество классов эквивалентности не имеют смысла или практически

бесполезны. Таким образом, процесс есть самостоятельной фоновой задачей в ОС и

поэтому нецелесообразно его рассматривать с точки зрения возможности

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

Учитывая, что практически полезными является лишь пять классов компонентов,

одним из решений может быть непосредственное формирование единой

характеристики, которая имеет пять признаков (каждый для соответствующего

класса). При таком подходе существует вероятность потери информации, и, тем не

менее, количество классов эквивалентности для классификационной системы

значительно уменьшится. В этом случае имеем

= {полный сервер, обычный сервер автоматизации

мини-сервер, компонент Active X, сервер процесса}.

Выбор конкретного решения (расширенная или упрощенная система

классификации) зависит от целевого назначения самой классификации как

инструмента для практического применения.

Как и в предыдущем примере, если отнести конкретный COM компонент к

определенному классу классификации, то можно получить информацию о его

структуре, представлении, методах применения и др.

Классификация компонентов корпоративных приложений. Каждый из

этих типов (веб-приложение, корпоративное приложение и др.) имеют типовую

архитектуру. Реализация компонентной программы согласно выбранной

архитектуре предусматривает распределение компонентов по уровням архитектуры

с учетом необходимых архитектурных свойств.

Основа построения классификации по заданным признакам – архитектурная

модель, которая состоит из четырех уровней, каждый из которых делится на