14) Особенности применения базовых классов.

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

Интерфейс – это спецификация класса методы которого не хранят никакого кода. Другими словами, в классе определены сигнатуры всех методов, но нет их реализации. Предоставить осуществление каждого метода входить в обязанности класса, реализующего интерфейс. Такой класс может содержать методы или атрибуты. Обычно интерфейс проектируется для того, чтобы придать классу дополнительную функциональность. Если бы иерархию рис 4.3 нужно было бы использовать в среде, не поддерживающей множественное наследование (Java), то класс «пара ботинок» мог бы наследовать классу «ботинки» и реализовывать интерфейс «предмет проката». В этом случае класс «пара ботинок» имел бы атрибуты, описывающие прокат инвентаря. А также методы, необходимые для выдачи. Например, вычисление арендной платы и времени возврата арендованного инвентаря. Т.о. любой класс, представляющий собой инвентарь, должен был бы реализовывать этот интерфейс, описав тем самым поведение, которым должен обладать сдаваемый напрокат объект. В общем случае методы наследуются подклассами от своих суперклассов. Подкласс может применять как методы базового класса, так и свои собственные. Однако иногда невозможно написать метод, достаточно общий для всех подклассов. Предположим, что класс инвентарь имеет метод Print catalog entry. Этот метод предназначен для красивой печати каталогов описания одного вида товаров. Подкласс класса инвентарь имеет атрибуты отсутствующих других подклассов. Поэтому метод Print catalog entry по разному реализуется в каждом подклассе. Решение этой проблемы лежит в преимуществе, которое даёт полиморфизм, а именно возможность иметь разные тела у методов с одним и тем же именем и принадлежащим разным классам в одной иерархии массивов. Класс инвентарь включает в себя прототип метода Print catalog entry, который только описывает его открытый интерфейс.

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

15) Виды и принципы отладки программных средств.

Отладка ПС – это деятельность по обнаружению и исправлению ошибок с использованием процессов выполняемых программ в ПС. Тестирование ПС – это процесс выполнения его программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ. Этот набор программ называется тестовым или просто тестом.

Отладка=Тестирование (для логических ошибок)+Поиск ошибок (реализуется при компиляции)+Редактирование.

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

1. Необходимо подготовить такой набор тестов, чтобы обнаружить в ПС как можно больше ошибок.

2. Определить момент окончания отладки ПС или отдельно его компонент.

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

При этом в первом случае эта стратегия базируется на принципах:

- на каждую исп. функцию (процедуру или возможность) иметь хотя бы 1 тест.

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

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

Во втором случае на первом принципе:

- каждая команда каждой программы ПС должна проработать хотя бы на 1 тесте.

В нашей стране различают два вида отладки ПС:

- автономная (последовательное раздельное тестирование различных частей программ с поиском и исправлением фиксируемых в нем при тестировании ошибок. 2 функции – контроль ошибок и диагностика.

- комплексная (тестирование ПС в целом с поиском исправления всех ошибок во всех документах).

Отметим следующий феномен: по мере роста числа обнаруженных или исправленных ошибок в ПС растёт также относительная вероятность существования в нем необнаруженных ошибок. Существуют следующие основные принципы отладки ПС:

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

2. Хорош тот тест, для которого имеется высокая вероятность обнаружить ошибку, а не тот, который демонстрирует правильную работу программы. Готовые тесты как для правильных, так и для неправильных данных.

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

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

5. Пропускайте заново все тесты, связанные с проверкой работы какой-либо программы или её взаимодействие, интеграцию с другими программами. если в программу были внесены изменения, например в результате изменения ошибок.

16 ) Автономная отладка ПС.

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

Модуль основной – Ведущая---Ведомая-Программа тестирования.

Ведущий модуль – это драйвер. Ведущий отладочный модуль подготавливает информационную среду для тестирования отлаживаемого модуля. (осуществляет обращение к этому отлаживаемому модулю и сможет выдавать необходимые сообщения.

Восходящее тестирование.

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

Такая стратегия тестирования называется смешанной.

Достоинства восходящего тестирования:

1. Простота подготовки тестов;

2. Возможность полной реализации плана тестирования модуля;

Недостатки :

1. Текстовые данные готовятся без расчета на пользователя или без учёта пользователя.

2. Большой объём отладки программирования.

3. Необходимость специального тестирования с сопряжением модуля.

Достоинства нисходящего программирования:

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

2. Во многих случаях относительно небольшой объём отладочного программирования.

3. Отпадает необходимость тестирования с сопряжением модуля.

Недостатки:

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

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

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

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

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

17 )Комплексная отладка. Организация тестирования в ОО системах.

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

Тестирование архитектуры ПС. Целью тестирования является поиск несоответствия между описанием архитектуры и совокупностью ПС. К моменту начала такого тестирования должна быть уже закончена автономная отладка каждой подсистемы.

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

Тестирование качества ПС. Целью тестирования является поиск нарушений требований качества, сформулированных в спецификации качества ПС. Это тестирование завершает тестирование внешних функций.

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

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

Комплексная отладка: тестирование архитектуры ПС, внешних функций, качества, документации ПС, требований ПС.

Тестирование ОО систем является достаточно независимым процессом, который имеет свои особенности. Традиционно такое тестирование делится на тестирование элементов, интеграционное тестирование и системное. Эа уровне элементов тестирования учитываются сл. показатели: определение единиц тестирования (класс), наследование, полиморфизм.

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

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

Интнграционное тестирование представляет собой тестирование того, как отдельные элементы программы работают вместе. Свойства ОО языков исключает целый ряд возможных ошибок. И прежде всего за счёт строгого определения внешних интерфейсов классов и объектов. Но это не означает, что интеграционное тестирование от этого становится легче, поэтому существуют специальные методы планирования для интеграционного тестирования. При традиционном тестировании имеется такая характеристика, как степень покрытия кода. При тестировании по принципу открытого или белого ящика необходимо обеспечить прохождение теста по всем ответвлениям программы, т.е. требуется выполнить как можно более инструкций, имеющихся в программе. Наряду с этой характеристикой для ОО программ применяют характеристику «покрытия состояний». Известно, что объект соединяет в себе состояние и поведение, поэтому необходимо проверять все возможные переходы из одного состояния в другое. Планирование таких тестов выполняется с помощью специальных моделей состояний класса, постр. на этапе анализа и проектирования.

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